Entwurf Von Eingebetteten Systemen

HEINZ NIXDORF INSTITUTE
University of Paderborn System and Circuit Technology Prof. Dr.-Ing. Ulrich Rckert
Outline


An introduction to embedded systems design

Matthias Grnewald
1. 2. 3. 4. 5. 6. 7.
Introduction to embedded systems Design metrics Embedded system technologies Design processes Computation models and languages Design technologies Summary
References

Embedded systems overview

Embedded System Design: A Unified Hardware/Software Introduction Frank Vahid and Tony Givargis, John Wiley & Sons, 2002 Slides are mainly based on the lecture slides available at the book homepage (http://www.cs.ucr.edu/content/esd/) Draft version online available at: http://www.cs.ucr.edu/~vahid/courses/122a_f99/
Embedded computing systems

Computing systems embedded Computers are in here... within electronic devices and here... Hard to define. Nearly any computing system other than a desktop and even here... computer Billions of units produced yearly, versus millions of desktop units Perhaps 50 per household and per automobile Lots more of these,
though they cost a lot less each.
Further references:
J. Teich. Digitale Hardware/Software-Systeme Springer, 1997. ISBN 3-54062433-3 Vorlesung Eingebettete Systeme, Bernd Kleinjohann und Lisa Kleinjohann, C-LAB, Frstenallee 11, Raum FU.214, Tel. 606101 oder 606102, e-mail: bernd@c-lab.de lisa@c-lab.de Embedded Systems Internet Resources: http://www.compapp.dcu.ie/~cdaly/embed/embedsys.html
3
A short list of embedded systems And the list goes on and on

Anti-lock brakes Auto-focus cameras Automatic teller machines Automatic toll systems Automatic transmission Avionic systems Battery chargers Camcorders Cell phones Cell-phone base stations Cordless phones Cruise control Curbside check-in systems Digital cameras Disk drives Electronic card readers Electronic instruments Electronic toys/games Factory control Fax machines Fingerprint identifiers Home security systems Life -support systems Medical testing systems Modems MPEG decoders Network cards Network switches/routers On-board navigation Pagers Photocopiers Point-of-sale systems Portable video games Printers Satellite phones Scanners Smart ovens/dishwashers Speech recognizers Stereo systems Teleconferencing systems Televisions Temperature controllers Theft tracking systems TV set-top boxes VCRs, DVD players Video game consoles Video phones Washers and dryers

Some common characteristics of embedded systems

Single-functioned
Executes a single program, repeatedly
Tightly-constrained
Low cost, low power, small, fast, etc.
Reactive and real-time

Continually reacts to changes in the systems environment Must compute certain results in real-time without delay
An embedded system example -- a digital camera

Design challenge optimizing design metrics

Obvious design goal:

Digital camera chip CCD CCD preprocessor A2D lens JPEG codec Microcontroller Multiplier/Accum Pixel coprocessor D2A
Construct an implementation with desired functionality
Key design challenge:

Simultaneously optimize numerous design metrics
Design metric
A measurable feature of a systems implementation Optimizing design metrics is a key challenge
DMA controller
Display ctrl
Memory controller
ISA bus interface
UART
LCD ctrl
Single-functioned -- always a digital camera Tightly-constrained -- Low cost, low power, small, fast Reactive and real-time -- only to a small extent
7 8


Common metrics
Unit cost: the monetary cost of manufacturing each copy of the system,
excluding NRE cost
Common metrics (continued)

Time-to-prototype: the time needed to build a working version of the
system
NRE cost (Non-Recurring Engineering cost): The one-time

monetary cost of designing the system
Time-to-market: the time required to develop a system to the point

that it can be released and sold to customers
Size: the physical space required by the system Performance: the execution time or throughput of the system Power: the amount of power consumed by the system Flexibility: the ability to change the functionality of the system without
incurring heavy NRE cost
Maintainability: the ability to modify the system after its initial release Correctness, safety, many more
10
Design metric competition -- improving one may worsen others

The performance design metric

Power
Performance
Size
Expertise with both software and hardware is needed to optimize design metrics
Not just a hardware or software expert, as is common A designer must be comfortable with various technologies in order to choose the best for a given application and constraints
Hardware Software
11
Widely-used measure of system, widely-abused

Clock frequency, instructions per second not good measures Digital camera example a user cares about how fast it processes images, not clock speed or instructions per second
Latency (response time)

Time between task start and end e.g., Cameras A and B process images in 0.25 seconds
NRE cost
Throughput
Tasks per second, e.g. Camera A processes 4 images per second Throughput can be more than latency seems to imply due to concurrency, e.g. Camera B may process 8 images per second (by capturing a new image while previous image is being stored).
CCD lens
Digital camera chip A2D JPEG codec DMA controller CCD preprocessor Pixel coprocessor D2A
Speedup of B over S = Bs performance / As performance

Throughput speedup = 8/4 = 2
Microcontroller
Multiplier/Accum Display ctrl
Memory controller
ISA bus interface
UART
LCD ctrl
12
Moores law

Design productivity gap

The most important trend in embedded systems

Predicted in 1965 by Intel co-founder Gordon Moore IC transistor capacity has doubled roughly every 18 months for the past several decades
10,000 1,000
While designer productivity has grown at an impressive rate over the past decades, the rate of improvement has not kept pace with chip capacity
10,000 1,000 100,000 10,000 1000
Logic transistors per chip (in millions) Note: logarithmic scale
100 10 1 0.1 0.01 0.001

1981 1983 1985 1987 1989 1991 1993 1995 1997 1999 2001 2003 2005 2007 2009
Logic transistors per chip (in millions)
100 10 1 0.1 0.01 0.001

1991 1993 1995 1997 1999 2001 2003 2005 1981 1983 1985 1987 1989 2007 2009
Gap IC capacity
100 10 1
Productivity (K) Trans./Staff-Mo.
productivity
0.1 0.01
13
14
Design process model

Waterfall method

Describes order that design steps are processed

Behavior description step Behavior to structure conversion step Mapping structure to physical implementation step
Waterfall design model Behavioral Structural Physical
Not very realistic

Bugs often found in later steps that must be fixed in earlier step
E.g., forgot to handle certain input condition
Waterfall model
Proceed to next step only after current step completed
Prototype often needed to know complete desired behavior

E.g, customer adds features after product demo
Waterfall design model Behavioral Structural Physical
Spiral design model Structural Behavioral
System specifications commonly change

E.g., to remain competitive by reducing power, size
Certain features dropped
Spiral model
Proceed through 3 steps in order but with less detail Repeat 3 steps gradually increasing detail Keep repeating until desired system obtained Becoming extremely popular (hardware & software development)
Unexpected iterations back through 3 steps cause missed deadlines

Physical
Lost revenues May never make it to market

15 16
Spiral method
First iteration of 3 steps incomplete Much faster, though
End up with prototype
Use to test basic functions Get idea of functions to add/remove

Modelling embedded systems

Describing embedded systems processing behavior

Can be extremely difficult
Complexity increasing with increasing IC capacity
Spiral design model Structural Behavioral
Original iteration experience helps in following iterations of 3 steps
Must come up with ways to obtain structure and physical implementations quickly
E.g., FPGAs for prototype
silicon for final product
Past: washing machines, small games, etc. Hundreds of lines of code Today: TV set-top boxes, Cell phone, etc. Hundreds of thousands of lines of code
Desired behavior often not fully understood in beginning

Many implementation bugs due to description mistakes/omissions
Physical
May have to use more tools

Extra effort/cost
Could require more time than waterfall method

If correct implementation first time with waterfall
English (or other natural language) common starting point

Precise description difficult to impossible Example: Motor Vehicle Code thousands of pages long...
17
18
Models and languages How can we (precisely) capture behavior?

Models vs. languages

We may think of languages (C, C++), but computation model is the key
Poetry
Recipe
Story
Models
State machine
Sequent. program
Dataflow
Common computation models:

Sequential program model
Statements, rules for composing statements, semantics for executing them
Languages
English Spanish Japanese C C++ Java
Recipes vs. English
Sequential programs vs. C
Communicating process model

Multiple sequential programs running concurrently
Computation models describe system behavior

Conceptual notion, e.g., recipe, sequential program Concrete form, e.g., English, C E.g., sequential program model C,C++, Java E.g., C++ ? sequential program model, object-oriented model, state machine model
State machine model

For control dominated systems, monitors control inputs, sets control outputs
Languages capture models Variety of languages can capture one model One language can capture variety of models
Dataflow model
For data dominated systems, transforms input data streams into output streams
Object-oriented model
For breaking complex software into simpler, well-defined pieces
19
Certain languages better at capturing certain computation models

20
Finite-state machine (FSM) model

Concurrent process model

UnitControl process using a state machine

req > floor
ConcurrentProcessExample() { x = ReadX() y = ReadY() Call concurrently: PrintHelloWorld(x) and PrintHowAreYou(y) } PrintHelloWorld(x) { while( 1 ) { print "Hello world." delay(x); } } PrintHowAreYou(x) { while( 1 ) { print "How are you?" delay(y); } }
Describes functionality of system in terms of two or more concurrently executing subtasks Many systems easier to describe with concurrent process model because inherently multitasking E.g., simple example:
Read two numbers X and Y Display Hello world. every X seconds Display How are you? every Y seconds
u,d,o, t = 1,0,0,0
GoingUp req > floor
!(req > floor) timer < 10 !(timer < 10)
u,d,o,t = 0,0,1,0 Idle req == floor req < floor
DoorOpen u,d,o,t = 0,0,1,1
More effort would be required with sequential program or state machine model
Enter X: 1 Enter Y: 2 Hello world. Hello world. How are you? Hello world. How are you? Hello world. ...
u,d,o,t = 0,1,0,0
!(req<floor) GoingDn u is up, d is down, o is open req < floor t is timer_start
PrintHelloWorld
Simple concurrent process example
ReadX
ReadY PrintHowAreYou time
(Time (Time (Time (Time (Time (Time
= = = = = =
1 2 2 3 4 4
s) s) s) s) s) s)
Subroutine execution over time
Sample input and output
21
22
Dataflow model
Derivative of concurrent process model Nodes represent transformations
May execute concurrently

Role of appropriate model and language

Z = (A + B) * (C - D)
Finding appropriate model to capture embedded system is an important step

Model shapes the way we think of the system
Originally thought of sequence of actions, wrote sequential program
First wait for requested floor to differ from target floor Then, we close the door Then, we move up or down to the desired floor Then, we open the door Then, we repeat this sequence
Edges represent flow of tokens (data) from one node to another

May or may not have token at any given time
B C
+ t1 t2 *
When all of nodes input edges have at least one token, node may fire When node fires, it consumes input tokens processes transformation and generates output token Nodes may fire simultaneously Several commercial tools support graphical languages for capture of dataflow model
Can automatically translate to concurrent process model for implementation Each node becomes a process
Nodes with arithmetic transformations

A B C D
To create state machine, we thought in terms of states and transitions among states
When system must react to changing inputs, state machine might be best model
modulate t1 t2
convolve
Language should capture model easily

Ideally should have features that directly capture constructs of model Other factors may force choice of different model
Structured techniques can be used instead E.g., Template for state machine capture in sequential program language
transform
Nodes with more complex transformations
23
24
Implementation

Concurrent processes
Consider two examples having separate tasks running independently but sharing data Difficult to write system using sequential program model Concurrent process model easier
Separate sequential programs (processes) for each task Programs communicate with each other

Mapping of systems functionality onto hardware processors:

captured using computational model(s) written in some language(s)
State machine Sequent. program Dataflow Concurrent processes
The choice of computational model(s) is based on whether it allows the designer to describe the system.
Heartbeat Monitoring System

B[1..4]
Task 1: Read pulse If pulse < Lo then Activate Siren If pulse > Hi then Activate Siren Sleep 1 second Repeat Task 2: If B1/B2 pressed then Lo = Lo +/ 1 If B3/B4 pressed then Hi = Hi +/ 1 Sleep 500 ms Repeat
Heart-beat pulse
Implementation choice independent from language(s) choice Implementation choice based on power, size, performance, timing and cost requirements Final implementation tested for feasibility
Also serves as blueprint/prototype for mass manufacturing of final product
Pascal
C/C++
Java
VHDL
The choice of language(s) is based on whether it captures the computational model(s) used by the designer.
Set-top Box
Task 1: Read Signal Separate Audio/Video Send Audio to Task 2 Send Video to Task 3 Repeat Task 2: Wait on Task 1 Decode/output Audio Repeat Task 3: Wait on Task 1 Decode/output Video Repeat
Implementation A
Implementation B
Implementation C
The choice of implementation is based on whether it meets power, size, performance and cost requirements.
Video
Input Signal
Audio
25
26
Communication among processes Processes need to communicate data and signals to solve their computation problem
Processes that dont communicate are just independent programs solving separate problems

Concurrent process model: implementation

Basic example: producer/consumer

Process A produces data items, Process B consumes them E.g., A decodes video packets, B display decoded packets on a screen
processA() { // Decode packet // Communicate packet to B } }
Process1 Process2 (a) Process3 Process4
Processor B Processor C Processor D
True multitasking (parallel processing) General-purpose processors

Use programming language like C and compile to instructions of processor Expensive and in most cases not necessary
(b) Process1
Decoded video packets

void processB() { // Get packet from A // Display packet }
Process2 Process3 Process4 General Purpose Processor
Custom single-purpose processors

More common
Processor A Process1 Process2 (c) Process3 Process4 General Purpose Processor
Two basic methods

Shared memory Message passing
To display
Most processes dont use 100% of processor time Can share processor time and still achieve necessary execution rates Multiple processes run on one general-purpose processor while one or more processes run on own single_purpose processor
(c) Combination of (a) and (b)
Important mechanisms: Mutual exclusion, Synchronization => Deadlocks!

27
Communication Bus
How do we achieve this communication?
(b) One general-purpose processor running all processes
Communication Bus
Encoded video packets
Can use single and/or general-purpose processors (a) Multiple processors, each executing one process
Processor A
28
Three key embedded system technologies

Processor technology

Technology
A manner of accomplishing a task, especially using technical processes, methods, or knowledge
The architecture of the computation engine used to implement a systems desired functionality Processor does not have to be programmable
Processor not equal to general-purpose processor
Controller Control logic and State register Datapath Register file General ALU Controller Control logic and State register Datapath Registers Custom ALU Controller Control logic State register Datapath index total +
Three key technologies for embedded systems

Processor technology IC technology Design technology
IR
PC
IR
PC Data memory Data memory
Program memory Assembly code for:
Data memory
Program memory Assembly code for: total = 0 for i =1 to Application-specific Single-purpose (hardware)
total = 0 for i =1 to General-purpose (software)
29
30
IC technology

Design Technology

The manner in which a digital (gate-level) implementation is mapped onto an IC

IC: Integrated circuit, or chip IC technologies differ in their customization to a design ICs consist of numerous layers (perhaps 10 or more)
IC technologies differ with respect to who builds each layer and when
The manner in which we convert our concept of desired system functionality into an implementation
Compilation/ Synthesis Compilation/Synthesis: Automates exploration and insertion of implementation details for lower level. System specification System synthesis Libraries/ IP Hw/Sw/ OS Test/ Verification Model simulat./ checkers
Types: Full-custom/VLSI, Semi-custom ASIC (gate array and standard cell), PLD (Programmable Logic Device)
Behavioral specification Libraries/IP: Incorporates predesigned implementation from lower abstraction level into higher level.
Behavior synthesis
Cores
Hw-Sw cosimulators
RT specification
RT synthesis
RT components
HDL simulators
Test/Verification: Ensures correct functionality at each level, thus reducing costly iterations between levels. IC package IC source gate oxide channel
Logic specification
Logic synthesis
Gates/ Cells
Gate simulators
drain Silicon substrate
To final implementation
31
32
The co-design ladder

Independence of processor and IC technologies Basic tradeoff

In the past:
Hardware and software design technologies were very different Recent maturation of synthesis enables a unified view of hardware and software
Sequential program code (e.g., C, VHDL) Compilers (1960's,1970's) Assembly instructions Assemblers, linkers (1950's, 1960's) Machine instructions Behavioral synthesis (1990's) Register transfers RT synthesis (1980's, 1990's) Logic equations / FSM's Logic synthesis (1970's, 1980's) Logic gates
General vs. custom With respect to processor technology or IC technology The two technologies are independent
General, providing improved: Flexibility Maintainability NRE cost Time- to-prototype Time-to-market Cost (low volume)
Generalpurpose processor
ASIP
Singlepurpose processor
Customized, providing improved: Power efficiency Performance Size Cost (high volume)
Hardware/software codesign
Microprocessor plus program bits: software
Implementation
VLSI, ASIC, or PLD implementation: hardware
The choice of hardware versus software for a particular function is simply a tradeoff among various design metrics, like performance, power, size, NRE cost, and especially flexibility; there is no fundamental difference between what hardware or software can implement.
PLD
Semi-custom
Full-custom
33
34
Design technology Design task

Improving productivity

Define system functionality Convert functionality to physical implementation while

Satisfying constrained metrics Optimizing other design metrics
Design technologies developed to improve productivity We focus on technologies advancing hardware/software unified view
Automation
Program replaces manual design Synthesis
Automation Specification
Designing embedded systems is hard

Complex functionality
Millions of possible environment scenarios Competing, tightly constrained metrics
Reuse
Verification
Implementation
Reuse
Productivity gap
As low as 10 lines of code or 100 transistors produced per day
Predesigned components Cores General-purpose and single-purpose processors on single IC
Verification
Ensuring correctness/completeness of each design step Hardware/software co-simulation
35
36
Automation: synthesis

Gajskis Y-chart

Early design mostly hardware Software complexity increased with advent of general-purpose processor Different techniques for software design and hardware design
Caused division of the two fields
The codesign ladder

Sequential program code (e.g., C, VHDL) Behavioral synthesis (1990s) Register transfers Assembly instructions RT synthesis (1980s, 1990s) Logic equations / FSM's Assemblers, linkers (1950s, 1960s) Logic synthesis (1970s, 1980s) Logic gates Implementation VLSI, ASIC, or PLD implementation
Each axis represents type of description

Behavioral
Defines outputs as function of inputs Algorithms but no implementation
Structural Behavior Sequential programs Register transfers Logic equations/FSM Transfer functions Cell Layout Modules Chips Boards Physical Processors, memories Registers, FUs, MUXs Gates, flip-flops Transistors
Structural
Design tools evolve for higher levels of abstraction

Different rate in each field
Compilers (1960s,1970s)
Implements behavior by connecting components with known behavior
Physical
Gives size/locations of components and wires on chip/board
Hardware/software design fields rejoining

Both can start from behavioral description in sequential program model 30 years longer for hardware design to reach this step in the ladder
Many more design dimensions Optimization critical
Synthesis converts behavior at given level to structure at same level or lower

E.g.,
FSM ? gates, flip-flops (same level) FSM ? transistors (lower level) FSM X registers, FUs (higher level) FSM X processors, memories (higher level)
Machine instructions Microprocessor plus program bits
37
38
Verification Ensuring design is correct and complete

Correct
Implements specification accurately

Advantages over physical implementation Controllability

Control time
Stop/start simulation at any time

Complete
Describes appropriate output to all relevant input
Control data values

Inputs or internal values
Formal verification
Hard For small designs or verifying certain key properties only
Observability
Examine system/environment values at any time
Debugging
Can stop simulation at any point and:
Observe internal values Modify system/environment values before restarting
Simulation
Most common verification method
Can step through small intervals (i.e., 500 nanoseconds)
39
40
Disadvantages

Simulation speed

Simulation setup time

Often has complex external environments Could spend more time modeling environment than system
Relative speeds of different types of simulation/emulation

1 hour actual execution of SOC
= 1.2 years instruction-set simulation = 10,000,000 hours gate-level simulation
1 10 100 1000 IC FPGA 1 hour 1 day 4 days 1.4 months
Models likely incomplete

Some environment behavior undocumented if complex environment May not model behavior correctly
Simulation speed much slower than actual execution

Sequentializing parallel design
IC: gates operate in parallel Simulation: analyze inputs, generate outputs for each gate 1 at time
Several programs added between simulated system and real hardware

1 simulated operation:
= 10 to 100 simulator operations = 100 to 10,000 operating system operations = 1,000 to 100,000 hardware operations
hardware emulation throughput model
instruction-set simulation 1.2 years 10000 cycle-accurate simulation 12 years 100,000 register-transfer- level HDL simulation >1 lifetime 1,000,000 gate- level HDL simulation 1 10,000,000 millennium
41
42
Emulators
General physical device system mapped to
Microprocessor emulator
Microprocessor IC with some monitoring, control circuitry

Reuse: intellectual property cores

Commercial off-the-shelf (COTS) components

Predesigned, prepackaged ICs Implements GPP or SPP Reduces design/debug time Have always been available
SPP emulator
FPGAs (10s to 100s)
Usually supports debugging tasks
Created to help solve simulation disadvantages

Mapped relatively quickly
Hours, days
System-on-a-chip (SOC)
All components of system implemented on single chip Made possible by increasing IC capacities Changing the way COTS components sold
As intellectual property (IP) rather than actual IC
Behavioral, structural, or physical descriptions Processor-level components known as cores
Can be placed in real environment

No environment setup time No incomplete environment
Typically faster than simulation

Hardware implementation
www.raptor2000.de
SOC built by integrating multiple descriptions
43
44
Summary

Summary

Embedded systems are everywhere Key challenge: optimization of design metrics

Design metrics compete with one another
State machine models good for control Concurrent process model for multi-task systems
Communication and synchronization methods exist Scheduling is critical
A unified view of hardware and software is necessary to improve productivity Three key technologies
Processor: general-purpose, application-specific, single-purpose IC: Full-custom, semi-custom, PLD Design: Compilation/synthesis, libraries/IP, test/verification
Computation models are distinct from languages Sequential program model is popular
Most common languages like C support it directly
Dataflow model good for signal processing Design technology seeks to reduce gap between IC capacity growth and designer productivity growth Synthesis has changed digital design Increased IC capacity means sw/hw components coexist on one chip Design paradigm shift to core-based design Simulation essential but hard Spiral design process is popular
45 46

Entwurf Von Eingebetteten Systemen

Uploaded by

Document Information

Original Description:

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Entwurf Von Eingebetteten Systemen

Uploaded by

Copyright:

Available Formats

HEINZ NIXDORF INSTITUTE

HEINZ NIXDORF INSTITUTE

HEINZ NIXDORF INSTITUTE

An introduction to embedded systems design

HEINZ NIXDORF INSTITUTE

Embedded systems overview

HEINZ NIXDORF INSTITUTE

Embedded computing systems

A short list of embedded systems And the list goes on and on

HEINZ NIXDORF INSTITUTE

Some common characteristics of embedded systems

HEINZ NIXDORF INSTITUTE

Reactive and real-time

An embedded system example -- a digital camera

HEINZ NIXDORF INSTITUTE

Design challenge optimizing design metrics

HEINZ NIXDORF INSTITUTE

Obvious design goal:

Construct an implementation with desired functionality

Key design challenge:

ISA bus interface

Design challenge optimizing design metrics

HEINZ NIXDORF INSTITUTE

Design challenge optimizing design metrics

HEINZ NIXDORF INSTITUTE

Common metrics (continued)

NRE cost (Non-Recurring Engineering cost): The one-time

Time-to-market: the time required to develop a system to the point

Design metric competition -- improving one may worsen others

HEINZ NIXDORF INSTITUTE

The performance design metric

HEINZ NIXDORF INSTITUTE

Widely-used measure of system, widely-abused

Latency (response time)

Speedup of B over S = Bs performance / As performance

Multiplier/Accum Display ctrl

ISA bus interface

HEINZ NIXDORF INSTITUTE

Design productivity gap

HEINZ NIXDORF INSTITUTE

The most important trend in embedded systems

Logic transistors per chip (in millions) Note: logarithmic scale

100 10 1 0.1 0.01 0.001

Logic transistors per chip (in millions)

100 10 1 0.1 0.01 0.001

Productivity (K) Trans./Staff-Mo.

Design process model

HEINZ NIXDORF INSTITUTE

HEINZ NIXDORF INSTITUTE

Describes order that design steps are processed

Waterfall design model Behavioral Structural Physical

Not very realistic

Prototype often needed to know complete desired behavior

Waterfall design model Behavioral Structural Physical

Spiral design model Structural Behavioral

System specifications commonly change

Unexpected iterations back through 3 steps cause missed deadlines

Lost revenues May never make it to market

HEINZ NIXDORF INSTITUTE

Modelling embedded systems

HEINZ NIXDORF INSTITUTE

Describing embedded systems processing behavior

Original iteration experience helps in following iterations of 3 steps