Final Project

CMSC 611, Spring 2006

Last change:
Thu Feb 9 15:24:55 EST 2006

Projects will be completed in teams of 2-3. By February 21st, you should let me know your partner and proposed project application and user by email (one email per team is sufficient).

For the project, you will pick an application area of your choice and a specific use or user for your application. You will analyze the characteristics of your application and user in detail and apply the results to the architectural design of a specialized coprocessor or stand-alone hardware system. Projects should consider one or two of the following design levels: HDL of a functional block, processor organization, ISA, or system organization. Two person teams should address a single level, while three person teams should address two levels.

Your focus on a single application and user will lead you to make different design choices than would be made in a more general purpose system. Factors to consider (and quantify) may include instruction mix, memory size, memory access pattern, bandwidth requirements, and throughput requirements.

Some possible application areas include:

Video compression/decompression
- For teleconferencing
- For a DVD player
- For a digital video recorder
Image processing
- For analyzing satellite imagery
- For cleaning up digital scans
- For manipulating and compositing multiple broadcast video streams
3D graphics
- For computer aided design
- For flight simulation
- For gaming
Audio processing
- For MP3 recording/playback
- For an internet telephone
- For professional mixing
Network switching
- For a home network hub
- For a university department
- For an ISP
Any other approved application area of your choice. Like the above suggestions, it should include both what aspect you are addressing and who your intended users are. The application area will provide focus to your project, but should be narrowly enough defined to avoid having the application analysis take over the entire project.

The end result of your project will be one team-written report of 5-10 pages. Please do not use abbreviations or mnemonics for signals, instructions, registers, etc. As Fred Brooks^* once said, "By the time I read seven projects I no longer know even what my own initials stand for." Keep a copy for yourself, and turn in a hardcopy at the final class on May 16th. Projects will not be accepted late, and are not eligible for either the 20% week-late penalty or the free late. Each team member must also send a separate short private email to me indicating what portions of the project (research and report) were done by each of you.

The report should include the following sections:

Introduction
Application overview and a short (1 paragraph) summary of your design
Characteristics of the application.
Include all properties usable in specializing your computer system. If you include performance metrics, you should also indicate whether they are estimated, based on external benchmarks, or measured. Some information in this section may be best presented in tables or graphs.
Description of your design.
You should spend the most time and space on the application-specific portions. You should still address the normal aspects of the design, but can spend less time on those. You should also address how your design fits into the next level of the system — how it communicates with the world beyond.

For example, if you create a system-level design whose main feature is set of parallel general purpose CPUs arranged in an interesting way, you should spend most of your time describing that aspect of the design. However, you should still provide a concrete block diagram of the entire system including details like the estimated bandwidths between components and communication with the outside world, but not necessarily spending a lot of space explaining a relatively typical memory system.

As another example, if you are developing an instruction set architecture for a special-purpose embedded processor, you should spend the majority of your effort explaining any special purpose instructions, addressing modes, or other unusual features you have decided to include. You should still consider the other classes of instructions in your design and mention them in your report, but you need not spend pages explaining your ADD or SUBTRACT instruction if there is nothing unusual about them. You should, however, be sure to describe what means of I/O or synchronization are provided for to allow your embedded processor to work within the larger system.

As a final example, if you are creating a VHDL-level design for one or several interesting functional blocks, you should describe those in detail including their inputs, outputs, timing constraints, etc. You should also include a sketch of how your functional blocks fit within the complete ASIC but need not create VHDL for an entire CPU.
Justification and analysis of the application-specific portions of the design.

Relevant measures may vary with application and design, but you should provide a concrete and analytical analysis of your expected performance or speedup.

Conclusions
How do you think it turned out? How well did it meet the goals? What other approaches would you consider if you had it to do over again?

^* Fred Brooks was the IBM System/360 project manager, author of The Mythical Man-Month (which you should read if you have not already!), and founder of the UNC department of computer science. His advanced architecture class project was also the inspiration for this project.