Simulink_tutorial With System Generator

Tutorial CASPER Reference Design Author: Henry Chen June 23, 2007 (v1.0) Hardware Platforms Used: IBOB FPGA Clock Rate: 100MHz Sampling Rate: N/A Software Environment: TinySH

This tutorial walks through the process of building a Simulink design with Xilinx System Generator, simulating it, and compiling to an FPGA bitstream using the bee_xps toolflow. The design uses an addressable ROM to generate a pattern of bits which are output to LEDs on an IBOB.

Creating the Design

Start Matlab, making sure that library paths are properly set (see Toolflow Setup Manual), and run Simulink by typing simulink in the Matlab command prompt. To create a new design, select File New Model from the Simulink Library Browser. Save as casper_tutoria.mdl in a directory whose path has no spaces and is not a UNC path (\\somedrive\somefolder\...)

Open the Xilinx Blockset library, and from Basic Elements drag a new System Generator block into the design.

CASPER Reference Design Tutorial (v1.0) June 23, 2007 1

All designs using System Generator and blocks from the Xilinx Blockset need the System Generator block. Settings in the block will be modified automatically by the toolflow, so you can just insert the block and leave it alone.


Next, insert an XSG core config block from the BEE_XPS System Blockset library. This block is required by the bee_xps toolflow, and is used to define the compilation parameters for the design. The settings in this block are used to automatically define the settings of the System Generator block during system generation.

Double-click on the XSG Core Config block to set the parameters: Set Hardware Platform to iBOB Uncheck Include Linux add-on board support Set User IP Clock source to sys_clk Set User IP Clock Rate to 100MHz Set Sample Period to 1 Select XST as the Synthesis Tool Click OK


Add a software register block from the BEE_XPS System Blockset library to the design. This block inserts a 32-bit register that is accessible to both the PowerPC TinySH shell and the FPGA fabric, and is a handy way of passing low-speed control or status signals.

This register will be used as a user reset to the design. Since the register will be propagated to the top level and visible from TinySH, its a good idea to give it a more meaningful name. To do this, click on the name label beneath the block, and rename the block to reset. CASPER Reference Design Tutorial (v1.0) June 23, 2007 6

Configure the block to have: I/O direction of From Processor. Data Type of Unsigned Data Binary Point of 0 Sample Period of 1

CASPER ReferenTutorial (v1.0) June 23, 2007 7

ce Design

Once the software register is reconfigured to be a From Processor register rather than the default To Processor, the block will redraw and the ports will be renamed.

The sim_in input port on the register block expects an input coming in from the simulation domain, rather than the FPGA domain, so it needs to be connected to a block in the Simulink library. In this case, it can just be connected to a constant 0, so add a Constant block from the Sources subset of the Simulink library. Give it a Constant Value of 0, then connect the constant block to the software register by dragging a connector line from the output port of the Constant block to the input port of the software register block.


Because the software register is a 32-bit unsigned number, we have to extract a relevant bit and convert it to a boolean before it can be used as a reset signal to the rest of the circuit. This is done using the Slice block from the Xilinx Blockset Basic Elements library.

It should be configured as: Specify Range As: Lower Bit Location + Width Width of Slice: 1 Offset of Bottom Bit: 0 Relative To: LSB of Input Check Boolean Output


The next step is to add in a Counter block from the Xilinx Blockset. This will be used to generate the addresses for the ROM.

The Counter Type should be set as Free Running, such that when it overflows its bitwidth it wraps back to zero. Set the Number of Bits to 28, with a Binary Point Position of 0 and an Unsigned Arithmetic Type. By using a 28-bit counter and choosing bits from the vector, we can


control how fast we cycle through the LED pattern. Lastly, check the Provide Reset Port box, and leave all other parameters at their default values.

When the counter is updated with its new parameters, it will have a new reset input port. Connect the reset signal sliced from the software register; this provides a user-controlled reset to the counter.


We anticipate using a 16-entry ROM, so only 4 bits from the counter are needed to cover the entire address space. The pattern cycling rate can be controlled by selecting the appropriate 4 bits from the counter. This can range from a rate of 100MHz (lowest 4 bits) to 5.96Hz (highest 4 bits).

A cycling rate of 5.96Hz is more readily seen in hardware compared to something in the MHz ranges. However, this means that though the counter is incrementing every cycle, the output wont change for 224 = 16777216 cycles. A simulation of this kind of duration in Simulink can be very slow. A compromise can be made by building the design to have different simulation and compilation behaviors.

In this case, we want to cover both extremesa 100MHz cycling rate to see outputs change in every cycle of simulation, and the 5.96Hz cycling rate for a easier visual verification in hardware. To do this, add two Slice blocks to the design both connected to the same counter output. One should be set to slice the lower 4 bits from the count, while the other should slice the upper 4 bits from the count. By simulating the circuit using the lower 4 bits, the full pattern can be seen using a shorter simulation time. This allows us to make sure the rest of the designi.e., the ROM and the pattern stored in it, the reset logic, the LED interface blocks, etc.are correct.


Simulink Tip:

If the two slice blocks are placed close to each other, their name labels may start to overlap and make the model messier to view. For a slice block which that has a generic name and gives other visual clues about what kind of block it is, its name label can be hidden from view. To do this, right-click on the block, then select Format Hide Name.

When the slice blocks are added to the design and configured, connect both to the counter output. Notice that once the Counter blocks output is connected to a Slice blocks input, its port is taken and you can no longer drag a connector from it. To connect the second Slice block to the same Counter block, youll have to do it in reverse. Rather than connect an output to an input, connect the input to the existing signal: drag a connector line from the input port of the second Slice block and connect it to the connection between the Counter block and the first Slice block.


To use two different slicing behaviors for simulation and compilation, we can use a Simulation Multiplexer block from the Xilinx Blockset, Tools subset. Configure it so that Simulation uses port 1, and that Generation uses port 2, then connect the outputs from the 2 slice blocks accordingly.


The LED pattern will be generated using a ROM, rather than explicit logic. A ROM block can be found in the Xilinx Blockset/Memory subset library. Connect its address input port to the output from the Simulation Multiplexer block so that it gets a slice off the address counter.


The ROM needs to be filled with the values for the LED pattern. Set its Depth as 16, and set Number of Bits to 8, with a Binary Point of 0, so that there will be one bit for each of the 8 LEDs. The suggested LED pattern is a back-and-forth sweep of one LED each. This needs a sequence of numbers in which only one bit is 1 at a time, i.e., powers of 2. In the Initial Value Vector field, enter the Matlab vector construct [1 2 4 8 16 32 64 128 128 64 32 16 8 4 2 1].

Tip for advanced users:

ROMs in System Generator are by default implemented 18kb BlockRAM SRAM blocks. This default can be overridden in the block setting by checking Show Implementation Parameters and selecting Use Distributed Memory (Instead of block RAM). This will cause the ROM to be implemented in the FPGA using distributed SelectRAM built out of LUTs (each LUT can be configured as a 16x1-bit SRAM) in the FPGA fabric. In this particular case, the generation and synthesis tools are able to reduce this ROM to a block of logic, rather than SelectRAM memory.


To add another feature, we will also use the reset to select between the output of the ROM and a constant signal. This way, when the reset is held high, a completely different pattern will be shown on the LEDs, rather than simply the first value in the ROM. This makes it clear that the system is in reset, and not just frozen.

To do this, add three blocks from the Xilinx Blockset/Basic Elements library: a Constant block, a Slice block, and a Mux block. Connect the input of the Slice block to the output of the reset Software Register block. Again slice off the bottom bit from the reset signal; this time do not make it a Boolean output so it stays as an 1-bit unsigned number. As a number, this can be used as a select signal for the multiplexer, so connect the output of the Slice block to the sel input of the Mux block.

Set the Constant block to have a Constant Value of 255. It should be an Unsigned, 8-bit number with a binary point at 0. Make sure that Sampled Constant is turned on; all Xilinx Constant


blocks should always be Sampled Constants to avoid any problems when System Generator tries to infer sample periods for the entire design.

Connect the outputs of the ROM and the Constant blocks to the input of the Mux, with the ROM connected to input d0 and the Constant connected to input d1. This will switch the output of the LEDs to be all on when the ROM addressing is held in reset.


The last piece to add before going out to LEDs is a Delay block from Xilinx Blockset/Basic Elements. Set the Latency of the block to 8 and turning on Enable Register Retiming; this will aid in the place-and-route of the FPGA design.


Tip for advanced users:

A Delay block is by default implemented using SRL16s (a LUT configured as a 16-bit shift register). By enabling register retiming, each delay stage is instead built out of flip-flop registers, which aids in spatial pipelining. The impetus for this is that the circuit is connected to both the PowerPC core at the center of the die as well as the IOB output pads at the edges. The extra registers aid in spanning the circuit across the chip to help meet timing by providing more elements to spread out spatially (note, though, that a latency of 8 is probably excessive for this purpose). A Delay implemented out of SRL16s is good for delaying data to align latencies but, as 16 delays are packed into the same LUT, is not very helpful for crossing die distances.


The last step is to send the output of the circuit to the LEDs. For this, bits need to be sliced from the 8-bit data stream and connected to the output pins on the FPGA connected to the LEDs. These can be added to the design using gpio blocks from the BEE_XPS System Blockset library.

For the first LED, add a gpio block and rename it led0. Select ibob:led as its I/O group with an I/O direction of out. Make it a 1-bit Boolean data type with binary point at 0 and a sample period of 1. As this is the first LED, its GPIO bit index should be 0. Turn on Pack register in the pad with a Register clock phase of 0. This will latch all the outputs at the IOB and keep them all aligned with the rising edge of the clock. This gpio block will drive the LED with the LSB of the pattern, so connect a Slice block between the Delay block and this gpio.


Insert another Slice/gpio pair to drive the second LED. This Slice should take the next bit up from the pattern, which can be accomplished by increasing the Offset of Bottom Bit to 1. The gpio block should be named led1, with the same settings as led0 except its GPIO bit index should be set to 1.


Keep inserting Slice/gpio pairs to get the remaining bits of the pattern, using the LED GPIOs from 0 to 7.


These gpio blocks are interface blocks that represent the transition between the implementation and simulation domains. In this case, we go from the implementation (FPGA fabric) realm to the simulation (off-chip or PowerPC) realm, so the inputs to the gpio block should be Xilinx System Generator blocks, while the outputs should feed Simulink simulation blocks.

At this point, the design should be able to compile, but we want to be able to see results in simulation. The best way to visualize a time-varying result is to put in a Scope block from the Simulink/Sinks library.


Adding one to the design provides a one-input scope, which can probe a single signal. Wed like to be able to see all 8 signals on a single scope, so we can increase the number of inputs by opening the scope and clicking on the Parameters icon in the toolbar. Under the General tab, the Number of Axes can be set to 8. After you click OK and return to the scope display, the number of axes has increased from 1 to 8, and the number of inputs on the Scope block itself will also have increased. Connect the outputs from the 8 LED gpio blocks to the Scope block inputs.


Before starting a simulation and compiling, it is good to get some feedback from Simulink on the design. As were using blocks from libraries, we can see the relation of the instance to the library by going to Format Library Link Display All. This will display little arrows at the bottom left of all custom library components (Xilinx Blockset and Simulink library blocks will not have this). A black arrow means the block is synced to the library; a gray arrow means the block knows of its library source but will not update from the library if the library block changes, and a red arrow means that something has changed the block in relation to the library source. This is a good way to make sure the design isnt using out-of-date library components.


As Simulink operates on typed data rather than bit vectors, in some cases inferring and inheriting data types, a common source of errors is a wrong data type. This can be checked by turning on the data type displays in Format Port/Signal Displays Port Data Types, which will annotate each signal with its data type.

The syntax for this annotation is: Double: double-precision floating-point for Simulink simulation domain only UFix_X_Y: fixed-point unsigned number, X-bits wide with a binary point at Y Fix_X_Y: fixed-point signed number, X-bits wide with a binary point at Y


To run the simulation, first increase the simulation time from 10.0 to 1000, then click on the Start Simuation button.


The Scope display will show the output from the gpio blocks. Zooming in shows that the LEDs will be cycling as intended.


Having run the simulation, we can be fairly confident that the circuit will behave as we want, and can compile the design. Make sure that the Matlab current directory is where your .mdl file is located. Click on the top level model file, then from the Matlab command prompt type bee_xps. This brings up the BEE XPS GUI. If the System Generator Design Name is not casper_tutorial, click again on the top level model file (make sure you havent selected a block in the design) and click the gcs button. Select Complete Build from ISE Design Flow Choice, then click the Run XPS button.


The compilation progress will be displayed in the Matlab command window. When the build is finished, a status window should pop up.

The Matlab command window should also display some statistics about the build process:


=================================================================== Flow run time summary: (00:24:23 seconds total) System update............00:00:02 Design Rules Check.......00:00:01 Xilinx System Generator..00:02:08 Base system copy.........00:00:32 IP creation..............00:00:01 EDK files creation.......00:00:04 IP elaboration...........00:00:00 Software creation........00:00:01 EDK/ISE backend..........00:21:34 Download Bitfile.........00:00:00 ===================================================================

A toolflow working directory is created in the directory where the design is saved.

Under this directory will be a bit_files directory to which the FPGA bitstreams are copied after compilation.


The casper_tutorial_.bit file is the bitstream file that will be used to program an IBOB with the design. The .bof file can be ignored for now.

Start up the Xilinx iMPACT programming utility. If there is a window prompting you to open or load a project, select Cancel.


Making sure that the Boundary Scan tab is selected, right-click in the upper half window and select Initialize Chain. This gets the download cable to begin scanning for devices on the JTAG boundary scan chain.


When the scan finishes, the download cable should have picked up two devices: an xcf32p and an xc2vp50. The former is the Platform Flash PROM on the IBOB board, and the latter is the FPGA being targeted. For instructions on how to burn an image to the PROM, see the IBOB PROM burning procedure CASPER memo from March, 2006.


Click OK to proceed to the bitstream file selection. iMPACT will first prompt you to select an .mcs file for the PROM. Click Cancel or Bypass to skip loading anything into the xcf32p PROM.


iMPACT will next prompt for a new configuration file for the xc2vp50 FPGA. Select the casper_tutorial_.bit file created by the toolflow in the bit_files directory.


The next popup will prompt for additional BMM and PowerPC software files. Nothing needs to be done here, so click OK.


To download the bitstream to the FPGA, right-click on the xc2vp50 icon and select Program.


In the Program Options dialogue box that pops up, turn off Verify and turn on Pulse Prog, then click OK. iMPACT will begin programming the FPGA and show a progress bar.


The IBOBs LEDs should now be blinking in the specified pattern.

Revision History Date Revision Changes

June 23, 2007 v1.0 Initial revision.


Documents

Simulink_tutorial With System Generator