Introductionr93088/temp/一哥/Module-1.pdf · Digital signal processor (DSP): ... signal...

Embedded System Design - NTHU EOS Lab 1Module-1 Embedded Computing

Introduction

� Embedded System Introduction

� Embedded Systems Characteristics

� Embedded System Design Process

� Object-Oriented Design

� Unified Modeling Language (UML)

� Design Example: Model Train Controller


Embedded System Introduction

Embedded Systems CharacteristicsEmbedded Systems Characteristics

Embedded System Design ProcessEmbedded System Design Process

ObjectObject--Oriented DesignOriented Design

Unified Modeling Language (UML)Unified Modeling Language (UML)

Design Example: Model Train ControllerDesign Example: Model Train Controller


Definition

� Embedded system: any device that includes a programmable computer but is not itself a general-purpose computer

� e.g., PDA, printer, cell phone

� e.g., TV, household appliances

� e.g., automobiles: engine, brakes, etc

�NOT-e.g., PC


Embedded System Example

CPU

mem

input

output analog

analog

embedded

computer


2-layered System Architecture

THE Application

I/O ManagerGraphics

Subsystems

Network

Drivers

Device

Drivers

Scheduler

Graphics

Drivers

Operating

System

Kernel

Hardware


3-layered System Architecture

Applications

I/O ManagerGraphics

Subsystems

Network

Drivers

Device

Drivers

Scheduler

Graphics

Drivers

Operating

System

Kernel

Hardware

ApplicationsProcesses


Early History (1/2)

� Late 1940’s: MIT Whirlwind computer was designed for real-time operations� to control aircraft simulator

� First microprocessor: Intel 4004 in early 1970’s� microprocessor: a single-chip CPU

� Key breakthrough: HP-35 (1972)� due to the high cost of VLSI design, reuse the HW

design by changing the SW

� 1st handheld calculator to compute complex math functions

� HP-35 uses several chips to implement the CPU


Early History (2/2)

� Automobiles used microprocessor-based engine controllers starting in 1970’s.

� Control fuel/air mixture, engine timing, etc.

� 2 pushes: oil crisis & environment protection

� low fuel consumption & low emission

�Multiple modes of operation: warm-up, cruise, hill climbing, etc.

� sophisticated control can only be done with microprocessors


Microprocessor Varieties

� Microcontroller: includes I/O devices, on-board memory

� Players: Intel, ARM, Motorola, Hitachi

� Digital signal processor (DSP):microprocessor optimized for digital signal processing

� Players: Analog Devices, Motorola, TI

� Typical embedded word sizes: 8-bit, 16-bit, 32-bit


Application Examples

� Front panel of microwave oven

� Advanced thermostat systems� time-temperature settings

� Canon EOS 3 has 3 microprocessors� 32-bit RISC CPU runs auto-focus and eye-control

system

� Analog TV: channel selection, etc

� Digital TV: audio processing CPU� easier to design & debug

� possibility of upgrades


Automotive Embedded Systems

� Today’s high-end automobile may have 100 microprocessors:

� 4-bit microcontroller checks seat belt

�microcontrollers run dashboard devices

� 16/32-bit microprocessor controls engine


BMW 850i Brake & Control System

� Anti-lock brake system (ABS): pumps brakes to reduce skidding

� Automatic stability control (ASC+T):controls engine to improve stability

� ABS and ASC+T communicate


BMW 850i

brake

sensor

brake

sensor

brake

sensor

brake

sensor

ABShydraulic

pump


Review Slides (1)

� Embedded system definition? examples?

� First microprocessor?

� HP-35 significance?

� Microprocessor usage in automobiles?

� Microcontroller? DSP?



Embedded Systems CharacteristicsEmbedded Systems Characteristics






Embedded Systems Characteristics (1/2)

� Complex algorithms

� e.g., automobile engine control system

� Sophisticated user interface

� e.g., GPS navigation system

� Real-time operation

� hard-real-time

� e.g. life-critical system

� soft-real-time

� e.g. GPS navigation system


Embedded Systems Characteristics (2/2)

� Multirate functionality

� e.g., multimedia applications (video & audio)

� Low manufacturing cost

� Low power

� excessive power consumption increases system cost

� Designed to tight deadlines by small teams

� 6-month market window is common

� e.g. cannot miss back-to-school window for calculators


Why use microprocessors?

� Alternatives: field-programmable gate arrays (FPGAs), custom logic, etc.

� Microprocessors are often very efficient: can use same logic to perform many different functions

� Microprocessors simplify the design of families of products


The Performance Paradox

� Microprocessors use much more logic to implement a function than does custom logic

� instruction cycle: fetch, decode, execute, write

� however, for a set of family functions, microprocessors may use less logic

� But microprocessors are often at least as fast:

� heavily pipelined

� large design teams

� aggressive VLSI technology

� Microprocessors dominate new fabrication lines� custom logics have to wait and use old VLSI technology


Power

� Custom logic is a clear winner for low power devices

� Modern microprocessors offer features to help control power consumption

� Software design techniques can help reduce power consumption


Embedded System Design Challenges (1/2)

� How much hardware do we need?

�How big is the CPU? Memory?

� more hardware � capabilities � more money

� How do we meet our deadlines?

� Faster hardware or cleverer software?

� How do we minimize power?

� Turn off unnecessary logic? Reduce memory accesses? run at slower clock rate?


Embedded System Design Challenges (2/2)

� Does it really work?

� Is the specification correct?

�Does the implementation meet the spec?

�How do we test for real-time characteristics?

�How do we test on real data?

� How do we work on the system?

�Observability, controllability?

�What is our development platform?


Review Slides (2-1)

� Embedded systems characteristics?

� complex algorithms, complicated UI, real-time ops, multi-rate functions, low powers, tight deadline & budget

� FPGA, ASIC, Microprocessor

� manufacturing cost, power, efficiency, size, development cost

� Microprocessor efficiency factors

� pipelined, large design teams, latest VLSI

� Embedded system design challenges?

� HW usage, efficiency, power, testing, platform


Review Slides (2-2)

Exec Speed

Power Req

VLSI Tech

Design Team

Gate #

Functions

Flexibility

Manu Cost

MicroprocASICFPGA


Review Slides (2-2)

Fast*FastMediumExec Speed

Medium*LowMediumPower Req

High-endLow-endMediumVLSI Tech

LargeMediumSmallDesign Team

HighLowMediumGate #

MoreLessMediumFunctions

HighLowMediumFlexibility

ExpensiveCheapMediumManu Cost

MicroprocASICFPGA



Embedded Systems Characteristics






Growth Rate of Embedded Software

1

2

0 10 12 18 months

factor

*) Department of Trade and Industry, London

(1.4/year) [Moore’slaw]

>10 times more programmers will write

embedded applications than computer software by 2010Em

beddedsoftware

[DTI

*]

(~2.5/yr)

already to-day, more than 98% of all microprocessors are used within

embedded systems

© 2004, [email protected] http://hartenstein.de


Submarine Programming Model

Hardware invisible:under the surface

Hardware

Algorithm

Assembly Language

procedural high level Programming Language

SoftwareThis model does not suportHardware / Configware / Software partitioning



Dominance of the Submarine Model ...

Hardware

... indicates, that our CS education system produces zillions of

mentally disabled CS graduates

(procedural) structurallydisabled

… disabled to cope with solutions other than

instruction-stream-based



Built From Bottom-Up

proceduralhave not

You cannot *teach Hardware to a Programmer*) efficiently

But to a Hardware Guy you always can teach

Programming

structuralhave natural



Design Methodologies

� A procedure for designing a system

� Understanding your methodology ensures you didn’t skip anything

� Compilers, software engineering tools, computer-aided design (CAD) tools, etc., can be used to:

� help automate methodology steps

� keep track of the methodology itself


Design Goals

� Performance.

�Overall speed, deadlines

� Functionality and user interface

� Manufacturing cost

� Power consumption

� Other requirements (physical size, etc.)


Design Process Abstraction

requirements

specification

architecture

component

design

system

integration

top-down

design

bottom-up

design


Top-down vs. Bottom-up

� Top-down design:

� start from most abstract description

�work to most detailed

� Bottom-up design:

�work from small components to big system

� Real design uses both techniques


Step-1: Requirements

� Plain language description of what the user wants and expects to get

� May be developed in several ways:

� talking directly to customers

� talking to marketing representatives

� providing prototypes to users for comment


Sample Requirement Form

name project name

purpose one or 2 sentences

inputs type of data? periodic or non-periodic?

outputs I/O devices?

functions inputs � outputs

performance real-time req?

manufacturing cost rough estimation

power battery or wall-powered

physical size/weight e.g., PC or NB?


Example: GPS moving map requirements

� Moving map obtains position from GPS, paints map from local database.

lat: 40 13 lon: 32 19

I-78

Scotch Road


Step-1 of GPS moving map (1/3)

� Functionality: Show major roads and landmarks for automotive use

� User interface: At least 400 x 600 pixel screen. Three buttons max. Pop-up menu.

� Performance: Map should scroll smoothly. No more than 1 sec power-up. Lock onto GPS within 15 seconds.

� Cost: $500 street price = approx. $100 manufacturing cost.



� Physical size/weight: Should fit in hand

� Power consumption: Should run for 8 hours on four AA batteries



name MGPS: GPS moving map

purpose consumer-grade moving map for driving

inputs power button, two control buttons

outputs back-lit LCD 400 X 600

functions 5-receiver GPS; three resolutions; displays current lat/lon

performance updates screen within 0.25 sec of movement

manufacturing cost $100 cost-of-goods-sold

power 100 mW

physical size/weight no more than 2” X 6”, 12 oz.


Step-2: Specifications

� A more precise description of the system:

� should NOT imply a particular architecture

� provides input to the architecture design process

� Serve as a contract between customers and architects

� May include functional and non-functionalelements.

� May be executable or may be in mathematical form for proofs


Step-2 of GPS moving map

� Should include:

�What is received from GPS

�map data

� user interface

� operations required to satisfy user requests

� background operations needed to keep the system running


Step-3: Architecture Design

� Describe how the system implements the required functions

� Specifications: what the system does

� Architecture: how the system does things

� Hardware components:

� CPUs, peripherals, etc.

� Software components:

� major programs and their operations.

� Must take into account functional and non-functional (cost, speed, etc) specifications


Step-3: GPS moving map block

diagram (1/3)

GPS

receiver

search

enginerenderer

user

interfacedatabase

display


Step-3: GPS moving map Hardware

Architecture (2/3)

GPS

receiver

CPU

panel I/O

display frame

buffer

memory


Step-3: GPS moving map Software

Architecture (3/3)

position

database

searchrenderer

timeruser

interface

pixels


Step-3: Architecture Design (cont)

� Functional block diagram first � SW/HW architecture

� SW � HW module mapping

� Make sure both functional and non-functionalrequirements are satisfied

� Otherwise, redo Step-3 again

� How to make sure non-functional requirements are satisfied?

� Experience

� Modeling

� Simulation


Step-4: Designing Hardware and

Software Components

� Must spend time architecting the system before you start coding

� Some components are ready-made (e.g., CPU, topographic databases), some can be modified from existing designs, others must be designed from scratch


Step-5: System Integration

� Put together the components

�Many bugs appear only at this stage �

� Have a plan for integrating components to uncover bugs quickly, test as much functionality as early as possible


Summary

� Embedded computers are all around us

�Many systems have complex embedded hardware and software

� Embedded systems pose many design challenges: design time, deadlines, power, etc.

� Design methodologies help us manage the design process


Review Slides (3)

� Common design goals?

� Performance, functionality, user interface, cost, power, size, weight

� 5-step design process?

� Requirements? Requirement form?

� Specification?

� Architecture design?

� Component design?

� System integration?




Embedded System Design Process





System Modeling

� Need languages to describe systems:

� useful across several levels of abstraction;

� understandable within and between organizations

� Block diagrams are a start, but don’t cover everything


Object-Oriented Design

� Object-oriented (OO) design: A generalization of object-oriented programming�OO design is different from OO programming

� Object = state + methods� State provides each object with its own

identity

�Methods provide an abstract interface to the object


OO implementation in C++

class display {

pixels : pixeltype[IMAX,JMAX];

public:

display() { } // constructor

pixeltype pixel(int i, int j) { return pixels[i,j]; }

void set_pixel(pixeltype val, int i, int j) { pixels[i,j] = val; }

}


Objects and Classes

� Class: object type

� Class defines the object’s state elements

� Class defines the methods used to interact with all objects of that type

� Each object has its own state (memory)


OO Design Principles

� Some objects will closely correspond to real-world objects

� Some objects may be useful only for description or implementation

�Not every object is executable

� Objects provide interfaces to read/write state, hiding the object’s implementation from the rest of the system


UML

� Developed by Booch et al.

� Goals:

� object-oriented

� visual

� useful at many levels of abstraction

� usable for all aspects of design


UML object

d1: Display

pixels: array[] of pixels

elements

menu_items

pixels is a

2-D array

comment

object name

class name

attributes


UML class

Display

pixels

elements

menu_items

mouse_click()

draw_box()operations

class name


The class interface

� The operations provide the abstract interface between the class’s implementation and other classes

� Operations may have arguments, return values

� An operation can examine and/or modify the object’s state


Class Derivation

� May want to define one class in terms of another

�Derived class inherits attributes, operations of base class

Derived_class

Base_class

UML

generalization


Class Derivation Example

Display

pixels

elements

menu_items

pixel()

set_pixel()

mouse_click()

draw_box

BW_display Color_map_display

base

class

derived class


Multiple Inheritance

Speaker Display

Multimedia_display

base classes

derived class


Links and Associations

� Link: describes relationships between objects

� Association: describes relationship between classes


Association Example

message

msg: ADPCM_stream

length : integer

message set

count : integer

0..* 1

contains

# contained messages # containing message sets

0 or more messages


Link Example

� Link defines the contains relationship:

m1:message

msg = msg1

length = 1102

m2:message

msg = msg2

length = 2114

ms1:message set

count = 2


State Machines

a b

state state name

transition


Event-Driven State Machines

� Behavioral descriptions are written as event-driven state machines

�Machine changes state when receiving an input

� An event may come from inside or outside of the system


Event Type

� Signal: asynchronous event

� Call: synchronized communication

� Timer: activated by time


Signal Event

<<signal>>

mouse_click

leftorright: button

x, y: position

declaration

a

b

mouse_click(x,y,button)

event description


Call Event (Procedural Call)

c d

draw_box(10,5,3,2,blue)


Timer Event

e f

tm(time-value)

• State change after a certain amount of time• time-value = amount of time to expire


Example State Diagram

region

found

got menu

item

called

menu item

found

object

object

highlighted

start

finish

mouse_click(x,y,button)/

find_region(region)

input/output

region = menu/

which_menu(i) call_menu(i)

region = drawing/

find_object(objid) highlight(objid)


Sequence Diagram

� Shows sequence of operations over time

� Relates behaviors of multiple objects


Sequence Diagram Example

m: Mouse d1: Display u: Menu

mouse_click(x,y,button)which_menu(x,y,i)

call_menu(i)

time

lifeline


Summary

� Object-oriented design helps us organize a design

� UML is a transportable system design language

� Provides structural and behavioraldescription primitives






Unified Modeling Language (UML)



Model train setup

console

power

supply

rcvr motor

ECCaddressheader command


Step-1: Requirements (1/2)

� Console can control 8 trains on 1 track

� Throttle has at least 63 levels

� Inertia control adjusts responsiveness with at least 8 levels (加速度)

� Emergency stop button

� Error detection scheme on messages


Step-1: Requirements Form (2/2)

name model train controllerpurpose control speed of <= 8 model trainsinputs throttle, inertia, emergency stop,

train #outputs train control signalsfunctions set engine speed w. inertia;

emergency stopperformance can update train speed at least 10

times/secmanufacturing cost $50power wall poweredphysicalsize/weight

console comfortable for 2 hands; < 2lbs.


Step-2: Conceptual Specification

� Before we create a detailed specification, we will make an initial, simplified specification

�Gives us practice in specification and UML.

�Good idea in general to identify potential problems before investing too much effort in detail


Basic System Commands

command name parameters

set-speed speed(positive/negative)

set-inertia inertia-value (non-negative)

estop none


UML Sequence Diagram

:console :train_rcvrset-inertia

set-speed

set-speed

set-speed

estop


Class Diagram

command

set-inertia

value: unsigned-

integer

set-speed

value: integer

estop


Subsystem Collaboration Diagram

Shows relationship between console and receiver (ignores role of track):

�One console can control up to 8 receivers

:console :receiver

1..n: command


System Structure Modeling

� Some classes define non-computercomponents

�Denote by *name

� Choose important systems at this point to show basic relationships


Major Subsystem Roles

� Console:

� read state of front panel

� format messages

� transmit messages

� Train:

� receive message

� interpret message

� control the train


Console System Class Diagram

console

panel formatter transmitter

Knobs* sender*

1

1

1

111

11

11


Console class roles

� panel: describes analog knobs and interface hardware

� formatter: turns knob settings into bit streams

� transmitter: sends data on track


Train System Class Diagram

train set

train

receiver

controller

motor

interface

detector* pulser*

11..t

1

1

11

1 1

1

1

11


Train class roles

� receiver: digitizes signal from track

� controller: interprets received commands and makes control decisions

� motor interface: generates signals required by motor


Detailed Specification

� We can now fill in the details of the conceptual specification:

�more classes

� behaviors

� Sketching out the spec first helps us understand the basic relationships in the system


Console Physical Object Classes

knobs*

train-knob: integer

speed-knob: integer

inertia-knob: unsigned-

integer

emergency-stop: boolean

pulser*

pulse-width: unsigned-

integer

direction: boolean

sender*

send-bit()

detector*

read-bit() : integer


Panel and Motor Interface Classes

panel

train-number() : integer

speed() : integer

inertia() : integer

estop() : boolean

new-settings()

motor-interface

speed: integer


Class Descriptions

� panel class defines the controls

� new-settings() behavior reads the controls

� motor-interface class defines the motor speed held as state


Transmitter and Receiver Classes

transmitter

send-speed(adrs: integer,

speed: integer)

send-inertia(adrs: integer,

val: integer)

set-estop(adrs: integer)

receiver

current: command

new: boolean

read-cmd()

new-cmd() : boolean

rcv-type(msg-type:

command)

rcv-speed(val: integer)

rcv-inertia(val:integer)


Class Descriptions

� transmitter class has one behavior for each type of message sent

� receiver function provides methods to:

� detect a new message

� determine its type

� read its parameters (estop has no parameters)


Formatter Class

formatter

current-train: integer

current-speed[ntrains]: integer

current-inertia[ntrains]:

unsigned-integer

current-estop[ntrains]: boolean

send-command()

panel-active() : boolean

update-panel()


Formatter Class Description

� Formatter class holds state for each train, setting for current train

� The operate() operation performs the basic formatting task


Control Input Cases

� Use a soft panel to show current panel settings for each train

� Changing train number:

�must change soft panel settings to reflect current train’s speed, etc.

� Controlling throttle/inertia/estop:

� read panel, check for changes, perform command


Control Input Sequence Diagram

:knobs :panel :formatter :transmitter

change in speed/

inertia/estop

change in

train number

change in

control

settings

read panel

panel settingspanel-active

send-command

send-speed,

send-inertia.

send-estop

read panel

panel settings

read panel

panel settingschange in

train number

set-knobs

new-settings


Formatter Operate Behavior

idle

update-panel()

send-command()

panel-active() new train number

other


Panel-active behavior

panel*:read-train()current-train = train-knob

update-screen

changed = true

T

panel*:read-speed()current-speed = throttle

changed = true

T

F

...

F

...


Controller Class

controller

current-speed: integer

current-inertia: unsigned-integer

set-speed(integer)

set-inertia(integer)

new-speed(integer)


Setting the Speed

� Don’t want to change speed instantaneously

� Controller should change speed gradually by sending several commands


Set-Speed Sequence Diagram

:receiver :controller :motor-interface :pulser*

new-cmd

cmd-type

rcv-speed new-speed set-pulse

set-pulse

set-pulse

set-pulse

set-pulse


Refined Command Classes

command

type: 3-bits

address: 3-bits

parity: 1-bit

set-inertia

type=001

value: 3-bits

set-speed

type=010

value: 7-bits

estop

type=000


Summary

� Separate specification and programming

� Small mistakes are easier to fix in the spec

� Big mistakes in programming cost a lot of time

� You can’t completely separate specification and architecture

�Make a few tasteful assumptions


Useful Links

� http://www.uml.org/

� Official UML resource page

� You will find many good links here

� http://www.raba.com/~jcstaff/oodev/presents/uml/intro_uml/

� A pretty good introduction to UML

� http://www.softdocwiz.com/UML.htm

� UML Dictionary

� http://uml.tutorials.trireme.com/

� A relatively complete UML tutorial

Introductionr93088/temp/一哥/Module-1.pdf · Digital signal processor (DSP): ... signal...

Documents

Transcript of Introductionr93088/temp/一哥/Module-1.pdf · Digital signal processor (DSP): ... signal...