Project Deadlines and Grading

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 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: February 19th (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. Update the course wiki's Project Progress page.

2.  Project plan: February 26th (4.5% 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 updated/revised version of this 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.

Bring this report to class on 26th.

3.  Design review: March 6th (4.5% 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-SP08 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-SP08 instruction using the schematic as a reference. Teams will also be expected to defend the design decisions that they make.

Signup instructions will be mailed closer to the deadline. You will use the sign up sheet on the Project progress page.

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 : March 27th (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-SP08 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 provide 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.

• Each group will schedule a time to meet in the lab with Professor Sankaralingam and/or the TA to provide a demonstration of your design.
• Both partners must be present.
• What to bring:
  • All schematics
  • Workplan and schedule for demo 2
  • Be prepared to demonstrate your project running the test programs
  • All Verilog and test files must be electronically submitted by 11:00am on 27th.

Logistics:

• Prior to the demo
  • Handin assignment name is demo1
  • Handin all your verilog and vcheck.out files for all your verilog in one single file called demo1-src.tgz by 11:00am. This version of your code will be evaluated at the demo.
  • Run the insts_tests using the wsrun.pl -list /u/k/a/karu/courses/cs552/spring2008/handouts/testprograms/public/inst_tests/all.list option. Handin the output file summary.log. See also -list option
  • If your design does not conform to the provided proc_hier_bench.v template and wsrun.pl, email instructor before-hand and get permission.
• At the demo
  • Demos will be at one of the CS labs.
  • Each team will get a 15 minute slot
  • Bring your hand drawn schematics
  • Be prepared to answer questions on the designs - both partners should know about all parts of the design.
  • Be prepared to run the additional programs on your design and debug any failures. It is "ok" if your processor fails on these tests. You must be able to debug your design and isolate where the bug (if any) is.

Signup on the project progress page

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

---

5.  Demo #2 - Pipelined design with Perfect Memory : April 15th (35% 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. The signup for demo will be optional and required if your design fails any of the additional tests. You must signup for a time-slot before-hand, so that you are available in case your design has a failure. You will use the sign up sheet on the Project progress page. It is ok for at most two teams to share a time slot.

Asim will run your demos on the existing programs, and a small set of new programs off-line. If your processor fails on any of these, then you will have to show up for the demo and explain your design.

Handin instructions

Logistics:

0) The handin assignment name is demo2

1) Handin all your code by 11am on April 15th. Your pipelined implementation should run all of the tests from demo1 correctly. Your handin must include

• one tgz with all source (demo2-src.tgz)
• 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
• mytests.tgz <--- tgz of all the asm tests you wrote for testing your pipeline. 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.

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 handin email the TA *before* the deadline and double-check.

2) 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. A printout of your summary page from Mantis, showing number of opened, resolved, etc.
3. If there are known failures, a listing of those and reasons for the failures.
4. Work plan for final demo.

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

3) At the end of class on 04/15, Asim will make announcement on teams that have failures, and those teams must show up for the demo on the time slot they signed up for. Demos will again be at the CS labs as before.

4) If there questions you have or specific items you would like to discuss about your project, you are welcome to show up during your time slot even if your design has no failures.

---

6.  Demo #3 (final demo) - Pipelined Multi-cycle Memory with Optimizations: May 8 (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:

• 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

Format will be similar to the other demos. Asim will run your demos on the existing programs, and a small set of new programs off-line.

Handin instructions

Logistics:

0) The handin assignment name is demofinal

1) Handin all your code by 11am on May 8th. Your pipelined implementation should run all of the tests from previous demos correctly. See the Test Programs page . Your handin must include

• one tgz with all source (demofinal-src.tgz)
• complex_demofinal.summary.log
• rand_final.summary.log
• mytests.tgz <--- tgz of all the asm tests you wrote for testing your pipeline. 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.

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 handin email the TA *before* the deadline and double-check.

2) No additional written document is required for the final demo. Bring all your schematics and state machines to class. Be prepared to answer questions about all parts of the project. In addition, bring the following.

1. A printout of your summary page from Mantis, showing number of opened, resolved, etc.
2. If there are known failures, a listing of those and reasons for the failures.

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

---

7.  Final Project Report: May 9th (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 listing the possible hazards that arise in your pipelined design and the number of stall cycles that each hazard incurs.
4. 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.
5. A conclusion outlining what you learned by doing this project
6. An appendix containing all custom code used to test your design. The assembly files should be well commented and include a description of the program at the top of the file.
7. A list of your summary page from Mantis.
8. A state diagram for any state machine controllers in your design. All other controllers should include a high-level textual description.
9. Run the create_final_report_table.sh script. It will create two pdf files: all.summary.pdf and table.pdf. Print the files and attach it with your report.

The files it generates will look like this: all.summary.pdf, table.pdf. Ignore the values of CPI in that example report.

All printouts should be well annotated.

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