EE 475 Workload and Grading.......


Workload....

The course consists of the following elements:

  1. Lectures: There will be a total of 30 hours of lectures.
  2. Reading: We will be covering most of the Wakerly text.
  3. Assignments: Weekly assignments will be done in the lab and will be based upon material covered in the week's lectures and will include a substantial design project for the last six weeks of the quarter.

Hardware and Software development often takes a lot more time than we expect. We will try to design the initial assignments so that you can come up to speed with the tools and the concepts slowly. We hope this introduction will permit you to comfortably use these tools during the later portion of the course. This is a design course and as such can be challenging, frustrating, and exciting all at the same time. Please make sure to ask for help rather than spend countless hours making no progress. If you don't know something, most likely there is someone around who does or knows where to look ....if you don't ask, you'll never know.

Remember the old saying, We had better get the coding done quickly because we have a lot of debugging to do. This is an approach we see all too often even with professional programmers. We strongly encourage you to take the time as you start your projects to think it through at the architectural level first then develop, test, and integrate the individual pieces. You will find you will have very little debugging to do.


Lab Projects...

The weekly labs and the final project are going to be a significant part of your grade in the course. Because each week’s work will often depend upon previous designs, it’s important that you keep up with the assignments and also ensure that your designs are robust and well tested.

There will be 2 weekly projects at the start of the quarter. We will use these to gain facility with some of the tools and techniques. During the remaining 5-6 weeks of the quarter, you will be working on a significant design of your own choice. Because of limitations on both equipment and space, we will have to be working in three person teams.

Our goal is to have each project follow a traditional product development cycle beginning with your initial idea. Throughout the course of the quarter, as you work, you will be supporting your development with formal specification, design, and test documentation.

In Class Projects...

In EE 475 we will be studying the design and development of digital computer subsystems and systems. If we look at the literature, It seems that our field is changing almost daily as new ideas and products are developed and introduced. As engineers, it is essential that we stay abreast of these rapid changes by reading the literature, attending seminars and specialized classes, or by attending more formal continuing education or degree programs.

As a step towards learning more about project design and development, we will conduct a number of in class 'workshops' during which we will work through the steps one generally takes when developing a new product.  

We will also have a formal presentation of a topic of current interest by each project team.

Projects Teams...

An important part of working as an engineer is working with different people to design, develop, then bring together all the elements of a project into a working system.  To this end, we will be working in 3 person teams as we design and develop our embedded systems.   . 

When selecting a partners, please choose someone you can work with.   Remember, different people may like to work different hours or have different work habits...Check this out at the beginning of the quarter, not at week 4.  We expect each person to contribute equally to the final design and we want people to remain with their original partner until the final project.  We will only consider team changes under the most extreme of circumstances.

To try to simulate the real work place, we view the the final project as if you have just finished a major project and are now ready to be reassigned to a new team. Although it's certainly not required, we encourage people to explore working with someone else. This will give you the opportunity to work with different people and to learn new ideas, and see different approaches to designing things.

If you want to stay with the same team, cool, not a problem...if you'd like to try working with someone else, please choose your new partner at least two weeks before the final project is to start.   Out of fairness to everyone, we will not change teams after that time


Due Dates and Requirements...

Weekly Homework Assignments:

Will be available on the web by midday on Monday.
The due date will be posted on the assignments page. Late assignments will be assessed 15% per day.

You must show all of your work for all problem solutions.  

Solutions will be given a mark of 0 if work is not shown or the answer has been copied from a solutions manual or someone elses paper.  

For each problem, it is important to understand what the problem is asking and if your solution makes sense and accurately answers that question.  Problems selected for the home works are specifically and intentionally chosen to present and illustrate a real-world issue that is important to understand.

Weekly Lab Projects:

Will be available on the web by midday on Monday.
The due date will be posted on the assignments page. Late assignments will be assessed 20% per day.

Final Project:

The project schedule is posted on the assignments page.

Project Demos and Design Reviews:

You must demo each weekly project and your final to one of the TAs.  Prior to the demo, each team member must prepare a brief description of what he or she did on the project, write a set of test cases to show how the project works, and be prepared to answer questions on the project.  This information must be given to the TA prior to the demo.  You cannot demo your project until this information is complete and available. 

All team members are expected to be present for all project demos and design reviews. Team members who are not present and who have not made prior arrangements to be absent will be given a mark of 0 for the review or demo. 

Grading...

Course:

10% 	Homework
15% 	In Class Presentation, Workshops, and Applications
35% 	Weekly Labs and Design Reviews
40% 	Final Project

Weekly Lab Assignments:

Point distribution

Will vary with the assignment


Each weekly project must include

Signed statement of individual contribution


Software....

Hard copy of the program source code as appropriate

All major procedures and functions must be annotated

  • Public Interface
  • Brief description
  • Side effects

Set of test cases. All test cases must be annotated

  • Public interface
  • Brief description
  • What is tested

Hardware....

Design Documentation as appropriate

  • State Diagrams
  • Structure Diagrams - Data and Control Flow
  • Block Diagrams

Schematics and Logic Diagrams

Timing Diagrams - Critical timing paths must be clearly identified

Set of test cases. All test cases must be annotated

  • Brief description
  • What is tested

Lab Reports and Research Reports...

Note: 

Any technical report is NOT a narrative or commentary of how much you learned, enjoyed, liked, disliked, struggled with, etc. the project, lab, equipment, or your lab partners. Such personal views have no place in a formal technical report. 

The report is intended as that:  a succinct presentation of the problem, how it was solved or the design implemented, what technical problems or errors were encountered, how these were solved (or could be worked around), and concludes with a summary of the work.

The report is generally written in the third person and frequently using passive voice (although this is changing).

Format

To practice preparing formal lab/research reports as well as technical articles, we will use some of the paper requirements and guidelines from an international symposium on systems engineering. As an aside, it is highly recommended that you keep your lab projects. These will be excellent material to include in an interview portfolio. Therefore, you must write these labs assuming the reader has only a basic understanding of electrical engineering.  They do not know anything of the specific lab assignment!

As an aside, it is highly recommended that you keep your weekly lab projects and, in particular, your final project. These will be excellent material to include in an interview portfolio.

        Thus, the Module Specification, Test Plan, and Test Specification must be type written and use the following specifications:

Page Size:

Layout:

Headings, Subheadings, and Paragraphs:

Fonts:

Tables and Figures:

Major Sections:

The abstract should provide a brief overview of the report.  It should provide a summary of the main specific points for the introduction, the main tests and experiments, the results, and the conclusions. It is called an abstract because you can literally "abstract" sentences from the other sections. 

Once again, this is not a narrative of your experiences as you executed the design.  The abstract should mirror (albeit in a very condensed way) the content of your report.

Brief introduction and overview of the purpose of the lab and of the methods and tools used.

This section should include the following:

Design Specification - In this subsection you will textually describe your client's requirements.  What does he or she need in the project you are developing.  If you are incorporating extra features or capabilities, please describe them clearly in this section.

Design Procedure - In this subsection you will first describe how you developed your design. You might want to include the theorems you used to simplify logic expressions, the K-map(s) or the truth tables you used to simplify or verify your conclusion if that these are tools you used. 

System Description - Overall summary description of your hardware and software modules

Specification of the public interface to the module

  • Inputs
  • Outputs
  • Side effects

Pseudo English description of algorithms, functions, or procedures
Timing constraints
Error handling

Software Implementation

What is your design????

Present your design starting from a top level functional view and potentially block diagram or high level architecture.  Refine that view to present and explain each of the modules that comprise the major functional blocks.  Discuss the flow of control through the design.  Identify and discuss the specific processes/tasks you have implemented in your design. Explain your design choices. 

Hardware Implementation

See software implementation.  Now, draw the block diagrams of how you connected interconnected the major / minor modules in your system.

Include your logic equations as well.

  • Test Plan

    Overall summary of what needs to be tested to ensure that your design meets the original requirements, 2-3 paragraphs maximum unless specified otherwise

    Present your plan to prove that your circuit works as specified. How can you prove that circuit you designed meets all the specifications and extra features?

    This is an annotated description of what is to be tested and the test limits
    Note, this does not specify test implementation...this is what to do, not how

    In addition, you should also consider testing the don’t care terms, the false conditions, and the boundary limits of the hardware elements of your circuit as well as any software inputs.

  • Test Specification

    Annotated description of what is to be tested and the test limits.  This specification quantifies inputs, outputs, and constraints on the system.  That is, it provides specific values for each. 

    Note, this does not specify test implementation...this is what to do, not how to do it.

     

  • Test Cases

    Annotated description of how your system to be tested against the test limits
    Note, this does specify test implementation...this is not what to do, this is how to do it based upon the test specification.

  • Based upon the execution of your design, present your results. Explain them and what was expected, and draw any conclusions (for example, did this prove your design worked).

    In addition to a detailed discussion and analysis of your project and your results, you must include all the answers to all questions raised in the lab.

    This one is obvious. Do this section as appropriate.  If it improves the flow, it does not need to be a separate section and may be included in the presentation, discussion, and analysis of the results.  However, it will still be graded separately and must be present.

    State any problems you encountered while working on the project. If your project did not work or worked only partially, provide an analysis of why and what efforts were made to identify the root cause of any problems.

    You should know these sections very well, no need to explain.  Note, however, that they are two different sections.  The summary is just that, a summary of your project.  It should loosely mirror the abstract with a bit more detail.  The conclusion concludes the report, potentially adds information that is often outside the main thrust of the report, and may offer suggestions or recommendations about the project.

    Your final version of any Verilog code, simulation waveforms, the Chip report of ispDesignExpert should go in this section.

    Your final version of your software sources.

    Your logic diagrams / schematics.  These show how you connected the switches, chips, LED bargraphs etc. Use standard logic symbols for SSI parts and appropriately labeled boxes for MSI and LSI parts.

     

  • Link to supplementary lab write-up information: LabReportSupplement 


  • Comments to: jkp@u.washington.edu (Last Update: 04 / 01 / 2019 )