Project

General

Profile

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..._