Sample Project Submission
This page contains a sample project that was created to illustrate what is expected of reports in this class. This report goes into some extra detail that is not necessary (for example, there is no need to produce schematics for alternate designs). You do not need a table of contents or table of figures nor do you need to label your figures with captions. However, you may find these items to be useful, so I show them here as an example. Spend your time on your design and the rest of the content.
Report - Printed and handed to TA. If you wish to use this document as a starting point for your files, you can download the word version here
Files - Emailed to instructor and TA
- Cover Page with the project title, your name, your section, and the date the project is submitted.
- All report sections (Objectives, Background, etc). While the names of these sections may be changed as appropriate - they need to appear in the report. In this example, the section names are changed, but I put the "real" name in parenthesis for clarity. See below for a description of the contents that should be present in each section of the report.
- Full design explained. If you build modules, explain them. Show a truth table or logical argument (I have examples of both in this sample). Reduce your equations using boolean algebra, k-maps, or other technique whenever possible. Then show how these modules are pulled together to produce the final circuit.
- File naming convention - see below for a simple way to do this.
- Formal writing style - no first person (I, We), proper spelling, grammar, etc.
- Single file - all schematics, diagrams, tables, etc are cut and pasted into the report. See below for some tips on how to do this well.
- Submitted on time either printed and emailed, or printed with a diskette.
- Objectives - Very breifly state what the entire report is about. It will sound fairly similar to your conclusion section. Like all sections of your report, this must be in your own words - do NOT copy the project handout I provide you.
- Background - Projects will always have an incomplete specification. The background section should be used to fully specify the inputs and outputs of the circuit. The reader should gain an understanding of how the circuit works from the user's level and may start to understand the decomposition that will be used in the procedure.
- Procedure - Working either top-down, or bottom-up, your design needs to be decomposed into smaller pieces that can be worked on and tested (think of functions in programming languages). This is where the bulk of your work will appear. Make sure that your report flows in a logical order so the reader can understand what you are doing and why. They may have to jump around a little to reference diagrams or schematics, but you want your paper to have a consistent flow to it. Make sure you include truth tables, reduction techniques, final equations, and a schematic for every block that you work on. This proves that it is your work and allows the reader to build your design without having to find you and ask you questions. If some of these items are too big and are breaking up the flow of your writing too much, move them to an appendix and reference where to find it.
- Test Results - Each module should be tested independently before using it to build the final circuit. Debugging at the top-most level is very time consuming and prone to subtle errors that do not get detected until your TA is looking at your work.
- Discussion - For any design decisions you made (and there will always be some) you should try to comment on decisions that will have impacts on the ability to make changes to your solution at a later time. Gee, what you did looks good, but can we add 10 more widgets to it. Depending on some decisions you made, your design may be highly optimized to use as few parts as possible, but completely inflexible to changes or vice versa. As an engineer you need to keep these decisions in the back of your mind.
- Conclusions - Does this solution appear to work? It should, but may have some limitations. Perhaps the error checking isn't that good so while it works, you found a few bugs during testing. If you didn't call this out in your discussion, then it should appear here. This should really be a quick summary of the state of the project (not that it was hard, you didn't like it, etc) This is a formal paper - keep it objective. Toss complaints, suggestions, etc in the email you send your TA and myself.
Naming Convention Tips
To make your life simple, when you start working on a project create a folder for yourself that matches the required naming convention. For example,
207_FA03_0_Mapen_Barry_SampleReport. Then keep all of your work in here using any naming convention you want. When you are ready to send your work in, simply right-click on the folder (assuming you have WinZip installed) and select
Add to 207_FA03_0_Mapen_Barry_SampleReport.zip. You are all set to email this in.
Cut and Paste Tips
Cutting and pasting different types of objects can get a little challenging some times. Here are my recommendations for moving schematics into your report. I tend to type my entire report and put captions as places holders for schematics. I then go back and add the schematics at the very end. No matter when you add the schematics, start with your schematic open in LogicWorks. Ctrl-A will highlight and select the entire file. Ctrl-C will copy the selected items to the clip board. Switch to your word document and select Edit -> Paste Special. You will have a few options for how to pull the schematic in. Use the Picture (Enhanced Metafile) option. Sometimes the graphics don't fit on the screen. Press shift-F10 (equivalent to right-clicking - but you don't need to find the graphic if it shot off the screen). Choose Format Picture (Object) to adjust how the object appears in Word. Select Layout -> In line with text, Size -> 50% (typically). If you have a large white space surrouding the picture after this point, you can change the cropping in the Picture tab while in Format Picture (Object).
Barry E. Mapen