CMSC 611, Fall 1998
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.
- 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.
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
- At what point (if ever) will CISC retake the performance edge
- 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
- 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.
9 Sep 1998