DOC PREVIEW
Berkeley COMPSCI 150 - FINAL PROJECT GRADING CRITERIA AND REPORT FORMAT

This preview shows page 1-2 out of 5 pages.

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

Unformatted text preview:

University of California, BerkeleyCollege of EngineeringComputer Science DivisionElectrical Engineering and Computer Science DepartmentCS 150 R. H. KatzSpring 2001 Po YanFINAL PROJECT GRADING CRITERIA AND REPORT FORMATA critical aspect of your final project is to document what you have done in a final report. A perfectlyworking design is worthless unless it can be duplicated and built upon, and this is the role of properdocumentation. Long after the components are returned and the wiring is torn up, your report will remindyou of the design experiences that you had and the many things that you learned. It is not uncommon forstudents to bring their CS 150 Final Report to job interviews (be sure to make a copy for each projectpartner). This course has long had an excellent reputation among corporate recruiters from suchcompanies as AMD, Compaq, HP, IBM, Intel, Sun Microsystems, etc.We understand that you have worked hard on your project. We don’t want the final report to represent toomuch of an additional burden. The key thing is for you to evaluate your design and to document your extracredit features and lessons learned. The report sections and suggested lengths are described below. Thetypical report will be around 5 pages with quite a few additional pages dedicated to additional appendices,to hold your block diagrams, schematics, state diagrams, etc.) and tables (register transfer operations,microoperations, ROM contents, etc.). Use the following page lengths as guidelines, though we do want tokeep written descriptions short and crisp. The overall report outline is as follows:1. Introduction2. Theory of Operation3. Control Description4. Datapath Design5. Control Design6. Evaluation7. Lessons Learned and ConclusionsAppendix A: Control State DiagramAppendix B.1: Game Controller Interface SchematicsAppendix B.2: Audio Interface SchematicsAppendix B.3: Video Interface SchematicsAppendix C: Controller SchematicsAppendix D: Project Checkpoint Check-off SheetsIn more detail, the following describes in more detail the expectations for each subsection:1. Introduction (0.5 Page)What is the function of your project, in general terms? We know what it is—we assigned it to you!—so it is not necessary to go into details. This is to make the report able to stand on its own.Concentrate on how you differ from the original specification, especially in terms of extra credit workand special game features. What aspects of your implementation make you particularly proud (e.g.,few control states, able to run at a fast clock rate, unusual datapath or control organization, cool userinterface, etc.)? Why did you choose to implement that aspect of your design in that way?2. Theory of Operation (0.5 page)Describe how your project would be used by someone not intimately familiar with its detailedimplementation. What do you do on power up? How do you reset it? What is the detailed procedurefor getting it going? What assumptions about the supporting hardware environment are you making,e.g., memory system organization? What are the detailed timing constraints on your processor, e.g.,clock frequency or period and duty cycle? Include a diagram that shows the layout of yourprototyping board’s switches and LEDs and the functions and indications they provide.3. Control Description (1 page)Describe the basic control sequencing of your system, including your proto-board user interface.Attach a state diagram, a program-like description, or similar method for describing your control asAppendix A. In this section, the output of the control should be described in high-level registertransfer operations, not detailed control signals.4. Datapath Design (1 page)The major subsystems of your design map onto the three checkpoints we gave you: (1) GameController Interface, (2) Audio Interface, and (3) Video Interface. The purpose of this subsection is todocument these components in terms of their control signals and their timing behavior, and todescribe any changes you may have made to the original checkpoint specifications. Include blockdiagrams with documented input/output signal names for each subsystem in Appendix B.1, AppendixB.2, and Appendix B.3, one section for each of the three checkpoints.If you made significant change to a subsystem, include in this section a short description of its theoryof operation. Include a high-level register transfer diagram showing busses, registers, and functionalunits. Focus on how you have interfaced the three checkpoint components. Include in Appendix B a more detailed schematic, showing all library components and the detailedimplementation of interconnections such as tri-state buffers or multiplexers. The detailed diagramshould show all microoperation control signals. Appendix B should include a table that correlates theregister transfer operations of Section 3 with the microoperations in your datapath. Very brieflydescribe the function performed by each register transfer operation. 5. Control Design (0.5 Page)Give a short description of your controller’s theory of operation. Did you use random logic, shiftregister “one hot” design, counter-based state register, a ROM-based design, or some other strategy,such as multiple communicating state machines? Describe your approach for state assignment, if any.In Appendix C, (1) give a block diagram description showing the controller inputs, state register, andoutputs, (2) describe any equations or microcode formats, and (3) for ROM-based designs, include atable showing the ROM contents in terms of your chosen format. Briefly describe what is happeningin each ROM word. 6. Evaluation (1 Page)Describe the overall system timing considerations for your design. What is your critical path? What isthe maximum speed you believe you can transmit and receive data? Justify your answer based onidentifying your critical path and determining its speed. In addition to time, consider space. Include inyour answer the number of Xilinx CLBs used in your design. What percentage of the Xilinxcomponent did your design consume?7. Lessons Learned and Conclusions (0.5 Page)What have you learned from you experience implementing your project? What would you dodifferently if you had the ability to start over from


View Full Document

Berkeley COMPSCI 150 - FINAL PROJECT GRADING CRITERIA AND REPORT FORMAT

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 GRADING CRITERIA AND REPORT FORMAT
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 GRADING CRITERIA AND REPORT FORMAT 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 GRADING CRITERIA AND REPORT FORMAT 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?