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

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

3.  Design Overview: March 14th (4% of project grade)

4.  Demo #1 - Unpipelined design : March 23rd (17.5% of project grade)

5.  Demo #2 - Pipelined design with Perfect Memory : April 23rd (31% of project grade)

6.  Demo #3 (final demo) - Pipelined Multi-cycle Memory with Optimizations: May 11th (32% of project grade)

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

Deadlines and grading

There are three major deadlines meet 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 all 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: February 24th (0.5% of project grade)

The project is done in groups of two or three. These groups should be formed no later than February 24th. Email me and the TA the group members and a unique team name. Your email should have the subject line: CS552 group creation.

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

Each group needs to turn in a typed report (2-3 page) describing your project design and test plan. You need to include a computer aided, or nicely hand drawn diagram of your processor's basic pipeline structure. You may use the one on page 355 of cod4 as a guide. 

You are expected to develop a detailed schedule identifying key milestones and a breakdown of the tasks by project partner.  (Although, all members should have some part in everything). 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.

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 all project members names, email addresses, and team name on the report.

Bring this report to class on 29th.

3.  Design Overview: March 14th (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-SP12 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.

The overview should include a brief description of the datapath for major WISC-SP12 instructions. Also highlight (and defend if necessary) any major design decisions.

---

4.  Demo #1 - Unpipelined design : March 23rd (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-SP12 instruction set, except for the extra-credit instructions. It should use the single-cycle memory model.

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). It is ok to have a very small number of failures - but for every failure you must know the reason. In addition I will use some extra test programs at the demo and you should run these on your design. Ideally your design should run these correctly, but again it is ok to have failures at this stage. 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.

Directions:

1. “handin” your code into demo1

2. All necessary verilog files must be in the Top Level Directory. Otherwise automatic grading could fail.

3. Submit vcheck output (all non-testbenches must not have errors)

4. Submit the “synth” directory. If any of these files are missing or if the Cell area of your processor is reported as zero, you will get ZERO for entire demo1.

Bring to class written or printed copies of the following:

• Workplan and schedule for demo 2

• Copies of neatly drawn schematics of the processor

All projects will be automatically graded on Friday at midnight.

---

5.  Demo #2.0 - Pipelined design with Perfect Memory : April 23rd (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. Tests will be run, and teams with failures will be asked to come to the demo hours (after class: 2:30 until needed).

In this demo also, you must also synthesize your processor and submit the results of synthesis, including the area and timing reports.

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 more to help simplify debugging. They should all end with the extension .asm.

What to submit: (handin to “demo2”)

• You must run the following tests and submit log files for them. You must follow this exact naming convention.

• inst_tests.summary.log

• complex_demo1.summary.log

• complex_demo2.summary.log

• rand_simple.summary.log

• rand_complex.summary.log

• rand_ctrl.summary.log

• rand_mem.summary.log

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 in doubt about what to handin email the TA *before* the deadline and double-check.

Bring to class the following (or to the demo hours)

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. A photocopy of your current pipelined design's schematic. Include a top level and schematics for one more level of hierarchy. Use your discretion on what to handin.

2. If there are known failures, a listing of those and reasons for the failures.

3. Work plan for final demo.

4. 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 (you may start with verilogsim.trace)

---

10.  Demo #3 (final demo) - Pipelined Multi-cycle Memory with Optimizations: May 11th (32% of project grade)

• Demo May 11^th for all students (Have code submitted midnight the day of for automatic grading)
• Absolutely no extensions.
• Having multiple failures (not counting aligntest and extracredit failures) will result in severe penalties.
• Processor performance will be based on 552mark programs.

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

• Two-way set-associative caches with multi-cycle memory

• Register file bypassing

• Bypassing from beginning of the MEM stage to beginning of EX stage

• Bypassing from beginning of the WB stage to the beginning of the EX stage

• Branches predicted non-taken

• Halt instructions must leave the PC pointing to Halt+2. Do not let it increment past this address

Electronically submit the following files: (handin to demo3)

1. All your verilog source code.
2. All the .txt files in the synth/ directory. (This directory should sit in the top-level-directory)
3. Your pipelined implementation should run all of the tests from previous demos correctly. Your handin must include

• 552marks.summary.log
• complex_demofinal.summary.log
• rand_ldst.summary.log
• rand_idcache.summary.log
• rand_icache.summary.log
• rand_dcache.summary.log
• complex_demo1.summary.log
• complex_demo2.summary.log
• rand_complex.summary.log
• rand_simple.summary.log
• rand_ctrl.summary.log
• rand_mem.summary.log
• inst_tests.summary.log

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 40-60 minutes. So plan ahead!

• If your design has known failures, then bring to the demo a written short explanation for as many failures as you can track down. This will greatly increase the partial credit you will receive, compared to simply showing up and saying we don't know the reason for the failures.

• If your entire design does not work, then you may show me a demo of a partially complete processor. So in your best interest, snapshot working parts of your design as you add more functionality. For example, you may show any one of the following, if your full pipeline+cache does not work.

• Stalling instruction memory alone
• Stalling data memory alone
• Stalling inst+data memory
• Direct-mapped instruction memory alone
• Direct-mapped data memory alone
• Direct-mapped inst+data memory
• 2-way instruction memory alone
• 2-way data memory alone
• 2-way inst+data memory

All partners are required to be present and all 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....".

The following rough rubric will be used to determine demo3 grades:

• 25% Functionality (Passing Required Tests)

• 10% Stalling Memory

• 20% Cache

• 20% Forwarding

• 10% Predict Not-Taken

• 15% 552 Mark Performance

---

11.  Final Project Report: May11th (8% of project grade)

Each team should turn in one final report that is typed, well written, and well organized. Semantic, spelling, or grammatical errors will be penalized. You should include at least the following:

1. A brief overview of your design

2. A discussion of any optimizations made to the CPU

3. A table describing your processor's performance on the 552mark tests.

4. A table listing the possible hazards that arise in your pipelined design and the number of stall cycles that each hazard incurs.

5. A discussion of what does not work and why. Also include what you would have liked to implement given more time. For each part of the implementation that does not work, turn in an annotated output in the form of a trace or script run that clearly shows the error. Give your thoughts as to why the error occurs and what could be done to fix it.

6. A conclusion outlining what you learned by doing this project

7. A state diagram for any state machine controllers in your design. All other controllers should include a high-level textual description.

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