Project requirements

Last updated 2003-3-26
1 Project Proposal
2 Project Specification
3 Resource Requirements and Interface Demonstration
4 Simulation Documentation
5 Final Report
Student Application Notes
Complete Design
Oral Presentation
please use the following order for sections or obtain permission from instructor
Hints
+ + + + + title page
include names and preferred email addresses of all group members, no student IDs please
+ + + + declaration of original content signed by all group members 
     "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, e.g. 
     schematic in figure 3 was taken from reference [5] 
     VGA driver "vga.vhd" was modified from [7] 
     ADC support circuitry was taken from the manufacturer's application notes [15]
     coefficients for motor PID controller are from [16]
+ + + + + abstract (<250 words)
+ + + + table of contents
+ + achievements 
  what worked and what didn't
+ + o + + 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.
   o = optional for Resource Requirements
+ + what requirements do you have for the FPGA/CPLD
  • Do you need a reprogrammable FPGA?
  • Do you need RAM?
  • Do you need a microprocessor?
  • What chip will you be using?
  • Will you be demonstrating your design by building a system, or using an IC tester?
  • + + + + identify and describe all FPGA user IO signals in a table, provide total number of pins required
    e.g. a pair of 7-segment LEDs requires 14 output pins
    + datasheet for FPGA as configured 
      features, IO pins, timing, maximum speed 
      seek inspiration from manufacturer's data sheets
    + + + estimate/measure of number of FPGA logic blocks required to build design 
      for estimates, justify your estimate & provide an itemized list
      describe architectures that had been designed, but wouldn't fit, etc.
    + + o describe features that could be added or deleted (due to time or space constraints) 
    (Your final report mark will be based on what you actually submit. You will not be penalized for proposing to implement more that you end up doing.)
    + parts list 
    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 will need these parts in time for your next report.  You can also sign out prototype boards and some parts for the duration of classes from Rick McGregor in CEB 355.  Anything signed out must be returned by the end of classes.
    + + + old schedule with annotations 
      provide the schedule you submitted in the last report 
      add comments (hand written or typed) about completed tasks and why tasks weren't completed on time 
      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

    5
    new schedule 
      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 
      list at least N (at right) uncompleted tasks per group member (not including course due dates) 
      as you progress, each task will become more finely subdivided
    + + + + minutes taken at all weekly group meetings
    I recommend point form notes be taken and emailed, without formatting, to all  group members, plus save a copy for reports.  Include
    attendance
    progress and new task assignments for each group member
    concerns
    + + results of experiments and characterization
    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)
  • numerical simulations of your algorithm in C or Matlab etc., before reducing it to hardware
  • + + + starting this year,
    you must use some externally provided HDL components in your design
    Verify these components and establish that they are suitable
    + After you receive your report back and have all read the comments, meet with me to discuss any design issues and concerns.  Office hours (including after the lectures) are best, but other times can also be arranged.
    + demonstration of IO 
      book an appointment with your instructor during the lab 
      bring your questions and concerns
    + demonstration of entire project
    your tangible achievements are worth approximately half of your final report
    + IC test measurements (optional)
    + + + + + references 
      What textbooks, articles, web pages or other resources will you use for background information on the topic? 
      Using someone else's work and forgetting to reference it is plagiarism and the penalties are harsh. 
      see examples in textbooks etc. for correct format for references 
      give author (or failing that, corporation), title, date, full URL if on the web 
      number your references and place reference numbers [42], etc., in text, VHDL code, and schematic and figure captions
    + + + + feedback and comments to instructor (optional)
    + + + datasheets for chips used 
      first page usually contains enough detail
    + + + index to test cases / verification 
      describe each test case in 1 or 2 sentences
    + + + design verification - description of test cases and simulations 
      each simulation run is proceeded by a description page of what is being tested and what is shown 
      write in annotations of significant signal edges and values on simulations 
      What is the maximum speed?  What is the critical path?  What would you change to make it faster?
    + + + + diagram of design hierarchy 
      draw a tree diagram of all entities in your FPGA design, starting at the top with the entity for your chip and (recursively) show arrows pointing down to all the entities that each architecture instantiates.
      label each entity as "not compiled", "compiled - no errors", or "simulated - no known bugs" 
      (look at the maxplus2 hierarchy display, but don't include it)
    + + + + index to VHDL packages and code 
    package(s) are required
    provide entity name, one sentence description, and once again, 
    label each entity as "not compiled", "compiled - no errors", or "simulated - no known bugs" 
    + The top levels of your VHDL design (3-6 completed architectures plus the component definitions these require)
    + + + VHDL design -  provide all code as indexed - follow class coding standards
    + + + test bench index (with descriptions) and test benches 
    + + + schematics 
      provide schematics of all circuits to be connected to the FPGA
    o o o o o any amount of material in appendices
    + + please submit 2 copies of this report
    + please submit an extra copy of your new schedule, paper clipped to the last page
    + + web form submission 
    Fill out this web form including the following information.  It will be made available on the web. 
  • family name, preferred given name of all partners
  • project title
  • 2-10 sentence abstract describing project

  • please spell check all entries

    For the final report, add 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)

    + Self evaluation of group
    Paper clip to the report 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 (also attached).

     

    Hints

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

    Project Specification

    requirements

    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

    requirements

    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

    All coding of your design should be complete at this time.  See the checklist for what should be included in this report.

    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

    Your FPGA should be configured and testing started shortly after handing in the Simulation Documentation.

    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

    requirements

    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:

    Submit a paper copy of your report to the assignment box or your professor.  Final reports are archived -- make a copy for your own use (to show to potential employers, etc.).  A demonstration of your project is expected, either during presentations or separately scheduled with your professor.

    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

    The submission of a copy of your report in a machine-readable form for posting on the web ( HTML, PDF, Postscript, ASCII text)  would be appreciated.  Create a descriptive directory name under ~/elliott/www552projects on the nyquist HPs and deposit your project there. Web versions of reports over 200 KB  total will not be marked without special permission.
    Next, view your page to ensure you left it readable.
    See WWW Submissions for additional requirements.
     

    Bonus 2: open house demo

    Some projects may make excellent demonstrations for the next University Open-House or Engineering Week. Talk to your professor about leaving your project wired up and leaving a poster or modified set of slides from your oral presentation. Include brief instructions for setting up and operating your project. Extra FPGAs and reimbursement for other parts may be available for this purpose.

    Oral Presentation

    Oral presentations to the class will be approximately 10 minutes plus questions.  This is not long enough to give a comprehensive description of how you implemented your project.  Try to give a brief overview and focus on some interesting details.

    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

    Over the term, your fellow students will be contributing documentation and examples of how to use other available tools,  how to use features of familiar tools more effectively, or contributing other tools and libraries.  As these documents become available, they can be viewed here.

    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:

    You can submit documentation as early as you want (so more people have a chance to use it) and submit as many pieces of documentation 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 documentation is appreciated and rewarded. The marking will be done at the end of classes.  Documentation can have one or more authors.  Marks will be attributed to the project group unless a special arrangement is made.  Please identify the authors and group at the top and bottom of the application note.

    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:

    App notes over 50 KB will not be marked without special permission.
    Next, view your page to ensure you left it readable.
    See WWW Submissions for additional requirements.

    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

    If your submission isn't readable, it can't and won't be marked.  Read the unix man page for chmod.  Double check that you can read your submission in  http://www.ee.ualberta.ca/~elliott/ee552/studentAppNotes/ or  http://www.ee.ualberta.ca/~elliott/ee552/projects/
    Also, use "ls -laR" to check that all of your directories have permissions "rwxr-xr-x" and all files have permissions "rw-r--r--". Double-check that your names and group name appear at the top (and preferably the bottom as well) of the main web page.

    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.