Overview and Specifications

In this final lab of the semester, you will design and build a scalar five-stage pipelined processor for the LC4 ISA. Your pipeline will target frequency (of course) and IPC (via bypassing and branch prediction). As usual, I am providing you with skeleton code. The pipeline skeleton and all of the supporting modules are in this compressed tarball. Most of your code will be in the file lc4_pipe.v, whose current contents are given below. You may want to split out large sub-components of your pipeline, like the register file, ALU, and branch predictor, into seperate files.:

module lc4_pipe(CLK, RST, GWE,
               IMEM_ADDR, IMEM_OUT,
               DMEM_ADDR, DMEM_OUT, DMEM_IN, DMEM_WE,
               // options
               BPRED_ON, BYPASS_ON,
               // debug interface
               _TEST_W_PC,
               _TEST_W_STALL,
               _TEST_W_INSN,
               _TEST_W_REGFILE_DATA_IN,
               _TEST_W_REGFILE_WE,
               _TEST_W_NZP_IN,
               _TEST_W_NZP_WE,
               _TEST_W_DMEM_ADDR,
               _TEST_W_DMEM_IN,
               _TEST_W_DMEM_WE,
               _TEST_PMC_CYCLE,
               _TEST_PMC_INSN,
               _TEST_PMC_LOAD_STALL,
               _TEST_PMC_BRANCH_STALL);
                               
  input         CLK;   // main clock
  input         RST;   // global reset
  input         GWE;   // global we for single-step clock
  
  output [15:0] IMEM_ADDR;   // instruction address
  input [15:0]  IMEM_OUT;    // output from data memory
  output        DMEM_WE;     // data memory write-enable
  output [15:0] DMEM_ADDR;   // data memory address
  input [15:0]  DMEM_OUT;    // output from data memory
  output [15:0] DMEM_IN;     // input to data memory

  input         BPRED_ON;    // branch prediction is on
  input         BYPASS_ON;   // bypassing is on
  
  output [15:0] _TEST_W_PC;
  output [15:0] _TEST_W_INSN;
  output [15:0] _TEST_W_REGFILE_DATA_IN;
  output        _TEST_W_REGFILE_WE;
  output [2:0]  _TEST_W_NZP_IN;
  output        _TEST_W_NZP_WE;
  output [15:0] _TEST_W_DMEM_ADDR;
  output [15:0] _TEST_W_DMEM_IN;
  output        _TEST_W_DMEM_WE;
  output        _TEST_W_STALL;
  
  output [15:0] _TEST_PMC_CYCLE, _TEST_PMC_INSN, _TEST_PMC_LOAD_STALL, _TEST_PMC_BRANCH_STALL;
  
  // YOUR CODE GOES HERE
  
  always @(posedge CLK)
    if (GWE)
      begin
         $display("--------------------------------------------------------------------------------");
         $display("F:");
         $display("D:");
         $display("X:");
         $display("M:");
         $display("W:");
      end
  
endmodule // lc4_pipe

The pipeline module interface is a superset of the single-cycle module interface. The CLK, RST, GWE and instruction and data memory interfaces are the same. However, there are two additional mode switches (BPRED_ON and BYPASS_ON), a bunch of output signals that start with _TEST_W_, and four output signals that start with _TEST_PMC_. The _TEST_ outputs will be used for debugging and test fixtures only. There is also skeleton behavioral code for displaying interior values. You can modify this code to create print-out snap-shots of pipeline that you can observe in ModelSim to help you debug.

Anyway, here are the basic specifications for the pipeline.

Demos

There will be two demos.

• Preliminary demo by Friday, April 17: Demonstrate that your basic pipeline works on the board (i.e., runs maelstrom). Bypassing and branch prediction do not have to be working at this point. Neither do the performance counters.
• Final demo by Friday, May 1: Demonstrate the fully-working design, including bypassing, branch prediction, and performance counters. In addition to maelstrom, we'll give you some additional testing programs that will test both the functional and timing correctness of your design. We'll also record the CPIs of the benchmark suite programs we gave you.

All group members should be present at the demos. All group members should understand the entire design well enough to be able to answer any such questions.

Writeups

There will also be two writeups.

• Preliminary Design Document due Friday, April 3. Designing a pipelined processor is significantly more complex than designing a single-cycle version of the same processor. Before you begin writing the Verilog code, you should think through the design carefully. You'll want to consider how the datapath is broken into stages, identify which values need to be propagated in pipeline latches, uncover any tricky bypassing cases, and decide upon a strategy for stalling the pipeline and recovering from branch mispredictions. Don't spend a lot of time polishing this document, but do include:
  • Design decisions: Describe in prose any high-level design decisions for your pipelined datapath. This should be a substantial portion of this part of the design document.
  • Pipeline diagram: You'll probably want a pipeline datapath diagram. You can draw out the diagram on a single page or use one page per pipeline stage (it is actually hard to fit it all on one page).
  • Pipeline registers: Give a table or list that describes which values you're latching between which stages. Give these signals good names that you'll then use in your actual Verilog code. For example, you might want to call the PC in the fetch stage F_PC, the PC in the decode stage D_PC, and latch between the stages the FD_register. You'll want every signal prepended with either F, D, X, M, or W to distinguish in which stage the signal belongs.
  • Implementation plan: Which group members are going to do what part of the implementation? Which part will be done first? What can be done at the same time? What must be done consecutively?
  • Testing plan: How are you going to test your design? Both for functional correctness and performance correctness.
• Final Writeup due Friday, May 1: The final writeup should include:
  • Design update and retrospective. Write a "design retrospective", focusing on what you learned during the design that you wish you would have known when you began the implementation. Even if you scored well on your initial design document, you'll probably have uncovered a lot of additional information in your final lab writeup. In the end, how did you actually implemented bypassing and stalling? How do the performance counters work? Etc. Basically, describe how your design changed and evolved over time, what parts you left out of the design document, which parts you got wrong, and assess the effectiveness of your approach to testing and debugging your implementation. This shouldn't (just) be a narrative of what when wrong; instead, it should be a deep analysis of your original design. You also might want to include things that, in retrospect, you wish you could go a month back in time and tell yourself concerning the lab.
  • Clock period and CPI analysis: More info about this soon.
  • Verilog code. As before, your Verilog code should be well-formatted, easy to understand, and include comments where appropriate. 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.
  • Answer the following questions:
    • What problems, if any, did you encounter while doing this lab?
    • How many hours did it take you to complete this assignment (total for entire group)?
    • What was the division of labor on the assignment between the group members?
    • On a scale of 1 (least) to 5 (most), how difficult was this assignment?

Hints

• The preliminary demo will make sure that you are on track. But you probably want to set some finer-grained intermediate milestones as well. For instance, you could create a short program in which all dependent instructions are separated by two explict NOPs. A program like this will run correctly on a pipeline that has no bypassing or stall logic. You can then add stall logic in stages. First, you can simply add two implicit NOPs before every instruction regardless of dependences. Then you can take dependences into account. Finally, add bypassing. And so on.
• Little test programs that you write yourself and that exercise specific bypass and stall conditions will be very helpful in debugging. Use these liberally.
• Use good signal names and comments. Using well-named signals and well-documented code will help you and your partner understand each other's code. Plus, this code is complicated enough and you'll be working on it over several weeks, so the comments really will pay off. I really cannot stress this enough.
• You should be able to reuse your register file and ALU from lab1. You may also be able to reuse your decoder/controller. You can do this by placing the decoder/controller in the decode stage, and then propagating the generated signals to the right stages using the pipeline latches.
• You will need to "bypass" around the register file. The register file you created in the last lab is somewhat different than the register file used in the pipeline described in the CSE371 lecture. When a register is read and written in the same cycle, our register file from lab1 returns the old value. For this pipelined design, we want it to return the newly written value. More specifically, if the register file write enable is asserted, and the register being read matches that being written, you'll write to return the new value being written (and not the old value). The simplest way to do this is to make a wrapper around the existing register file that does this bypassing locally. Note, this "WD" bypass is not real bypass. It should be on always, even when the BYPASS_ON signal is 0.
• Be careful not to bypass a value from a prior instruction that either doesn't write a register or an instruction that has been squashed due to a branch misprediction.
• Similarly, be sure not to falsely stall any instruction whose encoding might match the previous instruction's output register, but does not actually read the register. For example, the JUMP instruction doesn't read any registers, so it shouldn't be stalled just because the bits in its immediate field happen to match the output register of a prior load. Over-stalling is difficult to detect because it is a "performance bug" and not a "correctness bug". That is, you'll get the right answer, but your processor will have a worse CPI than it should.
• The NZP bits are implicit values that have to be bypassed between register writing instructions and conditional branches. Basically, you can think of the NZP bits as an additional register.
• In several places in the design, you'll have instructions that either (1) don't write a register value (for example, stores) or (2) don't read both input registers (for example, loads). You might consider encoding these cases using an explicit "valid" bit for each 3-bit register specifier. Doing so could dramatically simplify your bypass and stall logic.
• In a pipline with full bypassing, stalls can be implemented either in the Decode or eXecute stage. In a pipeline with no bypassing, stalls can only be implemented in the Decode stage. Because your pipeline should be able to operate both with and without bypassing, you should implement your stalls in the Decode stage.
• You can implement flushing and stalling (NOOP insertion) using the pipeline register reset (.rst) signal. Alternatively, you could mux in a NOOP into the pipeline latch.
• When a pipeline bubble arrives at the Writeback stage, it is difficult to figure out what caused it and which performance counter needs to be updated as a result. You will need to remember why different pipeline registers are cleared at those latches and then propagate the information forward. Careful, although you can reset the main pipeline registers, you should not reset the pipeline registers that track why the main pipeline registers were reset.