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

More documents

Recommendations

Info

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
Page 1 and 2: Hardware \in the Loop" Simulation w
Page 3: at each time instant. Consequently

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

You also want an ePaper? Increase the reach of your titles

Delete template?

Save as template?