Development Milestones » History » Version 5
Alexander Kamkin, 04/02/2014 10:33 AM
1 | 1 | Alexander Kamkin | h1. Development Milestones |
---|---|---|---|
2 | |||
3 | 2 | Alexander Kamkin | h2. Version 2 (deadline: 31/08/2014) |
4 | 1 | Alexander Kamkin | |
5 | 2 | Alexander Kamkin | 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. |
6 | 1 | Alexander Kamkin | |
7 | 5 | Alexander Kamkin | | *Version 2.0* | *30/04/2014* | test situations, exceptions, initialization code, branching instructions | |
8 | 3 | Alexander Kamkin | |
9 | 2 | Alexander Kamkin | * _Test Situations_ |
10 | ** Manual description of test situations in Java and XML should be supported |
||
11 | ** Test situations should be accessible from test templates (corresponding solvers should be invoked, and generated data should be substituted into the test program) |
||
12 | ** Each instruction should have a top-level test situation (by default, the top-level situation is @Random@) |
||
13 | ** There should be a configuration file assigning top-level test situations to instructions (@Random@, @Zero@, etc.) |
||
14 | * _Initialization Code_ |
||
15 | ** Manual specification of initialization code (for each access mode) should be supported |
||
16 | ** Automated extraction of initialization code (for each access mode) should be implemented |
||
17 | * _Exceptions_ |
||
18 | ** Mechanism for specifying exceptions should be clarified (probably, a predefined function, like @RaiseException@, should be introduced) |
||
19 | ** Means for describing exception handling logic should be added |
||
20 | * _Branch Instructions_ |
||
21 | ** Facilities for defining/using labels in test templates should be revisited |
||
22 | ** Combinatorial test program generation based on test templates with branch instructions should be implemented |
||
23 | 4 | Alexander Kamkin | * _Examples_ |
24 | ** A test template with branch instructions (combinatorial generation) |
||
25 | 1 | Alexander Kamkin | * _Documentation_ |
26 | 2 | Alexander Kamkin | ** All new facilities should be documented |
27 | |||
28 | 5 | Alexander Kamkin | | *Version 2.1* | *31/05/2014* | VLIW, aliases, self-checking test programs | |
29 | 3 | Alexander Kamkin | |
30 | * _Specification_ |
||
31 | ** Auxiliary nML constructs, like @alias@, should be enabled |
||
32 | ** Mechanisms for calling operations in operations should be implemented |
||
33 | ** Means for specifying VLIW architectures (e.g., Elbrus) should be added |
||
34 | * _Testing_ |
||
35 | ** Mechanisms for calling test templates in test templates should be implemented |
||
36 | ** Generation of self-checking test programs should be supported |
||
37 | 1 | Alexander Kamkin | ** Means for writting test templates for VLIW architectures should be added |
38 | * _Examples_ |
||
39 | 4 | Alexander Kamkin | ** A fragment of the Elbrus architecture should specified |
40 | 3 | Alexander Kamkin | ** Some test templates for the Elbrus architecture should be written |
41 | * _Documentation_ |
||
42 | ** All new facilities should be documented |
||
43 | 1 | Alexander Kamkin | |
44 | 5 | Alexander Kamkin | | *Version 2.2* | *30/06/2014* | test situation composition/decomposition/iteration, test coverage extraction | |
45 | 1 | Alexander Kamkin | |
46 | 4 | Alexander Kamkin | * _Test Situation Composition_ |
47 | ** Disjunctive composition of test situations should be supported (random choice of a test situation based on biases) |
||
48 | ** Conjunctive composition of test situations should be supported (there should possibility to specify hard and soft constraints) |
||
49 | * _Test Situation Decomposition_ |
||
50 | ** Means for splitting test situations into disjunctions of implicants should be implemented (BDD-based and other test generation algorithms can be applied): @rule(situation)@ |
||
51 | ** The set of decomposition rules should be extensible |
||
52 | * _Test Situation Iteration_ |
||
53 | ** Means for iterating test situations should be implemented: @iterate(disjuntive_situation)@, @iterator(rule(situation))@ or @iterate(situation1, situation2, ...)@ |
||
54 | * _Test Coverage Extraction_ |
||
55 | 1 | Alexander Kamkin | ** For each instruction and for each path in its CFG, the corresponding test situation should be constructed |
56 | 4 | Alexander Kamkin | ** For each instruction, the top-level test situation should be constructed as the disjunctive composition of the extracted test situations |
57 | * _Examples_ |
||
58 | ** A test situation composition example should be added |
||
59 | ** A test situation decomposition example should be added |
||
60 | ** A test situation iteration example should be added |
||
61 | * _Documentation_ |
||
62 | ** All new facilities should be documented |
||
63 | 1 | Alexander Kamkin | |
64 | 5 | Alexander Kamkin | | *Version 2.3* | *31/08/2014* | TestBase, Eclipse, tracing | |
65 | 1 | Alexander Kamkin | |
66 | 4 | Alexander Kamkin | * _TestBase Project_ |
67 | ** Functions for structuring/composing/decomposing/... test situations should be separated into the TestBase project |
||
68 | ** Additional test generation facilities should be implemented |
||
69 | 1 | Alexander Kamkin | * _MicroTESK IDE_ |
70 | 4 | Alexander Kamkin | ** An Eclipse plugin should be implemented (including an nML editor, instructions/situations viewers, test template wizards, compiler/generator launchers, etc.) |
71 | * _Tracing_ |
||
72 | ** A trace format should be developed |
||
73 | 1 | Alexander Kamkin | ** Trace utilities should be implemented and integrated into the test program generator |
74 | 4 | Alexander Kamkin | * _Documentation_ |
75 | ** All new facilities should be documented |
||
76 | * _Promotion_ |
||
77 | 1 | Alexander Kamkin | ** The miniMIPS microprocessor should be specified |
78 | 4 | Alexander Kamkin | ** Test templates for the miniMIPS microprocessor should be written |
79 | ** The test program generator should be added into the miniMIPS project at OpenCores |
||
80 | |||
81 | 5 | Alexander Kamkin | h2. Version 3 (Deadline: 31/08/2015) |
82 | 2 | Alexander Kamkin | |
83 | 4 | Alexander Kamkin | MicroTESK v3 should support microarchitectural specifications and automated test template generation. The tool should be extended to complex multicore microprocessors with cache coherence support. |
84 | 2 | Alexander Kamkin | |
85 | 5 | Alexander Kamkin | | *Version 3.0* | *31/12/2014* | memory management, caching, address translation | |
86 | 4 | Alexander Kamkin | |
87 | * _Microarchitectural Specifications_ |
||
88 | ** Specification of memory management units should supported |
||
89 | 2 | Alexander Kamkin | |
90 | 5 | Alexander Kamkin | | *Version 3.1* | *31/05/2015* | pipelining, microarchitectural networks | |
91 | 4 | Alexander Kamkin | |
92 | * _Internal Representation_ |
||
93 | 2 | Alexander Kamkin | ** Internal representation should be unified with the Retrascope''s one |
94 | |||
95 | 5 | Alexander Kamkin | | *Version 3.2* | *31/08/2015* | multicore microprocessors, Promela, cache coherence | |
96 | 4 | Alexander Kamkin | |
97 | * _Multicore Microprocessors_ |
||
98 | ** Integration with Promela specifications should be implemented |
||
99 | |||
100 | _To be continued..._ |