Introduction to embedded system design

INTRODUCTION TO EMBEDDED
SYSTEM DESIGN
Mukesh Kumar
mkb@genericembedded.com
www.genericembedded.com
www genericembedded com

Agenda (1)
• Introduction to Embedded System Design
– General Introduction to Embedded Systems
General Introduction to Embedded Systems
– Hardware Platforms and Components
• System Specialization
y p
• Application Specific Instruction Sets
– Micro Controller
– Di i l Si l P
Digital Signal Processors and VLIW
d VLIW
– Programmable Hardware
– ASICs

Agenda (2)
Agenda (2)
• Challenges in embedded system design
Challenges in embedded system design
• Dependability, efficiency, …
– Design flows
Design flows
– Requirements for specification techniques
– Models of computation
Models of computation
• Local model
• Communication

What is Embedded System?..
y
Embedded systems (ES) information
Embedded systems (ES) = information
processing systems embedded into a larger
product
An embedded system is a computer system
designed to do one or a few dedicated and/or
specific functions often with real‐time
computing constraints. It is embedded as part
of a complete device often including hardware
f l d i f i l di h d
and mechanical parts.

What is Embedded System?..2
What is Embedded System?..2

Application areas (1)
• Automotive electronics

• Avionics

• Trains

• Telecommunication

Application areas (2)
• Robotics

Examples of Embedded Systems
• Car as an integrated control, communication
and information system.
di f i

Consumer electronics, for example MP3 Audio,
digital camera, home electronics, … .

Information systems, for example wireless
communication (mobile phone, Wireless LAN,
communication (mobile phone, Wireless LAN,
…), end‐user equipment, router, …

Communicating Embedded Systems
• Example: BTnodes http://www.btnode.ethz.ch)
– complete platform including OS
– especially suited for pervasive computing applications

Communicating Embedded Systems
• sensor networks (civil engineering, buildings, environmental
monitoring, traffic, emergency situations)
• smart products, wearable/ubiquitous computing
/

Characteristics of Embedded Systems (1)
• Must be dependable:
– Reliability: R(t) = probability of system working correctly
provided that is was working at t=0
– Maintainability: M(d) = probability of system working
correctly d time units after error occurred.
correctly d time units after error occurred
– Availability: probability of system working at time t
– Safety: no harm to be caused
Safety: no harm to be caused
– Security: confidential and authentic communication

Even perfectly designed systems can fail if the assumptions about the
workload and possible errors turn out to be wrong. Making the system
dependable must not be an after‐thought, it must be considered from
the very beginning
beginning.

• Must be efficient:
– Energy efficient
– Code‐size efficient (especially for systems on a chip)
– Run‐time efficient
– Weight efficient
Weight efficient
– Cost efficient

• D di
Dedicated towards a certain application: Knowledge
d d i li i K l d
about behavior at design time can be used to
minimize resources and to maximize robustness.
• Dedicated user interface (no mouse, keyboard and
screen).

• Many ES must meet real‐time constraints:
– A real-time system must react to stimuli from
the controlled object (or the operator) within the
time interval dictated by the environment.
– For real‐time systems, right answers arriving too late
(or even too early) are wrong.
(or even too early) are wrong
• “A real‐time constraint is called hard, if not
meeting thatconstraint could result in a
g
catastrophe”[Kopetz, 1997].
• All other time‐constraints are called soft.
• A guaranteed system response has to be
explained without statistical arguments.

• Frequently connected to physical environment
through sensors and actuators,
• Hybrid systems (analog + digital parts).
• Typically, ES are reactive systems:
• “A reactive system is one which is in continual
interaction with is environment and executes at
a pace determined by that environment“
d i db h i “
[Bergé, 1995]
• B h i d
Behavior depends on input and current state.
d i t d t t t
– automata model often appropriate,

Comparison
Embedded Systems General Purpose Computing
• Few applications that are known
F li i h k • Broad class of applications.
B d l f li i
at design‐time.
• Not programmable by end user. • Programmable by end user.
• Fixed run‐time equirements • Faster is better.
(additional computing power not
useful).
• Criteria:
• Criteria:
– cost
– cost
– average speed
– power consumption
– predictability
– …

Agenda
• General Introduction to Embedded Systems
• Hardware Platforms and Components
–S t
System Specialization
S i li ti
– Application Specific Instruction Sets
• Mi
Micro Controller
C ll
• Digital Signal Processors and VLIW
Programmable Hardware
– ASICs

Embedded System Hardware
• Embedded system hardware is frequently
used in a loop ( hardware in a loop ):
used in a loop (“hardware in a loop”):

Agenda
– System Specialization
• Mi
Micro Controller
C ll
Programmable Hardware
– ASICs

General‐purpose Processors
• High performance
– Highly optimized circuits and technology
– Use of parallelism
• superscalar: dynamic scheduling of instructions
• super‐pipelining: instruction pipelining, branch prediction,
speculation
– complex memory hierarchy
• Not suited for real‐time applications
f pp
– Execution times are highly unpredictable because of
intensive resource sharing and dynamic decisions
• Properties
– Good average performance for large application mix
– High power consumption

• The main difference between general purpose highest
volume microprocessors and embedded systems is
p y
specialization.
• Specialization should respect flexibility
– application domain specific systems shall cover a class of
application domain specific systems shall cover a class of
applications
– some flexibility is required to account for late changes,
debugging
• System analysis required
– identification of application properties which can be
used for specialization
df i li ti
– quantification of individual specialization effects

Example: Code‐size Efficiency
• CISC machines: RISC machines designed for run‐
time, not for code size efficiency.
time, not for code‐size‐efficiency.
• Compression techniques: key idea

Example: Heterogeneous registers

Example: Multiple memory banks or memories

Agenda
• Mi
Micro Controller
C t ll
–PProgrammable Hardware
bl H d
– ASICs

Microcontroller
• control‐dominant applications
– supports process scheduling and
synchronization
– preemption (interrupt),context
switch
it h
– short latency times
• low power consumption
• peripheral units often
integrated
• suited for real‐time
applications

Control Dominated Systems
• Reactive systems with event driven behavior
• Underlying semantics of system description (“input
model of computation”) typically (coupled) Finite
State Machines

Agenda
• Micro Controller
Micro Controller
– ASICs

Digital Signal Processor
• optimized for data‐flow applications
• suited for simple control flow
• parallel hardware
ll l h d
units (VLIW)
• specialized
specialized
instruction set
• high data throughput
• zero‐overhead loops
• specialized memory
• suited for real‐time
df l
applications

MAC (multiply & accumulate)

Data Dominated Systems
• Streaming oriented systems with mostly
periodic behavior
• Underlying semantics of input description e.g.
flow graphs (“input model of computation”)

• Application examples: signal processing,
control engineering
g g

Very Long Instruction Word (VLIW)
• Key idea: detection of possible parallelism to be done
by compiler, not by hardware at run‐time (inefficient).
• VLIW: parallel operations (instructions) encoded in
one long word (instruction packet), each instruction
controlling one functional unit. E.g.:
controlling one functional unit E g :

Example: Philips TriMedia TM1000

Agenda
Micro Controller
bl d
– ASICs

FPGA – Basic Structure
• Logic Units
• I/O Units
• Connections

FPGA ‐ Classification
• Granularity of logic units:
– Gate, tables, memory, functional blocks (ALU,
control, data path, processor)
• Communication network:
– Crossbar, hierarchical mesh, tree
• Reconfiguration:
– fixed at production time, once at design time,
p , g ,
dynamic during run‐time

Floor‐plan of VIRTEX II FPGAs

Agenda
Micro Controller
–PProgrammable Hardware
bl H d
– ASICs

Application Specific Circuits (ASICS)

• Custom‐designed circuits
necessary
– if ultimate speed or
– energy efficiency is the goal and
energy efficiency is the goal and
– large numbers can be sold.
• Approach suffers from
–llong design times,
d i i
– lack of flexibility
(
(changing standards) and
g g )
– high costs
(e.g. Mill. $ mask costs).

Agenda (2)
Agenda (2)
– Design flows
Design flows
– Structure of this course
Requirements for specification techniques
• L l
Local model
d l
• Communication

Quite a number of challenges, e.g.
dependability
• Dependability?
– Non‐real time protocols used for real‐time applications
(e.g. Berlin fire department)

– Over‐simplification of models
(e.g. aircraft anti‐collision system)

– Using unsafe systems for safety‐critical missions
(e.g. voice control system in Los Angeles; ~ 800
planes without voice connection to tower for > 3 hrs
l h f h

It is not sufficient to consider ES
just as a special case of software engineering
just as a special case of software engineering
EE knowledge must be available,
Walls between EE and CS must be torn down

CS EE

The same for walls to other disciplines and more challenges ….

Hypothetical design flow

Specification Design repository Design
nowledge
plication Kn

ES‐hardware Test *
Application mapping

System software
System software * Could be
Could be
App

Optimization
O ti i ti
(RTOS, middleware, integrated
Evaluation & Validation into loop
…) (energy, cost, performance,
…)
)

Generic loop: tool chains differ in the number and type of iterations
e e c oop oo c a s d e e u be a d ype o e a o s

Iterative design (1)
‐ After unrolling loop ‐
After unrolling loop

• Example:
• SpecC
SpecC
• tools

Iterative design (2)
‐ After unrolling loop ‐
• Example: V‐model
Requirement
analysis System
architecture System
System
design Software
architecture
Software
design
Unit
Integration tests
System testing
integration
Acceptance
& use
Skipping some explicit
repository updates ..

Hypothetical design flow

2: Specification Design repository Design
owledge
Application Kno

3: ES‐hardware 8. Test *
6: Application
mapping
4: System software
4: System software 7: Optimization
7 O ti i ti * Could be
Could be
(RTOS, middleware, integrated
5: Evaluation & Validation into loop
…) (energy, cost, performance,
…)
)

Numbers denote sequence of chapters

Motivation for considering specs
Motivation for considering specs

– Why considering specs?
– If something is wrong with the specs then it
If something is wrong with the specs, then it
will be difficult to get the design right,
potentially wasting a lot of time.
– Typically, we work with models of the
system under design (SUD)
What is a model anyway?

Models
• Definition: A model is a simplification of another entity,
which can be a physical thing or another model. The model
which can be a physical thing or another model. The model
contains exactly those characteristics and properties of the
modeled entity that are relevant for a given task. A model
• is minimal with respect to a task if it does not contain any
is minimal with respect to a task if it does not contain any
other characteristics than those relevant for the task.

[Jantsch, 2004]:

Which requirements do we have for our models?

Requirements for specification techniques:
Hierarchy

• Hierarchy
Humans not capable to understand systems
containing more than ~5 objects.
Most actual systems require more objects
Hierarchy
proc
– Behavioral hierarchy proc
Examples: states, processes, procedures. proc

– Structural hierarchy
Examples: processors, racks,
p
printed circuit boards

Requirements for specification techniques (2):
Component based design
Component‐based design

– Systems must be designed from
components
– Must be “easy” to derive behavior from
behavior of subsystems
Work of Sifakis, Thiele, Ernst, …

Concurrency
Synchronization and communication

Timing
Ti i

– Timing behavior
Essential for embedded and cy‐phy systems!
• Additional information (periods, dependences,
scenarios, use cases) welcome
• Also the speed of the underlying platform must be
Also, the speed of the underlying platform must be
known
• Far‐reaching consequences for design processes!

“The lack of timing in the core abstraction (of computer science) is a flaw, from the
perspective of embedded software” [Lee, 2005]

Timing (2)
Ti i (2)
• 4 types of timing specs required, according to Burns, 1990:

1. Measure elapsed time
Check, how much time has elapsed since last call

? execute
t

2. Means for delaying processes

t

Requirements for specification techniques (3)
Timing (3)
Ti i (3)
3. Possibility to specify timeouts
Stay in a certain state a maximum time.
Stay in a certain state a maximum time

4. Methods for specifying deadlines
Not available or in separate control file.

execute
t

Specification of embedded systems (4):
Support for designing reactive systems
Support for designing reactive systems

– State‐oriented behavior
Required for reactive systems;
classical automata insufficient.
– Event‐handling
(external or internal events)
– Exception‐oriented behavior We will see, how all the
Not acceptable to describe arrows labeled k can be
replaced by a single one.
p y g
exceptions for every state
exceptions for every state

Requirements for specification
techniques (5)
techniques (5)
– Presence of programming elements
– Executability (no algebraic specification)
y( g p )
– Support for the design of large systems ( OO)
– Domain‐specific support
– Readability
R d bilit
– Portability and flexibility
– Termination
– Support for non‐standard I/O devices
– Non‐functional properties
– Support for the design of dependable systems
S t f th d i fd d bl t
– No obstacles for efficient implementation
– Adequate model of computation
q p
What does it mean “to compute”?


• What does it mean, “to compute”?
• Models of computation define:
C‐1
– Components and an execution model for
computations for each component
– Communication model for exchange of
Communication model for exchange of C‐2
information between components.

Communication
Shared memory
y

Comp‐1 memory Comp‐2

Variables accessible to several components/tasks.

Model mostly restricted to local systems.

Shared memory
Shared memory
• Potential race conditions ( inconsistent results possible)
Critical sections = sections at which exclusive access to
Critical sections = sections at which exclusive access to
resource r (e.g. shared memory) must be guaranteed.

task a { task b { Race‐free access to shared
.. .. memory protected by S
P(S)  //obtain lock P(S)  //obtain lock possible
..    // critical section ..    // critical section
V(S)  //release lock V(S)  //release lock
} }

P(S) and V(S) are semaphore operations,
allowing at most n accesses, n =1 in this case (mutex, lock)

Non‐blocking/asynchronous
message passing
message passing
• Sender does not have to wait until message has arrived;

… …
send () receive ()
… …

Potential problem: buffer overflow

Blocking/synchronous message passing
rendez‐vous
d

• Sender will wait until receiver has received message

… …
send () receive ()
… …

No buffer overflow, but reduced performance.

Agenda (2)
Agenda (2)
– Design flows
Design flows
• Local model
• Communication

• Testing

Test: Goals
Test: Goals

1. Production test
2. Is there any way of using test patterns for production
2 I th f i t t tt f d ti
test already during the design?
3. Test for faults after delivery to customer
3 T t f f lt ft d li t t

Why is testing of embedded
systems difficult?
– Embedded/cyber physical systems integrated into a
Embedded/cyber‐physical systems integrated into a
physical environment may be safety‐critical. As a
result, expectations for the product quality are
higher than for non‐safety critical systems.
h h h f f l
– Testing of timing‐critical systems has to validate the
correct timing behavior. This means that just testing
the functional behavior is not sufficient.
– Testing embedded/cyber‐physical systems in their
real environment may be dangerous.

Scope
Testing includes
the application of test patterns to the inputs of the
device under test (DUT) and
the observation of the results.
the observation of the results

More precisely, testing requires the following steps:
p y, g q g p
1. test pattern generation,
2. test pattern application,
3. response observation, and
4. result comparison.

Fault models and test pattern
generation
• T
Test pattern generation typically
i i ll
considers certain fault models and
generates patterns that enable a distinction
between the faulty and the fault‐free case.
Examples:
• Boolean differences
• D‐Algorithm
• Self‐test programs

Stuck at fault model
Stuck‐at fault model
• Hardware fault model:
• Net permanently connected to ground or Vdd
– Simplification of the real situation
– Nevertheless useful in many cases
• Example: Stuck‐at‐1at port p
Stuck‐at‐1at port p

Other Hardware fault models
Other Hardware fault models
Fault models include:
stuck‐open faults:
stuck open faults:
for CMOS, open
transistors can
behave like
behave like
memories www.cedcc.psu.edu/ee497f

/rassp_43/sld022.htm

delay faults: circuit is
functionally correct,
but the delay is not.
but the delay is not.

The D‐algorithm: a simple example
no error error
0
p 0 /1
0 1/0
1/0
1
1
1

• Could we check for a stuck at one error at port p (s‐a‐1(p)) ?
• Solution (just guessing):
Solution (just guessing):
– Signal f='1' if there is an error
– a='0', b='0' in order to have f='0' if there is no error
– g= 1 in order to propagate error
g='1' in order to propagate error
– c='1' in order to have g='1' (or set d='1') Symbolic values D
– e='1' in order to propagate error and D are assigned to
signals f, h and i
– i= 1 if there is no error & i='0' if there is
i='1' if there is no error & i= 0 if there is

Generation of Self‐Test Program Generation
‐ Key concept ‐
y p

1. Store pattern of all ‘1’s in the register file
2. Perform xor between register and constant “00..0";
3. Test if result contains ‘0’ bit
4. If yes, report error;
5. Otherwise start test for next fault;
Otherwise start test for next fault;
Exmaple: checksum matching.

Software fault injection
Software fault injection
• Errors are injected into the memories.
j
• Advantages:
– Predictability: it is possible to reproduce every injected
it is possible to reproduce every injected
fault in time and space.
– Reachability: possible to reach storage locations within
y p g
chips instead of just pins.
– Less effort than physical fault injection: no modified
hardware.
hard are
Same quality of results?

References:
• “Embedded System Design” Book and
Embedded System Design Book and
Lecture of Peter Marwedel
• “Hard Real Time Computing Systems” Book
Hard Real‐Time Computing Systems Book
of Giorgio Buttazzo.
• “E b dd d S
“Embedded System Design : A unified
D i A ifi d
Hardware/software introduction”
Vahid/Givargis
V hid/Gi i

Introduction to embedded system design

Recommended

Recommended

More Related Content

What's hot

What's hot (20)

Viewers also liked

Viewers also liked (19)

Similar to Introduction to embedded system design

Similar to Introduction to embedded system design (20)

Recently uploaded

Recently uploaded (20)

Introduction to embedded system design