From CS552 Course Wiki: Spring 2013

Main: Course calendar and lecture notes

On this page... (hide)

  1. 1. Form team: (0.5% of project grade)
  2. 2. Project plan: (4% of project grade)
  3. 3. Design review: (4% of project grade)
  4. 4. Demo #1 - Unpipelined design (17.5% of project grade)
  5. 5. Demo #2.0 - Pipelined design with Perfect Memory (31% of project grade)
  6. 6. Demo #2.1 - Pipelined design with Aligned Memory (0% of project grade)
  7. 7. Demo #2.2 - Pipelined design with Stalling Instruction Memory Only : 1 week after demo 2.0 (0% of project grade)
  8. 8. Demo #2.3 - Pipelined design with Stalling Data Memory Only : 1 week after demo 2.0 (0% of project grade)
  9. 9. Demo #2.4 - Pipelined design with Stalling Instruction+Data Memory : 1 week after demo 2.0 (0% of project grade)
  10. 10. Demo #3 (final demo) - Pipelined Multi-cycle Memory with Optimizations (35% of project grade)
  11. 11. Final Project Report: May 9th (8% of project grade)

Deadlines and grading

Date Project
7-Feb Form project team (Feb 8th)
26-Feb Project plan
7-Mar Design Review
21-Mar Demo 1
16-Apr Demo 2
8-May Final demo
9-May Final report

There are three 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. During a demo, it is important that both team members posses a conceptual understanding of the entire design. Answers such as "I don't know, my partner did that" will not be acceptable. However, a response such as "I didn't implement that part of the design, but it works in the following way..." is perfectly fine.

Teams 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.

1.  Form team: (0.5% of project grade)

The project is done in groups of two. These groups should be formed no later than February 19th. Email me and the TA the group members and a unique team name. Your email should have the subject line: CS552 group creation. Also, update the course wiki's Project Teams page.

2.  Project plan: (4% of project grade)

Each group needs to turn in a typed report (2-3 page single-spaced) describing your project design and test plan. You are expected to develop a detailed schedule identifying key milestones and a breakdown of the tasks by project partner. Make sure that your schedule takes into account the remaining homework assignments and your other course obligations (e.g., midterms). Use the suggested Project Stages as a guideline.

You must have thought about the design at the high level and partitioning of work between you and your partner. The plan you come up will be your master plan for the semester and you will 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 component, module, and system tests. Include both project members names, email addresses, and team name on the report.

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

Bring this report to class on due date. One report per team is sufficient.

3.  Design review: (4% of project grade)

Each group 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.

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.

During the review, individual team members should be able to describe the datapath of any legal WISC-SP13 instruction using the schematic as a reference. Teams will also be expected to defend the design decisions that they make. You need to have thought through the control path and decode logic. 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.

Signup instructions are posted. You should sign-up for a time-slot in doodle. Write your team's name against a time-slot. If none works, discuss with your class mates about a possible swap. If you still cannot find a time-slot that works, email both the TAs and Karu.

In the doodle poll, use teamnames to signup.

Both partners are required to be present and both are expected to explain and answer questions about the whole design. Answering a question with: "I have no idea, my partner did that" is a failing answer. You must (at least) be able to answer: "My partner implemented that, but it works in the following way....".


4.  Demo #1 - Unpipelined design (17.5% of project grade)

At this milestone, you are expected to have a correctly functioning single-cycle, non-pipelined design. It should be running the full WISC-SP13 instruction set, except for the extra-credit instructions. It should use the single-cycle memory model. You should run vcheck and your files must all pass vcheck.

In the demo you will run a set of programs on your processor using the wsrun.pl script, show that your processor works on the test programs (full list in Test Programs page). You should run the 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

If you have more than two failures in the simple tests, you will automatically lose 75% of the demo1 grade.

Use the -list file to run each of the categories of test. When you run wsrun.pl with the -list option, 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

SUCCESS means the test passed. Run all the categories and rename the summary.log files as 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

You should do rigorous testing and verification and should try to have zero failures on the other categories. It is ok 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.

In this demo, you must also synthesize your processor and submit the results of synthesis, including the area and timing reports. If there are any synthesis errors you will get ZERO for the entire demo1.

Everything due before class.

  1. Electronic submission instructions
    1. Submit a single demo1.tar [ tar cvf demo1.tar verilog synthesis summary ]
    2. The folders should contain the following files
      1. verilog/ containing all verilog files. Please copy over ALL necessary files, your processor should be able compile and run with files from this directory alone.
      2. synthesis/ containing area_report.txt, cell_report.txt, timing_report.txt.
      3. summary/ containing the 6 summary.log files.

If the summary.log files are missing, you will automatically get zero points.


5.  Demo #2.0 - Pipelined design with Perfect Memory (31% of project grade)

At this point, the 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., stall). You will still use the single-cycle memory model. We will follow similar protocol as demo1. I will run your tests and ask teams with any failures to signup for a demo with me.

In this demo also, you must also synthesize your processor and submit the results of synthesis, including the area and timing reports. If there are any synthesis errors you will get ZERO for the entire demo1.

You must write a few additional hand tests to test pipelining. You must comment your tests appropriately and not use any infinite loops. You MUST have written at least two tests. I recommend many more to help simplify debugging. All these tests must be in verification/mytests/. They should all end with the extension .asm.

Everything due before class.

What to submit

Electronic submission instructions

 Submit a single demo2.tar file containing the following directories [tar -cvf demo2.tar verilog verification synthesis]
  1. verilog/ containing all verilog files. Please copy over ALL necessary files, your processor should be able compile and run with files from this directory alone.
  2. verification/mytests/ The assembly (.asm) files that you have written.
  3. verification/results/ Run all the categories and rename the summary.log files as 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
    4. Random tests for demo2: complex_demo2.summary.log
    5. Your code results: mytests.summary.log
  4. synthesis/ the area and timing report

Bring to class the following

You must submit a document (one per project team) which should include the following. Put the name of the team on the document and bring this to class:

  1. An explanation for each of the complex_demo2/perf-test-*:
    1. How many cycles does your processor take for each of those tests
    2. An annotated trace showing how/when your processor is stalling for each of those tests

Note: You dont have to turn in more than 1 page.


The next few demos are minor changes to your processor and you should plan on doing them very quickly. They are optional. No print or electronic submissions required. April 24th is simply a suggested date. Make sure all demo2 tests pass at this phase.

6.  Demo #2.1 - Pipelined design with Aligned Memory (0% of project grade)

See ProjectStages. No Submission required. This is optional.

7.  Demo #2.2 - Pipelined design with Stalling Instruction Memory Only : 1 week after demo 2.0 (0% of project grade)

See ProjectStages. No Submission required. This is optional.

8.  Demo #2.3 - Pipelined design with Stalling Data Memory Only : 1 week after demo 2.0 (0% of project grade)

See ProjectStages. No Submission required. This is optional.

9.  Demo #2.4 - Pipelined design with Stalling Instruction+Data Memory : 1 week after demo 2.0 (0% of project grade)

See ProjectStages. No Submission required. This is optional.


10.  Demo #3 (final demo) - Pipelined Multi-cycle Memory with Optimizations (35% of project grade)

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

Format will be similar to demo1.

What to submit:

  1. Electronic submission instructions
    Submit a single demo3.tar file containing the following directories [tar -cvf demo3.tar verilog verification synthesis]
    1. verilog/ containing all verilog files. Please copy over ALL necessary files, your processor should be able compile and run with files from this directory alone.
    2. verification/mytests/ The assembly (.asm) files that you have written.(atleast two tests)
    3. verification/results/ Run all test programs and rename the summary.log files as listed below:
      1. perf.summary.log
      2. complex_demofinal.summary.log
      3. rand_final.summary.log
      4. rand_ldst.summary.log
      5. rand_idcache.summary.log
      6. rand_icache.summary.log
      7. rand_dcache.summary.log
      8. complex_demo1.summary.log
      9. complex_demo2.summary.log
      10. rand_complex.summary.log
      11. rand_ctrl.summary.log
      12. inst_tests.summary.log
    4. synthesis/ the area and timing report (no reports or zero area => zero for this demo)
You can use the script run-final-all.sh to run all the required tests. It will create all these summary.log files.
Running all the tests will take about 40 minutes. So plan ahead!

Best overall processor will be based on performance on all of the above tests except inst_tests.

The log files MUST have the exact name. These are the log files produced by running wsrun.pl -list with the all.list file for each of those sets of benchmarks. 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 and double-check.

Printed submission:

I will electronically grade this submission and schedule an appointment with teams that have failures. If you have more than 2 failures you will receive at least a 50% penalty.

No late submissions shall be graded. If we meet you for a demo, we will use files that you submitted at or before 5PM on the 8th of May.

Both partners are required to be present and both are expected to explain and answer questions about the whole design. Answering a question with: "I have no idea, my partner did that" is a failing answer. You must (at least) be able to answer: "My partner implemented that, but it works in the following way....".


11.  Final Project Report: May 9th (8% of project grade)

Due by 2:30pm on May 9th

Each team should turn in one final report that is typed, well written, and well organized. Semantic, spelling, or grammatical errors will be penalized.

For writing the final report use this template if you use Word, or follow the format in this pdf.

FinalReport.doc, FinalReport.pdf.

Retrieved from http://pages.cs.wisc.edu/~karu/courses/cs552/spring2013/wiki/index.php/Main/ProjectDeadlinesAndGrading
Page last modified on April 29, 2013, at 04:16 PM