CSE141L Lab 1: Tools of the Trade

CSE 141L Homepage | Lab Overview | Lab Description | Useful Resources

Jump to: Part 1 | Part 2 | Part 3 | Part 4 | Part 5 | Part 6

We encourage you to also work in the CSE labs in the basement of the CSE building. These software tools should be installed on the Windows partitions of all the computers in the lab after the second week of class. Please let us know (via the web forum) if you find lab computers that don't have these tools installed or have an older version of the software. Since the necessary tools will not be installed in the basement labs in time for this first lab, please install the tools on your own machine; the tools are available for Windows and Linux. If you cannot do this, please speak with the professor ASAP.

At AwesomeCore, we just bought a couple new Cyclone II FPGAs. To get you started, your manager has given you a Verilog file (adder.v) that describes a basic 8-bit adder. Look at the file and make sure you understand it thoroughly. After doing so, create a new project in Quartus II that contains this adder. When creating the project, set the device to Cyclone II EP2C35F672C6 and simulator to ModelSim-Altera with Verilog HDL.

Note: the Altera tools don't seem to like spaces in filenames and paths, so don't use spaces in any filenames or directory names. This includes the "My Documents" directory; you can create your project on your network drive, which "My Documents" points to anyway--just don't specify the project location using the "My Documents" shortcut. There is a post on the discussion board with a little more detail.

To see what is really going on, perform a behavioral (a.k.a. functional) simulation. Use test_adder.v as your testbench. When you've run the simulation, you should see something like what's in the figure below. Play around ModelSim (and perhaps the testbench) until you feel comfortable with it. You'll be using ModelSim as your primary debugging tool to debug your processor designs this quarter, so get familiar with it.

You might have noticed that output 'isOdd' is updated one cycle later than 'out'. (Stupid...who wrote this?) Anyway, it is a good opportunity to show your ability to tweak a design to get maximum performance. Modify the Verilog file so that 'isOdd' is simultaneously updated with 'out'. Perform the same behavioral simulation you did in the previous step again. (Hint: You may want to examine blocking vs non-blocking assignment in Verilog.) Note: When updating your adder.v, both 'out' and 'isOdd' should be updated the cycle after the input(s) change, not two cycles later.

Now that you have verified that your adder is functionally correct, it is time to synthesize. In the synthesis stage, Quartus translates your Verilog design to what its backend stage (implementation stage) can understand. To synthesize a design, double click on "Analysis and Synthesis" in the Tasks pane. When synthesis is done skim through the generated reports.

Now you'll want to see how your design maps onto the FPGA device. The stage where the design tools find a good layout on the device is called "Place and Route". Run this stage by double clicking on "Fitter" in the Tasks pane. Skim through the generated reports.

Now that the design tools have mapped your design to an FPGA, you can estimate timing and figure out how fast your adder will operate. Now run the whole design compilation chain, which includes a timing analysis: go to "Processing" - "Start Compilation". Look over the reports in the "Classic Timing Analyzer" section. The frequency in the "Clock Setup" section is the maximum clock frequency at which your adder will run. The "tco" is the maximum amount of time from the active clock edge input to the output arriving at an output pin. For more information on timing analysis in Quartus II, see the tutorial on timing.

In order to prove that your adder works at a certain frequency, you need to do a post-route simulation. By comparing the results of your behavior simulation with post-route simulation, you can verify the validity of your implementation. Luckily, you can reuse the testbench from the behavior simulation you did earlier, and the process for running the simulation is very similar. Since the tutorials do not cover how to run timing simulations using ModelSim and a Verilog testbench, here are the instructions you'll need to get started:

1. Make sure to run the entire compilation process in Quartus II (including "EDA Netlist Writer").
2. Open ModelSim.
3. Select "File" - "Change Directory..." and navigate to the "simulation" and then "modelsim" subdirectories under your adder project directory.
4. Select "File" - "New" - "Library..." and select "a new library and a logical mapping to it". Name the library "work" and enter "work" for the library physical name as well. You should then see the "work" library at the top of the library list.
5. Select the work library and select "Compile" - "Compile...". Select "adder.vo" and then click "Compile". Then navigate to "test_adder.v" (the same testbench file you downloaded before and used for your functional simulation), which should be a couple directories up. Click "Compile" with "test_adder.v" selected. Then click "Done". Now, in the library list, if you expand the "work" library, you should see "adder" and "test_adder". In the future, if you make any changes to adder or testbench Verilog source, you'll need to re-compile the "work" library before re-simulating.
6. Select "Simulate" - "Start Simulation".
   1. In the "Design" tab, expand the "work" library and highlight "test_adder". Select "ns" in the "Resolution" drop-down field.
   2. In the "Libraries" tab, in the "Search Libraries" area, select "Add" and add the "cycloneii_ver" library.
   3. In the "SDF" tab, select "Add". Add "adder_v.sdo" and apply it to the region "/test_adder/dut".
   4. Finally, click on "OK" to start the simulation. After this, use ModelSim to run the timing simulation in the same manner you used it to run the functional simulation.

Q5

Include the two simulation results (behavioral and post-route) in your report. Are they the same as each other? If not, why are they different? If needed, modify the test bench file and make sure post-route simulation works correctly. (Hint: Behavioral simulations do not have a sense of frequency while post-route simulations do.)

Part 4: 32-bit Adder

Now that you have a working, validated 8-bit adder, you should turn your attention towards bigger and better designs. One simple extension you can do is to modify your adder to support 32-bit addition rather than just 8-bit. Modify your Verilog source file then synthesize and implement it.

Generally, the bigger and more complex your design is, the slower it will be. It is important to understand the main causes of this phenomenon:

• Bigger/more complex logic usually requires more logic cells for implementation. This will often lead to an increase in logic delays.
• Increasing the number of logic cells also increases the difficulty of finding the optimal placement and routing for the circuit. As a result, you end up with a suboptimal circuit which is slower than it could be.

Q6

Since your FPGA has limited hardware resources and you are always concerned about your performance, you should try to characterize the cost of different sizes of adders. Fill out the following table with information on adders ranging from 8 bits to 64 bits. Width Max Freq # of logic cells used # of registers used 8-bit       16-bit       32-bit       64-bit

Part 5: Register File

Now that you are a master of adders, it is time to move on to bigger and better things. Your next task is to design a register file. Go ahead and create a new project for your register file design. Processors keep a small, but extremely fast collection of storage locations, called registers, grouped into what is called a register file. You'll design a register file with 2 read ports and 1 write port, so that every cycle two registers can be read and one written. You should parametrize your register file with number of registers and data width (the number of bits in each register). You can set the default parameters to 6 16-bit registers. Your register file should take as input:

• a clock signal (call it clock)
• a write_enable signal (asserted when a value is to be written to a registers)
• a write register number (call it write_reg) to specify which register to write
• a value to write to the given register (call it data_in)
• and two register numbers to select which registers to read (call them read_reg0 and read_reg1).

Your register file should have two outputs (data_out0 and data_out1) to return the values read from the specified registers.

On every rising clock edge your register file should save whatever value is on data_in into whatever register number is specified in write_reg if write_enable is high. In this register file, while writes are synchronous (happening only on rising clock edges), reads are asynchronous. Anytime read_reg0 or read_reg1 changes, the value(s) in the newly-specified register(s) should be output on data_out0 and/or data_out1 immediately (or as fast as the logic and signal propogation will allow). Below is a part of a wave (from a behavioral simulation) demonstrating the desired register file behavior. Later in the quarter when you design the register file for your processor, you'll have to decide what kind of timing semantics your register file will need to support. Based on how it fits in with the rest of your processor design, it may make sense to have it support synchronous reads, for example.

Synthesize and Place and Route your design. Then create a testbench in Verilog to test your register file design. Test a variety of inputs including all the corner cases you can think up. Use ModelSim to perform a behavioral (not timing) simulation of your design and verify correct operation.

Q7	Include the Verilog code for your register file and your register file testbench in your report. Also include a screenshot of part of your simulation wave demonstrating correct operation (for just a couple of sample inputs and outputs).

In order to get an estimate from the Altera tools of the maximum clock frequency of a design, there needs to be, at minimum, two flip-flops with wires and logic in between them. Then the tools can tell you the estimated maximum frequency based on how long it takes values to leave one flip-flop, pass through the wires and logic, and safely arrive at the other flip-flop. Since your register file design should not have any logic and wires between registers (just logic and wires around registers), you will not be able to estimate maximum frequency unless you sandwich your register file between some flip-flops (i.e. you latch its inputs and outputs somewhere). To facilitate this, use this wrapper module. Below is a schematic showing how the wrapper is sandwiching your register file between flip-flops. You should change its parameters each time you chage the parameters for your register file. You should probably create a new project for the wrapped register file which should include the register file wrapper and your register file (with the wrapper as the top-level design element); if you just add the wrapper to your exisiting register file project, the tools may not recognize the wrapper as the top-level design element.

Q8

Fill out the following table for register files of different configurations. Note that some register files might not fit in the FPGA device due to their demands on resources. In such cases, explain the reason. Configuration Max Freq # of logic elements used # of flip-flops used 8 16-bit registers       16 16-bit registers       32 16-bit registers       32 64-bit registers       256 32-bit registers

Part 6: Free Form Experiment

Now that you have gotten a feel for working with the Altera tools, it is time to play around with them.

Q9	Design an experiment that answers some kind of question you have about the tool, and report on the results. The best free-form experiments will be highlighted in the class.

---

Useful Resources

• All Altera Tutorials
• Refer to the class handouts for Verilog commands and style that you are allowed to use in this class. If you would like to propose that we add a construct to the class lexicon, post to the webboard with your argument as to why we should include it.
• Avoid as much as possible referring to the web for verilog, since much of it is not SYNTHESIZABLE. Much of it is also incorrect, and not written by real hardware designers.
• Altera DE2 board: Information about the DE2 boards (featuring the Cyclone II EP2C35F672C6) that we have in the department (if you want to go a step further and burn your design onto a real FPGA).

---

This lab created by Donghwan Jeon, 2007. Modified by Sat Garcia, 2008. Modified by Matt DeVuyst, 2010.