This page created and maintained by Jeffrey A. Six.
Last Updated: 31 March 2005
As part of CMSC 411, a large-scale design project must be completed. The key objective of this project is to give you an oppurtinuity to apply what you have learned in lecture in a design setting and to solidify a basic understanding of VHDL and computer-based design. You will be asked to extend the design of a MIPS microprocessor core, implement your extensions in VHDL, and then to simulate and verify your new design. Just like in the real world, this is a team project.
UMBC has a site license for the Cadence VHDL software package. This is an industry-grade computer-aided hardware design tool with full simulation capabilities. This software lives on the machine cadence.gl.umbc.edu - you need to login to that machine to use Cadence. The first link below goes to the UMBC website that describes how to setup your environment to use the Cadence tools. Please note that although this software exists for you to use, it is not required for you to use this particular design package - you are free to search out and use any available VHDL design pacakage you can legally obtain and use.
The basic microprocessor architecture that will be used is a stripped-down version of the MIPS architecture that has been studied in lecture. This microprocessor, named RRRMIPS (really, really, reduced MIPS), supports a small subset of the MIPS instruction set, but it can run complete programs. The instruction set supported by RRRMIPS is:
You will be provided with a complete, multicycle, and unpipelined VHDL implementation of the RRRMIPS microprocessor. Your task is to extend this unpipelined implementation to support simple pipelined execution. Note that this extenstion may introduce structural hazards - your hardware does not need to deal with these; it will be up to the compiler to produce code that is free of such hazards. In order to successfully complete this project, you will be required to perform a number of different tasks:
The end result of your project will be a report containing all of the above requirements. For your simulations, make sure you include screenshots and/or listings of result files from the simulation tools that show the (hopefully correct) output of your tests. You also need to include the block diagram and all VHDL code that you created or modified.
This is a team project. Each team will consist of two, three, or four people (you pick your own teams). You should establish a team methodology and a system of dividing up tasks and integrating separate work into a common group project in order to be successful. A good idea would be to elect a group leader who would be responsibile for calling and leading design meetings. This project is not very difficult, but it will require a good design and alot of time for debugging and integration. Also, please note that it is expected that each group member contributes a fair amount of work to the team. It is strongly suggested that your team strategy be geared to prevent bottlenecks where group progress is overly dependent on one person. A well-considered strategy and a clearly defined interface in your design will go a long way to mitigating such difficulties.
Please note that while discussion of the project in general terms is expected and encouraged, members of different groups should not exchange any VHDL code or implementation details. Any such sharing among groups will be considered academic dishonestly and be handled in the manner described on the course webpage. The work of your group must be entirely the work of your group.
A week after the project is formally assigned, each team must submit a project plan. This should be a two to three page document that describes your team's approach to solving the problem. This should include a summary of your general approach, a listing of the components that you think will need to be modified and, in general terms, how they will need to be modified, a description of any additional components you think you will need to create, and so forth. The intent is to make sure your team has thought about the problem and has a sound solution strategy. This project plan will count as 25% of your project score.
Approximately two thirds of the way through the project, each team must submit a status report. This should be a two to three page document that describes all of the progress the team has made. This should include a summary of everything that has been done up to that point, including components developed, changes made, and so forth. It should also include a list of problems that the team encountered and how they were overcome. This project progress report will count as 5% of your project score.
On the scheduled last day of the course, each team will present their results to the class. This will be a 5 minute presentation that should explain the solution that the group developed (your pipelined design) and any tradeoffs made in the design. This should be a quick high-level overview of the final design and anything that your team feels should be pointed out (if you have made any design decisions that are unique to your design, this would be a great place to point them out to the class). Each team should also describe their final progress including what they got done, what was not completed, and so forth. As the final project is due on the presentation day, this will be your a summary of your final product. Finally, each team should consider this five minute presentation a chance to "sell" your team's final microprocessor - highlight the strengths of your design and point out and explain your weaknesses (if you point out weaknesses or components that have not been completed with a good explaination, you will lose less points than if you ignore them). More details on how to prepare your presentation will be provided at a later date. This presentation will count as 15% of your project score.
Your final project report must address and contain all of the elements specified above. This report must be typed and a hard copy submitted at the end of your project presentation. Each team must submit all code for their design (electronically, in VHDL) by the end of the day that the presentations are given.
| Project Plan | 25% |
| Project Status Report | 5% |
| Project Presentation | 15% |
| Final Product | 55% |
While every effort has been made to provide you with a complete and fully working RRRMIPS microprocessor on which to base your project, there will always be bugs in the implementation. If you find such a bug during your work, please report it to me immediately. For every bug that your find and provide to me, along with a fix, I will award five extra credit points on the project to your team (one extra credit point for a bug with no fix). Also note that this offer only applies to the first person to point out a bug.