EECS 373 Course Information

Fall 1998

Course Objectives

In EECS 373 "Design of Microprocessor-based Systems", you will:

• learn how the hardware and software components of a microprocessor-based system work together to implement system-level features;
• learn both hardware and software aspects of integrating digital devices (such as memory and I/O interfaces) into microprocessor-based systems;
• learn the operating principles of, and gain hands-on experience with, common microprocessor peripherals such as UARTs, timers, and analog-to-digital and digital-to-analog converters;
• get practical experience in applied digital logic design and assembly-language programming; and
• be exposed to the tools and techniques used by practicing engineers to design, implement, and debug microprocessor-based systems.

Prerequisites

You must have taken EECS 270 and EECS 280 to take this course. I will assume you are familiar with (on the hardware side) boolean algebra, gates, multiplexors, flip-flops, and finite-state machines, and (on the software side) program control structures (if/then/else, while and for loops), functions/procedures, parameter passing, and basic structured programming techniques (information hiding, modular programming, etc.).

Instructor

Professor Steve Reinhardt (stever@eecs.umich.edu), 2223 EECS, 647-7959
Office hours: Tue, Thu 2:30-3:30 or by appointment (send email)

Course Materials

Text:

There is no required textbook for this course. Lecture notes will be handed out in class and/or made available on the web page.

Lab materials:

You will each be loaned a package of documentation (including a data book, electrical specifications, a CD-ROM, and a quick reference guide) on the MPC823, the microprocessor you will be using in the lab. You must return the entire package at the end of the term. If you lose any part of the package, you will be responsible for ordering a replacement from Motorola.

Additional lab materials will be handed out in the labs and/or made available on the web page.

Reference (on reserve at the libary):

Microprocessor-based Design, Michael Slater, Prentice-Hall, 1989.

The best textbook I've seen on this topic, although some of the examples are dated.

PowerPC: A Practical Companion, Steve Heath, Butterworth-Heineman, 1994.

You may or may not find this a more readable introduction to the PowerPC architecture than the MPC823 data book.

Lab Location

2332/2334 EECS, 936-0392

Teaching Assistants

• Nathan Binkert (binkertn@engin.umich.edu): lab sections 6 and 7.
• Chau Doan (doan@eecs.umich.edu): lab sections 3 and 8.
• Erik Hallnor (ehallnor@engin.umich.edu): lab sections 4 and 5.
• Steve Raasch (sraasch@eecs.umich.edu): lab section 10.

On-Line Resources

• The course web page (http://www.eecs.umich.edu/~stever/373) has pointers to a lot of useful and occasionally necessary information.
• The news group umich.eecs.class.373 will be used for announcements and to answer questions. If you email a question to the professor or the TAs, your question and the answer will be posted to the newsgroup. If you email a question that has already been answered on the newsgroup, you will be chastised.

Labs

• Each lab typically involves developing both software and hardware and getting the two to work together. (Exception: the initial labs are software only.) The lab boards include a PowerPC processor connected to two field-programmable gate arrays (plus a bunch of other stuff). You will implement your hardware using the field-programmable gate arrays, execute your software on the processor, and observe wonderful and exciting results.
• The same software and hardware development tools used in the lab are also available on the CAEN Windows NT machines. These tools include simulators that let you (1) simulate the execution of your software and (2) simulate the operation of your hardware. You are expected to use these tools to develop and debug your hardware and software before you come to the lab. The purpose of your lab section time is integrate and debug your hardware and software, not to develop it. To verify that you have at least completed an initial design, you will not be allowed to work in the lab without first showing the TA a printed listing of your source code and a printed schematic (if appropriate).
• You should demonstrate your complete, working lab to your TA by the end of the lab period (the end of the second lab period for a two-week lab). The TA will sign your code listing and/or schematic to turn in with your lab report.
• Labs will be done in groups of two. However, each student is responsible for understanding all aspects of the lab fully. The lab TA will quiz you on your understanding of the lab.
• If you cannot get your lab working during the section, you may return to the lab to continue debugging any time it is open (the schedule will be posted on the web), but during scheduled lab sections students registered for that section will have priority for the workstations. When you get your lab working, demonstrate it for the TA on duty, who will sign for you. If you demo any time before the beginning of your next lab period.
• Each lab (except lab 1) has a set of prelab questions to help prepare you for the lab. You may think of the prelabs as your homework problem sets. Answers to prelab questions must be done individually (not in lab groups) and must be turned in at the start of your lab section. Late prelabs will not be accepted. If you do not turn in a prelab on time you will get a zero for that part of that lab.
• Final lab reports (one per group) are due one week after the lab work is complete, at the beginning of your next lab period. Late lab reports will be penalized 20% per weekday and 30% per weekend. Each lab builds on the previous one, so do not get behind.  If there is a problem with completing a lab on time, get in touch with Prof. Reinhardt (and only Prof. Reinhardt) as soon as possible.
• Summary:
  • In the week before lab n:
    1. Write lab report for lab n-1.
    2. Do prelab questions for lab n (individually).
    3. Develop hardware & software for lab n with your lab partner.
    4. Test and debug hardware and software using tools on CAEN.
  • At your lab section for lab n:
    1. Turn in your lab report for lab n-1.
    2. Turn in your prelab questions for lab n.
    3. Your TA will answer questions on lab n and hand out lab n+1.
    4. Show your printed code listing and schematic (if appropriate) to your TA. If you do not have these, you must leave at this point.
    5. Download your hardware design and software to the lab board. Debug if necessary. Once your system is working, demonstrate it to the TA.
  • ++n; goto Summary;

Course Policies

• The honor code is in force on all assignments and exams. All individual assignments (e.g., prelabs and exams) are to be performed on your own.  All group assignments (e.g., lab work and lab reports) are to be performed only by members of the group.  There shall be no sharing of code or hardware designs among lab groups. You may not help debug another group's hardware or software without consent from the TAs or the instructor. You are also not allowed to possess, look at, use, or in any way derive advantage from the existence of code, lab reports, or other material prepared in prior years. Remember, you are obliged to report any cheating you witness. Violation of this policy is grounds for initiating an action that would be filed with the Dean's office and would come before the College of Engineering's Honor Council. If you have any questions about this policy, do not hesitate to contact Prof. Reinhardt.
• Keep all your files in your CAEN AFS directory. We will be creating class directories for this purpose. The PCs in the lab have AFS access, but it would be wise to make backups onto your own floppy and bring it to the lab just in case.  Although there should be no need to copy files to or create files on the lab machine's local hard disk, if you do create files there make sure you delete them. If you find another group's files on the hard disk, delete them yourself (if you can) or notify the TA.  Looking at another group's files is an honor code violation (see above).
• No food or drink in the lab.
• You are expected to attend the lab section for which you are registered. If you would like to switch lab sections, but the section you want is full, you must find someone in that lab section to switch with. The course newsgroup is a logical place to advertise for such a person. Once you have agreed on a switch, send email to the the TA(s) responsible for both of the affected sections (see above). All section switches must be completed before the first lab meets (Wednesday, September 16).

Grading

Lab grade breakdown:

Item	Weight
Prelab	30%
Demonstration	40%
Lab report	30%

Overall breakdown:

Item	Weight (each)	Total
Labs (approx. 8)	approx. 5%	40%
Midterm exams (2)	17.5%	35%
Final exam	25%	25%

In spite of this breakdown, you will not earn a C in this course unless you have a C average on the labs and on the exams independently.

Schedule

• Lab sections will meet starting Wednesday, September 16. Do not miss this first week, or you may lose your slot in the lab section. There are no prelab questions for Lab 1; just show up.
• Midterm exam 1 will be given in class on Tuesday, October 6. Midterm exam 2 will be given in class on Tuesday, November 10. The final exam will be given in the regular finals-week time slot (Friday, December 18, 1:30-3:30). Mark these dates on your calendar. Do not make any conflicting commitments. Exams will be rescheduled only in the case documented medical or personal emergency.
• See the web page for a tentative schedule of lecture topics and labs.