Computer Science 252. Graduate Computer Architecture

Final Project Report Format Specification

The model to follow for your final project report to be like a research conference paper. The elements of such a paper are the following. While it is not necessary to slavishly follow this outline, it is a good starting point, and any reasonable report with cover this set of topics. We expect the reports to be between 25 and 30 pages in length, including figures, charts, and tables of results. However, please do not pad your reports simply to achieve a particular length. If you require less space or more space to communicate your ideas, that is fine. Use these page lengths are broad guidelines only, based on past experience. Three person projects would be expected to be at the upper end of this range (or beyond). One person projects could be shorter.

  1. Abstract (0.5 pages)
  2. Introduction (2-3 pages)
  3. Related Work (2-3 pages)
  4. Methodology or Technical Approach (2-3 pages)
  5. Design Rationale (3-5 pages)
  6. Technical Results and Analysis (as long as necessary; 10-15 pages is not uncommon)
  7. Future Work (0.5-1 page)
  8. Summary and Lessons Learned (1-2 pages)
These are explained in more detail in the remaining sections.

Title

It is important to choose a report title that communicates what your project is about. For example, a title like "On Performance Evaluation of Caches" is not nearly as descriptive as "The Performance of Direct Mapped versus Set Associative Caches on the Spec95 Benchmark Set." Attention getting titles do pull in the reader. One of my favorites is "Are Disks in the Air Just Pie in the Sky?"

Abstract

The abstract should provide a broad overview of the report, ending with a short statement of the major results of your investigation. Identify the audience likely to be interested in your results (processor designers, memory system designers, I/O architects, etc.), and use the abstract to draw in that audience by briefly describing your key idea and experimental approach. The abstract should be strong enough to encourage the reader to read the rest of the report. Abstracts are very limited in length, rarely more than one half page.

Introduction

The Introduction usually expands on the abstract, and is often 2-3 pages long. It starts out broad and then gets very specific about your project. It's job is to set the stage for the report. Why is cache performance important? What are the relevant technology trends that influenced your project? End the Introduction with a paragraph or two description of what you did and your key results and/or observations. The very last paragraph should a roadmap to the rest of the report.

Related Work

It is unlikely that you invented something completely new to be reported on in your report. I believe that it was Einstein who said "If I have seen farther, it is because I have stood on the shoulders of giants." Scientific papers (and dissertations!) are full of citations to related and previous work. You must put your own work in the context of what has been done before. Review the previous literature, identify its strengths and weaknesses, and make allusions to what is new or unique about your own work. 2-3 pages should be enough, but if you have done a very extensive literature search, this is an excellent opportunity to document what you have learned outside of the textbook (and suggestions for high quality supplemental readings are always welcome!).

Sometimes it is easier to place the related works section at the end of the report, after you have presented your own ideas and results first. Either approach is fine, and it is just a matter of taste as to where this important section fits best.

Methodology/Technical Approach

It is important to communicate to your readers about your experimental method. Did you use an analytical model, a simulator, or a performance monitor? What benchmarks did you use, and why? Did you collect traces? Do you analyze the layout or register-level architecture of some existing processing? How did you collect your traces? What machines did you evaluate. Why did you choose those machines?

It is the responsibility of the section to document the PROCESS you followed during your project and the tools you used (including new ones you developed) in completing your project. 2-3 pages should be sufficient to document your project methodology.

Design Rationale

This is the first section that gets into the real meat of the report. It is difficult to give sweeping advice for a section like this, because the details will vary from one project to the next. Some projects may have a large design component, like a new power model or a new CPU mechanism. For example, if you developed a new branch prediction algorithm, this is the place to document that design and to explain why you designed it as you did. Others are designing a new benchmark set. There is some element of design in almost every project. The job of this section is to document that design and to report on the alternatives you may have considered but then rejected. 3-5 pages should be long enough in most cases, but this section is one likely to vary in length the most from one project to another.

Technical Results and Analysis

This is the centerpiece of the report, and the one that will influence the project grade the most (by the way, it is also the one that gets the paper accepted or rejected at the conference!). Again, it is difficult to give general advice, but we will be looking for a quantitative analysis of your ideas in this section. Prove to us that your benchmark set really predicts performance across a class of machines. Show us how your branch prediction algorithm or other CPU enhancement really does improve performance. Demonstrate the value of your power estimation model and how it can be used to understand power tradeoffs in CPU design. And so on.

Now it may be the case that your brilliant ideas have not panned out as big performance wins. This is ok. What IS important is that you understand the strengths and weakness of your proposed mechanism and that you include a detailed evaluation of that mechanism that illuminates its value (or lack thereof). We expect this section to be quantitative, complete with plots, performance graphs, etc. It is important that you take as many pages as necessary to explain the performance of your approach as is required.

If you have a huge number of plots, it may make sense to place the detailed plots in an appendix, and just include summary data in the body of the report. The same is true if you have extensive equations or derivations for your analytical performance models.

Future Work

This is can be a short section. The main idea here is to document things you wish you had time to do but could not accomplish in the time frame of the project. Also suggestions for future CS252 projects that build on your accomplishments would be very much appreciated!

Summary and Lessons Learned

This is another short section. Now that you have presented your methodology, rationale, and results in some detail in the preceeding sections, you can summarize these in few paragraphs. A recipe for a good paper or presentation is the following: "Tell them what you are going to tell them, then you tell them, then you tell them what you told them." The summary section is responsible for the latter. Reiterate your results, now in the context of the full report.

Undoubtedly, you will have learned much from the project in non-technical areas. For example, how to work as a team, how to schedule time, how to deal with the shortage of machines or other resources. This is an opportunity to document the lessons you have learned and to make suggestions to the instructors of how to improve the experience for future generations of CS 252 students. We value your feedback!

References and Bibliography

The final section is a complete bibliography of the references you used in formulating the project and in shaping your final results. An annotated bibliography is nice feature to include if you have time. We are interested in identifying valuable supplemental readings that could be included in future offerings of CS 252, and we are interested in your impressions of the papers you have read.
Randy H. Katz, ed., randy@cs.Berkeley.edu, Last Edited: 5 April 96