Lab 1 - Single-Cycle LC4 Processor

CIS 372 (Spring 2009): Computer Organization and Design Lab

Regfile behavioral simulation demo due Friday, 2/20, 6:30pm

Writeup and board demo due Friday, 3/6, 6:30pm

This lab is worth 50 points.

Announcements and Addenda

3/15, maelstrom trace file posted.

2/25, lab due date changed to Friday, 3/6.
2/25, a note about implementing comparisons in hardware. Evidently, I goofed on this explanation in 240 this fall. Thanks to Lei for pointing this out.

2/25, some people have experienced strange clocking behavior using ModelSim. Here is a slightly modified version of test_lc4_single.tf that will hopefully fix the problem. Here is a cleaned up version of bram.v that goes with this new version.

2/24, I put up a new version of PennSim (with the video wrap-around fix), a new version of maelstrom.hex (with same, plus nicer game reset) as well as a gzipped tarball containing the object and symbol files used to create the maelstrom binary. You can load and run these in PennSim using the command line 'java -jar PennSim.jar -s run.script' so you can see step by step how each instruction is supposed to execute. This may help in debugging.

2/23, here is a summary of the board debugging features
2/20, here is a new version of the test_lc4_regfile.tf test fixture. This one tallies up the number of errors in the run and prints it explicitly at the end.
2/20, and here is a new version of the one_pulse.v signal to pulse converter. This module converts a signal that may span multiple clock cycles to one that spans a single clock cycle. It is used to convert button presses to single-cycle events. The most important use of this is clock single-stepping. The previous implementation was susceptible to "bouncing" and so sometimes when you single-stepped the clock, it actually stepped by 2, 3, 4, or 5. This made it difficult to board debug. This new implementation fixes the bounce problem.

Overview

In this lab, you'll combine your timer from lab0 with a register file, ALU, controller, and other datapath elements to create a single-cycle LC4 processor.

A skeleton implementation, including Verilog code for the memory and all of the devices (except for the timer), user constraints, and the maelstrom memory image on which your processor will be tested is included in the compressed tarball lab1_skeleton.tgz. To extract the tarball, type 'zcat lab1_skeleton.tgz | tar xvf -' at the eniac command line.

LC4 Processor Module

The processor module is in the file lc4_single.v. Most of your code should go into this file, although you can create and use auxiliary files for sub-modules like the register file, ALU, and controller.:

module lc4_single(CLK, RST, GWE,
                   IMEM_ADDR, IMEM_OUT, 
                   DMEM_ADDR, DMEM_IN, DMEM_OUT, DMEM_WE);

  input         CLK;         // main clock
  input         RST;         // global reset
  input         GWE;         // global we for single-step clock

  input [15:0]  IMEM_OUT;    // output from insn. memory
  input [15:0]  DMEM_OUT;    // output from data memory
  output [15:0] IMEM_ADDR;   // insn. memory address (i.e., current PC)
  output        DMEM_WE;     // data memory write-enable
  output [15:0] DMEM_ADDR;   // data memory address
  output [15:0] DMEM_IN;     // input to data memory

  // YOUR CODE GOES HERE
  ...

endmodule

You will notice that lc4_single has instruction and data memory signals declared in its external interface. The top module is lab1.v which instantiates the processor, memory, and devices, and interconnect them to each other and to the pins. In Xilinx, you must set lab1.v as the top module or else you will only synthesize the datapath and will not have a full working system.

The tarball includes a test fixture for the datapath.

Register File

You have full control over the design of the datapath, but one element whose interface will be fixed is the register file. We are setting design and test of the register file as an intermediate milestone to encourage you to get started promptly.

The LC4 ISA uses eight registers and follows a two-input, one-output operation format. As such, the register file should have eight registers accessed via two read ports and one write port. The register file will be in the file lc4_regfile.v.:

module lc4_regfile(CLK, RST, GWE,
                   r1sel, r1data, r2sel, r2data, wsel, wdata, we);

  input CLK, RST, GWE;
  input [2:0] r1sel, r2sel, wsel;
  input we;
  input [15:0] wdata;
  output [15:0] r1data, r2data;

  // YOUR CODE GOES HERE 
  ...

endmodule

In a given cycle, any two registers may be read and any register may be written. A register write occurs only when the we signal is high. If the same register is read and written in the same cycle, the old value will be read (not the new value being written).

To encourage you to perform bottom-up testing of your design, we're giving you a testbench for testing just the register file component. This testbench uses VPI file IO which are not supported by ICARUS. You need to run this testbench on ModelSim.

Datapath

You have the freedom to implement the datapath and control any which way you want. We strongly suggest that in addition to the regfile, you split out the ALU and decoder/controller into separate modules. All in all, the entire system should be about 150-200 lines of Verilog.

Verilog Restrictions

This synthesizable part of this lab should be implemented using the structural and behavioral Verilog subset as in presented in the class notes. The only state element you are allowed to use for synthesis is Nbit_reg. You are allowed to use behavioral Verilog and reg primitives in test fixtures. If you're not sure if you're allowed to use a certain Verilog construct, just ask (post a message on the newsgroup, send an e-mail, etc.).

Demos

You'll have to demonstrate that your design works using both simulation and the hardware prototyping boards:

Regfile Behavioral Simulation: Use the regfile testbench to demo your register file. You must do this by 2/20, at 6:30pm.
Full Processor Hardware: You'll demonstrate that your design works correctly on your board using the maelstrom hex file we give you. You must do this by 2/27, at 6:30pm.

Writing Your Own Tests

You can use PennSim to compile your own LC4 code and generate hex files for testing. You can run PennSim from the command line like so: java -jar PennSim.jar -t.

What to Turn In

Pencil and paper datapath: by 2/20, 6:30pm

Turn in a pencil and paper drawing of your datapath with all of the paths and control signals labeled. Turn in a separate sheet with the values of each of the control signals for the following LC4 instructions: ADD, HICONST, CMPU, LDR, STR, BRn, JSR, TRAP.

Final Writeup: by 2/27, 6:30pm

Your writeup should include your Verilog code. Not the Verilog code we gave, just the stuff you wrote. As before, your Verilog code should be well-formatted, easy to understand, and include comments where appropriate (for example, use comments to describe all the inputs and outputs to your Verilog modules). Some part of the project grade will be dependent on the style and readability of your Verilog, including formatting, comments, good signal names, and proper use of hierarchy.

Also hand in an annotated schematic in which the different modules, interconnection buses and control signals are named with the names you use in your Verilog code. This can be a copy of the datapath you handed in a week earlier provided you thought of everything and didn't make any changes.

Finally, answer the following questions:

What is the delay of your datapath? What is the maximum "big clock" frequency at which it operates?

Once you had the design working in simulation, did you encounter any problems getting it to run on the FPGA boards? If so, what problems did you encounter?

What other problems, if any, did you encounter while doing this lab?

How many hours did it take you to complete this assignment?

On a scale of 1 (least) to 5 (most), how difficult was this assignment?

What was the group division of labor on this assignment, in both hours and functional and debugging tasks?