Course calendar and lecture notes

Project Steps & Grading

Download Files

1.  Stages & Deadlines

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 (2% 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 WISC-SP13 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 WISC-SP13 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 (32% of project grade)

Design a single-cycle, non-pipelined WISC-SP13 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 WISC-SP13 ISA, except for the extra-credit instructions. 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 wsrun.pl script (check the verification and simulation page for more info) and show that your processor works on the test programs (full list can be found in the Test Programs page). You should run tests under the following three categories:

1. Simple tests
2. Complex tests
3. Random tests for demo1
   1. rand_simple
   2. rand_complex
   3. rand_ctrl
   4. rand_mem

Use the -list option of wsrun.pl. It will generate a file called summary.log, which looks like below:

add_0.asm SUCCESS CPI:1.3 CYCLES:12 ICOUNT:9 IHITRATE: 0 DHITRATE: 0

add_1.asm SUCCESS CPI:1.7 CYCLES:7 ICOUNT:4 IHITRATE: 0 DHITRATE: 0

add_2.asm SUCCESS CPI:1.7 CYCLES:7 ICOUNT:4 IHITRATE: 0 DHITRATE: 0

A message of "SUCCESS" means test passed. Run all the categories and rename the summary.log files to the names shown below:

1. Simple tests: simple.summary.log
2. Complex tests: complex.summary.log
3. Random tests for demo1
   1. rand_simple: rand_simple.summary.log
   2. rand_complex: rand_complex.summary.log
   3. rand_ctrl: rand_ctrl.summary.log
   4. rand_mem: rand_mem.summary.log

Notes on Grading:

• The log files MUST have the exact names. These are the log files produced by running wsrun.pl -list. You will have to rename summary.log manually into these names. If your handed-in code does not follow this convention, it will not be accepted and you will receive a zero for this demo. If in doubt about what to submit, email the TA before the deadline.
• If you have more than two failures in the simple 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[15:0] >-------|             |--------> data_out[15:0] 
     addr[15:0] >-------| 65536 word  | 
         enable >-------| by 8  bit   |
             wr >-------| memory      |
            clk >-------|             |
            rst >-------|             |
     createdump >-------|             |
                        +-------------+

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

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 file, "loadfile_all.img". You may change that in the Verilog source to any filename you prefer. The file is loaded at the first rising edge of clock during reset. The simulator will look for the file in the same location as your .v files (or the directory from which you run wsrun.pl). The file format is:

  @0
  12
  12
  12
  12

where "@0" specifies a starting address of zero, and "12" represents any 2-digit hex number. Any number of lines may be specified, up to the size of the memory. The assembler will produce files in this format.

At the end of a simulation, the memory can produce a dump file so that you may check what has been written to the memory. When createdump is asserted at the rising edge of the clock, the memory will create a file named "dumpfile" in the directory. You may want to use the decode of the "halt" instruction to assert createdump. The dump file will contain locations zero through the highest address that has been modified with a write cycle (not the highest address loaded from the load file). The format is:

  0000 1234
  0001 1234
  0002 1234

Examining the source file memory2c.v, several possible changes should be obvious. The names of the files can be changed. The format of the dump file may be changed by modifying the $fdisplay statement; the syntax is very similar to C's fprintf statement. The starting and ending addresses to dump may be modified in the "for" statement. The only thing that cannot be modified is the format of the load file - that is built-in.

When you have two copies of the memory, one for instructions and the other for data, you may want to let both memories load the same load file, but only have the data memory generate a dump file.

The way to load a program for your processor is using the assembler, which will create a memory image of assembled machine code (named loadfile_all.img by default). Put that image file in the directory where memory2c.v stays, and rename it if you have changed the filename that memory2c expects.

5.  Demo #2 - Pipelined Design (32% 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.

You must also submit a document named titled instruction_timeline.pdf which gives an explanation of the behavior of your processor for the perf-test-dep-ldst.asm test. Please use the following format:

The Instruction Retired field would either be one of the instructions from the test program or a "NOP" if dependencies necessitate any stall cycles. The Reason column should give an explanation of why a stall was needed in that instance.

Again, you should also include a bunch of summary.log files:

1. Simple tests: simple.summary.log
2. Complex tests for demo1: complex_demo1.summary.log
3. Random tests for demo1
   1. rand_simple: rand_simple.summary.log
   2. rand_complex: rand_complex.summary.log
   3. rand_ctrl: rand_ctrl.summary.log
   4. rand_mem: rand_mem.summary.log
4. Complex tests for demo2: complex_demo2.summary.log
5. Results for your own tests: mytests.summary.log

Notes on Grading:

• The log files MUST have the exact names. These are the log files produced by running wsrun.pl -list. You will have to rename summary.log manually into these names. If your handed-in code does not follow this convention, it will not be accepted and you will receive a zero for this demo. If in doubt about what to submit, email the TA before the deadline.
• 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 (32% of project grade)

All information on cache design can be found on the Cache Design page.

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.