Tutorial - casper.berkeley.edu · Number of Bits to 8, with a Binary Point of 0, ... LEDs. The...

CASPER Reference Design

Tutorial (v1.1) December 18, 2009 1

Tutorial CASPER Reference Design

Author: Henry Chen

December 18, 2009 (v1.1)

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.



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, it‟s 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.



Configure the block to have:

I/O direction of From Processor.

Data Type of Unsigned

Data Binary Point of 0

Sample Period of 1



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

won‟t 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 extremes—a 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 design—i.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 block‟s output is connected to a Slice block‟s 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, you‟ll 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. We‟d 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 we‟re 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 isn‟t 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 haven‟t 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_<yyyy_mmm_dd_hhmm>.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.



Double-click on the Boundary Scan in the Modes pane. In the Boundary Scan pane that gets

opened, right-click 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 cascaded devices on the

JTAG chain: 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.



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_<datecode>.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.



In the Program Options dialogue box that pops up, select Device 2 (FPGA, xc2vp50) and turn

off Verify and turn on Pulse Prog, then click OK.



Right-click on the xc2vp50 icon and select Program.



iMPACT will begin programming the FPGA and show a progress bar:



When programming finshes, the “Program Succeeded” banner will be displayed. The IBOB‟s

LEDs should now be blinking in the specified pattern.

Revision History

Date Revision Changes

Dec. 18, 2009 v1.1 Updated iMPACT screenshots with 10.1 version.

June 23, 2007 v1.0 Initial revision.

Tutorial - casper.berkeley.edu · Number of Bits to 8, with a Binary Point of 0, ... LEDs. The...

Documents

Transcript of Tutorial - casper.berkeley.edu · Number of Bits to 8, with a Binary Point of 0, ... LEDs. The...