1. INTRODUCTION TO EMBEDDED
SYSTEM DESIGN
Mukesh Kumar
mkb@genericembedded.com
www.genericembedded.com
www genericembedded com
2. 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
3. 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
4. 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.
15. 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.
16. Characteristics of Embedded Systems (2)
• 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).
17. Characteristics of Embedded Systems (3)
• 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.
18. Characteristics of Embedded Systems (4)
• 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,
19. 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
– …
20. Agenda
• General Introduction to Embedded Systems
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
Programmable Hardware
– ASICs
23. Agenda
• General Introduction to Embedded Systems
General Introduction to Embedded Systems
• Hardware Platforms and Components
– System Specialization
System Specialization
– Application Specific Instruction Sets
• Mi
Micro Controller
C ll
• Digital Signal Processors and VLIW
– Programmable Hardware
Programmable Hardware
– ASICs
25. 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
27. System Specialization
• 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
31. Agenda
• General Introduction to Embedded Systems
General Introduction to Embedded Systems
• Hardware Platforms and Components
– System Specialization
System Specialization
– Application Specific Instruction Sets
• Mi
Micro Controller
C t ll
• Digital Signal Processors and VLIW
–PProgrammable Hardware
bl H d
– ASICs
32. 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
34. Agenda
• General Introduction to Embedded Systems
General Introduction to Embedded Systems
• Hardware Platforms and Components
– System Specialization
System Specialization
– Application Specific Instruction Sets
• Micro Controller
Micro Controller
• Digital Signal Processors and VLIW
– Programmable Hardware
– ASICs
40. Agenda
• General Introduction to Embedded Systems
General Introduction to Embedded Systems
• Hardware Platforms and Components
– System Specialization
System Specialization
– Application Specific Instruction Sets
• Micro Controller
Micro Controller
• Digital Signal Processors and VLIW
– Programmable Hardware
bl d
– ASICs
42. 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
44. Agenda
• General Introduction to Embedded Systems
General Introduction to Embedded Systems
• Hardware Platforms and Components
– System Specialization
System Specialization
– Application Specific Instruction Sets
• Micro Controller
Micro Controller
• Digital Signal Processors and VLIW
–PProgrammable Hardware
bl H d
– ASICs
45. 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).
46. Agenda (2)
Agenda (2)
• Challenges in embedded system design
Challenges in embedded system design
• Dependability, efficiency, …
– Design flows
Design flows
– Structure of this course
– Requirements for specification techniques
Requirements for specification techniques
– Models of computation
• L l
Local model
d l
• Communication
47. 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
48. 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 ….
49. 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
50. 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
52. 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 ..
53. 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
54. 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?
55. 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?
56. 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
58. Requirements for specification techniques (3):
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]
59. Requirements for specification techniques (3):
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
61. 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
62. 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”?
63. Models of computation
Models of computation
• 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.
64. Communication
Shared memory
y
Comp‐1 memory Comp‐2
Variables accessible to several components/tasks.
Model mostly restricted to local systems.
65. 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)
68. 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
• Testing
69. 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
70. 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.
71. 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.
72. 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
73. 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
74. 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.
75. 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
76. 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
77. 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.
78. 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?
80. 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