Lecture Notes in Computer Science 3472

15 Case Studies 443
Different studies in model-based testing of hardware systems use hardware
specifications at different levels of abstraction as the basis for modeling the
SUT. In [DBG01] for example, the SUT was the Store Data Unit (SDU) block
of ST100, a high performance digital signal processor (DSP). The SDU is a block
of the Data Memory Controller that is responsible of storing data to memory.
In this study, the design was described at behavior abstraction level in MµALT
(Modeling Micro-architecture Language for Traversal), which is a VHDL-based
language.
In [SA99], the SUTs were two general-purpose microprocessors. The first is
GL85, which is a model of the Intel 8085 processor, designed in VHDL. The second
is ARM, which is a downscaled model of the commercial ARM-2 processor.
ARM is designed in Verilog. In both cases, the SUT was described at the RTL
level.
What is common in these studies is that a full formal description of the
SUT is available at one level or another. This opens the door to introduce some
automation during model abstraction via a tool that can take the formal description
as input and partially infer a state machine from it. This idea was
implemented only in [SA99].
In [FKL99], an Architecture Validation Suite (AVS), which is a suite of tests
to verify the compliancy of an architecture implementation against the architecture
specifications, was built for IBM PowerPC processor architecture. Like
the cases above [SA99, DBG01], a formal description of PowerPC architecture
was built. But additionally, a behavioral simulator that implements PowerPC
architecture was used as a reference model. The simulator is a software that
simulates a PowerPC processor. So, given a certain state for the processor and
an input, the simulator determines the next state and the output. The basic
idea of using the simulator is that a behavioral simulator can be viewed as a
formal, correct and complete representation of the architecture. This is because
very early in the verification phase, the simulator was used heavily, debugged
and tested. Hence, generating an AVS for the SUT can be reduced to generating
an AVS for the simulator.
Protocols A protocol is a formal description of the message formats and the rules
that two devices or parties must follow to exchange those messages. A number
of case studies were done for automatic generation of test suites for protocols.
In [KVZ98], the SUT was an implementation of the cache coherency protocol of
Bull’s CC-NUMA (Cache-Coherent Non Uniform Memory Architecture) multiprocessor
architecture. Bull’s CC-NUMA consists of a scalable interconnection
of modules; the memory is distributed among different modules. Each module
contains a set of processors. The key feature of Bull’s CC-NUMA architecture is
its distributed directory-based cache coherency protocol, which uses a Presence
Cache and a Remote Cache in each module.
In [BFdV + 99], the SUT was an implementation of the Conference Protocol
described in [Pir95]. The conference provides a multicast service, resembling a
chat box, to the users participating in a conference. A conference is a group of
users that can exchange messages with all conference partners in that conference.