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 |
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. 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 in report
"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 |
||||
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 DE2, DE0 or other) What are your IO rates? 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 |
Proposed parts order list,
supplier, cost include web links to supplier and datasheet provide total cost of preferred parts |
||||
s |
i |
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 to datasheet provide total cost of preferred parts |
|||
f |
Bill of materials, description, part number, most relevant spec (e.g. pixels, power), unit cost, quantity, total cost web links to supplier and to datasheet provide 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 DE0-nano development board $132.11 Altera/Terasic DE2 development board $517.72 |
||||
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:
|
||
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 DE2 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 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 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 bogus data sources and sinks instead of real IO to establish the ratio of performance as built to the requirement (a safety margin). Hardware: functional test procedure calibration/performance/characterization measurement procedures simulation and testbenches if appropriate |
|
s |
i |
f |
Results of experiments and
characterization:
|
||
s |
i |
f |
L |
Safety Your own assessment of the safety of you project, possible failure modes, any mitigation you have incorporated. Report maximum voltage, power, stored energy (e.g. battery), operating temperature, (as applicable, e.g. robots) velocity, kinetic energy, potential energy. |
|
s |
i |
f |
L |
Regulatory and Society What laws and regulations are applicable? Privacy, storage of personal data, FOIPP? 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? What area of fixed solar cells in Edmonton could power your project continuously? 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 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) 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]Use IEEE format, pages 34-40, for your reference page, which contains a list of all references, e.g.: %%% 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. 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) or a service such as github. For the
specification, you have the option of including these files
in the report text.source code - documented, indented and readable embedded source code software testbench source VHDL/Verilog source with testbenches simulation source if applicable any other design files (final report) all compiled binaries (software and FPGA configurations) |
||
s |
Complete and submit paper copy to the
assignment box 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. 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 |
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 a 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 grades.
A TA will meet with you weekly (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 instructor into the conversation when
you have questions about revising the goals of your project.
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 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). All compiled binary files for FPGA
implementations should also be included (including .SOF, .POF,
etc.) and tested in this demonstration.
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:
Please file each application note in its own subdirectory.
Instructions are complete.
Include all assumptions that you make about the
system/browser/operating system/smartphone etc.
Necessary files are included.
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 (e.g. .sof or .pof), In this case,
the 1MB limit does not include the .sof or .pof file size.
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.
To submit on the web, create a directory with a descriptive name
under an appropriate subdirectory on any AICT machine, e.g. gpu.srv.ualberta.ca
(access with ssh). Use one of these directories with the
current year:
~delliott/www/local/ece492/projects/2019w/cdr-slides/
~delliott/www/local/ece492/projects/2019w/final-slides/
~delliott/www/local/ece492/projects/2019w/posters/
~delliott/www/local/ece492/projects/2019w/
~delliott/www/local/ece492/appnotes/2019w/
Next, 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).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:15-9pm. Please have a group member at each 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 9:00pm.