Chapter 3: Using Hardware Co-Simulation
15. Record the amount of time required to simulate the design for 10000 cycles.
___________________________________________________________________
16. Close the design, but leave the hardware co-simulation library open since you will need it in the next topic.
In the simulation above, hardware co-simulation uses single word transfers. That is, whenever there is a new simulation value to be read or written to the hardware cosimulation, the PC initiates a transaction with the FPGA. The next topic describes how vector transfers may be used to increase simulation speed by making more efficient use of the available hardware co-simulation bandwidth.
Using Vector Transfers
The System Generate Shared Memory Read and Write blocks allow you to use vector transfers with hardware co-simulation. These blocks may be found in the Shared Memory library in the Xilinx Blockset.
The Shared Memory Write block accepts a Simulink scalar, vector, matrix or frame data type and writes the data sequentially into a shared memory. The complete contents of the
Simulink signal are written into the shared memory in a single simulation cycle. As is the case with all shared memory blocks, an association is made between a Shared Memory
Read or Write block and another shared memory by specifying the same shared memory name.
Matrix types are treated as having a column-major order. That is, when data is written sequentially into a shared memory, the elements in a column are written first before advancing to the next column. For example, assume you have the matrix of data shown below. During simulation, this matrix data is written into the FIFO (or shared memory) in the following order:
220
Using these blocks, it is possible to read or write full vector, frame, or matrix signals into shared memories, provided the following conditions are met:
•
The input signal driven to a shared memory write block is an 8-bit, 16-bit, or 32-bit signed or unsigned integer;
•
The number of elements in the vector or matrix does not exceed the depth of the shared memory or FIFO.
•
The data width of the Shared Memory Read or Write block (i.e., the bitwidth of the scalar, or vector or matrix element) equals the shared memory or FIFO data width.
You can use these blocks in the example design to read and write vectors of data samples to the MAC filter in a single software / hardware transaction. www.xilinx.com
System Generator for DSP User Guide
UG640 (v11.4) December 2, 2009
Frame-Based Acceleration using Hardware Co-Simulation
17. Open macfir_hw_w_frames_tb.mdl from the MATLAB console.
This design is a very similar to the previous design, with a few modifications made to support the Shared Memory Read and Write blocks. Before simulating the design, you consider each of these modifications. Most importantly, Shared Memory Read and Write blocks have been substituted in place of the To and From FIFO testbench blocks in the previous design. By specifying CA and VA as the Write and Read shared memory names, respectively, an association is automatically made to the input and output FIFO buffers in the FPGA hardware during simulation.
A Simulink Buffer block builds a frame of scalar input samples by sequentially buffering the unfiltered input data. A simple analogy is that the Buffer block is performing a serial to parallel conversion. Recalling that you compiled the FIFO buffers with a depth of 4K, you choose a frame size of 4095.
Note that the buffer block introduces a sample rate change in the design. For every 4095 inputs, there is only one output. Thus if the data input sample period is 1, the buffer data output sample period is 4095. This means that the Shared Memory Write block need only send a new frame of data to the FPGA on every 4095th simulation cycle (which is considerably more efficient than initiating a hardware transaction during every simulation cycle).
Because the Buffer block introduces a rate change, you must adjust the downstream blocks to accommodate the slower sample period. You begin by telling the Shared Memory Read block to read a frame of data every 4095th simulation cycle.
18. Double-click on the Shared Memory Read block to open its parameters dialog box.
On the Type field under the Basic tab, you have configured the block to use shared FIFOs.
To ensure a new frame is read at the appropriate time, you configure the Shared Memory
Read block with a Sample time value of 4095.
The Shared Memory Read block allows you to specify the output data type and dimensions.
System Generator for DSP User Guide
UG640 (v11.4) December 2, 2009 www.xilinx.com
221
Chapter 3: Using Hardware Co-Simulation
19. On the parameters dialog box, switch to the Output Type tab.
There are several things of interest on this tab. First, you set the output data type as an int32 to match the filter data path output width of 32-bits. Note the design will not simulate unless these widths match. Secondly, you choose an output dimension that is 4095 words deep in the Output dimensions field. Finally, you tell the block to generate frame-based output since frame data types are required by the downstream Unbuffer block.
20. Close the parameters dialog box.
The Simulink Unbuffer block takes the frame data from the Shared Memory Read block and deserializes it into sequential scalar values. The Simulink Unbuffer block also introduces a sample rate change in the diagram. Because the input sample period to the block is 4095, and the frame size is 4095 words, the Unbuffer block output sample period is
1. This works out nicely since you have data moving through the overall system at an effective sample period of 1.
Because the Shared Memory Write and Read block operate on integer values, you must insert Simulink type conversion blocks into the diagram so that the data is interpreted correctly in various portions of the model. The in_data_conv subsystem converts the
Simulink doubles into 16-bit integer values that can be interpreted appropriately by the
FPGA hardware. On the output side, the out_data_conv subsystem converts the 32-bit integers into 32-bit Simulink fixed-precision values.
Before simulating the design, you must add the hardware co-simulation block you created from the previous design.
222
www.xilinx.com
System Generator for DSP User Guide
UG640 (v11.4) December 2, 2009
Frame-Based Acceleration using Hardware Co-Simulation
21. Add the hardware co-simulation block to the design as shown below.
As mentioned before, the Shared Memory Write block writes a new input frame of 4095 words to the FPGA on every 4095th clock cycle. Likewise, the Shared Memory Read block reads an output frame of 4095 words from the FPGA on every 4095th clock cycle. This means that the FPGA must process the entire frame in a single-cycle. How exactly is this accomplished?
The first step is to configure the FPGA in free-running clock mode. In doing so, you allow the FPGA to process data considerably faster than if it were otherwise kept in lockstep with the Simulink simulation. Whereas in single-step mode the FPGA can only process one data per Simulink cycle, the FPGA processing speed is limited only by the system clock frequency when operating in free-running clock mode. Even so, if the buffer is large enough, the FPGA may not have time to process the complete buffer before the next block in the design is woken up. You still need a way to stall the rest of the simulation while the
FPGA processes the entire buffer.
The Shared Memory Read block checks the number of FIFO words available in the output buffer before trying to read a frame. If the number of words in the buffer is insufficient, the
Read block waits for a small amount of time, and then checks again to determine if the words have become available. It only reads the frame once all of the words are available in the output buffer, in this case 4095. In this manner, the Shared Memory Read block can stall the simulation until the complete frame has been processed by the FPGA.
System Generator for DSP User Guide
UG640 (v11.4) December 2, 2009 www.xilinx.com
223
Chapter 3: Using Hardware Co-Simulation
The simulation flow of data through the diagram is shown below.
Two steps necessary to run the simulation using Simulink frames signals are provided below:
22. Double-click on the hardware co-simulation block to bring up the parameters dialog box.
23. Select Free running clock mode as shown below.
224
24. Configure the hardware co-simulation block with any additional settings necessary for simulation according to the requirements of your co-simulation platform.
25. Press the Simulink Start button to start the design.
26. Record the amount of time required to simulate the design for 10000 cycles.
___________________________________________________________________
27. What is the simulation speed increase over the time recorded in step 15?
___________________________________________________________________ www.xilinx.com
System Generator for DSP User Guide
UG640 (v11.4) December 2, 2009
Real-Time Signal Processing using Hardware Co-Simulation
Real-Time Signal Processing using Hardware Co-Simulation
The shared memory interfaces available in System Generator allow signal processing designs with high bandwidth and memory requirements to be co-simulated using FPGA hardware. When used in conjunction with the Xilinx Shared Memory Read and Write blocks, it is possible for hardware co-simulation designs to process complete Simulink vector and matrix signals in a single simulation cycle. These large data transactions between Simulink and the FPGA are realized using burst transfers, and depending on the co-simulation interface, often provide sufficient throughput for real-time signal processing applications.
There are two types of System Generator interfaces that support burst transfers when compiled into FPGA hardware. These interfaces include lockable shared memories and shared FIFO blocks. Both blocks provide different handshaking protocols that determine how and when transactions between the FPGA and host PC occur. Before using these blocks, it is useful to understand how they work in relation to hardware co-simulation. For more information, please refer to the following topics:
Co-Simulating Lockable Shared Memories
Co-Simulating Shared FIFOs
In this document, a high-speed co-simulation buffering interface implemented as a System
Generator model is presented. The example interface uses lockable-shared memories to implement the required buffer storage. Note that it is relatively straightforward to modify the flow control logic so that shared FIFOs may be used in place of the shared memories.
The high-speed buffering interface is discussed first, followed by an example in which the interface is used to support real-time processing of a video stream using a 5x5 filter kernel.
Described last is how an additional unprotected shared memory is applied to the system to support dynamic reloading of the image kernel during co-simulation.
Shared Memory I/O Buffering Example
When a lockable shared memory is compiled for hardware co-simulation, additional circuitry is included in the FPGA to the handle the mutual exclusion. Part of this circuitry includes logic to enable high-speed transfers of the memory image when the FPGA acquires or releases lock of the memory. It takes advantage of the lockable shared memory mutual exclusion semantics to implement a high-speed I/O buffering interface for hardware co-simulation. This topic describes this interface, which is included as an example model in your System Generator software installation.
1.
From the MATLAB console, change directory to
<sysgen_tree>/examples/shared_memory/hardware_cosim/io_bufferin
2.
Open highspeed_iobuf_ex.mdl from the MATLAB console.
The I/O buffering interface allows you to easily buffer and stream data through a System
Generator signal processing data path during hardware co-simulation. The example design is comprised of two subsystems that implement input and output buffer storage, named Input Buffer and Output Buffer, respectively. The turquoise block in the center of the diagram is a placeholder for the signal processing data path which you will substitute into the design.
At the heart of each buffering subsystem is a lockable shared memory block that provides the buffer storage. Each shared memory is wrapped by logic that controls the flow of data
System Generator for DSP User Guide
UG640 (v11.4) December 2, 2009 www.xilinx.com
225
Chapter 3: Using Hardware Co-Simulation from the host PC, through the interface, and back to the host PC. Operation of the I/O buffering interface is shown in the flow chart below:
226
Notice that the buffering interface design includes several data valid ports. These ports are used for data flow control. A "true" output from the Input Buffer dout_valid port indicates new data is ready to be processed by the data path. Likewise, when the data path is finished processing the data, it should drive the Output Buffer subsystem's din_valid
port to "true" to indicate valid output data (the din_valid port is analogous to a write enable control signal).
The example includes a placeholder that should be replaced by a System Generator data path. You may insert any data path in the buffer interface provided that it works within the valid signal semantics described above. www.xilinx.com
System Generator for DSP User Guide
UG640 (v11.4) December 2, 2009
