Lecture Notes in Computer Science 3472

446 Wolfgang Prenninger, Mohammad El-Ramly, and Marc Horstmann
The control flow graph is searched for the transition conditions between the different
states of each selected variable.
The abstract FSM has the same timing as the original processor. It encapsulates
the same control behavior in terms of the movement of instructions through
the processor. In complex designs, the control might consist of multiple communicating
FSMs. In this case, the FSM that changes most frequently, its states are
chosen as the primary control states. For example if the cycle of an FSM needs
5 cycles of another FSM, then the control states of the later are chosen as the
primary control states. Other variables or inputs, which affect the control state
transition or the datapath operation at different states of the FSM, are selected
and added to the FSM manually.
In [FKL99], an Architecture Validation Suite (AVS) was generated for IBM
PowerPC architecture using Genesys. Genesys is a directed-random test generator
developed by IBM for verification of various processor architectures. Genesys
dynamically generates tests using a generation-simulation cycle for each instruction.
Genesys needs two models of the SUT. The first is a formal test model
of the SUT. This is created manually from PowerPC architecture books. The
second is an implementation description in the form of a behavioral simulator
for the SUT, which is used to predict the results of instruction execution. Result
prediction is done automatically by just running the simulator to execute the
desired instruction sequence. However, the simulator itself was built manually.
Modeling from Natural Language Specifications In cases where the SUT was specified
in natural language with no formal specifications, hand-built test models
needed to be constructed. In [FHP02], this was done for parts of POSIX standard
and Java exception handling facility. In both cases, the model was crafted
as an FSM in GDL. At this stage, specification defects and inconsistencies were
discovered.
In [CJRZ01], the test model was a hand crafted FSM for the part of CEPS
that was tested, using IOSTS (Input-Output Symbolic Transition Systems).
IOSTS is a modeling language for reactive programs with symbolic processing
of variables, parameters and inter-process value passing. IOSTS is rather low
level. So, using a higher level language that translates to IOSTS would ease the
modeling process.
In [BFdV + 99], the SUT is an implementation of the Conference Protocol
described in Sec. 15.3. The purpose of this study was to study the feasibility of
automatic test derivation and execution from a number of formal specifications
and different test execution approaches. Test generation was done with TorX, a
generic model-based testing environment. TorX allows plugging in different test
generation tools, which accept models of the SUT in different formal languages
(cf. Sec. 14.2.11). Since this is a benchmarking experiment, three formal models
of the same SUT were built for this study in LOTOS , SDL and PROMELA, each
to use with a different test tool. More details of this experiment were introduced
in Sec. 14.3.2.
In [PPS + 03], the modeling language of AutoFocus was used to build a test
model for the WAP Identity Module (WIM). AutoFocus is a tool for develop-