The purpose of the design document is for you to get some feedback about the design of your project before you start on the actual implementation. We hope that, by reading about your design before you start, we can correct or prevent architectural issues that would seriously hamper your efforts later on. We all make mistakes; the design docs are all about finding your mistakes before you've invested too much time in them.
As such, design docs must be reasonably detailed and will take you several hours to finish. This is OK. You would have to spend that time thinking about the project anyways; we just want you to write down and organize your thoughts.
To make it easier for your TA to find the relevent material, please follow the standard convention for design docs outlined below. Appended to this HOWTO is a sample design document in html and pdf.
Read over the entire assignment and try to get a feel for what you will be doing. Get together with your partners and make the hard architectural and design decisions: What will our top-level datapath look like? What sorts of submodules will we need? Are any submodules of such complexity that they need their own submodules? What will our control look like? How do we plan to minimize control signal complexity? How will we manage testing? Are there any interesting, non-standard features or ideas that we want to incorporate? What are the timing consequences of such features? Et cetera.
This section includes the goal of the project (so that we know that you are going to solve the right problem) as well as an overview of the steps you plan to take to get your assignment working. This should read like a very, very brief overview of the design doc itself.
This section should include all of the relevant and interesting design decisions that you made. You don't have to include the obvious stuff ("We decided to use the Xilinx tools and a Calinx board to implement our design..."), but we do want to know about any non-trivial decisions that you made. In particular, what features and properties could separate your implementation from that of everyone else? Also, put here anything that you think we should know about that will help us understand the lower-level material that follows.
This section should include prototypes for all of your major modules, including inputs, outputs, and a basic 2 or 3 line description of what it does and interesting, non-standard features it might have. Include things like (a)synchronous resets, clock enables, etc. You don't have to include every single module, but we do want you to include every module that is non-trivial. The modules should be listed in roughly postorder depth first: start at the lowest abstraction level and move up. Your last module should be your overarching TopLevel module.
We also want you to include a schematic of your datapath. This should show all of the major connections between all of your major modules. The easiest way to do this is to sae a Xilinx schematic and insert it in your project report. Lastly, we want you to include a solid description of the mechanics of your control. We would prefer it in FSM-form, where you describe the operations of each state. However, you are free to talk about control however you like, as long as it is understandable and reasonably detailed.In this section, talk about your overall testing plan (what will you test first, what next, etc.) as well as specific ideas for how to test the relevant sections. We want to see that you are coming up with a maintainable, sustainable, and exhaustive way of testing your components.
If you made any design decisions that you think will affect the timing of your assignment, please analyze their consequences here. What do you think your criticial path will be? Which sections will have the loosest timing? Which will have the tightest? Use numbers where possible.
Include a day-by-day plan of how your team will spend its hours, as well as major milestones (design, testing, writeup, etc.). Appoint someone to be responsible for scheduling stuff with the TAs. Give a rough division of labor.