ECE 453 Embedded Microprocessor System Design

1
ECE 453Embedded Microprocessor System Design
Introduction

• Michael G. Morrow, P.E.

2
Week 1 Topics

• Introduction
• Course Administration
• Design Process

3
Introduction

• Instructor
• Michael Morrow (morrow_at_engr.wisc.edu)
• Office Hours (3537EH) also posted on web page
• Monday 900-1000am
• Tuesday 1000-1100am, 100-200pm
• Wednesday 230-430pm
• Friday 800am-900am, 230-330pm
• Other times by appointment / drop-in (look at web
  schedule for conflicts)
• Teaching Assistant
• Dan Seemuth
• Office Hours TBA, held in lab

4
Course Administration

• Course Goals
• Course Schedule
• Team Requirements
• Weekly status reports by email starting in week 6
• Lecture / Labs
• Projects
• Deliverables
• Expert Teams
• Grading
• Texts / Class Notes
• Web Resources
• Initial Survey

5
Class Boot-Up

• Teams
• Assignment
• Contracts
• Assessment
• Labs
• Scheduled
• Second half of semester
• Schematic Capture / Board Layout Packages
• ExpressPCB.com
• Eagle CAD software
• Cadence OrCAD

6
Individual Assignment 1

• Write a short essay (300 words) that answers the
  following
• What is engineering? How do engineers do it, and
  who cares anyway?
• You may NOT use any references this is to come
  from your existing knowledge, experience and
  thought only.
• I expect a critical perspective. Make sure you
  are not using circular definitions.
• Submit your essay as plain text via email by
  Thursday, 1/29. Grading will be based on the
  depth of thought exhibited, as well as grammar
  and spelling.

7
Embedded Microprocessor System Design

• Whats involved in the design of an embedded
  system?
• Design Issues
• Problem definition
• Exploration of possible solutions
• Evaluation of alternatives
• Component selection
• Development tool selection
• Prototype development
• Test and verification
• Interaction with other disciplines
• Regulatory approvals
• Marketing and sales

8
The Design Environment

• Questions
• Whats design all about?
• Whats so hard about design?
• What are some of the common milestones in a
  design process?
• Why do we need a design process?
• Can creative work like engineering ever be
  constrained a priori to a process?

9
User needs
1 Requirements Analysis
2 Specification
3 System Architecture
4 HW Design
4 SW Design
5 HW Implementation
5 SW Implementation
6 HW Testing
6 SW Testing
7 System Integration
8 System Validation
9 O M, Evolution
10
Generic Design Process

• All real design is iterative.
• It usually involves unknowns, estimations, and
  predictions that may not be correct.
• Keep this in mind as you do your design!

11
Sample Design Process

• Specifications Phase
• Requirements definition
• Simulation plan
• Hardware verification test plan
• Manufacturing test strategy
• Resource identification/allocation
• People
• Tools
• Licensing
• Review
• Requirement specifications
• Customer sign-off
• EMC concept

12
Sample Design Process

• Design Phase
• Architecture and system
• Component selection / BOM / part obsolescence
• Parts procurement
• Cost analysis
• Timing analysis
• EDA part creation / schematic capture
• DFV / DFT / DFM / Design for agency, EMC
• PCB guidelines
• Simulation
• Model generation
• Simulation
• Review
• Design
• Schematic
• Agency / EMC

13
Sample Design Process

• PCB Design
• Place and route
• Mechanical/electrical design interchange
• Signal integrity
• Review
• PCB checklist / guidelines
• Prototype documentation
• Build
• Board or system

14
Sample Design Process

• Integration / Verification
• System
• Embedded software
• Mechanical
• Engineering testing
• Compliance testing
• Execute hardware verification test plan
• Review
• Deliverables
• Manufacturing documents
• Release to manufacturing

15
Lessons Learned from Semesters Past
16
Some Lessons Learned

• If you fix a problem and you dont know how you
  fixed it, that means its still broken.
• No Brownian debugging
• Wire-wrapping the prototyping board is not fun.
• Completely rewiring the prototyping board after
  you find a conflict is even less fun.
• 20 minutes before your project demo, it will
  break in a way it never has before.

17
Some Lessons Learned

• Work hard early.
• If something isnt working, check the basic
  assumptions first (i.e. power correct, good fuse,
  wiring correct), then move up to the code.
• Dont underestimate the complexity of software.
• Make sure everyone has a firm understanding of
  the projects goals, requirements, and plans.

18
Some Lessons Learned

• Never assume.
• Things do not magically work as planned.
• Dont ignore simple errors if you dont know why
  they occur. They are pointing to a problem.
• Always examine datasheets in detail.
• Even datasheets can have errors.
• Documentation is the key when interfacing
  multiple parts of the project done by different
  people.

19
Some Lessons Learned

• They werent kidding about synchronization in
  352, 551, etc.
• Be aware of the logic level and power supply
  requirements of your devices i.e. if you are
  using a 3.3V part, can it interface with a 5V
  part (and in both directions)?
• Some hardware can only be hooked up in one
  direction.
• Everything takes much longer than you think it
  will.

20
Some Lessons Learned

• If you catch yourself saying wellit kind of
  works, GO BACK and make sure it completely
  works!
• Big code doesnt necessarily equal good code.
• Many times, things can be done simply and
  elegantly.
• Choose a project that fits your interests and
  talents.

21
Some Lessons Learned

• Be gentle with components the hardest to solder
  leads are the quickest to break
• If a component is relatively cheap, order extras
  odds are youll need them
• Large, complicated projects with many extra
  design features should be started early if you
  plan on sleeping at the end of the semester
• Morrows Corollary impulse effort bad
• Know the S-curve of project progress

22
Group Design Exercise

• You are to design a portable microprocessor-based
  MP3 player with audio record capability,
  removable SD memory for music storage, and a USB
  2.0 connection for music download.
• Create a functional block diagram to show how
  such a system would likely be built.
• Pass your block diagram for critique by another
  team.
• With instructor, develop a consensus block
  diagram.
• Develop a construction and test plan for building
  this device. What HW and/or SW tools might you
  want/need to develop along the way?

23
Wrapping Up

• Get talking about project ideas!
• Reading for next week (available on the course
  web page)
• MC9328MX21 Datasheet
• i.MX21 Reference Manual (scan)

24
Projects

• Project design to be completed by teams of three
  persons.
• Project environment
• TLL5000 Logic Development board
• Spartan 3 FPGA (1.5 million gate-equivalent)
• TLL6219 ARM9 Mezzanine Board
• MC9328MX21 ARM926 microprocessor
• QVGA LCD (w/ unconnected touch-screen)
• FPGA connects to external memory bus
• Prototyping Mezzanine Board
• Connects to FPGA signals, level-translation
• Flexible connection to prototyping board
• Embedded operating system (Linux)
• Eclipse/gcc development environments
• Sponsorship opportunities

25
6 Phases of a Project

• Enthusiasm
• Disillusionment
• Panic
• Search for the guilty
• Punishment of the innocent
• Praise and honors for the non-participants

26
Project Ideas

• The skys the limit!

27
Deliverables

• Initial project proposal
• Detailed proposal, schedule, cost/time estimate
• Requirements definition ¹
• Register set deliverable, timing analysis
• Schematic diagram, BOM, test plan, formal design
  review ¹
• Initial hardware test
• Final project demonstration
• Final project report

¹Updated schedule, cost/time estimate
28
Expert Teams

• Students will become an expert in a specified
  area, and then be available to assist other
  students in that area.
• The specific topics will be decided later.

29
Grading

• Individual/team assignments 10
• Final Examination 15
• Cumulative
• Includes questions on expert areas
• Quality and Effort 10
• Professionalism
• Team contributions
• Design Project Deliverables 65