Project Report Requirements

This document will be periodically updated. Last update 2018-4-5

Hints, Weekly Minutes, Requirements for each report,
Proposal, Specification, Critical Design Review Presentation, Progress Report & IO Demonstration, Final Report, Application Notes, Final Presentation, Posting to the Drive, Video project overview

Web forms: Group info, Peer-to-peer shared feedback, Team engagement survey

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

In groups, students will specify, design and implement an embedded system.

Project reports must be electronically submitted to your instructor as PDF documents by 6pm on the due date.

You may change your goals during the term. Marking will be based on what you achieve. Set basic goals and keep a list of features to add once the basic functionality is achieved.

Any variation from the requirements, below, require approval of your instructor:

You need permission to use a platform other than the Intel Altera DE1-SoC or DE10-Nano. In any event, a demonstration on a DE1-SoC or DE10-Nano board is recommended should your other platform fail.
Your design must have elements of software and hardware design. Interfacing hardware via the processor bus (including within the FPGA) or via a co-processor interface is encouraged.
Your embedded system must start on power up (program/configuration in flash memory, not downloaded).
Reuse of design components is encouraged. Be sure to cite other people's work, application notes, etc.
Robust mechanical design is expected. Don't use the white bread boards for the final project. Use connectors and cables rather than loose wires. Reports of "It was working last night", although invariably true, will be met with limited sympathy.

Hints

Need an idea for a project? Consult this list or ask me about your own idea. (You must login with 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. Consider Google Docs or other collaborative writing tools.
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 course 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 programming languages and hardware description languages that are appropriate and supported under the tools. Expect to be able to get more help with C, 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

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

The main guidance as to what should be included in project reports is on this web page. I will make tentative marking schemes available here. These are subject to revision over time and are not final until used.

Which report					subject to change
p					Proposal
	s				Specification
					Critical Design Review Presentation
		i			Progress Report & IO Demonstration
			f		Final Report
					Application Notes
					Final Presentation
o	o	o	o		optional materials marked with "o"
				L	"L" = Your instructor will explain the requirement and provide an example in a lecture
p	s	i			Title page 2 or 3 - word title for public schedule (no obscure words or acronyms) full title (you will probably put this title in your employment resume) optional subtitle if the title is too cryptic include names and preferred email addresses of all group members, no student IDs please a recent face photo (cell phone photo or better) of each group member with name <20 word summary of project list group number (= tool box number) and list other afternoons when available
			f		Your project will be publicly available on the web in most cases. Please remove any personal information you don't want to share throughout your report. Don't include your group number - we know it by now. title page full title (you will probably put this title in your employment resume) optional subtitle if the title is too cryptic (optional) names of all group members, no student IDs please <20 word summary of project
	s	i			Declaration of original content two copies included on sequential pages in the PDF report unsigned typeset declaration Signed printout of this declaration page, scanned or cell phone photo. All group members must sign and date their own signature. Retain original signed copy in case it is requested. 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 X [1] transcendental functions library used was [2] schematic in figure 5 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 web report. Submit via email.
p	s	i	f		Abstract (<250 words) highlight achievements - what did you do and what worked (or what you will build)
	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 does it do? Were those met? To what degree? Move options, extensions to Future Work in an appendix
	s	i	f		Design Alternatives Most functional requirements can be met by an infinite number of designs. Briefly, list some design alternatives, their advantages & disadvantages and why you chose the solution you describe in detail in the next section.
p	s	i	f		Design and description of operation Hardware block diagrams and diagrams showing data flow 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		L	Hardware requirements - what do you need? interfaces calculate estimates of required capacities (e.g. Flash, RAM, FPGA logic elements /gates) proposed lab platform (Altera/Terasic DE1-SoC or DE10-Nano or other) What are your IO rates? How much memory is required. What processor performance will be required? 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 or running benchmarks. Remember that on the supplied boards, the flash memory is slower than the DRAM so the processor runs slower when executing flashed object code. Show all calculations.
p	s				Parts lists, Hopefully ordered before or shortly after submitting spec report and many weeks before IO demo. Description, most relevant spec (e.g. pixels, power), cost, order status {not ordered, ordered, received} Include web links to supplier and to datasheet Include source currency, CDN $, shipping (as quoted on the supplier's web page (you may need to click "check out" but don't complete the check-out) else make an estimate (e.g. est. $25)) for each supplier. If the supplier does not charge GST on their webpage, add GST and $15 brokerage fees per such supplier. Provide total CDN$ cost of preferred parts, including shipping, tax and brokerage.
		i	f		Bill of materials, Description, part number, most relevant spec (e.g. pixels, power), unit cost, quantity, total cost in source currency and CDN $. Web links to supplier and to datasheet Include everything, including stock items that we have not ordered for you, except test bench equipment (but mention, e.g. "5V 2A power supply required, not included in total"). Estimate all standard and small items, e.g.: screws $0.02 perf board $7.50 40-pin ribbon cable $10 Altera Terasic DE10-Nano development board $130US Altera/Terasic DE1-SoC development board $249US Provide total in CDN$. Do not include shipping, tax or brokerage in the bill of materials
p	s	i	f		Available Source 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 to other boards or chips, identify voltages levels & VOH, VOL VIH VIL off-board electronics to world {transducers, motors, etc.}, identify voltages levels, currents, etc. Identify all required power supplies (voltage and calculated current). In addition to the above, complete one table for each set of signals.
			f		Datasheet Performance, user-perspective block diagram, operating conditions. Expand on the above IO signals to produce a datasheet of your complete embedded system. Provide calculated and measured power in various modes of operation {peak, idle, standby as applicable}. Ask Nancy for a DE1-SoC power measurement wiring harness. Record V and I off bench power supplies. Describe how each is calculated and measured .
	s	i	f		Background Research Search for articles that provide background helpful for your project {algorithms, designs, standards, etc.}. At least one article should be from a peer-reviewed scholarly journal or conference. I suggest searching IEEE Xplore. From off-campus, use the library link. Describe and critically access the background information you found and comment on its utility for your project.
	s	i	f	L	Software design description block diagram of how processes interact, flow of data, other synchronization list any libraries or RTOS used
	s	i	f	L	Test plan Software: test of hardware-independent software components (e.g. on PC) 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. Instrument and record high and low levels of FIFOs to assess if the system is near overrun or under-run. Measure the max performance of real-time software against artificial data sources and sinks instead of real IO to establish the ratio of performance as built to the requirement (a safety margin). From the progress report on, numerical measurements should be reported. Hardware: functional test procedure calibration/performance/characterization measurement procedures simulation and testbenches are expected
	s	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 calculate performance, resolution, errors, as appropriate benchmarking different approaches
	s	i	f	L	Safety Your own assessment of the safety of you project, possible failure modes, any mitigation you have incorporated. What harm could a software or hardware failure cause? From a human safety perspective, report maximum voltage, power, stored energy (e.g. battery), operating temperature (could it burn flesh), (as applicable, e.g. robots) velocity, kinetic energy, potential energy. (Optional) From the perspective of harm to the project, what are the safe operating condition?
	s	i	f	L	Regulatory and Society What laws and regulations are applicable? Privacy, storage of personal data, FOIPP? Codes: RF exposure, RFI Can it be remotely hacked (internet of things becomes the internet of zombies)? mitigations: authentication (unique per device authentication), encryption, purging data, anonymizing data ...
		i	f	L	Environmental impact What hazardous substances does your project contain? Are there alternatives? Is it RoHS (Restriction of Hazardous Substances Directive) compliant? Other environmental impact?
		i	f	L	Sustainability Measure the power consumption of your project in all relevant modes (e.g. active, idle, sleep). Repeat measurements for final report. What are the typical duty cycles and average power consumption? What does this translate to in terms of energy cost per year, CO2 production per year from coal-fired generation? Other thoughts on sustainability?
	s	i			Optional integrated circuit design proposal - what will be included in the integrated circuit designed below?
			f		Optional integrated circuit design This will be added to the marking for code and schematic designs. Take the VHDL (or Verilog) code you have designed for your project, remove references to proprietary cores you don't have source code for, and complete synthesis, place, route and verification of 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			Previous 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
p 3	s 5	i 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 accurate 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) realistic project planning probably calls for many more tasks than the minimum requested As you progress, each task will become more finely subdivided
p	s	i	f		References (a.k.a. citations) Using someone else's ideas or work and forgetting to cite it is plagiarism and the University penalties are significant. You, may for instance, have used: textbooks, research papers, datasheets, applications notes, web pages and past projects. Any report contents used verbatim from another source must be clearly quoted (or otherwise identified) and referenced in the paragraph or figure caption where used, e.g.: "Absolute maximum operating temperature is 125C", datasheet [2] The operating conditions in the box below are from the manufacture's application note [3] Figure 6, Microphone connection schematic, redrawn from [4] Figure 7, Speaker connection schematic, copied from [5] Use IEEE format, pages 34-40, for your reference page, which contains a list of all references: When referencing materials obtained on the web, provide author (e.g. company), date read and full URLs to the document. Create "clickable links", but, in case hyperlinks don't get translated to the PDF, spell out the URLs. Usually a URL to the parent page is useful.
					Appendices
			f		Quick start manual All instructions required to re-assemble project, connect IO to lab boards, configure and demonstrate. All instructions required to 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 than were possible to build, share these ideas with the next generation.
	s	i	f		Hardware documentation 1-page block diagram of hardware (including components used on FPGA board) 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 are half the work, then arguably, most or all of your code needs to be written by halfway through the term. If any of the below information is missing, source may not be marked. diagram: graphical hierarchy of function calls for source code (for each process if applicable) index page to source code Provide two index lists: (a.) Original Source Code, (b.) Adapted Source code Do not include unmodified third party code -- include file name & path in repository, and 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 GIT repository or a compressed archive (e.g. tar, zip) or a service such as github or bitbucket. Make a branch for specification, progress or final that has no commits after the deadline. Any temporary or throw-away code present will be marked according to the coding standards, so please remove anything not intended for submission. For the specification, you have the option of including these files in the report text. Source code should be documented, indented and readable. Start each file with a comment block, including creation date, original authors, authors of modifications if applicable, contents of the file. Files without such a comment block will be considered as not submitted work and will not be marked. include: embedded source code software testbench source (code for testing will have a separate mark in the marking scheme) VHDL/Verilog source with testbenches simulation testbench source if applicable prototype code (e.g. Matlab experiments) any other design files
			f		For the final report, in addition to any online GIT repositories, your web submission must include an archive containing all compiled binaries (software and FPGA configurations) as well as source code on the web page as an archive (.tar, .zip, etc.) in the directory you created for your final report.
	s				Complete and hand a paper copy to your instructor of the consent form for displaying your project work (one per person).
		i			Peer-to-Peer shared feedback Due 6pm the day after the Progress Report is due. Each team member evaluates the performance of each other in this form. All responses are shared with all group members, so be diplomatic. This might be a wake-up call. No marking action will be taken on this information. That comes in the next report.
			f		Peer evaluation of group members hard or electronic copy only, signed and submitted separately to report Provide your estimate of what fraction of the work and the successful work was performed by each group member. This will be used as a guide for the instructor to assign marks. One copy signed by all will suffice, unless the group does not agree on how this should be done. In this case, each group member should submit their own signed proposal, with justification and reference to the group meeting minutes. Group members have the right to review their group members' submissions and submit a response. This may be submitted 2 days after the deadline without penalty.
p		i			Complete this web form, including project title and group members. For accuracy, all members should be present when completing the single copy.
			f		Video project overview 1-3 minutes
			f		Team engagement survey To receive credit for the final report, each team member should individually complete this team engagement online survey (CCID login required). Other than the names of people completing this, the results will remained sealed until after grades have been submitted and the results will be used in aggregate form for appraising the course itself.
o	o	o	o		Feedback and comments to instructor (optional) For the final report, please email separately

Minutes of Weekly Group Meeting

Each group must meet at least weekly to manage their project and assess their progress. Minutes must be recorded at the meeting and edited & agreed to by the end of the meeting. An example minutes document is provided here.

The minutes can be fairly simple. An example is provided. No formatting is required other than a new-page for each meeting. Include date, time, attendance, reasons for absences, past and future work. Rotate who takes minutes. Comments and suggestions by course instructor, lab instructor and TAs are welcome.

Use the provided Google document edit-shared with all group members’ CCIDs and read-shared with all instructors and TAs.
Maintain the original Google document with full change logs. Using a copy or uploading/downloading will disrupt the change log and affect grading.

Weekly, ask Brendan to join you (for about 5-10 minutes) during the lab to review your past two weeks of meeting minutes and see examples of progress or demonstrations. Early examples may be code interfaces. Early code examples may well be demonstrated on a PC first. Later demos will likely include working embedded software and hardware.

Please take the opportunity to ask TAs for help with problems. Bring your prof into the conversation when you have questions about revising the goals of your project.

Project Proposal

requirements

By now, you will have formed groups and have chosen a topic for your project. Describe it 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.

Complete the web form, including project title and group members.

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 discussed and approved 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 (cout or printf's might suffice). Image and audio IO could be replaced with simple disk file IO.

Include software and HDL source code in an appendix or as a tar/zip archive.

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 9 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
Design calculations

List components implemented in FPGA, other parts

Code example
Test plan

Results of any Testing

Describe your application notes, if applicable
Optional features to add or previously described features that could be removed

There will be 2 minutes for audience questions. Please contribute to your classmates' success by participating in the design review. All are expected to attend unless you've made other arrangements.

To give a successful presentation in the short time, your group will need to rehearse together with a stopwatch.

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 Drive. 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"). This is unit testing -- system integration is not required. You may download multiple configurations to test different parts of your IO if you wish, since system integration is not yet a requirement (have everything pre-compiled, ready to demo in a short time). Each test will usually include some external hardware or circuits, microcontroller interface on the FPGA, Nios-II processor, software driver for hardware, test code to exercise all of the previous parts.

Demonstrate at least one routine or a simulation thereof on a workstation or laptop that will be eventually incorporated into the embedded system. You will have the opportunity to demonstrate additional aspects of your design project, including embedded software, algorithm demonstrations running on a PC and simulations.

All, or at least most, 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. Remember the class coding guidelines.

Edit/update this web form, including project title and group members, preferably using the login of the group member who first completed it.

Your report will expand on your Specification. Include 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 and follow the copying directions under Posting to the Drive, below the Application Notes section. A PDF of the report and a compressed archive {.tar.gzip, .zip, .qar} of all source code, configurations and downloadable binaries ready-to-demonstrate are appropriate. You are not required to disclose any personal information, even your name in your report. Be aware of any personal information you disclose in your report (e.g. did you want to share your email address, your photo?).

Prepare a 1-3 minute video pitch describing the features and capabilities of your project.

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 and 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.

To be graded, all application notes that contain source code must be demonstrated at some point in the term to one of your lab TAs to ensure error-free compilation in the tools and functionality in the FPGA (as applicable). In addition to reusable code (e.g. a hardware device, a device driver, a library, or all of the above), provide some means for demonstration such as a trivial test application. For FPGA designs, include the configuration saved as a Quartus project archive, as described in the beginning of tutorial 2 (source code, however, should be stored in a non-proprietary archive, e.g. .tar, .zip). If applicable, a compiled binary file for FPGA implementations should also be included and tested.

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

Include near to top of your app note what version of tools you used, e.g.
Quartus 17.0
DS-5

I'd prefer that app notes not contain a group number, as people will be referring to these for a long time. For marking, we can use your name, or let us know if you decline to use your name.

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.

Marking guidelines -- General Tutorial Appnotes:

Instructions are complete.

Include all assumptions that you make about the system/browser/operating system/smartphone etc.
Necessary files are included.

Marking guidelines -- component & code Appnotes:

A TA must sign off that they have seen the Appnote source code downloaded, compiled and run/demonstrated successfully in order to be graded.

Instructions should be complete including BSP settings.

Quartus and Software IDE Version dependencies should be included with instructions. Include whether your component needs the NIOS2 IDE or the SBT for NIOS2 IDE.

Code provided:
A complete Top level file that demonstrates the component.
Pin assignments for whichever board/Quartus version is supported.
launch scripts used with any modifications needed.
Component VHDL or Verilog.
C source code including a small demonstration of the component in C/C++ or instructions on how to generate a sample software project that requires no additional code to function.

Complete tar/zip/rar/qar files of a demonstration project are also acceptable which include both the hardware and the software portion of the code. Ensure you have all source files, e.g. {.c, .vhd. .v}, as well as all configuration files and have tested a full compile from this archive. If you wish, you can just remove the "db" directory and create an archive.

If your app note has a stand-alone demo, include FPGA programming files ready to download.

Relying on links to third party sites is discouraged because they could disappear so include the code/reference manual/documentation as well as a link.

Application notes over 3 MB 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.

Announce the existence of your application notes to your class (and your professor) by posting an article to the course forum.

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).

Posting project work to the Google Drive

For submitting:

CDR slides
Application Notes
Final presentation slides
Final reports
Videos

Copy your files to the appropriate sub-folder of this Google drive. For your Application Notes and Final Report, create a sub-sub-folder with a descriptive name (feel free to reduce write permissions, but keep read permissions for your class). Use descriptive file names.

Verify that you can download your appnotes and report components to ensure all parts are readable.

Final Oral Presentation

You will present your work in an oral presentation in ETLC e1-007, and in the ETLC Solarium 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 part of the presentation grade. Every line should be completed and indicated lines should be initialed.

Oral public presentations will be 12 minutes including demonstration (you will be penalized if you have to be cut off at 13 min.) plus additional time for 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 7-12 other slides, depending if you will be showing slides during your demo.

A common question from students is "At what level should the presentation be directed?" The answer is mixed levels. The objectives, demos and whether you achieved those objectives will be understandable by everyone. Some of the presentation content will be teaching new technical solutions to your peers.

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 ECE492 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.

See instructions for posting to the Drive for presentation slides and posters. 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. Verify slides and posters.

Presentation Day Logistics

Plan to arrive well before the start to get your projects ready and loaded on carts. The e3-011 lab is our staging area. Carts will be shared. Look for a note on the white board. The right (East) elevator beside Rick and Nancy's office has a "G" button and the rear door that takes you to the presentation classroom. If the wrong elevator comes, send it away and keep trying.

During your question period, unplug and step forward so the next group can quietly be bringing over their cart and starting up their project for fast seamless transitions. You won't have access to projection during questions.

You are expected to attend all Computer Engineering presentations unless you've made arrangements with your instructor.

After presentations, posters and live demonstrations will be judged in the Engineering Solarium, 7:30-8:30pm. Please have a group member at each of these at all times (thus you can take turns eating). Try to answer questions anyone might raise.

Please try to help with the Solarium furniture setup beforehand (3pm) and replacement after 8:30pm.