Project requirements

Hints

• Need an idea for a project?
• Any material prepared for one project submission can probably be reused in subsequent submissions. Start early!
• 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.
• Where appropriate, reuse 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 course VHDL coding standards
• Long before completing your design, compile it into the FPGA to check if your design is likely to fit. You may have to temporarily tie off unused inputs to a defined signal (like ground), etc.
• Find partners who have similar goals, levels of ambition and work hours.  Groups can have 4-6 members.  Group size will not normally be taken into consideration for marking.
• You may use VHDL, Verilog, or both.  You may be able to get more help with VHDL bugs.

Project Proposal

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 digital system to be implemented in an FPGA.  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.

Fill out this web form.  Your entry will be made available on the web.

• preferred given name and family name of all partners
• project title
• 2-10 sentence abstract describing project
• please spell check all entries

Project Specification

The project specification can be up to 5 pages plus figures, code and appendices.  Please submit two copies.

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.  You can also sign out prototype boards and some parts for the duration of classes from Rick McGregor in ETLC e3-012.  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.
What FPGA / CPLD will you use?  See list of available boards.

Hint: Don't use external logic ICs if the same function could fit in the FPGA.

Resource Requirements and Interface Demonstration

Complete a non-trivial part of your design, compile it, and find out how much of the chip resources (logic elements and memory) are consumed.  Provide calculations and estimates of the resources that will be required by the incomplete portions of the design.  You will notice that this report is also a scaled down version of the simulation documentation.

Demonstrate your external interface circuitry working with the FPGA/CPLD to your professor in the lab (or schedule an appointment).  You will also be asked questions about your design choices.  This is another good opportunity to get design help.

The project resource requirements should be up to 7 pages plus figures, code and appendices.  Submit a second copy, attached with a paper clip, of your schedule only please.

Hint: save your VHDL test benches or simulator waveform stimuli so you can easily re-simulate after correcting errors.

Simulation Documentation

Please submit one copy of this report.

Before blowing the fuses on an FPGA or wasting time debugging, you must demonstrate that all aspects of your design simulate correctly. The simulation must be post-layout (extracted or back-annotated).

At least one simulation should include a test bench.

Hint: save your VHDL test benches or simulator waveform stimuli so you can easily re-simulate after correcting errors.

Complete Design

If you are using one-time-programmable chips (Actel), you'll want to be sure you get it right the first time.  After your simulation documentation has been approved, get ready to program an FPGA. Give your design a meaningful and unique name and copy your ".afm" design fuse file to "~delliott/projects/*".  Send me email specifying the name of your design file, and the IC type (1010B, 1020B) and package (44 PLCC, 68 PLCC) you require.

Final Report

This report carries a great weight in your final mark. Submit one copy (and make an additional copy for each group member).  Include in your report:

• title page
• declaration signed by group members

"The project and the contents of this report are entirely the original work of the authors except as follows:"
provide a list of exceptions, e.g.
schematic in figure 3 was taken from reference [5]
VGA driver "vga.vhd" was modified from reference [7]
• abstract (< 250 words, what was accomplished)
• IC data sheet (1-2 pages, include features, maximum speed, number of logic blocks and names of IO pins)
• table of contents
• overview, including an english description of the chip's function
• design details, particular solutions for specific problems
• describe the results of any experiments you tried in the course of your design, for example:
• number of logic blocks to implement an architecture using different styles of synthesis
• speed vs. area (number of logic blocks) trade-offs
• characteristics or calibration of circuits involving external components (e.g. oscillators, thermometers, robot actuators)
• design verification (simulation)
• IC test measurements (prototype system and/or IC tester)
• references
• complete design documentation (VHDL, schematics if applicable, module and interface descriptions)

Submit via the web form, your project title, names, abstract, type of chip used, number of logic modules / configurable logic blocks used, number of lines of VHDL code (no, your mark will not be based on the number of lines of VHDL code - this will help future students).

Bonus 1: web copy of report

hp13% umask 022
hp13% mkdir ~elliott/www/ee552/projects/2000_w/flying_bicycle_controller
hp13% cp index.html file1.html file2.gif file3.txt design.vhd design.acf design.sof !$
hp13% chmod 644 !$/*
hp13% du -k !$

Bonus 2: open house demo

Oral Presentation

Brief demonstrations are encouraged.  Ask what facilities will be made available.

Please submit one paper copy of your overhead slides at the start of the class.
 

Student Applications Notes

Start early.  The availability of your documentation for other students to use during this  term will be a consideration in your mark.  Application notes submitted by the "early" due date will receive a 20% bonus.  Application notes submitted by the last day of classes will receive a 20% late penalty.

In the course of your project work, you will have the opportunity to use other available 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 CAD 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
• VHDL code or libraries which might be generally useful
• arithmetic
• interfacing (e.g. SRAM, microprocessor bus)
• interfacing + external circuits (these should be demonstrated to your prof)
• interface circuits to be used with FPGAs
• if you have other kinds of ideas to share, see your professor

Please file each application note in one of the appropriate subdirectories.

To submit your documentation, create a directory with a descriptive name under an appropriate subdirectory in
~elliott/www/ee552/studentAppNotes on the nyquist HPs:

hp13% umask 022
hp13% mkdir ~elliott/www/ee552/studentAppNotes/2000_w/cad/synthesis_hints
hp13% cp index.html file1.html file2.gif file3.txt design.vhd design.acf design.sof !$
hp13% chmod 644 !$/*
hp13% du -k !$

Next, announce the existence of your application notes to your class (and your professor) by posting an article to the newsgroup: ualberta.courses.ee.552

You can update your documentation 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 documentation will be published on the Web, HTML, ASCII text, PDF and PostScript are all acceptable formats (the content counts, don't get too fancy with the formatting).
 

WWW Submissions

Use GIF images for figures and line drawings.  Use JPEG (*.jpg) for photographs only (it "smudges" drawings and takes more disk space).  If you've started out with an electronic version of a drawing, don't convert it to a disk space hungry and lower resolution pixel image. Instead, transfer drawings as *.epsi or *.eps and generate PDF files.

Do not used scanned images without referencing them and getting permission from the copyright holder.

Don't use frames or background images.  Use a table of contents instead of frames.

Beware of generating web pages from some word processors (Microsoft Word in particular). They can blow up to be 6 or 7 times the original size of the text.