Introductiontoembeddedsystemdesign 111230080657 Phpapp01 PDF

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
– Digital Signal Processors and VLIW
Di i l Si l P 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)
Embedded systems (ES) = information
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
BTnode Platform
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
Dedicated towards a certain
di d d i application: Knowledge
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
g could result in a
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]
• Behavior depends on input and current state.
B h i d d i t d t t t
– automata model often appropriate,
Comparison
Embedded Systems General Purpose Computing
• FFew applications that are known
li i h k • B d l
Broad class of applications.
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
– System Specialization
S t S i li ti
– Application Specific Instruction Sets
• Micro Controller
Mi C ll
• Digital Signal Processors and VLIW
Programmable Hardware
– ASICs
Embedded System Hardware
• Embedded system hardware is frequently
used in a loop (“hardware
used in a loop ( hardware in a loop
in a loop”):
):
Typical Architecture
Agenda
System Specialization
Mi C ll
Programmable Hardware
– ASICs
Implementation Alternatives
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
Pentium P4
• The main difference between general purpose highest
volume microprocessors and embedded systems is
p y
specialization.
• Specialization should respect flexibility
– application
application domain specific systems shall cover a class of
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 C t ll
P 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
– 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
P 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
– long design times,
l 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
• Local model
L l 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 ….
Agenda (2)
Agenda (2)
– Design flows
Design flows
• Local model
• Communication
Hypothetical design flow
Specification Design repository Design

nowledge
plication Kn
ES‐hardware Test *
Application mapping
System software
System software * Could be
Could be
App
O ti i ti
Optimization
(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 O ti i ti
7: Optimization * 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
If something is wrong with the specs, then it
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
Component based design
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
Ti i
Timing
– 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]
Ti i (2)
Timing (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)
Ti i (3)
Timing (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
– R d bilit
Readability
– Portability and flexibility
– Termination
– Support for non‐standard I/O devices
– Non‐functional properties
– S
Support for the design of dependable systems
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 memoryy
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 IIs there any way of using test patterns for production
2. 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
Embedded/cyber‐physical systems integrated into a
physical systems integrated into a
physical environment may be safety‐critical. As a
result, expectations for the product quality are
h h h f
higher than for non‐safety critical systems.
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
• Test pattern generation typically
T 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
Stuck at fault model
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
stuck‐open faults:
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.
Fault models and test pattern
generation
• Test pattern generation typically
T 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
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
– 1 in order to propagate error
g='1'
g= 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
– 1 if there is no error & i=
i='1'
i= if there is no error & i='0'
0 if there is
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:
y p
possible to reach storage locations within
g
chips instead of just pins.
– Less effort than physical fault injection: no modified
hard are
hardware.
Same quality of results?
Th k
Thank you!
!
References:
• “Embedded
Embedded System Design
System Design” Book and
Book and
Lecture of Peter Marwedel
• “Hard
Hard Real‐Time Computing Systems
Real Time Computing Systems” Book
Book
of Giorgio Buttazzo.
• “Embedded System Design : A unified
“E b dd d S D i A ifi d
Hardware/software introduction”
V hid/Gi
Vahid/Givargis
i

Introductiontoembeddedsystemdesign 111230080657 Phpapp01 PDF

Uploaded by

Document Information

Original Title

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

Introductiontoembeddedsystemdesign 111230080657 Phpapp01 PDF

Uploaded by

Copyright:

Available Formats

INTRODUCTION TO EMBEDDED

Specification Design repository Design

2: Specification Design repository Design

“The lack of timing in the core abstraction (of computer science) is a flaw, from the

Comp‐1 memory Comp‐2

task a { task b { Race‐free access to shared

You might also like