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.
These are explained in more detail in the remaining sections.
- Abstract (0.5 pages)
- Introduction (2-3 pages)
- Related Work (2-3 pages)
- Methodology or Technical Approach (2-3 pages)
- Design Rationale (3-5 pages)
- Technical Results and Analysis (as long as necessary; 10-15 pages is not uncommon)
- Future Work (0.5-1 page)
- Summary and Lessons Learned (1-2 pages)
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?"
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.
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.
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.
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?
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.
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
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
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: 8 Nov 95