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.
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:
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 December 10th. Projects will not be accepted late. Each team member must also send a separate short private email to me describing the accomplishments and contribution of each team member ("I did this, wrote this, they did this, wrote this, etc.").
The report should include the following sections:
Application overview and a short (1 paragraph) summary 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.
Relevant measures may vary with application and design, but you should provide a concrete and analytical analysis of your expected performance or speedup.
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.