Final Project

CMSC 611, Fall 2003

Changes marked in red
  • Thu Sep 25 18:37:04 EDT 2003
  • Projects will be completed in teams of two in all but the most exceptional circumstances. By September 23rd, you should let me know your partner and proposed project by email (one email per team is sufficient).

    For the project, you will pick an application area of your choice. You will analyze the characteristics of your application and apply the results to one level of the architectural design of a specialized coprocessor or stand-alone hardware system. Some possible application areas include:

    The end result of your project will be one team-written report of 5-10 pages. The document should be in diagram-outline-table form, and it need not contain complete sentences. Keep a copy for yourself, and turn in a hardcopy at the final class on December 9th. 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:

    1. 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.

    2. 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.

    3. Justification and analysis of the application-specific portions of the design.

    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."

    [Note: Many aspects of this project were based on one assigned by Fred Brooks for UNC COMP265, Spring 1993.]