Project Reports

This document will be periodically updated. Last update 2012-2-28

Carefully read the Report requirements. You can't receive marks for what you don't submit. Worse still, you can't receive the best feedback to revise your plans.

Hints, Requirements for each report, Proposal, Specification, Critical Design Review Presentation, Progress Report & IO Demonstration, Final Report, Application Notes, Final Presentation

Hints

Need an idea for a project? Consult this list or create your own. (You will be prompted for your CCID)
Have sections of your report ready 2-3 days before the due date to give all group members a chance to proof read and integrate all sections together. Don't forget to check spelling and grammar.
Where appropriate, reuse code / subcircuits / VHDL -- your own or those from libraries. Be sure to note the sources of all items from libraries in your references to avoid worries of plagiarism.
Follow the acceptable C, RTOS and VHDL coding standards for portable, maintainable, documented code. See the CMPE 450/490 coding guidelines.
Long before completing your design, compile C code and VHDL to check if your design is likely to fit in the proposed platform.
Find partners who have similar goals, levels of ambition and work hours.
You may use any program languages and hardware description languages that are appropriate and supported under the tools. Expect to be able to get more help with C, Nios-II and VHDL bugs.
Figures produced on a computer should be imported into your report as vector graphics. Raster graphics (pixelated) are not acceptable. JPEG is good for photos (and otherwise 1MB chip plots). If you scan hand-drawn figures (for the earlier reports), use black-and-white 1-bit per pixel with at least 300 dpi resolution.

Report requirements

Any material prepared for one project submission can probably be reused in subsequent submissions. Start early!
Reports are to be submitted electronically here as a single PDF file. The command "ps2pdf" is available in multiple Linux labs.
The required sections below should be submitted in order and have identifiable section headings.
Weekly meetings with course instructor and/or lab instructor are an important part of the course and will be reflected in project report marks.

Which report				subject to change
p				Proposal
	s			Specification
		i		Progress Report & IO Demonstration
				Critical Design Review Presentation
			f	Final Report
				Application Notes
				Final Presentation
o	o	o	o	optional materials marked with "o"

p	s	i	f	title page title (plus a subtitle if the title is too cryptic) include names and preferred email addresses of all group members, no student IDs please <20 word summary of project list group number and preferred lab day and other lab days when available
	s	i		Declaration of original content All group members must sign and date their own signature. Other text should be typeset and included in your report. Hard copy of only this page may be submitted to the cmpe490 assignment box. If you choose to scan and submit this, then scan the whole page and have the original available on request. State: "The design elements of this project and report are entirely the original work of the authors and have not been submitted for credit in any other course except as follows:" provide a descriptive list of exceptions that reference your citations [], e.g. embedded processor core and UART provided by manufacturer [1] transcendental functions library used was [2] schematic in figure 3 was taken from reference [3] video frame buffer "vga.vhd" was modified from [4] ADC support circuitry was taken from the manufacturer's application notes [5] coefficients for motor PID controller are from [6] portions of the code in "controller.c" were previously submitted in course ECE 388.
			f	Same as above, but the declaration does not appear in your report. Hand it in separately as hard copy to the assignment box.
p	s	i	f	abstract (<250 words) highlight achievements - what did you do and what worked
p				bonus: include a recent face photo of each group member with name - all on one page cell phone photo or scan of a OneCard are fine.
	s	i	f	table of contents
p	s	i		functional requirements of project What is it supposed to do? backup plans or features to remove options/extensions
			f	functional requirements of project What is it supposed to do? Were those met? To what degree? Move options, extensions to Future Work
p	s	i	f	design and description of operation block diagrams of data flow can help out here From the specification on, I would expect sufficient detail so that if I gave the description to another group, they could build a project with similar behaviour. Show all algorithms and math that describe the behaviour.
p	s	i		hardware requirements - what do you need? interfaces estimate required capacities (e.g. Flash, RAM, FPGA logic elements /gates) proposed lab platform (Altera DE2 or other) Estimate calculations per second (multiply, {add, subtract, compare}) by task. Which tasks require a multiplier in the microcontroller and which require a hardware accelerator? Estimates could be verified through profiling code.
p				proposed parts order list, supplier, cost include web links to supplier and datasheet
	s	i	f	parts lists, description, most relevant spec (e.g. pixels, power), cost, order status (ordered before spec report, should all arrive shortly after submitting spec report and many weeks before IO demo) include web links to supplier and datasheet
p	s	i	f	Describe and evaluate different available sources of reusable design units {open source software, device drivers, FPGA IP cores, opencores.org}: source size, compiled size, performance, resource requirements
p	s	i		All IO signals Signal names, number of wires in buses; be as accurate as you can Indicate where each signal is found: (optional) generic microprocessor peripheral to custom HDL design within FPGA FPGA to board off-board off-board electronics to world {transducers, motors, etc.}, identify voltages levels, currents, etc. Also identify all required power supplies.
			f	Datasheet %%% performance, user block diagram Expand on the above to produce a datasheet of your complete embedded system. include calculated and measured power {peak, idle, standby as applicable} describe how each is calculated and measured
		i	f	Background Reading Search for articles that provide background helpful for your project {algorithms, designs, standards, etc.}. At least one article should be from a scholarly journal or conference. Suggest searching IEEE Xplore. From off-campus, use the library link. Describe the background information you found and comment on its utility for your project.
	s	i	f	Software design description block diagram of how processes interact, flow of data, other synchronization list any libraries or RTOS used
	s	i	f	Test plan Software: test of hardware-independent software components software test benches test of hardware-dependent software components Check for "memory leaks" and other reliability issues. Measure free space after 5 and 30+ minutes of activity. Hardware: functional test procedure calibration/performance/characterization measurement procedures simulation and testbenches if appropriate
	o	i	f	Results of experiments and characterization: numerical simulations of your algorithm in C or Matlab etc., before reducing it to hardware trade-offs in design effort, size, speed, power, cost characterization and calibration
	s	i		Integrated circuit design proposal - what will be included in the integrated circuit designed below? %%% For CMPE 450 students, optional for CMPE 490 student
			f	Integrated circuit design %%% For CMPE 450 students, optional for CMPE 490 student Take the VHDL code you have designed for your project, remove references to proprietary cores you don't have source code for, and synthesis, place, route and verify an integrated circuit. Prepared a datasheet. Compare to FPGA performance. Show conclusions of CAD logs, including verification {synthesis speed, power & size, P&R speed & size, LVS, DRC}. If the pin count turns out to be excessive, you can route a core without the pad frame.
	s	i		old schedule with annotations provide the schedule you submitted in the last report add comments (hand written or typed on each line) about completed tasks and explain schedule updates no penalty of course for missing your own targets honesty won't be held against you here -- this schedule exercise is for your benefit
3	5	7		new schedule ideally you have all your work broken down into many several hour tasks, but do your best after analyzing each old schedule, you can hopefully prepare a new more realistic schedule provide name of task, who will do it, start & finish dates, hours required, (leave a blank column for hours left for above) list at least N (at left) uncompleted tasks per group member (do not include course deadlines or submission preparation) as you progress, each task will become more finely subdivided
	s	i	f	References (a.k.a. citations) Using someone else's work and forgetting to cite it is plagiarism and the penalties are harsh. textbooks, research papers, datasheets, applications notes, web pages, past projects Use IEEE format, pages 4-5. For materials obtained on the web, provide full URLs to the document. In case hyperlinks don't don't get translated to the PDF, spell out the URLs. Sometimes a URL to the parent page is useful.
p	s	i	f	Weekly brief group minutes must be submitted starting the day of the proposal submission until final report is submitted. Preferably, the minutes will be the body of the email, not an attachment. No formatting required. These should not go in the report. Send via email to repository and to all group members Email subject must start with group number, e.g. "g1" Rotate who takes minutes Minutes should include: Dates of work and casual meetings, who was present What each member achieved and whether the week's goals were achieved Goals for each member in the coming week Comments and suggestions by course instructor, lab instructor and TAs
				Appendices
			f	Quick start manual All instructions required to re-assemble project, connect IO to lab boards, configure and demonstrate. What do the buttons and switches do? Include file names of binary/configuration files which should all be in your source and binary archive submitted with your final report. Assume that the reader is familiar with Quartus, so brief descriptions such as "Program the FPGA with game.SOF" should be sufficient. Provide files and instructions for both .SOF and .POF routes to demonstrating the project. Ask yourself, is there anything Nancy or I need to know to demonstrate your project at open house? %%%
			f	Future work Move and rewrite backup plans, options, extensions as Future Work. You have more great ideas that was possible to build, share these ideas with the next generation.
	s	i	f	Hardware documentation 1-page block diagram of hardware Full (hierarchical) schematics showing all components FPGA boards and other modules may be represented as one component.
	s	i	f	source code section: If systems integration and testing is half the work, then arguably, most or all of your code needs to be written by half through the term. block diagram of interactions between processes (copy of diagram from software design, above) diagram: graphical hierarchy of source code (for each process if applicable) index to source code -- include a one-line description of each file -- indicate the status of each source file as one of {Not compiled successfully, Compiled without errors, Executed or otherwise demonstrated, Tested and passed}, one letter abbreviations are fine. Include the following files in a compressed archive (e.g. tar, zip). For the specification and progress report, you have the option of including these files in the report text. source code - documented, indented and readable embedded source code testbench source VHDL/Verilog source with testbenches if applicable simulation source if applicable any other design files (final report) all compiled binaries (software and FPGA configurations)
			f	Self evaluation of group members - hard copy only submitted separately Provide your proposal for how project marks should be distributed among group members (hopefully evenly). If the group does not agree on how this should be done, each group member should attach their own signed proposal, with justification and reference to the group meeting minutes.
o	o	o	o	Feedback and comments to instructor (optional) For final report, send separately

Project Proposal

requirements

By now, you will have formed groups and have come up with an idea for the project. Describe that idea with particular attention to what's involved in the embedded software, . Pay attention to what features can be added or dropped as time and space concerns arise.

Hand in about 3 pages plus figures and whatever documentation you want to add in an appendix.

Have sections of your report ready 2-3 days before the due date to give all group members a chance to proof read and integrate all sections together. Don't forget to spell and grammar check.

Specification

requirements

The project specification should be about 6 pages plus figures, code and appendices.

While your final project may include more or fewer features, you should give a detailed report on the proposed operation of one possible implementation of your project.
Any additional components you will require should be ordered by now. Provide a list of what components you have and when the others will arrive. Anything signed out must be returned by the end of classes.
Include in an appendix any design and simulation documentation which you have produced to date.

With the exception of drivers that talk to embedded IO, software can be designed and tested on a desktop computer, up to and often past unit testing. If you wish, you can make a mock-up of your system on the desktop computer to further test software module integration and system functionality. Beware of spending too much time on "throw-away" code that doesn't appear in your final project, such as IO for the desktop computer (printf's might suffice).

If you intend to use the machine shop's services or have a printed circuit built, you should provide your designs for approval days after submitting your specification.

Critical Design Review Presentation

Each group will present to the class for 10 minutes (max) during the regular 8AM lecture time. Convince the audience that you have the majority of the design problems solved and that the project will be successful. This will follow on from your specification. Choose the most likely set of features you'll be implementing. Provide and explain at least one interesting example of code {C, HDL, pseudocode} (probably shouldn't go over 1 minute). Include:

Introduce group members and any parts of the project each has lead
Functionality, motivation
Design, include block diagrams of hardware, organization of software

Describe the biggest challenge thus far

Components implemented in FPGA, other parts
Code example
Test plan

Results of Unit and Integration Testing

Describe your application notes, if applicable
Other features to add or previously described features to remove

There will be 5 minutes for audience questions. Please contribute to your classmates' success by participating in the design review.

Submit your presentation slides by 7AM on the day of your presentation. You can use PPT, PPTX or PDF formats. See instructions for posting your slides to the web. File names must start with your group number (e.g. g0_xyzzy_slides). Bring a backup copy of your slides on a USB memory key.

Progress Report & IO Demonstration

requirements

At this time, you should demonstrate that all parts of your IO are working under microcontroller control (e.g. motors move to where they should go, sensors sense, displays display -- I don't want to mark any more projects that are "entirely working except for all of the IO"). You may download multiple configurations to test different parts of your IO if you wish, since system integration is not yet a requirement. You will have the opportunity to demonstrate additional aspects of your design project, including software.

A significant portion of your code should be written at this time. Given that system integration and test may take half the time, a strong argument can be made for having all code completed, but not necessarily integrated.

Your report will expand on your Specification. Include any measurements and characterization of your IO.

Final Report

requirements

This is your masterpiece. Employers may ask you for a sample of your work -- why not this report?

Be sure your achievements are clearly stated. Did it work?

The final report should be posted on the web by creating a subdirectory under login.ece.ualberta.ca: ~elliott/www/cmpe490/projects/<year>/ and follow the copying directions under Posting to the web, under in the Application Notes section. A PDF of the report and a compressed archive {tar, zip} of all source code, configurations and downloadable binaries ready-to-demonstrate are appropriate.

Application Notes

Over the term, your fellow students will be contributing IO drivers, libraries, VHDL or Verilog designs, documentation (e.g. demystifying interfaces) and examples of how to use other available libraries or tools, and how to use features of familiar tools more effectively. As these application notes become available, they can be viewed here.

Start early. The availability of your application notes for other students to use during this term will be a consideration in your mark. Application notes first submitted in substantial form by the "early" due date will receive a 20% bonus; 10% bonus for the middle deadline.

In the course of your project work, you will write code (C, C++, VHDL, Verilog) that others may find useful, this year and in subsequent years. You will also have the opportunity to use other available software and CAD tools and learn features of familiar tools which make their use more effective. In the past, some students have taken the time to share the skills they've picked up. While extensive documentation is supplied with tools, tutorials and step-by-step procedures can help others and save them time. This sharing will now be recognized as part of the course.
You can also contribute design components which are likely to be reused. Consider submitting:

tutorials on using features of existing tools
tutorials on using publicly available tools
bug fixes and work-arounds
techniques and circuits
your useful, well designed, reusable and well documented C, C++, VHDL, Verilog code

especially IO drivers and IO devices

if you have other kinds of ideas to share, see your instructor

You can submit application notes as early as you want (so more people have a chance to use it) and submit as many pieces of application notes as you want up to the end of classes. The timeliness, quality, quantity, originality and utility to your fellow students will have a positive impact on your mark. Compilations of existing work receive minimal credit for the editorial work only. Reference your sources of course. Once you have feedback from classmates, revised and clarified application notes are appreciated and rewarded. The marking will be done at the end of classes. Application notes can have one or more authors. Marks will be attributed to the project group unless a special arrangement is made. Please identify the authors at the top and bottom of the application note.

Please file each application note in its own subdirectory.

Posting to the web

To submit on the web, create a directory with a descriptive name under an appropriate subdirectory on the department machine login.ece.ualberta.ca (access with ssh).

$ umask 022

$ mkdir ~elliott/www/cmpe490/appnotes/2012w/RC_servo_motor_driver

$ cp index.html file1.html file2.gif file3.txt driver.c !$

$ chmod -R go+r !$ $ ls -laR !$

$ du -k !$

Application notes over 400 KB will not be marked without special permission. Use an HTML editor that understands HTML (e.g. seamonkey) rather than RTF or DOC editor that loosely translates to bloated HTML.
Next, view your page to ensure you left all parts readable. Remember that all files must be world readable and all directories world readable and executable.

Next, announce the existence of your application notes to your class (and your professor) by posting an article to the course group.

You can update your application notes as often as you like, up to the end of classes. Be sure the author's or authors' name(s) are clearly identified near the top of the main document for marking. Since this application notes will be published on the Web, HTML, ASCII text and PDF are all acceptable formats (the content counts, don't get too fancy with the formatting).

Final Oral Presentation

Saturday April 14, you will present your work in an oral presentation in ETLC e1-013, as a demo and on a poster.
Print out and complete the tasks on this sign-off sheet and hand it in to Nancy by the last lab (or make other arrangements) for credit in the presentations. Every line should be completed and indicated lines should be initialed.

Oral presentations to the class and public will be 15 minutes including demonstration plus questions. Your adherence to the time limit will be part of the mark. Remember to rehearse the timing of the presentation and the demo. This is not long enough to give a comprehensive description of how you implemented your project. Try to give a brief motivation, overview and focus on some technically interesting details. Your demonstration can be at any time during the presentation -- it doesn't have to be at the end. You will have a document camera to project the demonstration of your project. While you are presenting, the previous group will cart away their project and the next group will be setting up for seamless presentations and demos.

Your first slide should contain a title (plus an optional sub-text), group members' names, a photo or illustration (possibly as the background). Rehearse and time your presentation. You will probably only have time for 10-15 slides, depending if you will be showing slides during your demo.

During the break before your presentation, your group members will also take turns demonstrating your project from a table to people passing by. Near the demonstrations, your poster will be on display. Try to answer questions anyone might raise. I would advise not letting anyone touch your hardware during the demo prior to your presentation. It would be a shame to go into your presentation with a broken project.

Posters are to be 23.4" high by 31" wide, in colour with a white background. Try to include at least one photo. Posters, like presentation slides, work better with bulleted points and figures than with paragraphs of text. Use this poster template [adapted from MECE 460 and EE 401]. You may submit .PPT .PPTX or .PDF generated by any software, but please try to have your poster resemble the template.

You can borrow the CMPE490 digital camera from Nancy or Rick to take pictures of your project in action for your presentation title slide, poster and report.
Recommended settings:
3 megapixels - (for reports and web pages), but can go to 7MP
auto - also close-up
USB drive - anyone can collect their photos without installing software
Remember to delete all photos when done.

Submit presentation slides to ~elliott/www/cmpe490/projects/<year>/slides/ and verify here.
Submit posters to ~elliott/www/cmpe490/projects/<year>/posters/ and verify here.
Both file names must start with your group number (e.g. g0_xyzzy_slides). Bring a backup copy of your slides on a USB memory key.
See instructions for posting to the web.

Presentation Day Logistics

You are expected to attend all presentations unless you've made other arrangements.

Arrive by 8AM and set up and test your project. The e3-011 lab is our staging area. There should be 4 carts, one per group per shift. One of the 2 elevators beside e3-011 has a "G" button and the rear door exits at the loading dock near the 1st floor classrooms - through the door on your left. I would appreciate the help of those presenting after the break (2nd shift) with pinning posters to the bulletin boards in the morning.

First-shift presenters will be demonstrating their projects in the hall outside of e1-013 by 8:30AM. At the 10:20 break, first-shift presenters will stow their projects and the second-shift presenters will demonstrate their projects in the hall. If you're not giving demos, please be near your poster to take questions.

Four minutes before the sessions start, the session's 4 projects will be carted into the e1-013 classroom. You will have 15 minutes for your presentation and demo. During your question period, the next group will quietly be bringing over their cart and starting up their project for fast seamless transitions.