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 Schedule

• 10 Sep 1998 (*): 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.
• 1 Oct 1998: 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.
• 22 Oct 1998 (*): Preliminary plans & design
  By this time, your group should have its project planned out and designed. Early results would be welcome, but not required.
• 19 Nov 1998: 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.
• 3 and 8 Dec 1998: 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.
• 11 Dec 1998 (4 PM in ECS 225H): Written project report due
  Each group must hand in a written report on the last day of class. This report should describe the background material, the project design, and any results. A sample paper is available.

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.

• 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 that might facilitate both security and sharing as appropriate.
• At what point (if ever) will CISC retake the performance edge from RISC?
• 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.