EECoE 11602160

1
EE/CoE 1160/2160

• Embedded Systems

2

• J.T. Cain
• Office 337 BEH
• Phone O 412-624-9664
• H 412-963-0518
• Email cain_at_ece.pitt.edu
• Office Hours M 500-600
• T 400-500
• W 300-400
• or stop in, call or email

3
TA

• Dan Zeevi
• Office361 BEH
• Office hours
• T 400-600
• W 200-400
• Email
• dzz2_at_pitt.edu

4
WEB Page

• http//www.engr.pitt.edu/electrical/faculty-staff/
  cain/1160/

5
Course Grade

• Undergraduates Graduate Students
•  
• Lab Component 30 Undergrad Comp 80
• Homework 10 Research paper 20
• Exam I 30 TOTAL 100
• Exam II 30
• TOTAL 100

6
What is an embedded computer system?

• Loosely defined - any device that includes a
  programmable computer but is not itself intended
  to be a general-purpose computer
• Examples
• A fax machine or a clock built from a
  microprocessor
• Automobiles, personal digital assistants (PDAs),
  household appliances

7
Course Outline

• Topic Reference
• Embedded System
• Overview Wolf Chapter 1
• Excalibur Overview Notes
• Tools
• NIOS Architecture Notes
• Instruction set

8
Course Outline

• Topic Reference
• Design Process
• Formal Specification UML NOTES, Wolf Chpt 1
• I/O Wolf Chapter 3
• Busy-Wait
• Interrupts
• Overhead
• Supervisor Mode
• Exceptions, and Traps Wolf Chapter 3
• CPU Performance/Power
• Consumption Wolf Chapter 3

9
Course Outline

• Topic Reference
• Real-Time OS Labrousse Chapters 2-7
• Tasks/Processes Wolf Chapter 6
• Context Switching
• OS Structure
• Scheduling
• Communication/Synchronization

10
Course Outline

• Topic Reference
• Embedded Computing Platform Wolf Chapter 4
• CPU Bus
• Memory Devices
• I/O Devices
• Analog Subsystems Notes
• Component Interfacing
• Development Environments

11
Course Outline

• Topic Reference
• Program Design and Analysis Wolf Chapter 5
• Program Design
• Program Models
• Analysis and Optimization of Execution Time
• Analysis and Optimization of Energy and Power
• Analysis and Optimization of Program Size
• Program Validation and Testing

12
Course Outline

• Topic Reference
• Hardware Accelerators Wolf Chapter 7
• Networks Wolf Chapter 8
• Distributed Embedded Architectures
• Network Based Design
• System Design Techniques Wolf Chapter 9
• Design Methodologies
• Requirements Analysis
• Specifications
• Systems Analysis and Architecture Design

13
Development System

• Alteras Excalibur System
• An FPGA and a down loadable scalable processor -
  the NIOS
• A development board
• Software Development Tools
• Testing Tools

14
Laboratories

• Lab 1 Introduction to Quartus
• Lab 2 Introduction to Pin Assignments
• Lab 3 Introduction to SignalTap II
• Lab 4 Introduction to Nios Hardware Development
  
• Lab 5 Introduction to Nios Software
  Development.
• Lab 6 A Simple User Interface
• Lab 7   Introduction to Embedded Systems with an
  RTOS
• Lab 8 Mini Project

15
Again - What is an Embedded System

• A system in which there is an embedded special
  purpose digital computer that supplies the
  functionality of the system but is not apparent
  to the user

16
(No Transcript)
17
Embedded System Designers

• Identify where microprocessors or
  microcontrollers can be used
• Design a hardware platform with I/O devices that
  can support the required tasks
• Design software that performs the required
  processing.

18
Microprocessors

• In 1971, the first microprocessor, the Intel
  4004, was designed for an embedded application,
  namely, a calculator, followed immediately by
  the 8008 for an intelligent terminal
• These two processors marked the start of the
  microprocessor revolution

19
Range of Microprocessors

• 8-bit microprocessor - designed for low-cost
  applications
• 16-bit microcprocessor - often used for more
  sophisticated applications
• 32-bit RISC microprocessor - very high
  computation-intensive applications
• 64-bit processors network switches, etc.

20
Microcomputers

• Processor, memory and I/O on a single chip
• PICs, Intel 8051, Motorola 68HC11, etc.

21
Example

• BMW 850i Brake and Stability Control System
• ABS - antilock brake system
• ASCT - automatic stability control system

22
Diagram
23
System Functions

• ABS controls brakes
• ASCT controls throttle, ignition, timing,
  differential brake, and gear shifting on
  automatics

24
Characteristics of Embedded Computing Applications

• Complex algorithms
• e.g.. the processors that control an
  automobile engine must perform complicated
  filtering functions to optimize the performance
  of the car while minimizing pollution and fuel
  utilizations
• e.g. steer-by-wire systems hard real- time

25
Characteristics of Embedded Computing Applications

• User Interfaces
• e.g. - the moving maps in Global Positioning
  System (GPS)
• Real Time
• Hard real time systems
• Soft real time systems

26
Characteristics of Embedded Computing Applications

• Multirate
• Multimedia applications are prime examples of
  multirate behavior
• Many complex control applications
• Manufacturing cost
• Power
• Designed by small teams on tight deadlines

27
Why Use Processor-based Design?

• vs. custom logic, field programmable gate
  arrays (FPGAs), etc.
• Processors
• very efficient way to implement digital systems
• easier to design families of products that
  provide various feature sets and to provide new
  features to keep up with rapidly changing
  markets

28
Embedded System Design Challenges

• How much hardware do we need?
• How do we meet deadlines?
• How do we minimize power consumption?
• How do we design for upgradeability?

29
Embedded System Design Challenges

• Complex testing
• Limited observability and controllability
• Restricted development environments

30
Text Description of the Design Process
31
Alternative View of Design Process Steps
32
Requirements

• Before we design a system, we must know what we
  are designing
• First - gather an informal description from the
  customers - a set of requirements
• Designers and customers likely speak different
  languages
• Then, refine the requirements into specifications

33
A Problem

• I know you believe you understood what you think
  I said, but I am not sure you realize that what
  you heard is not what I meant!

34
Requirements

• Types
• Functional
• At least some requirements must be functional
• Nonfunctional

35
Typical Nonfunctional Requirements

• Performance
• Cost
• Manufacturing costs
• Nonrecurring engineering (NRE) costs
• Physical size and weight
• Power consumption

36
Validating Requirements

• Ultimately a psychological task since it
  requires understanding both what people need
  versus what they want
• A sometimes useful technique is to use a mock-up
  or prototype i.e. rapid prototype
• Requirements analysis and verification can be
  complex and time consuming

37
A Requirements Summary Form

• Name
• Purpose
• Inputs and Outputs
• Types of data
• Data characteristics
• Types of I/O devices

38
A Requirements Summary Form - continued

• Functions
• Performance
• Manufacturing cost
• Power
• Physical size and weight

39
Consistency Check

• After determining a set of requirements
• must check them for internal consistency
• must check them for satisfying needs

40
Example

• Requirements Analysis of a GPS Moving Map

41
(No Transcript)
42
Initial Requirements Set

• Functionality
• Intended for highway driving and similar uses,
  not nautical or aviation
• Show major roads and other landmarks available
  in standard topographic databases

43
An Initial Requirements Set -continued

• User interface
• At least 400X600 pixel resolution
• Controlled by no more than three buttons
• A menu system should pop up on the screen when
  buttons are pressed

44
An Initial Requirements Set -continued

• Performance
• Upon power-up a display should take no more than
  one second to appear
• Verify its position and display the current map
  within 15 seconds.

45
An Initial Requirements Set -continued

• Cost
• under 500
• Physical size and weight
• Fit comfortably in the palm of the hand
• Power consumption
• Run for at least eight hours on four AA
  batteries

46
Summary Chart
47
Summary Chart

• Is just that
• In almost all cases need a complete
  Requirements Document as well

48
Specifications

• Serves as the contract between the customer and
  the architects.
• Must be carefully written so that it accurately
  reflects the customers requirements and does so
  in a way that can be clearly followed during
  design

49
Specifications

• Must be such that someone can verify that
  system requirements and overall expectations of
  the customer are met
• Must include a set of tests than when
  successfully met means specs have been met
• Be unambiguous enough that designers know what
  they need to build
• Be a contract

50
GPS System Specifications would include

• Data received from the GPS satellite
  constellation
• Map data
• User interface
• Operations that must be performed to satisfy
  customer requests.
• Background actions required to keep the system
  running, such as operating the GPS receiver

51
Architecture Design

• Purpose
• Describe how the system can implement the
  specifications
• Definition
• A plan for the overall structure of the system
  that will be used later to design the components
  that make up the architecture
• Must be designed to satisfy both functional and
  nonfunctional requirements

52
System Block Diagram

• Shows major operations and data flows among them
• Does not specify hardware or software but does
  go a long way toward describing how to implement
  the functions described in the specification

53
System Block Diagram
54
Hardware and Software Block Diagrams

• Refine the system block diagram into two block
  diagrams
• one for hardware and another for software
• after an initial architecture that is not biased
  toward too many implementation details is
  constructed

55
Hardware Block Diagram
56
Software Block Diagram
57
Architecture Verification

• The architecture must be checked to be in
  conformance with the system specifications

58
Designing Hardware and Software Components

• Components are designed and built in conformance
  to the architecture and component specifications
  

59
System Integration

• Consists of a lot more than just plugging
  everything together and standing back big
  bang theory of testing
• Build up the system in phases and run properly
  chosen tests - those from specs and additional
  tests
• Must ensure during the architectural and
  component design phases that it is possible to
  assemble the system in phases and test functions
  relatively independently