Development Milestones¶
Version 2 (deadline: 31/08/2014)¶
MicroTESK v2 should fully support instruction set specifications and random/combinatorial template-based test program generation. This is the minimal functionality that makes the MicroTESK tool useful.
Version 2.0 |
30/04/2014 |
Features: nML-based instruction set specification, test situations, exceptions, initialization code, branching instructions |
- Test Situations
- Manual description of test situations in Java and XML should be supported
- Test situations should be accessible from test templates (corresponding solvers should be invoked, and generated data should be substituted into the test program)
- Each instruction should have a top-level test situation (by default, the top-level situation is
Random
)
- There should be a configuration file assigning top-level test situations to instructions (
Random
, Zero
, etc.)
- Initialization Code
- Manual specification of initialization code (for each access mode) should be supported
- Automated extraction of initialization code (for each access mode) should be implemented
- Exceptions
- Mechanism for specifying exceptions should be clarified (probably, a predefined function, like
RaiseException
, should be introduced)
- Means for describing exception handling logic should be added
- Branch Instructions
- Facilities for defining/using labels in test templates should be revisited
- Combinatorial test program generation based on test templates with branch instructions should be implemented
- Examples
- A test template with branch instructions (combinatorial generation)
- Documentation
- All new facilities should be documented
Version 2.1 |
31/05/2014 |
Features: VLIW specification and testing, floating-point arithmetic, register aliases, self-checking test program generation |
- Specification
- Means for specifying VLIW architectures (e.g., Elbrus) should be added
- Floating-point arithmetic should be supported
- Auxiliary nML constructs, like
alias
, should be enabled
- Mechanisms for calling operations in operations should be implemented
- Testing
- Mechanisms for calling test templates in test templates should be implemented
- Generation of self-checking test programs should be supported
- Means for writting test templates for VLIW architectures should be added
- Examples
- A fragment of the Elbrus architecture should specified
- Some test templates for the Elbrus architecture should be written
- Documentation
- All new facilities should be documented
Version 2.2 |
30/06/2014 |
Features: test situation composition/decomposition/iteration, test coverage extraction, constrained-random test data generation |
- Test Situation Composition
- Disjunctive composition of test situations should be supported (random choice of a test situation based on biases)
- Conjunctive composition of test situations should be supported (there should possibility to specify hard and soft constraints)
- Test Situation Decomposition
- Means for splitting test situations into disjunctions of implicants should be implemented (BDD-based and other test generation algorithms can be applied):
rule(situation)
- The set of decomposition rules should be extensible
- Test Situation Iteration
- Means for iterating test situations should be implemented:
iterate(disjuntive_situation)
, iterator(rule(situation))
or iterate(situation1, situation2, ...)
- Test Coverage Extraction
- For each instruction and for each path in its CFG, the corresponding test situation should be constructed
- For each instruction, the top-level test situation should be constructed as the disjunctive composition of the extracted test situations
- Examples
- A test situation composition example should be added
- A test situation decomposition example should be added
- A test situation iteration example should be added
- Documentation
- All new facilities should be documented
Version 2.3 |
31/08/2014 |
Features: integration with TestBase, Eclipse-based development environment, test program tracing |
- TestBase Project
- Functions for structuring/composing/decomposing/... test situations should be separated into the TestBase project
- Additional test generation facilities should be implemented
- MicroTESK IDE
- An Eclipse plugin should be implemented (including an nML editor, instructions/situations viewers, test template wizards, compiler/generator launchers, etc.)
- Tracing
- A trace format should be developed
- Trace utilities should be implemented and integrated into the test program generator
- Documentation
- All new facilities should be documented
- Promotion
- The miniMIPS microprocessor should be specified
- Test templates for the miniMIPS microprocessor should be written
- The test program generator should be added into the miniMIPS project at OpenCores
Version 3 (Deadline: 31/08/2015)¶
MicroTESK v3 should support microarchitectural specifications and automated test template generation. The tool should be extended to complex multicore microprocessors with cache coherence support.
Version 3.0 |
31/12/2014 |
Features: memory management, caching, address translation |
- Microarchitectural Specifications
- Specification of memory management units should supported
Version 3.1 |
31/05/2015 |
Features: pipelining, microarchitectural networks |
- Internal Representation
- Internal representation should be unified with the Retrascope's one
Version 3.2 |
31/08/2015 |
Features: multicore microprocessors, Promela, cache coherence |
- Multicore Microprocessors
- Integration with Promela specifications should be implemented
To be continued...