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

More documents

Recommendations

Info

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.
Page 1: Hardware \in the Loop" Simulation w
Page 5 and 6: Interface Model IS2 - Interface Har

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

Create successful ePaper yourself

Delete template?

Save as template?