Co-simulating with hardware in the loop gives you faster simulations and eases hardware verification. System Generator for DSP Version 3.1 now lets you include FPGA hardware in Simulink simulations.

FPGA hardware can now be included in simulations controlled by the MATLAB™ language and its Simulink™ design tools. At the push of a button, the Xilinx System Generator for DSP Version 3.1 software tool produces an implementation of your model that is ready to run in hardware.

System Generator uses a special co-simulation block to control the design hardware during Simulink simulations. The co-simulation block looks just like traditional System Generator blocks. Its ports have names and types that match the ports on the original System Generator subsystem. The co-simulation flow for this architecture is shown in Figure 1. The simulation behavior of the co-simulation block is bit- and cycle-accurate when compared to the behavior of the original subsystem.

System Generator’s ability to incorporate hardware in the loop enables significant simulation speedups, provides incremental hardware verification capabilities, and removes many of the hurdles to getting a design up and running in an FPGA.

Hardware Co-Simulation Flow
Together, System Generator and hardware-in-the-loop co-simulation solve many problems normally associated with simulating and verifying a Xilinx FPGA design.

• You don’t have to know a hardware description language. System Generator performs automatic code generation when your model is translated into hardware.
• You don’t need in-depth knowledge of the board that hosts the FPGA. System Generator makes sure the correct hardware platform is targeted and implements the design accordingly.
• You need not create a separate test bench application. The co-simulation block can be used with the same Simulink test bench apparatuses that were used to test the original System Generator model.

A subsystem that contains a compilation block should also contain a System Generator block. System Generator uses the compilation block to provide information about the underlying hardware and how to prepare the model for co-simulation. Pressing the "generate" button on a System Generator block that has an accompanying compilation block automatically invokes the hardware co-simulation flow.

Some of the information obtained from a compilation block overrides values on the System Generator block parameters dialog box. The parameters that are overridden appear as grayed-out fields in the System Generator dialog box and cannot be modified. For example, the System Generator dialog box is shown for a subsystem that also contains an XtremeDSP compilation block. Notice in Figure 3 that the product, device, speed, and package fields have been grayed-out and are inactive. These parameters are used by System Generator when you press the "generate" button and the model is translated into hardware. This ensures that the correct device information is preserved when the FPGA configuration bit file is generated.

Generating a model for hardware co-simulation includes operations such as producing HDL code and netlists and invoking the Xilinx CORE Generator™ tool. After System Generator has generated a model, it invokes a compilation block script. Using the output from System Generator, the compilation block script invokes the tools necessary to produce a configuration file for the FPGA. Figure 4 illustrates the XtremeDSP compilation block script running ngdbuild.

The script creates a new library and adds a co-simulation block that is parameterized with information from the original subsystem. This information includes subsystem interface information such as port names, port data rates, port data types, and port directions. Figure 5 shows the library and co-simulation block created by the compilation block script for the cosim_ex model.

Figure 6 shows the co-simulation block first illustrated in Figure 5 as it is brought back into the cosim_ex model for simulation. Note that the ports on the co-simulation block match the port names on the input and output gateway blocks. The waveform in the scope shows equivalent output results for the AddSub block and the co-simulation block. The block’s inputs must be the same signal type, as shown in Figure 7.

Using Co-Simulation Blocks in Simulink
A co-simulation block is a Simulink block that interacts with an underlying co-simulation platform. This block behaves as a normal Simulink block and can be simulated transparently with other blocks. Each co-simulation block has a port interface that is parameterized by the compilation block script to match the ports on the original subsystem.

System Generator co-simulation blocks can be driven by either Xilinx fixed-point data types or by double-signal data types. The hardware co-simulation block must be of the same type of signals (bit width, binary point position, signed/unsigned) that were used in the original model. If there are no inputs to the block, the block allows you to choose between Xilinx fixed-point or double-signal output types.

When System Generator implements a model in hardware, it uses a single clock source to drive the design. Multi-rate blocks are supported by using derived clock enables. These clock enables have periods that are integer multiples of the period of the system clock. Data traveling in and out of the hardware also has a period that is a multiple of the system clock period. These multiples, or ratios, between the port data rates and the system clock rate are stored in the co-simulation block by the compilation block script when it is instantiated.

A co-simulation block must be driven by ports with data rates equivalent to the gateway data rates of the original subsystem. The block automatically adjusts its output ports to run at the appropriate rates. If the block detects an incorrect input port rate, it will generate an error message.

The easiest way to ensure that an input port has the appropriate rate is to drive the co-simulation port with the same signal that drove the original subsystem port or gateway.

Hardware Clocking
There are many possible synchronization techniques for the interface between FPGA hardware and Simulink. One technique uses a single-step clock to keep the hardware in lockstep with the software simulation. This is achieved by providing a single clock pulse to the hardware for each simulation cycle. Using this technique enables you to perform incremental design and verification.

On the other hand, the single-step clock technique has its disadvantages. When it is used for clocking the FPGA design, the communication overhead between hardware and Simulink can severely limit the effective processing rate in some designs. This condition is exacerbated by bus latency.

Simulation speed can be greatly increased by allowing the hardware to process more than one set of input samples at a time. One way to accomplish this is to provide a free-running clock to the design under test. Use an explicit synchronization mechanism such as a flag implemented as a memory-mapped register to coordinate data transfers between Simulink and the hardware. The inputs and outputs of the design are written to and sampled asynchronously.

Benchmarks
When using a single-step clock, speedups of seven to 50 times are typically achieved. The demos that come with System Generator were used as benchmarks. The results are shown in Table 1.

Table 1 – Benchmark results for hardware-in-the-loop co-simulation

Application	Software Simulation Time	Hardware Execution Time	Speedup
5x5 Image Filter	170 sec	4 sec	43x
Cordic Arc Tangent	187 sec	27 sec	7x
Additive White Gaussian Noise Channel (AWGN)	600 sec	80 sec	7.5x

Referring to the table, the bit error rate (BER) tester was created to test forward error correction (FEC) blocks. A free-running clock source achieved a speedup of six orders of magnitude. The data source for the BER tester was an LFSR in the FPGA. The test is started, and after some time when a "done" flag is set, you can read the results from the FPGA and display them in Simulink.

Conclusion
System Generator hardware co-simulation provides you with a simple but powerful method of incorporating hardware co-simulation in Simulink and System Generator models. The hardware co-simulation flow automates the entire hardware implementation process. You have more time to focus on the design itself. Once the hardware co-simulation software has produced a co-simulation block, it can be used just like any other System Generator block in a model.

To learn more about System Generator for DSP, go to www.xilinx. com/system_generator/and click on "System Generator for DSP."

Printable PDF version of this article.  (05/27/03) 175 KB