The goal of the semester project is to do research/development in a narrow computer architecture area and write up the results as a technical paper.
Choose something that interests you.
Keep a narrow focus.
It is OK to do an incremental extension of others work. Give credit.
It is OK with me to combine this course project with another course project.
1. Create or run unusual programs as benchmarks.
Possibly on various architectures or on simulators such as
"Simple Scalar" or others.
2. Benchmark some program written in several languages on various architectures
e.g. Java and C++. Should it be Java written in C++ syntax, C++ written
in Java syntax or optimally programmed in each language?
Pearl, Tcl/Tk, Fortran, Ada, or any languages you find interesting.
3. Use VHDL or Verilog or some CAD system to implement an IEEE floating point
arithmetic unit. If it comes out good, submit it to www.opencores.org.
it is OK to build on some implementation as long as you make a
contribution (e.g. faster, less gates, more in hardware)
3a. IEEE floating point is typically a hardware plus software solution.
Find or do your own hardware-software partitioning and then show
tradeoffs for more and less hardware.
4. Do a detailed analysis of some useful program to find how much can
be parallelized. e.g. maximum number of superscalar pipelines it
could use, average parallel issue, any interesting quantity related
to fine grain parallelism that might interest you.
5. Do some branch prediction experiments. Use an existing or modified
simulator or do your own code to run experiments.
You can build on others experiments and create your own branch prediction
method if you wish.
6. Analyze some program to compare its performance on an in-order execution
machine such as the Intel IA-64 verses an out-of-order machine such as
the Alpha 21264. Focus on some part of this area. e.g. the differences
in what the compiler should/could produce. The difference if the code
was compiled completely unoptimized. The difference if code size was
minimized in order to keep it all in the L1 cache.
7. Benchmark a Java Virtual Machine on several architectures.
Or, profile some JVM and find the highest use area of code them
analyze that code to predict on which architecture it would be fastest.
Or, analyze a high use part of a JVM for fine grain parallelism.
8. Seriously speculate how you would use a multi billion transistor chip for
making a better desktop computer. In other words, if you could put 100
times more on a chip without loosing speed, how would you use it
to help the person using the desktop computer. Keep some focus.
Be sure you are proposing something that really helps the user.
9. Analyze cache performance, some are saying zero levels of cache may be
best, others say we will go to four or five levels. With a 1GHz processor
the L1 cache takes a minimum of two clocks, L2 as many as 20 clocks.
At an average of three instructions and one data reference per clock,
can wide memory and lookahead buffers outperform caches?
9a Analyze I/O performance. For example ATA-160 vs SCSI 160.
Various speed hard drives, 5400, 7200, 10,000 rpm.
Does CPU speed make a difference? Does RAM size or at least
the amount of RAM used for disk read/write buffers change time?
Can you detect double buffering, quad buffering, read ahead?
Do writes appear to happen in zero time? Why? How much?
10. At greater than 10GHz clock rates a signal can not get across a chip
in a clock time. Designers are talking about microarchitectures that
form the core of fast processors. Find a recent paper on the subject
and make an incremental contribution.
11. Work out a TLB hardware plus software solution that works for more
than 4GB virtual address spaces.
12. Work out a way to make good use of one of the memory technologies.
Bigger is usually slower, smaller is usually faster, rows vs columns,
prefetch, precharge, width vs depth of buffers. Focus on only one
specific type of memory chip.
13. Use VHDL or ESIM and code a superscalar four pipeline architecture
with out-of-order execution and renaming registers. Simple SGI or
DLX are reasonable models. This may require a team effort and coding
up about 100 instructions to demonstrate it works is not easy.
There is some form of superscalar DLX on the WEB. You may want to
find it and enhance, modify, make user friendly that VHDL.
14. Do an economic analysis and show some interesting trend.
e.g. processor prices vs speed vs time, scattergram
Putting together your own system vs buying from IBM, DELL, etc.
(motherboard, case, processor, memory, CPU, video controller, etc.)
Show tradeoffs, non linear or jumps in price vs performance.
15. Pick some architecture related subject that interests you.
e.g. How to cluster old SGI boxes. Problems and solutions.
You should EMail me your project topic with a subject of "611 Project"
to get my opinion if the project is too big or too small at squire
You have to do something, not just write a report on the work of others.
You can "stand on the shoulders of giants so you can see further."
Your report needs to say what you expected, what actually happened,
some analysis or explanation or results.
Eight to ten pages long.
Typical title page: Title, author, date, CMSC 611 Project
Typical abstract page: one or two paragraphs, 1/2 page long at most.
Middle pages: Divide into sections, for example:
Introduction or Background
Problem Statement or Purpose of Study/Research
State what you did, can be incremental contribution.
Results or Conclusions or Findings (yours plus others OK)
Problems Encountered and/or Roadblocks and how solved
Credits or Related Research that directly apply.
Further Work or Open Problems or Suggested Follow on
Last page: References (minimum 3, limit to one page)
Text: computer printed, not hand-written.
Figures and graphs can be hand drawn.
Staple or put in a folder.
Keep a copy for yourself.
This is intended to be an individual effort.
(Keep it narrow, keep it focused, do a good thorough job.)
If I approve a team effort for a larger project, each
members specific contribution must be listed.
(After references or on separate sheet of paper.)
e.g. Who ran benchmark, Who did writing of report,
Who created program(s) or input data.
Grading: Positive points for following instructions above.
Negative points for really bad spelling or grammar.
Last updated 12/7/00