Assignments

Only one person from each team needs to submit an assignment (with the exception of the final reflection writeup at the very end). If both (or all three people) submit, we make no guarantees about which document we'll use so please make sure to communicate with your partner(s).

• Teaming Preference (Due October 8th at 10pm)
• Project Abstract Submission (Due October 18th at 5pm)
• Project Block Diagram Report (Due October 29th at 5pm)
• Project Presentation Submission (turn in after you present with requested changes)
• Preliminary Report (Due November 27th at 5pm)
• Final Report (Due December 10th at 4:00pm but there is a bug that will allow submissions until December 11th at 10pm)
• Final Video (Due December 10th at 4:00pm but there is a bug that will allow submissions until December 11th at 10pm)

Final Project Overview

The final project in 6.205 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. The final project and its associated technical presentation and writing components together comprise 48% of your overall grade in the class.

Previous Projects

Previous projects can be found on the project archive page.

Project Teaming

Projects must be done in teams of two and occasionally three. This is largely to ensure that you an undertake projects of significant but manageable complexity. This is also to ensure a good staff-to-team ratio. We will allow single person teams and three person teams occassionally with the permission of the instructor. Based on your answers in the teaming preference doc (Due October 8), teaming will be determined and released by October 15.

Deliverables/Dates

There are four pieces of technical writing, and two pieces of technical presentation, you will be responsible for throughout the span of the final project. They are intended to build on one another, and in conjunction with feedback from staff, are intended to help you refine your project as it develops. Effective communiation is critical to ensuring the staff can advise your project and that you have a successful project. Therefore a large portion of your final project grade is tied to your work in these assignments. These six pieces are described in the order they will appear and be due during the final project phase:

Project Abstract

A two to three paragraph summary of your project idea. This should include:

• A high level (no need to dig too deep yet) specification of what your project should do. This can absolutely be tweaked and tuned over the course of the next couple of days.
• A discussion what the system's use cases are, how it should behave, and what its desired properties are (i.e., how does this system benefit from being run on an FPGA?)
• Design goals for your project - what properties are you prioritizing for? What components do you need to build in order to bring together a minimal viable product?
• How work will be broken up to ensure everyone can always be working efficiently.

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. Feedback will be provided by staff over email. An example Project Abstract (from previous year TAs Fischer and Jay) is provided here.

Block Diagram Report

A two to three page report, largely consisting of diagrams detailing the design of your project, identifying what pieces and modules are needed, and how they will all connect together. By this time you should have a detailed functional specification for each module your project will be comprised of, including its ports (with widths), clocking, the protocol(s) it will use to communicate with other modules, etc.

Your report should:

• Briefly introduce your system by identifying its purposes and its goals, and then summarize your system’s modules, behaviors, and innovative techniques or strategies. Give your a system a name. Get creative.
• Have one or several schematics showing the internal datapaths and components of each module your system encompasses, along with a first cut at the state transition diagram for any FSMs your modules embody (if any). Indicate the rough number of BRAMs and hardware multipliers that will be needed, and which IP blocks you'll be using if any. You should also determine what (if any) external hardware is needed for the project. Include supplemental figures if necessary to illustrate complex or challenging concepts

• Define your system completely, clearly linking design choices, techniques, or strategies to the behaviors and properties they produce. Justify your choices with use cases, design principles, and so forth, and identify major design tradeoffs you may need to make through the design and development process.

• Conclude by summarizing how your design meets the requirements put forth in your opening paragraph and/or your abstract. Highlight the novelty or FPGA-specific focus of your system, and describe the problems that remain to be resolved.

Your report should contain enough information to convince the staff that your design is reasonable, but it does not need to describe every detail of the system. You do not need to evaluate your design; an evaluation section will be part of your final report, but not the preliminary report.

Also, you needn't establish a conclusive checklist of what your project is attempting to accomplish. This can wait until the presentation / after another round of feedback.

Feedback will be provided by staff over email. An example Block Diagram Report (from previous TAs Fischer and Jay) is provided HERE.

Project Design Presentations

You will schedule a 30 minute block (15 minutes presentation / 15 minutes Q&A) to go over your design with the course staff. Presentations will happen from October 31st to November 3rd.

Presentations should include:

• A brief summary of your design. This should include a block diagram, a summary of key design decisions you've made thus far, and a description of the problem you're solving from 5,000 feet up. This part of your presentation should be quick - we've already read your block diagram reports and provided feedback, so this is just to get us all on the same page.

• The bulk of your presentation should focus on what's changed since the block diagram report. This could include changes you’ve made in response to feedback, or an explanation of any aspects of your design that were incomplete since the block diagram report.

In addition, we expect the following in every presentation:

• A brief discussion of how you intend to evaluate your design's efficacy. This may include latency, throughput, discussions of resource utilization and timing, etc. More information about design evaluation is provided in the description of the final project design below - don't worry about diving too too deep on this for now.
• A rough timeline for the implementation of your design - where you are now, and where you'll be over the course of the remaining deliverables for this project
• Your Project Checkoff List (see Grading Section)

Each team member should give part of the presentation. The 6.205 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, acme¹, etc. Please format the material so that it can be projected properly, i.e., it should be in landscape format. 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 your allotted time.

Please upload a PDF of your presentation slides so that they can be posted on the course website. Feedback will be provided both in the meeting as well as afterward in email. As an example, Fischer and Jay's presentation slides and video are provided here.

Preliminary Report

A two to three-page two-column IEEE-formatted report describing your design. Due-date is right before Thanksgiving. It is expected that a sizable portion of this report and figures may be reusable for the final report. This report should be modeled after the format of the final report, and should contain all the background info, design info, diagrams and any evaluation results obtained so far in the development process. Feedback will be provided in-person during the final stretch meetings.

An example preliminary report is provided here. IEEE-style templates can be found here for Word, generic LaTeX, and Overleaf.

Final-Stretch Meeting

We'll schedule a ~30-minute with you right after Thanksgiving. Using the checklist of deliverables previously established, we'll assess where the project is at and make any course corrections we as a group determine are necessary for your project to end at a good spot and to ensure that you're capable of still being productive in the last two weeks of the project.

Final Report

A five to six page two-column IEEE-formatted report detailing your full design. This report will be evaluated by staff and its content and quality will influence a large part of your grade. The document should build on your preliminary report. The report should be written in a consistent voice and should provide sufficient detail about all portions of the project as well as indicate who wrote what portion.

A typical final report includes several columns of narrative supplemented as appropriate by diagrams, tables, photos, etc. But don't focus on length. Your goal is to:

• Summarize the problem to be solved, and what your design is intended to achieve. When summarizing the problem, you should highlight the technical challenges that make this issue non-trivial to solve. Outline the requirements you set forth in your project checklist, and show how your design meets these requirements.

• Provide a high-level description of your system’s modules, behaviors, and innovative techniques. This should include a system diagram and serve to introduce definitions for key terms used further in the report. This should include enough detail for a knowledgeable reader to understand your implementation and replicate it themselves.

• Explain your design. Identify your design's main modules and FSMs. You should sub-divide the design, with corresponding subsections in the text (potentially authored by different team members), so that the reader can focus on and understand one piece at a time. Explain why your design makes sense as well as explaining how it works. Use diagrams, pseudo-code, and worked examples as appropriate. It should be clear from this section that your design meets the specifications set forth in your project checklist.

• Evaluate your design. This should be a multifaceted discussion supplemented by hard calculations and data acquired from Vivado, simulation, and your own experiments:

  • How might you qualify the latency and the throughput of the modules you've written? Do you incur any overheads worth discussing, and what does your system gain from these overheads?
  • How much block RAM or DSPs are you using, and do you think this could be optimized further?
  • What timing requirements must your design meet, and how tightly do you adhere to these requirements?
  • What use cases does your design handle, and how do these relate to the deliverables in your project checklist? Have you reached your minimum, ideal, or stretch goals? Speculate about additional use cases you could accomodate with minimal changes to your design.

• Finally, pass along any implementation insights you had, and if appropriate, indicate how you might do things differently next time. Include photos/diagrams/graphics if they'd help explain your point.

• Do NOT dump your project's source in your report. Instead link to an external repository of your team's code, hosted on a site or server of your choice.

• Include a brief statement about what each author contributed to the project. These contributions could include designing specific components of the system, research or investigation related to the design problem, qualitative or quantitative evaluation, writing the report, creating figures, etc. Also give credit to folks inside or outside the class you consulted throughout your project, and provide references if appropriate.

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

An example final report is provided here.

Final Video Demonstration

A pre-recorded video in which your projects functionality and design are discussed and demonstrated. The video should be no more than four minutes in length. All members of the project are required to narrate and/or speak during it.

An example final video is provided here.

Schedule

• October 4th-8th/11th: Teams constructed
• October 18th @5pm: Project Abstract Due
• October 29th @5pm: Block Diagram Report Due
• November 3rd- November 8th: Project Design Presentations (to be scheduled with staff)
• November 27th @5pm: Preliminary Report Due:
• December 2nd - December 5th: Final Stretch Meetings: (to be scheduled with staff) A informal meeting with feedback about the Preliminary report. In addition, at this point, you should triage and pivot your project to make sure you get done everything neccessary for a functioning final project.
• December 10th @4pm: Final Report (but a bug is preventing us from locking the submission boxes until December 11th at 10pm...whoops)
• December 10th @4pm: Final Video Demonstration Due: (but a bug is preventing us from locking the submission boxes until December 11th at 10pm...whoops)

Grading

We have high standards for handing out points, and 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 or systems of modules, each having the complexity of Week/Lab 4 or Week/Lab 7. 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.

Since we don't have the facilities or 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 reports submission.

Project Checkoff Checklist and Status Update

In consultation with the course staff, each team submits a checklist of deliverables for their project at the time of their Project Design Presentation. 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. The checklist should have three sections:

• The Commitment: the minimum that you hope to achieve; shows an adequate understanding of digital systems and Verilog. We're expecting a system with complexity around twice that of lab04 and lab05, modulated by the number of people in your team. Project grades are typically in the B range.
• The Goal: a fully functioning project meeting all the checklist items in this section. Demonstrates a superior understanding to digital systems and implementing complex systems - perhaps with multiple time domains, interface to external devices, flash memory, audio, etc. The implementation goes beyond what was in the labs. The project grades range from B to A.
• Stretch Goal: a top notch project that really stands outs with complexity, innovation and risk. Grades are in the A range.

This will be recorded at the time of your Project Design Presentation and will also be updated in your Final Stretch Meeting (however the original goals will not be completely forgotten).

Much of this final project specification is lifted from the 6.033 DP Preliminary Assignment, DPPR, and DPR. This is by design - if you've taken 033 (another CI-M), you'll notice that a lot of this feels similar to the 6.033 final deliverable! Many thanks to Dr. LaCurts and the 033 course staff for inspiring some of this document.

Specific Point Breakdown

52% of your final grade comes from your final project. Specifically:

• 2% from your Abstract and successful teaming.
• 5% from your Block Diagram Report.
• 10% from your Project Design Presentation.
• 10% from your Preliminary Report and project progress to that point.
• 25% from your Final Report and project progress to that point.

Note that this grade is also determined based on how you worked with your team and what portion of work you contributed to your team's project. If you made things harder for your team, that will be taken into account. Also note failure to adhere to deadlines will impact grades.