1.0 Report Description2.0 Report Outline3.0 Hints4.0 SubmissionEECS150 Fall 2004 Final ProjectUNIVERSITY OF CALIFORNIA AT BERKELEYCOLLEGE OF ENGINEERINGDEPARTMENT OF ELECTRICAL ENGINEERING AND COMPUTER SCIENCEFall 2004 ProjectFinal Project Report1.0 Report DescriptionThe final report is a technical description of the device that you have designed andbuilt for your project.The main purposes of documentation are:1. Allow users to understand and operate your device.2. Help your fellow engineers to understand your design so it can beupgraded, improved, and maintained.Your goal should be to ensure that your design will be useful even if you are nolonger around to explain its function. Without adequate documentation, many greatdesigns are sent to the scrap heap.For this semester, since the SDRAM controller and arbiter, the game engine arethe heart of the project, we want them to be given the most emphasis. Make sure to leavetime for editing, typing, and proof-reading, nothing is more annoying than trying to readdocumentation that has obviously never been proof-read.2.0 Report OutlineThis is the closest you will get to detailed specification for the contents of yourreport. It is your job to design, write and edit your report as well as produce diagramsthat will adequately document your design.Anything with a “1.” Or a “a.” by it should be included as a section of your report.You report, excluding the cover page and table of contents may total no morethan 10 pages of text and 20 pages with diagrams. You may include diagrams withinthe text or on separate pages at the end. If you have draw diagrams, be sure to use a ruleror graph paper, messy diagrams are useless.1. Cover Page (See end of this document)a. Fill this in, print it out and staple it on top of your report2. Table of Contents3. Abstracta. Approximately 1 paragraphb. Your abstract should be about your projectc. Describe your design, not the project requirements4. Overview (1-2 pages)a. Design (Block Diagram)i. You may NOT use our diagramsii. You may draw this by hand, but use a rulerUCB 1 2004EECS150 Fall 2004 Final Projectiii. You must show more detail than our diagramsiv. You diagram should be easily read and understoodb. Brief Description of Major Sub-Modulesi. Keep this part shortii. Do not repeat the assignment specificationiii. Add details about how you changed or added to the assignment specifications5. System Description (5-6 pages)a. Include detailed figuresi. You may NOT use our diagramsii. You may draw these by hand, but use a ruleriii. You must show more detail than our diagramsiv. You diagrams should be easily read and understoodb. Subsystem 1: N64 Controlleri. Short Sectionii. Block and Bubble-and-Arc diagramsiii. Module decomposition / Block Diagram (if you have multiple modules)iv. Serial transmission and capture descriptionc. Subsystem 2: Game Enginei. Long Section (Lots of detail)ii. Include a detailed block diagramiii. Physics and math1. Include equations as needed2. This must be very detailed3. Every bus that carries a number must have units4. Every register that holds a number must have unitsiv. Modules1. Block diagram showing connections2. Show what state is in each module3. Describe what each piece of state representsv. Theory of operation1. How does it fit together2. Bubble and Arc Diagramd. Subsystem 3: SDRAM Control and Arbiteri. Medium Length Section (Medium Detail)ii. SDRAM Arbiteriii. Router (Static or Dynamic)iv. Block and Bubble-and-Arc diagramse. Subsystem 4: Video/FIFOi. Short Sectionf. Design Tradeoffsi. Did you have to sacrifice any features to make it work?ii. What did you change as a result of debugging?iii. What would you design differently next time?6. Design Metrics (1 page absolute max)UCB 2 2004EECS150 Fall 2004 Final Projecta. Number of 4LUTsb. Design and debugging time estimatesi. Design Timeii. Time for each checkpointiii. Time spent writing Verilogiv. Debugging time7. Conclusion (1 page)a. Summary of main featuresb. Problems Encounteredc. What would you do differently next time8. Suggestions (1 paragraph)a. What was too difficultb. What should we do differentlyFor the overview section, try to give a “breadth before depth” introduction to yourproject. Your readers need to get a general picture of your system before they canunderstand the details. Describe the user visible features; save the detailed innerworkings for the system description section. You should have a general block diagram inthis section. Try not to duplicate our description of the assignment too much; we alreadyknow what we assigned you. Also, do NOT use our block diagrams, you will lose manypoints and besides your project won’t completely match our diagrams.The detailed system description can start with functional and input/outputspecifications. Modules can be described in order from input to output, or from most toleast important module. Illustrate the descriptions with the block diagrams and timingdiagrams you have prepared; refer to these as figures. Don’t bother going into the detailsof very simple modules. However, do give detailed descriptions and figures for yourSDRAM Controller, Arbiter and FIFO interface as well as your game engine andeverything in it.For the conclusion, summarize the key design features. What will the reader needto be careful about if they were to attempt to duplicate or modify your design? And, whatare possible improvements which could be made to the design?3.0 Hints1. Type this report. DO NOT hand write ita. Diagrams and figures are an exception but please make them neat by usinga ruler and/or graph paper.2. Use standard 8.5 by 11 paper throughout the report.a. Diagram pages may be on larger sheets.b. Larger sheets for diagrams are easier to follow, and can be neatly folded tofit in a standard binder.3. Minimum 12pt font, single spaced with 1 inch margins.4. Page Limita. Cover page and Table of Contents are not included in the page limitb. Text portion of report should not exceed 10 pages.c. Appendices, including timing diagrams and schematics can be up to 20 pages MAXIMUM.UCB 3 2004EECS150 Fall 2004 Final Projectd. Anything after 20 pages will be torn off and IGNORED.5. Make a copy of your report for safety.6. Make sure the copy you hand in is easily readable.7. Include block diagrams, bubble and arc diagrams, timing diagrams, state diagrams, and tables
View Full Document
Unlocking...