Hardware \in the Loop" Simulation with COSSAP: Closing the ... - ICE

Hardware \in the Loop" Simulation with COSSAP:
Closing the Verication Gap
Olaf J. Joeressen and Heinrich Meyr
Aachen Univ. of Technology (RWTH), Integrated Systems for Signal Processing
ISS-611810, Templergraben 55, 52056 Aachen, Germany
Phone: +49-241-807632, email: joeresse@ert.rwth-aachen.de
Abstract: The paper describes the integration of an experimental
test system for digital signal processing hardware
into a data ow driven system simulation environment.
The integration enables running simulations with
actual hardware components \in the loop" (hardware modeling).
The implications of data ow driven simulation to
hardware modeling are discussed ascompared tohardware
modeling in conjunction with event driven simulation. The
experimental setup is described and results for the achieved
simlation speedup are given.
1 Introduction
The integration of telecommunication systems on silicon
is currently facing major challenges due to the fast progress
in technology. Today, managing design complexityhasbecome
the limiting factor rather than circuit technology.
Thus advanced design methodologies have become a prerequisite
to be capable of designing VLSI systems which
make ecient use of the technological opportunities. As
one consequence, the development of heterogeneous simulation
environments (which enable eg mixed mode simulation)
has recently attracted increased attention [1] { [4].
The motivation for this is that heterogeneous simulation
allows to model each part of the system under development
in dierent modeling paradigms whichallows to exploit the
respective advantages [1,5] of the paradigms. In particular
one can change the modeling paradigm for parts of the
system, eg to rene the model, while maintaining the high
level simulation setup as verication environment. This
prevents modeling large parts of a system more than once
for verication purposes which potentially speeds up model
development aswell as simulation runs and thus shortens
development cycles.
As a facet of heterogeneous simulations we discuss in this
paper simulations which employ actual hardware components
as their own simulation models. In the sequel the resulting
simulation is called hardware in the loop simulation
and the modeling technique hardware modeling. Hardware
modeling was introduced by Widdoes in 1984 [6] buthas
since that time exclusively been discussed in conjunction
with event driven simulation. In contrast to this approach,
hardware modeling is discussed in this paper in conjunction
with data ow driven simulation since performance
verication of todays communication systems requires extremely
runtime ecient simulation. Experiments have
proven that data ow simulation provides speedups in excess
of one order of magnitude as compared to event driven
simulaton which is predominantly used on lower levels
of abstraction [1,5]. The conjunction of runtime ecient
simulation paradigm and block diagram oriented user interface
can be considered to be the well accepted standard
for high level communication system design [7]. The potential
advantages of hardware modeling in conjunction
with data ow simulation, eg higher modeling and simulation
eciency, have tothebestofourknowledge not been
investigated before.
There are several advantages resulting from the use of
digital signal processing hardware whose input is computed
by asimulation program running on a workstation and
whose output is read in by the same program:
Authenticity: The piece of hardware is the same as in the
target system. This guarantees perfect authenticity
of the simulation results as far as the included piece
of hardware is concerned.
Modeling: In case hardware components are purchased
from external suppliers, system development ispossible
even with the basic black-box knowledge about
these components since this information is sucient
for hardware modeling. This may save a great amount
of time during system development.
WellDenedVerication Environment: Hardware
components can be veried against the specication
inawell dened environment. The data fed to the
hardware board can either be straightforward for debugging
purposes or very complex resulting from a
comprehensive system model implemented in the simulation
system. Contrary to eld tests in noisy
surroundings the verication stimuli can be reproduced
exactly and thus allows to compare simulation
results for dierent solutions.
Simulation Speed-Up: In many cases, the time consumed
when simulating the system by using components
of the real hardware will be less as compared
to a simulation performed completely on the host
computer.
The paper describes the integration of an experimental
test system for digital signal processing hardware into
the data ow driven system simulation environment COS-
SAP [8], which in turn enables hardware modeling. The

implications and restrictions of data ow driven simulations
in conjunction with hardware modeling are discussed.
The advantages are claried as compared to hardware
modeling in conjunction with event driven simulaton,
which is already supported by commercially available
products [9,10].
S
Clock
Event
Time
2 Hardware Modeling and Data Flow Simulation
We will briey introduce the concept of a signal in a
data ow driven simulation in this section to prepare the
ground for a clear discussion of advantages and limitations
of hardware modeling in the context of a data ow driven
simulation.
2.1 Signal Paradigms
Hardware modeling requires the generation of all physical
signals that are required to run the hardware controlled
by the simulation. Thus the clear understanding of the
meaning of a signal in the simulation (the signal paradigm)
is a prerequisite for the integration of hardware in the loop.
A signal paradigm denes
the relation of the value of a signal to the ongoing
(virtual) simulation time.
at which time a simulation model is red to compute
new values of its output signals (module scheduling).
Dierent signal paradigms reect dierent levels of abstraction
of a physical signal which exhibit a value at every
point of time and is thus not generally representable in a
digital computer. In digital system design two important
paradigms are the event driven [11] and data ow driven
signal paradigms [12,1]. Table 1 lists the basic properties
of these signal paradigms.
Tab. 1: Signal Paradigms
signal signal/time scheduling used
paradigm relation scheme in
event value & time change of an VHDL
driven of change input signal etc.
data ow only sequence all necessary input COSSAP
driven of values samples available etc.
Event driven simulations are based on the idea that
a signal can be described by a sequence of events which
describe a signal change. The event isthus characterized
bythenewvalue of the related signal and the time at which
the change occurs. A model needs to be red only when an
input signal is changed by suchanevent. The red model
then computes the new values of its output signals. The
associated events are inserted into an event table which is
managed by the kernel of the simulator.
Event driven simulations allow tosimulate circuit behavior
precise enough for chip sign o, including eg analysis
of setup and hold times. On the other hand the nature
of the paradigm requires that all control signals like clock
Time
Fig. 1: Event driven signal representation
and reset in synchronous designs are explicit since only
the association of clock edges and signal values allow to
determine what the meaningful data with respect to the
implemented chip function is (see Figure 1).
Data ow simulations, in contrast, do not keep track
of the time. Signal are represented merely by sequences
of values. The sequence does not even necessarily have an
interpretation on the time axis. The values may equally
well describe for example signals in the frequency domain
or asynchronous signals [13]. The models are executed
if all required input values for executing the model are
present in the input signal buers. The model then computes
output values based on its inputs and places them
in output buers. The simulator consequently does not
handle time. The number of items in signal buers and
the information about the required number of input values
to execute a model is sucient to execute the simulation.
This completely dierent signal paradigm leads to signicant
simulation speedups and provides increased modeling
exibility.
S
Fig. 2: Data ow signal representation
n
Sequence of values
No Time !
In contrast to event driven simulation control signals are
not required to model systems in a data owdriven simulation
since the sequence of values is sucient todrivemost
algorithms in digital signal processing. However, whenever
interfacing to real world signals is required an interpretation
over time must be added to the data ow signals.
Furthermore, data ow signals are always generated at a
single source and thus represent unidirectional data ow.
This leads to problems if bidirectional signals or busses are
to be interfaced and would required to represent a bidirectional
signal by three data ow signals (in, out, direction).
We do not discuss interfacing to bidirectional signals in
this report.
2.2 Interfacing to Physical Signals
Physical signals are obviously not directly interfaceable
to a data ow signal since they continuously exhibit a value

at each time instant. Consequently sampling of these signals
is required to interface to the simulation. This poses
the problem of dening or determining what the meaningful
sampling time instants are.
In the case of an analog hardware this leads immediately
to real time requirements, appropriate ltering of the
input data, analog to digital and digital to analog conversion.
Furthermore buering of the digital input and
output signals in FIFOs is required to maintain for example
an equidistant sampling since the simulation program
will usually not be able to consume and produce the data
at absolute time instants.
Digital hardware usually either runs at a xed clock rate
which in turn denes at what time meaningful signal values
at the ports are present or establishes explicit handshaking
schemes. Asynchronous interface schemes may require the
data to be set up in frames with clearly dened timing of
the data items. However, this timing scheme is usually
dened relative toasystemclock. Consequently, most
interface schemes can be handled without absolute signal
timing at the interfaces provided that clock and control
signals are under the control of the simulation program.
Exceptions are all systems which have internal clock
sources, completely asynchronous components or systems
which contain dynamic storage which loose their content
if the operating speed is below a certain limit. Such devices
can be handled either if realtime constraints are met
as discussed above orby means of running an appropriate
stimuli history every time a new output value is to be determined
[14]. As a advantage of the latter case multiple
instances of the device in a simulation can be handled if
the stimuli history is stored for each instance. Clearly,supporting
dynamic components and multiple instances leads
to very complex interfaces with high speed memory, programmable
clock sources etc. . However, an important
disadvantage of the approach is that the length of the stimuli
history is naturally limited which was not acceptable
in our case since we wanted to run very long performance
simulations.
2.3 Interface Model Requirements
It is of course desirable to provide a hardware model at
the system level to the design engineer which resembles
the hardware in a form that allows easy integration into
the system simulation setup. At best, the model interface
would resemble that of a standard simulation model of
similar functionality.
A primitive model 1 in COSSAP is a model written in a
programming language likeCwhich communicates via well
dened interface functions to other models. There are no
restrictions on what a primitive model may compute. Consequently,
the natural way tointegrate a facility for hardware
modeling in COSSAP is via a primitive model which
is tailored to steer a specic hardware interface, this model
is called the interface model in the sequel. The hardware
interface should be as versatile as possible and capable of
steering various hardware components. We consider the
1 The other kind of models which can be specied are the so called
hierarchical models which themself maycontain other hierarchical
models and primitive models. These modeling styles are in other contexts
usually denoted as behavioral and structural model respectively.
hardware interface for the discussion of the interface model
to be a simple parallel interface with N pins. Each
pin of the interface can be programmed as input or output
signal.
An obvious modeling possibility for the interface model
is of course a model with N inputs and outputs and
appropriate interface direction parameters. However, such
amodulewould be very cumbersome to use since explicit
mapping of data ow values to single interface bits would
be required. This would require the use of additional models
and would probably result in complex hierarchical models.
In order to be easy and convenient to use, the interface
model should comprise the following functionality :
Universality: The interface model should be parameterizable
to serve arbitrary hardware hooked on the
hardware interface.
Initialization: The interface model should provide a possibility
to initialize the hardware and the hardware
interface, since explicit signal generation for initialization
in the simulation setup can be very awkward.
Signal Hiding: The interface model should be capable of
applying simple clock systems, and constant signal
values to the hardware without requiring equivalent
data ow signals, since these signals are often not
required for the remaining simulation.
Signal Mapping: The interface model should interface
directly to data ow signals, and perform a mapping
of these signals to the wires of the hardware interface.
This is referred to as signal mapping in the sequel and
avoids to explicitly map a bit interpretation of a data
ow signal to single bits at the hardware interface by
means of other primitive models.
Generating clock signals of course implies that the hardware
hooked upon the hardware interface is clocked synchronous
hardware with static storage elements, but a
capability to hide any type of hardware control signals
would be very dicult to implement and the general specication
of such control signals is as well dicult.
To be able to perform a correct signal mapping, an interpretation
of numeric data ow signals in terms of an equivalent
bit vector representation must be specied. This
may comprise simple mappings of the internal representation
of the host computer to bits at the hardware interface
(which maybemachine dependent), but for output
signals it would be convenient to be able to specify interpretations,
eg whether a hardware signal is to be interpreted
as a sign bit.
3 Asample Solution
We developed a primitive model for the system simulator
COSSAP and a proprietary hardware interface at our
institute which allows us to model hardware mainly for
systems and ASICs developed in our institute.

COSSAP
COSSAP
3.1 ISS Test{Hardware
As was elaborated in section 2.2, the complexity ofthe
interface hardware is determined to a large degree by the
hardware which is to be included into the simulation setup.
The interface complexitymay range from simple programmable
parallel interface to complex hardware which
may be required to satisfy absolute timing requirements.
Ethernet
Host Computer
ISS-Testsystem
congured to be interpreted as positive binary numbers or
signedintwo's complement representation. Figure 4 shows
the principal functionality of the model.
In-Ports
Configuration Data: Mapping, Clock Speed, ..
Inputs Constants Clocking Outputs
Mapping
.
.
.
.
.
Mapping
Pins
Device
Adaptor
Pins
.
.
Mapping
Out-Ports
Host Interface
Versatile COSSAP Module + Interface +
Fig. 3: ISS Test Hardware
Device Adaptor
Device under Test
Standard Test Environment
The test hardware at our institute was developed for low
cost testing of fully synchronous digital hardware. The test
hardware consists of 160 programmable interface pins, a
programmable clock generator which provides three clock
signals of up to 50MHz frequency and a programmable cycle
counter which allows to apply clock bursts of up to 2 24
cycles to the device under test. During clock bursts neither
changing input signals is possible nor reading output signals.
Each device under test is tted with a unique device
adaptor to the test hardware, clock andpower is hardwired
this way which greatly reduces complexity of the test
hardware. The test hardware is steered by a simple interface
in the host computer. Figure 3 gives an overview
of the complete setup. Furthermore a program which is
capable of running stimuli in a proprietary format on the
hardware interface was developed. This capability isused
for automatic testing and initialization of the hardware
during the initialization phase of a simulation. There are
no FIFOs attached to the pins and the hardware interface
can therefore not satisfy absolute timing constraints.
However, tests at full speed are possible if the attached
hardware does not require input signal changes during the
test. This is often the case if ASICs contain circuitry for
built in self test [15]. The boards and ASICs developed in
our laboratory are indeed tested at full speed during the
initialization phase.
3.2 AVersatile Interface Model
Aversatile COSSAP module has been developed which
is congurable for any device adaptor. The module takes
a data set for module conguration [16]. Hardware initialization
is performed in the aforementioned manner. The
model is capable of applying constants and simple clock
systems. The data ow signals which are connected to
the model must be of type integer, output signals can be
HiSL_cossapsoft.id
ISS-
Testsystem
Initialization Data:
Reset, Initial Test, ..
Fig. 4: Structure of the COSSAP Module
The data set which congures the model has four parts
which establish input mapping, output mapping and interpretation,
constant signal specication and clock specication.
A mapping specication establishes a mapping
between a data ow signal (of type integer) at port number
N to one or more bits of the hardware interface. The
number of module ports is not xed and the ports consequently
have no names. They are identied by a unique
port number which represents the sequence in which signals
were connected to the model. This is the number
which is referred to in the data set. The interpretation
of the mapping records begins with the least signicant
bit (LSB) and proceeds towards the most signicant bit
(MSB) if more than one record establishes the mapping.
A sample mapping and its specication records for input
ports is shown in Figure 5.
This approach allows arbitrary mappings in a concise
form to be specied, since we do not need to map every
single bit by a separate data set entry as long as they are
to be mapped on sequential pins of the hardware interface.
At the output side of the model an additional entry in the
data set species whether a signed or unsigned representation
is to be assumed. Clock specication is done with
the parameters frequency, phase, duty cycle and cycles per
sample. The parameter cycles per sample allows to interface
eciently to hardware which exchanges only every N
clock cycles meaningful data. Since we can not guarantee
absolute timing at the hardware, the clock specication is
interpreted in our case more or less as a sequence of signal
changes rather than running a clock system with the
specied timing between sampling the hardware signals.
3.3 Performance
In many cases, the time consumed when simulating the
system by using components of the real hardware will be
less as compared to a simulation performed completely on
the host computer. Overhead is introduced mainly for

Interface Model
IS2 - Interface Hardware
LSB 0
3
Inport 1
1
2
10
11
1
2
1 1
Data Flow Signals
LSB
0
1
LSB 0
15
inmap_example.id
Inport 2
Inport 3
3
4
5
8
18
12
21
26
Data Record Sequence
Input Port-Number
First Sequential Pin
Last Sequential Pin
3
4
5
6
1
1
2
5
10
15
20
25
26 26
1 2
10 3
11 4
Pins
1 2 3 4 5 6
3 3 3
5 17 21
8 12 26
Fig. 5: Input mapping example
Device
transferring data between host and hardware and for mapping
signals of the simulator to actual hardware pins.
In the following we discuss as an example the simulation
of the experimental fully digital 100MBit/s receiver DI-
RECS [13], which consists of 6 ASICs. Figure 6 shows the
hierarchical software model of the receiver which consists
of several primitive models. These models reproduce exactly
the behavior of the chip set and consume over 92% of
the simulation runtime in conjunction with a simple noisy
channel and the appropriate signal source.
Fig. 7: COSSAP Hardware Model of DIRECS
complex component the rst step is eightfold serial to parallel
conversion in the module S2PI. The system clock is
generated in the block THW_LOOP thus no explicit clock signal
is required in the model of Figure 7. A constant signal
is applied with a data set entry while others were fed
into the hardware through the constant sources CONSTI because
their values were frequently changed. They could be
parameterized at the top level simulation setup this way.
Figure 7 shows several additional outputs of the receiver
board which allow observation of some internal signals.
By runtime proling of our software, it was found that
the bandwidth of the host interface limits the simulation
throughput of our example. However, even in the small
simulation setup described above, the interface software
to our testing environment consumed only 20% of the simulation
runtime which shows that optimization of this
interface would not result in large speedups. After all, the
verication of the receiver was made possible down to bit
error rates of 10 ;7 due to a tenfold increase in simulation
eciency as compared to the software models of Figure 6.
The resulting number of 250 million clock cycles (17 Gigabits
of data) shows clearly why playing stimuli historys
was not a viable solution for our application. A clock cycle
on the hardware with 93 bits interfacing takes 400s on a
SPARC Server 4/330.
Fig. 6: Hierarchical COSSAP Model of DIRECS
It is worth mentioning here that the model in Figures
6 has dierent data rates at inputs and outputs since a
digital receiver usually requires oversampling of the input
signals. In the case of DIRECS, fourfold oversampling together
with certain properties of the employed transmission
scheme lead to an eightfold rate reduction from inputs
to outputs. In real hardware, parallel processing was required
to achieve the extreme data rate and eight input
samples are processed in parallel. The hardware model
thus comprises some additional software blocks. Figure 7
shows the COSSAP conguration for the hardware model.
The block THW_LOOP is the versatile interface model .
Since the hardware has eight parallel inputs for each
4 Commercial Solutions
To the best of our knowledge hardware modelers are
available from Logic Modeling Inc. only [9] { [17]. They
have beendevelopedtowork well in the event driven context
but integration intoadataowcontext would be possible
as well. While data ow simulations do not need timing
information, event driven simulations do (see section
2.1). In commercial hardware modelers timing is added in
software by means of timing models rather than by measuring
the response of the device which would require much
more costly interface hardware. Thus the accuracy of the
timing model underlies the same restrictions as in standard
software models. In commercial hardware modelers

chips are tted on standard device adaptors rather than
device specic ones, which are needed in our case. This
increases the interface complexity sincepower and ground
pins need to be congurable, but eases the setup. However,
for complete systems rather than single chips special
device adaptors are still required. The hardware modelers
can handle bidirectional as well as unidirectional device
ports. They are stand alone ethernet devices and some
communication overhead is the price for obtaining a hardware
modeler which is independent of the simulation workstation
architecture. Current product information led to
the estimate that no simulation speedup would have been
possible in the simulation of DIRECS. Current pricing for
hardware modelers is well above US$ 100.000 and development
kits to integrate the hardware modelers into existing
simulation environments are very expensive too.
5 Conclusion
While hardware modeling in copnjunction with eventdriven
simulation is a commercial reality, our experimental
setup shows that hardware modeling is possible in conjunction
with data ow driven simulations. This is due to
the fact that we deal with the sequence of meaningful values
rather than timed signals. Furthermore, the class of
hardware components which can be handled was restricted
to fully synchronous components with static memory
to avoid recording and playing stimuli historys. We did
not support bidirectional ports. These restrictions reect
our application domain which is in the loop simulation
of digital signal processing ASICs for performance verication.
An experimental hardware modeling solution for
the simulation system COSSAP was developed in conjunction
with a proprietary test environment forintegrated
circuits and VLSI systems. This solution provides the full
functionality for hardware modeling of the envisaged class
of hardware components at high simulation speed and low
cost. It turned out during runtime proling that in our implementation
the small wordlength of the hostinterface is
the remaining bottleneck but the interface model provides
already a throughput at which simple additional software
models are the speed limiting factor.
Bibliography
[1] P. Zepter and K. ten Hagen, \Using VHDL with stream
driven simulators for digital signal processing applications,"
in EURO-VHDL'91 Proceedings, (Stockholm, Sweden),
pp. 196{203, September 8-11 1991.
[2] J. Buck, S. Ha, E. A. Lee, and D. G. Messerschmitt, \Ptolemy:
A platform for heterogenous simulation and prototyping,"
in Proc. 1991 European Simulation Conf., (Copenhagen,
Denmark), June 1991.
[3] M. Pankert, S. Ritz, and H. Meyr, \Integration of digital
signal processing hardware into a system level simulation
environment," in European Simulation Multiconference,
(York, United Kingdom), pp. 394{398, SCS International,
1992.
[4] \Simbus simulation backplane." Product Information, ViewLogic
Inc., 1993.
[5] G. Jennings, \A case against event driven simulation of
digital system design," in The 24th Annual Simulation
Symposium (A. H. Rutan, ed.), (Los Alamitos, California),
pp. 170{176, IEEE Computer Society Press, April 1991.
[6] L. Widdoes and W. Harding, \CAE station uses real
chips to simulate VLSI-based systems," Electronic Design,
vol. 32, pp. 167{76, March 1984.
[7] K. S. Shanmugan, \An update on software packages for simulation
of communication systems (Links)," IEEE JournalonSel.Areas
in Commun., vol. 6, pp. 5{12, January
1988.
[8] J. Kunkel, \COSSAP: A stream driven simulator," in
IEEE International Workshop on Microelectronics in
Communications, Interlaken, Switzerland, March 1991.
[9] M. Donlin, \Accurate device models makes PCB simulation
a reality," Computer Design, pp. 71{76, July 1991.
Penn Well Publishing Co.
[10] N. Kelly and H. Stump, \Software architecture of universal
hardware modeler," in Proceedings of the European Design
Automation Conference, (Glasgow, UK), pp. 573{7,
IEEE/EDAC, March 1990.
[11] R. M. Fujimoto, \Parallel Discrete Event Simulation,"
Communications of the ACM, vol. 33, pp. 31{53, Oct.
1990. 98 ref.
[12] E. A. Lee and D. G. Messerschmitt, \Synchronous data
ow," Proceedings of the IEEE, vol. 75, pp. 1235{1245,
September 1987.
[13] O. J. Joeressen, M. Oerder, R. Serra, and H. Meyr, \DI-
RECS: System design of a 100Mbit/s digital receiver," IEE
Proceedings-G,vol. 139, pp. 222{230, April 1992.
[14] L. Widdoes and H. Stump, \Hardware modeling," VLSI
Systems Design, vol. 9, pp. 30{8, July 1988.
[15] R. Serra and H. Meyr, \Geschwindigkeitsoptimierter Systemselbsttest
fur schnelle digitale Schaltkreise," in GME-
Fachbericht 8, (Baden-Baden), pp. 253{258, vde-verlag,
Berlin Oenbach, March, 4.-6. 1991.
[16] COSSAP Manual, Volume 1-5, Synopsys Inc., Herzogenrath,
Germany.
[17] H. Stump, \Hardwaremodellierung { ein wesentlicher Bestandteil
der Systemsimulation," Elektronik, no. 21, 1990.
Franzis Verlag, Munchen, (in german).
[18] D. Giles, K. Bowden, M. Haney, and G. Maston, \Maintaining
simulation accuracy through physical device models,"
in Proceedings of the International Test Conference 1985,
(Philadelphia, PA), pp. 692{695, IEEE, Nov 1985.
[19] A. Read and H. Stump, \Hardware modeling in ASIC prototype
verication," in ATE and Instrumentation Conference
West, (Anaheim, CA), pp. 76{81, Jan 1989.
[20] H. Stump, \A designer's guide to simulation models,"
Computer Design, vol. 29, pp. 91{2, Jan 1990.
[21] U. Dersch and P. Rauber, \Modellierung und Simulation
des Mobilfunkkanals," ASCOM Technische Mitteilungen,
no. 2, pp. 9{14, 1991. (in german).