6.111 Final Project

Overview

The final project in 6.111 is your opportunity to work on a small digital system. You will design, build, debug, demonstrate, and report on this system. This webpage sets forth our expectations and requirements for this project and makes a few suggestions which should help make your project a success.

Evaluating your effort and results is inherently subjective, but here are some guidelines about how your project grade will be determined (35 points total):

• Deadlines and participation: 8%
• Problem definition and architecture, design: 10%
• Functionality: 8%
• Complexity, innovation and risk: 9%

In addition to this, a substantial number of points (15) will go into the CI-M component which covers the reporting aspects of the project such as proposal (5%), presentation (3%), and final report (3% technical). The remaining 4% is based on a lab 4 report.

We have high standards for handing out points -- good projects typically score in the low-20's, very good projects in the mid-high 20's, and truly excellent projects above 30. We will evaluate each team member's performance separately and will be influenced by your level of effort.

The final six weeks of the course are devoted to the project and it is expected that you'll work "full time", i.e., 12 hours per week, for a total of 72 hours. In that time you should be able to design, implement, debug and document four or five modules, each having the complexity of Lab 4 or Lab 5. With a two-person team you'll be able to get a lot done and, indeed, final projects are often remarkable in what they are able to demonstrate.

In order to accomplish all that is expected by the end of the term, it is essential that you stay on schedule. In particular, it's unrealistic to put in all 72 hours during the last week — not only do you have other obligations, but your effectiveness will decrease dramatically after too many hours in the lab. Be fair to yourself and your partner and put in time on a regular basis over the seven week period. The most common comment at the end of the project: "I wish I had put in more time early on."

Since we don't have the facilities or supervisory resources to evaluate your project after the term ends, incompletes will not be given except in circumstances approved by the counseling deans. We will assign a final grade based on whatever progress you've made by the time of the final checkoff.

Project Abstract

The project abstract should include the project title, a list of team members, and a one paragraph description of the project itself. We'll use the abstract to assign your project to a member of the course staff who'll then interact with your team for the remainder of the project.

The approved abstract will be posted on the course website.

Proposal & Meeting

The Project Proposal is detailed description of the project, describing what it will do and how you plan to implement that functionality. Please include a draft block diagram showing the major modules and the information that flows between them. You'll refine the diagram in the coming weeks, but it's useful to make a rough cut of how you plan to modularize the design.

For each module specify its inputs and outputs, and give some indication of its complexity and level of performance (e.g., number and type of arithmetic operations, size of internal memories, required throughput). Describe how the module will be tested. Please indicate which team member will work on each module — for evaluation it will be best if most modules have a single designer.

Identify any external components that you're planning to borrow, buy or build and give some details about their cost, complexity, and how they will be interfaced to the FPGA.

Typically proposals are three to five pages long (single spaced), plus the block diagram and any figures you may need. The proposal will be evaluated by writing staff and you will received feedback to revise and submit a revised draft.

Sometime during the week schedule a meeting with your assigned staff member and go over all the information you'll be including in your proposal. It's not necessary to have finished your document, but you should have a block diagram to point at during the meeting.

The revised proposal will be posted on the course website.

Block Diagram Conference

By this time you should have a detailed functional specification for each module including its ports (with widths), clocking, the protocol(s) it will use to communicate with other modules, etc.

You should have a sketch of how each module will be implemented, e.g., a rough schematic showing the internal datapaths and components, along with a first cut at the state transition diagram for the controlling FSM (if any). Indicate the number of BRAMs or hardware multipliers that are needed, and which IP Core building blocks you'll be using.

Please summarize the amount of internal and external memory your design requires and indicate the rate at which each memory will be accessed. Many projects discover that they need more memory capacity or memory bandwidth than is realistically available and this can be a major headache to resolve late in the game.

Sometime during this week schedule a meeting with your assigned staff member to review this detailed implementation plan. You don't need to turn in a writeup, but you'll make a big dent in your final report writing chores if you write up a technical description of each module now.

If you're planning to buy some components: now's the time! We do have a small budget for acquiring components you'll need for your project. One of the TAs can help with the order, but first

• check with the folks in the Instrument Room to see if we already have an equivalent part.
• make sure the part comes in a package you can use (many parts now come in surface mount packages that are hard/impossible to connect to the lab kit).
• order a spare if the price isn't too over the top
• check that the parts are in stock and will arrive by Thanksgiving. Parts arriving after Thanksgiving are unlikely to be useful in your project. A good place to look is www.digikey.com.

Project Design Presentation

Your project team is required to make a 15-minute presentation to the class reviewing the project and its proposed implementation. Usually this is done by preparing about 10 slides that include an overview, a block diagram, discussion of the major modules identifying the tricky bits or implementation insights, and a simple timeline showing what you expect to have working when. Each team member should give part of the presentation. Both writing staff and 6.111 staff will be evaluating your presentation and providing feedback.

You're welcome to use whatever tool you'd like to create the presentation: HTML with figures, Powerpoint, Latex, etc. Please format the material so that it can be projected properly, i.e., it should be in landscape format. We'll have a projector you can use, so please post your presentation on Athena ahead of time or bring it along on a flash drive or on your own laptop.

We'll work to schedule your presentation at a time that's convenient for you. We have a lot of presentations, so please plan to start and end at the appointed times. Practice your presentation to ensure that it will fit into 15 minutes.

Please upload a PDF of your presentation slides so that they can be posted on the course website.

Project Checkoff Checklist and Status Update

In consultation with the course staff, each team submits a checklist of deliverables for their project. This is a comprehensive list of what you're planning to demonstrate at final project checkoff. Usually the list includes each of the major modules in the design with a sentence or two describing their functionality and how it will be demonstrated. Include your more ambitious goals too (mark them "if time permits") so we'll know all the things you're trying to get working.

In addition to the checklist, you will provide a status update near the end of November explaining the operational status of the blocks that you proposed to design and expected completion timeline, problems and solutions that you envision.

Final Project Checkoff

We'll schedule a 30-minute project checkoff meeting during the final week of the term. Using the checklist of deliverables, plan on showing off your project's functionality and talking about your implementation and any design issues that arose. With your permission, we'll make a short video of your project in action that will be posted on the course website.

Final Project Report

This report will be evaluated by both the 6.111 staff and CI-M staff and it is a big part of your project grade. It is expanded version of the proposal that you did earlier. The Introduction and Summary sections can be written jointly, but there should be sections written by each team member describing in detail the modules they designed (please identify the author of each section). You are free to reuse any materials submitted for the earlier project milestones.

A typical final report includes about 20 pages of narrative supplemented as appropriate by diagrams, tables, photos, etc. But don't focus on length. Your goal is to describe the work you did in enough detail so that a reader can understand how your implementation works and enable them to replicate it themselves if they wanted to. Pass along any implementation insights you had and, if appropriate, indicate how you might do it differently next time. If there are things to see, include some photos!

Talk a bit about the process itself, i.e., where your time went and what you had to do to get the module working. Describe implementation tasks that were particularly tedious and how they might be made less so.

It can be useful to include a listing of your Verilog as an appendix to your report.

Sorry, but because of the tight deadline on submitting grades, no extensions on the report due date will be possible.