DOC PREVIEW
Berkeley COMPSCI 150 - Final Project Report

This preview shows page 1 out of 4 pages.

Save
View full document
View full document
Premium Document
Do you want full access? Go Premium and unlock all 4 pages.
Access to all documents
Download any document
Ad free experience
Premium Document
Do you want full access? Go Premium and unlock all 4 pages.
Access to all documents
Download any document
Ad free experience

Unformatted text preview:

EECS150 Spring 2004 Final Check OffUNIVERSITY OF CALIFORNIA AT BERKELEYCOLLEGE OF ENGINEERINGDEPARTMENT OF ELECTRICAL ENGINEERING AND COMPUTER SCIENCESpring 2004 ProjectFinal Project ReportThe final report is a technical description of the device that you have designed and built for your project. The main purposes of documentation are to allow users to understand and operate your device, and for your fellow engineers to understand your design so it can be upgraded, improved, and maintained. Your goal should be to ensure that your design will be useful even if you are no longer around to explain its function. Without adequate documentation, many great designs are sent to the scrap heap. For this semester,since the SDRAM arbiter, router and ports are the heart of the project, we want them to be given the most emphasis. Make sure to leave time for editing, typing, and proof-reading. Your report should follow this general outline: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. Abstract (1 paragraph)4. Overview (1-2 pages)a. Design (Detailed Block Diagram)i. You may NOT use oursii. You may draw this by hand, but please use a rulerb. Brief Description of Major Sub-Modulesi. Keep this part shortii. Don’t bother telling us what we already know (FIFOs, EthTx, etc…)5. System Description (5-6 pages) with figuresa. Subsystem 1: Ethernet Modulesi. EthRx Moduleii. Network Portiii. A brief word on EthTxiv. Block and Bubble-and-Arc diagramsb. Subsystem 2: Audio Modulesi. How to you handle resetii. Shift registersiii. Timing and Block Diagramsc. Subsystem 3: SDRAM and Routingi. SDRAM Arbiterii. Router (Static or Dynamic)iii. Block and Bubble-and-Arc diagramsd. 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 max)a. Number of 4LUTsb. Design and debugging time estimatesi. Design Timeii. Time for each checkpointiii. Time spent writing verilogiv. Debugging time7. Conclusion (1 page)UCB 2003EECS150 Spring 2004 Final Check Offa. 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 differentlyc. We already know the class is hardFor the overview section, try to give a “breadth before depth” introduction to your project. Readers need to get a general picture of your system before they can understand the details. Describe the user visible features; save the detailed inner workings for the system description section. You should have a general block diagram in this section. Try not to duplicate our description of the assignment too much, we already know what we assigned you. Also, do NOT use our block diagrams, you will lose points for being lazy (besides your project won’t completely match our diagrams).The detailed system description can start with functional and input/output specifications. Modulescan be described in order from input to output, or from most to least important module. Illustrate the descriptions with the block diagrams and timing diagrams you have prepared; refer to these as figures. Don’t bother going into the details of very simple modules. However, do give detailed descriptions and figures for your SDRAM Arbiter, SDRAM FIFO modules and Router.For the conclusion, summarize the key design features. What will the reader need to be careful about if they were to attempt to duplicate or modify your design? And, what are possible improvements which could be made to the design?Standard hints for the Final Project Report:1. Type this report. DO NOT hand write ita. Diagrams and figures are an exception but please make them neat.2. Use standard 8.5 by 11 paper throughout the report, except for diagram pages, which can be on larger sheets. (Larger sheets for diagrams are easier to follow, and can be neatly folded to fit in a standard binder.) Minimum 12pt font, single spaced with 1 inch margins. Text portion of report should not exceed 9 pages. Any text after the first 9 pages will not be read. Appendices, including timing diagrams and schematics can be up to 20 pages MAXIMUM.3. Make a copy of your report for safety.4. Make sure the copy you hand in is easily readable.5. Include block diagrams, bubble and arc diagrams, timing diagrams, state diagrams, and tables as appropriate and on or as near as possible to the page in which they are referenced.6. Put titles on all figures and diagrams.7. Put some thought into thisa. Poor documentation will degrade the perceived quality of your workb. This report is worth as much as a checkpointReports are due Friday 5/7 at 4pm. Please submit an electronic copy to fileservice in the same folder that you submitted your project, you may update your verilog if you wish to add comments, DO NOT HAND IN PRINTED VERILOG. The electronic copy need not be complete, it may be missing diagrams and anything else hand-drawn. A paper copy is due at the same time, in the lab. A TA will be present to collect it.UCB 2003EECS150 Spring 2004 Final Check OffUNIVERSITY OF CALIFORNIA AT BERKELEYCOLLEGE OF ENGINEERINGDEPARTMENT OF ELECTRICAL ENGINEERING AND COMPUTER SCIENCEEECS150 Spring 2004 ProjectVoice Over Ethernet SwitchFinal Check Off & Project ReportSubmitted 5/7/2004ByLast Name First Name Login SIDLab SectionOverall Project Grade (100): _______Checkpoints (40): _______Final Project Demo (50): ________Project Report (10): ________Professor: Randy KatzProject: Greg GibelingTAs: Eric Chung, Gabriel Eirea, Greg Gibeling, Michael Liao, Zohair HyderUCB 2003EECS150 Spring 2004 Final Check OffEECS150 Spring 2004 ProjectPartner EvaluationLast Name First Name Login SIDYouPartnerLab SectionPlease indicate the percentage of work both you and your partner did. You and your partner must BOTH submit a copy of this form.If you partner did not put in their fair share of work, this is your last chance to tell us. Wewill investigate the matter if you check the line below.Please be honest.Percentage of work done by partner: _______I felt that this was unfair: _______UCB


View Full Document

Berkeley COMPSCI 150 - Final Project Report

Documents in this Course
Lab 2

Lab 2

9 pages

Debugging

Debugging

28 pages

Lab 1

Lab 1

15 pages

Memory

Memory

13 pages

Lecture 7

Lecture 7

11 pages

SPDIF

SPDIF

18 pages

Memory

Memory

27 pages

Exam III

Exam III

15 pages

Quiz

Quiz

6 pages

Problem

Problem

3 pages

Memory

Memory

26 pages

Lab 1

Lab 1

9 pages

Memory

Memory

5 pages

Load more
Download Final Project Report
Our administrator received your request to download this document. We will send you the file to your email shortly.
Loading Unlocking...
Login

Join to view Final Project Report and access 3M+ class-specific study document.

or
We will never post anything without your permission.
Don't have an account?
Sign Up

Join to view Final Project Report 2 2 and access 3M+ class-specific study document.

or

By creating an account you agree to our Privacy Policy and Terms Of Use

Already a member?