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