Project Deadlines and Grading

Project Steps & Grading

Download Files

---

1.  Stages & Deadlines

Date	Project
14-Feb	Form Project Groups
20-Feb	Design Review
26-Mar	Demo 1
8-Apr	Demo 2
16-Apr	Cache FSM turnin
23-Apr	Cache Demo
5-May	Final Demo

There are four major deadlines over the course of your term project design, which will be met in the form of project demos with the course TA and a final project report. The project will be done individually this semester.

Everyone should be well prepared before showing up to a demo. Time is limited and your grade may be negatively impacted if the demo could not be completed. Be sure that the designs you hand in work without alteration in such a way that the TA could easily compile and simulate the design without special instructions.

You can think of this project as having roughly six stages of development with several demos along the way.

1. You will first build a single cycle non-pipelined processor with a highly idealized memory
2. Your processor can then be pipelined into distinct stages but while still using a highly idealized memory
3. The memory will then be transitioned to using a more realistic banked memory module that cannot respond to requests in a single cycle
4. A cache can then be implemented that can be used to improve the now degraded memory performance

---

2.  Project Plan (2% of project grade)

Each student needs to turn in a typed report (one to two page single-spaced) describing your project design and test plan. You are expected to develop a detailed schedule identifying key milestones. Make sure that your schedule takes into account the remaining homework assignments and your other course obligations (e.g., midterms).

You must have thought about the design at a high level. The plan you come up with will be your master plan for the semester and you might be asked to update/revise the plan as we go along. In addition to the design, you are expected to develop a detailed test plan, including high-level descriptions of components, modules, and tests.

Look through the calendar for design review, demo-1, demo-2, and cache demo deadlines and plan your work accordingly. These dates are non-negotiable and you must adhere to them. There will be a signup for a 10-minute meeting for design review. Depending on how things shape up, we may do signup and meetings for demo-1, demo-2, and cache-demo also.

---

3.  Design Review (3% of project grade)

Each student needs to create a complete hand-drawn (or drawn with the aid of a graphing program like Openoffice draw) schematic of an unpipelined RISC-V implementation. Each module, bus, and signal should be uniquely labeled. The schematic should be hierarchical so that the top-level design contains only empty shells for each planned submodule. In general, there will be a one-to-one mapping of modules in your schematic to the modules you will eventually write in Verilog. The textbook pipeline diagram is a good starting point but there are many differences between it and the ISA for this project. You will need to look at the RISC-V ISA specification and make sure to adapt it to that.

While explicitly drawing pipeline stages in the schematic is not required, you should still design with a pipeline in mind. It is a good idea to place modules near their final location in the pipelined design.

We will go through your Canvas submissions and give comments as feedback. For incomplete submissions (or submissions with potentially serious flaws), we will arrange one-one meetings to help you catch up with the project pace. Not necessary to have done a complete table of signals, but if you have such a table with the control signal values for every instruction, that would be great.

---

4.  Demo #1 - Unpipelined Design (20% of project grade)

Design a single-cycle, non-pipelined RISC-V processor. For this stage, you will use the single-cycle perfect memory. Since you will need to fetch instructions as well as read or write data in the cycle, use two separate memories -- one for instruction memory and the other for data.

Your design should be running the full RISC-V ISA specified here. It should use a single-cycle memory model. Your modules must all pass Verilog rules check.

It is highly recommended to modularize your design. Put each of the 5 MIPS stages into a separate sub-high-level module. In this unpipelined version, your proc.v probably should not be more complex than five module instantiations.

In the demo, you will run a set of programs on your processor using the provided Makefile found in the project git repo (check the verification and simulation page for more info) and show that your processor works on the test programs (details can be found in the Test Programs page).

In order to run the provided tests easily, you should run the make all_regr REGR_TL=(testlist name) MODE=nopipe command from the /wiscv/tb directory. It will generate a file called regression_summary.log in a generated folder in the /wiscv/tb directory. The two provided testlists that can be used for regression testing are named unit_tests and random_tests. You should run both, one at a time, and save the generated log files as the following:

1. Unit tests: unit.summary.log
2. Random tests: random.summary.log

Note: The generated directory name can be manually set if the RUN_DIR flag is modified.

Notes on Grading:

• If you have more than two failures in the unit tests, you will automatically lose 75% of demo1 grade. You should do rigorous testing and verification and should try to have zero failures on other categories. It is fine to have a very small number of failures - but for every failure, you must know the reason. You will submit your design electronically, which will be graded automatically. The instructor will then schedule one-on-one appointments with teams that have exhibited a large number of failures.
• If the log files are missing, you will automatically get zero points.

What to submit:

• Check the Handin Instructions page.
• Make sure you run the Verilog rules check on all the files. Not necessary to run it on your testbench.

4.1  Single-cycle Memory Module Specification

Since your single-cycle design must fetch instructions as well as read or write data in the same cycle, you will want to use two instances of this memory -- one for data and the other for instructions. You should instantiate this memory module twice. One instance will serve as the instruction memory while the other will serve as the data memory. Note that the program binary should be loaded into both instances. This will indeed be done (without any additional effort from your side) if you use the same module definition for both instances.

                        +-------------+ 
  data_in[31:0] >-------|             |--------> data_out[31:0] 
     addr[15:0] >-------| 65536 word  | 
         enable >-------| by 32 bit   |
             wr >-------| memory      |
            clk >-------|             |
            rst >-------|             |
                        |             |
                        +-------------+

During each cycle, the enable and wr inputs determine which function this memory will perform:

enable	wr	Function	data_out
0	X	No operation	0
1	0	Read	M[addr]
1	1	Write data_in	0

Behavior:

• In a read cycle, the data output will immediately reflect the contents of the address input and will change in a flow-through fashion if the address changes.
• For writes, the wr, addr, and data_in signals must be stable at the rising edge of the clock (clk).

The memory is initialized from a hex file located, by default, in the wiscv/tb/(progam name)_sim directory, where program name is whatever program specified by the PROG flag, which is generated after running make all PROG=name_of_prog MODE=nopipe.

However, the name of the generated directory can be modified by setting the RUN_DIR flag to whatever value you would prefer (e.g. make all PROG=name_of_prog RUN_DIR=add_sim MODE=nopipe. This will create a directory named add_sim within the wiscv/tb directory). The makefile will automatically load the hex file into your design from this directory without any additional effort required on the student's end.

---

5.  Demo #2 - Pipelined Design (30% of project grade)

For this demo, a pipelined version of your design needs to be running correctly, but no optimizations are needed yet. "Correctly" means that it must detect and do the right thing on pipeline hazards (e.g., stalling). You will still use the single-cycle perfect memory model. We will follow a similar protocol as demo1. I will run your tests and ask teams with any failures to signup for a demo with me.

We recommend that you write at least two additional hand tests to test for pipelining. This will help simplify debugging. If you write additional tests, include them in verification/mytests/ folder.

For your own tests, follow the instructions here, and then run them using the makefile according to the normal method (where the value of the PROG flag would be the name of your assembly file).

For the time being, simply make sure that your unit tests and random tests pass with your pipelined design, as described in the non-pipelined section of this page.

• In this demo, you will also synthesize your processor and submit the results of synthesis, including the area, cell, and timing reports. If there are any synthesis errors you will get ZERO for the entire demo2. The longest paths in the timing report should not show the work of multiple stages being done in the same cycle, e.g., loading from memory, forwarding to the ALU, and performing the ALU operation in the same cycle. If your longest path from synthesis includes the work of multiple stages your processor is not properly pipelined and might be significantly marked down.

What to submit:

• Check the Handin Instructions page.
• Make sure you run the Verilog rules check on all the files. Not necessary to run it on your testbench.

---

6.  Cache Demo - Two-way Set-associative Cache (15% of project grade)

All information on cache design can be found on the Cache Design page (Note: This page is currently under construction).

What to submit:

• Check the Handin Instructions page.
• Make sure you run the Verilog rules check on all the files. Not necessary to run it on your testbench.

---

7.  Demo #3 - Cache Integration and Optimizations (30% of project grade)

At this final demo teams are expected to demonstrate the complete design to all specifications. This includes the following required items:

1. Two-way set-associative caches with multi-cycle memory
2. Register file bypassing
3. Forwarding from beginning of the MEM stage to beginning of EX stage (EX → EX forwarding)
4. Forwarding from beginning of the WB stage to the beginning of the EX stage (MEM → EX forwarding)
5. Branches predicted not taken

When implementing your forwarding remember to not implement it in such a way that the work of multiple pipeline stages occurs along a single combinational path or you will lose credit for violating the pipelining.

WARNING: There are a couple common issues in this phase when integrating your stalling memory and/or cache design into your pipeline:

• Multi-cycle cache hits: if your Phase 2.3 has multi-cycle cache hits (i.e., hit latency

> 1), then I strongly suggest you allow your pipeline to “drain” when one cache misses. For example, if the Instruction Cache misses, some students will chose to stall the entire pipeline until this miss is handled. However, with multi-cycle hits this will often lead to situations where the Instruction and Data Caches each are not ready perfectly out of phase with one another – causing infinite loops. By draining the pipeline (e.g., letting D, X, M, and W proceed when F is stalling due to the Instruction Cache), your processor will be able to make forward progress and avoid this infinite loop

• Interaction of Branches/Jumps with Multi-cycle Cache hits: Another common

problem is when branches/jumps resolve while your multi-cycle cache access is happening. In this case, there are several possible solutions, including halting the rest of the pipeline while the Instruction Cache access completes (beware the above problem though), storing the taken branch and updating the PC once the Instruction Cache finishes, and immediately updating the PC when the branch resolves – and then checking when the Instruction Cache completes if the instruction it fetched should be ignored. Regardless of which approach you choose, this is a problem you should be aware of.

Hand in format will be similar to demos 1 and 2.

What to submit:

• Check the Handin Instructions page.
• Make sure you run the Verilog rules check on all the files. Not necessary to run it on your testbench.

---