Format for EE414 Final Report

Format for Design Proposals and Final Project Reports

Last Modified 1/28/01

The final project report should be written with the above goals in mind. Do not assume that the grader of the report is the only one reading it, and start off with a highly technical explanation, or assume he knows everything and just include the layout, schematics, or source code without explanation. Instead, work your way up to the technical description in a clear and logical manner so that anyone reading the report will have some idea of what was achieved. Do not fill your report with tens of pages of schematics, VHDL code, and/or simulation waveforms, so that the report looks heavy with content. The final source and other run-time reports belong only in an appendix where an interested party can refer to them to get a complete understanding. Use the following guideline to write your report. The red headings generally apply to your final project, whereas the the blue ones apply to your project report.

Cover Page

The cover page should contain the title of the report, and a sub-heading indicating that it is the final project report/proposal for this quarter. Include the date, your name, and box number.

Introduction

This is the part where a layman reading your report should get an overall idea of your work. Use simple, non technical language and introduce the reader to your work (what is the purpose and history of the work? how was it achieved? was the work successful?, etc.) Lastly, introduce the reader to the rest of the report (what does the remainder of the report contain? what does the appendix contain? etc.).

Description

Use this section to introduce the reader to the design you have implemented (what does it do? how is it implemented?) Subsequent Sections

You can have any number of these as you see fit. Partition the explanation to logical parts and give each part a logical sub-heading. Some examples are, the architecture of the design and the modules (winner takes all, spiking neuron circuit organization and/or basic funcionality). In each part, explain clearly how you approached the design (did you use any examples from other designs?) and any design challenges you overcame. Remember, keep your explanation clear. Use plenty of diagrams; a block diagram is essential, and will give the reader an overall idea of the design. If you used a structural description at a high level, then include a block diagram or even a high-level schematic. Remember, if your schematic has several hundred transistors and each is the size of a sand grain, the reader will not benefit from it. In this case include circuit fragments to aid in the explanation. If your design includes one or more state machines, include a state diagram or SM ( flow) chart. Illustrate succinctly what each state does in the diagram (if it won't look too cluttered). When explaining a section of the design, to help clarify, you can include a VHDL code fragment for that part (for those using VHDL). Indicate all references in the text, and use footnotes if appropriate. These recommendations will greatly improve the readability of your report.

Schedule

Include a proposed schedule for your project. You will have approximately five week to work on the project. Describe how much time you intend to spend on logic design, simulation, layout of final design, testing, etc. Later when you write the final project report, you can explain if this schedule was realistic. For example, did it take more time than you anticipated to do the layout of the design?

Problems Encountered

You don't need a separate section if you already addressed design problems in the individual sections above. This section will contain challenges you faced during the design process. Do you have any rants about the Mentor Graphics software? Did the circuit simulate fine until you connected it to the rest of the design? Did you have trouble with the initial simulation and synthesized simulation not matching up (for VHDL)? How did you overcome these obstacles?

The Final Design

Again, think of a suitable heading. This section should explain the design in its final form. Does the design do what its supposed to? Is it fast and efficient? Can it be considered ready for production release?

Future Work

While working on the design, did you think: "Gee, wouldn't it be neat if I can add this feature so that it can also do this", or during the last week of the quarter you realize that the method you've been using is not the best but there is just not enough time to start over, then this is the place to address these issues. If you couldn't meet the entire design specification, then explain what else needs to be done to finish the design.

Conclusion

This is the punch line section of the report, where you impress the reader about what you have achieved. Be clear and concise, and go over the main points of the report that were explained in detail in the preceding sections.

References

Include all references used in your work. Use a standard format for references such as MLA. The old ENG305J textbook may be of help here.

Appendix

Include complete schematics, layout diagrams, VHDL source code, simulation results (waveforms), and synthesis and implementation reports in a numbered appendix. The simulation waveforms should be annotated, so that the reader clearly understands what the simulation is showing. Include a heading for each waveform and automatically generated report you include.

In addition to the above format, pay attention to the following:

Report should be printed on single-sided sheets, with double-spaced 12-point font that is left and right justified.
Use a word processor and preferably, a laser printer.
All layout diagrams should be printed in color. After making sure that you have everything set up correctly by doing a test print on the normal printer (ECEPS).
Number all pages.
Diagrams may be hand drawn. However, Xerox the entire page with the drawing before adding to the report. Please do not tape or staple drawings to the report.
Number all figures and tables in a logical manner and refer to them by number on the text. Don't say "the diagram above" or "the table below".
Text must have perfect spelling and grammar. You will lose points for errors.
Annotate simulation reports and circle interesting results if appropriate.
Preferably, the report should be bound. However, you may staple it if you wish.
Report should be neat and free of any smudge marks.

Remember, the ultimate objective is to impress the reader. In an industrial setting, you may end up getting a raise for your work. For this course, a good report will get you a good grade. Being able to clearly document what you managed to accomplish in a neat report can sometimes turn things in your favor. This in no way implies that you can get away with doing half the design and submit a good report. I will know by reading the report how hard you have worked on the project.

Lastly, please consider publishing your work on the web. Most word processing tools do a good job at converting documents to html. You can impress your potential employers by including the url in your resume.