Project Information

A semester-long project dealing with some aspect of computer architecture is an integral part of the CMSC 611 course. The best way to learn is by doing, and this project gives students a great opportunity to conduct experiments in computer architecture or explore more "far out" ideas.

Project Overview

Your group may pick any topic related to computer architecture; a list of project suggestions can be found below. However, you're encouraged to pick your own topic if possible. Anything related to computer architecture could become a project, but it should involve some implementation, design, or analysis - merely summarizing existing work in an area is not a project, though verifying previously published claims with your own experiment may be OK. Either way, you'll have to do some library research on your topic to get a basic grounding in the material. I encourage you to pick projects that you (and the rest of your group) find interesting, since those are the ones that are easiest to work on.

Your project will have several milestones throughout the semester to ensure that your project stays on schedule. The project schedule includes information on what has to be handed in for each milestone; some milestones will also require that you meet the professor for 10 minutes. Milestones aren't explicitly graded, and shouldn't require much time beyond what you need to do to finish your project. Milestones will not be graded except as part of the project as a whole. However, groups not satisfactorily meeting milestone dates will lose points from their final project grade.

Resources

Obviously, you'll want to look in the library for papers on your topic of choice. You may want to use the library's online abstract search tools to find papers you might want to read. Another approach is to find a recent paper on the topic and follow references back. You might also want to try using Web search tools such as HotBot, AltaVista, and Google.

Many papers are available on the Web; good places to check are tech report FTP sites and the authors' home pages.

Deliverables

Written report

Each group must hand in a written report on their project. This report should be 3500 - 5000 words long, or 8 to 12 single-spaced pages. It should describe the problem, cover sufficient background material so that others can understand the project, and describe both the project and results in detail. In short, it should resemble a conference paper in both length and scope. A sample project report (yes, this paper started as a class project) is available online. As you can see, it's certainly possible for some particularly interesting and well-done projects to lead to published papers, perhaps with some additional work.

Presentation

Each group must present their projects to the class during the last week or two of classes (the exact number of classes will depend on the number of project groups). The presentations will be 15-20 minutes each, and should focus on the project's results. Normally, only one member of the group will actually give the presentation, but there have been groups where two or more people "shared" the presentation. The presentation should include any slides or other materials that will help the class understand the project.

Project Schedule

Dates marked with a (*) require a 10 minute meeting with the professor. Signup sheets for these meetings are available online.

• 17 Feb 2000 (*): Group & project selection.
  Each group should turn in a single page listing the group members (with e-mail addresses) and a brief description of the project.
• 29 Feb 2000: Background research well underway.
  Each group should turn in a list of 8-12 papers on its topic along with a 1-2 line summary of each paper. These papers will form the basis for your project. You need not have read every paper by this date, but you should have read some of them and read the abstract for all of them.
• 6 Apr 2000 (*): Preliminary plans & design
  By this time, your group should have its project planned out and designed. Early results would be welcome, but not required.
• 27 Apr 2000: Implementation & coding complete:
  At this point, you should be done with any programming you need to do. The rest of the time will be spent running experiments and writing up your results. If you have no results by this time, it will be difficult to complete the project.
• 9-16 May 2000: Project presentations
  One member of the group will present their project in a 20 minute presentation (15 minutes for the talk, and 5 minutes for questions). This presentation should focus on quantitative results.
• 16 May 2000 (5:15 PM in ECS 225H): Written project report due
  Each group must hand in a written report, as described above.

Project Topics

This is a list of suggested topics for your semester projects. This is by no means an exhaustive list, and you are encouraged to pick a topic that you are interested in. If you're not sure whether your project is appropriate for a computer architecture class, please send me e-mail.

• Build a VHDL (or C/C++) simulation of a modern CPU (such as DLX, PowerPC, MIPS, Intel, etc.). Have it simulate programs to see how changes in architecture might affect CPU performance. Some changes might be:
  • Addition of a vector unit (i.e., AltiVec or MMX)
  • Going to 64-bit addresses (change in registers)
  • Different out-of-order execution schemes
  • Pipeline depth
• Chip designers have proposed replacing some or all of the data cache with a small, directly-accessible onchip memory. Is this likely to be a performance win? Back up your conclusions with measurements of a few applications, showing how the changes will affect cache hit rates and instruction count.
• Security is becoming an increasing concern on the WWW, but sharing (with the right people) is also important. Propose hardware security mechanisms for use in memory management (TLB / page table) that might facilitate both security and sharing as appropriate.
• For what kinds of applications do CISC processors make sense? Is the RISC vs. CISC battle over, and who has won (if anyone)?
• What is the maximum parallelism that a program can achieve in a perfect world? How big an instruction buffer (with out-of-order execution) is necessary to realize this parallelism, and how much parallelism can more realistic instruction buffers allow? Various options (speculative execution, etc.) can be added to increase potential parallelism and make the study more interesting.
• Create a benchmark suite to measure some aspect of a system's performance. Why is your suite better than those that are already available? Does it give different results than existing suites?
• Build (or modify) a CPU simulator for DLX, MIPS, or another architecture to include a vector processor. Perform simulations to see how much faster (if at all) the CPU can run if it includes a vector unit. Is the change worth the extra hardware necessary to do vector processing?
• The Tera computer uses a processor that can support multiple threads and switch between them while waiting for off-chip memory access. Build a simulator that shows how effective this is and how many user threads might be necessary to keep such a chip busy. This study could be done for "normal" workloads such as the SPEC benchmarks to see how worthwhile such a chip would be in desktop workstations.
• Gather instruction traces from machines in the department and analyze them. Are instruction set mixes different from those in the text? If so, how? NOTE: this project will involve getting tracing tools to work on a computer; you may not use downloaded traces except to compare your traces against.

I would prefer that no more than 1 (maybe 2) groups work on each project topic. There are plenty of topics here, and I expect that students will come up with many more interesting topics.