TDDD93
Fö “Embedded Systems” - 1
TDDD93
Fö “Embedded Systems” - 2
Information
TDDD93 Large-Scale Distributed Systems and Networks
Lecture notes: available from the course page, latest 24
hours before the lecture.
Lectures on
Embedded Systems
Recommended literature:
Peter Marwedel: "Embedded System Design",
Springer, 2nd edition, 2011.
Petru Eles
Institutionen för Datavetenskap (IDA)
Linköpings Universitet
Wayne Wolf: "Computers as Components. Principles of
Embedded Computing System Design",
Morgan Kaufmann Publishers, 2nd edition,
2008.
email: petel@ida.liu.se
http://www.ida.liu.se/~petel
phone: 28 1396
B building, 329:220
Edward Lee, Sanjit Seshia: “Introduction to Embedded
Systems - A Cyber-Physical Systems
Approach”, LeeSeshia.org, 2011.
Petru Eles, IDA, LiTH
Petru Eles, IDA, LiTH
TDDD93
Fö “Embedded Systems”- 3
TDDD93
That’s how we use microprocessors
Embedded Systems and Their Design
1. What is an Embedded System
2. Characteristics of Embedded Applications
3. Modeling of Embedded systems
4. The Traditional Design Flow
5. An Example
6. A New Design Flow
7. System Level Design
8. Power/Energy Consumption - a Major Issue
Petru Eles, IDA, LiTH
Fö “Embedded Systems”- 4
Petru Eles, IDA, LiTH
TDDD93
Fö “Embedded Systems”- 5
TDDD93
Fö “Embedded Systems”- 6
What is an Embedded System?
What is an Embedded System? (cont’d)
There are several definitions around!
Some of the main characteristics:
☞ Some highlight what it is (not) used for:
“An embedded system is any sort of device which includes a
programmable component but itself is not intended to be a general
purpose computer.”
• Dedicated (not general purpose)
• Contains a programmable component
☞ Some focus on what it is built from:
• Interacts (continuously) with the environment
“An embedded system is a collection of programmable parts
surrounded by ASICs and other standard components, that interact
continuously with an environment through sensors and actuators.”
Petru Eles, IDA, LiTH
Petru Eles, IDA, LiTH
TDDD93
Fö “Embedded Systems”- 7
TDDD93
Fö “Embedded Systems”- 8
Distributed Embedded System (automotive application)
A Look at Two Typical Implementation Architectures
Actuators
Sensors
Telecommunication System on Chip
RF
A/D
&
D/A
DSP core
RAM
High-Speed
DSP Blocks
RISC core
RAM
Control
Logic
Interface
Input/Output
RAM
CPU
LAN
Programmable processor
FLASH
Network Interface
Gateway
ASIC block (Application Specific Integrated Circuit) dedicated
electronics
Standard block
Memory
Gateway
Reconfigurable logic (FPGA)
Petru Eles, IDA, LiTH
Petru Eles, IDA, LiTH
TDDD93
Fö “Embedded Systems”- 9
TDDD93
Fö “Embedded Systems”- 10
The Software Component
Characteristics of Embedded Applications
What makes them special?
Software running on the programmable processors:
• Application tasks
☞ Like with “ordinary” applications, functionality and user interfaces
are often very complex.
• Real-Time Operating System
But, in addition to this:
• Time constraints
• I/O drivers, Network protocols, Middleware
• Power constraints
• Cost constraints
• Safety
• Time to market
Petru Eles, IDA, LiTH
Petru Eles, IDA, LiTH
TDDD93
Fö “Embedded Systems”- 11
TDDD93
Fö “Embedded Systems”- 12
Characteristics of Embedded Applications (cont’d)
Characteristics of Embedded Applications (cont’d)
☞ Power constraints:
☞ Time constraints:
Embedded systems have to perform in real-time: if data is not ready
by a certain deadline, the system fails to perform correctly.
- Hard deadline: failure to meet leads to major hazards.
- Soft deadline: failure to meet can be tolerated but quality of
service is reduced.
There are several reasons why low power/energy consumption is
required:
• Cost aspects:
High power consumption ⇒ strong power supply
expensive cooling system
• Battery life
High energy consumption ⇒ short battery life time
Petru Eles, IDA, LiTH
Petru Eles, IDA, LiTH
TDDD93
Fö “Embedded Systems”- 13
TDDD93
Fö “Embedded Systems”- 14
Characteristics of Embedded Applications (cont’d)
Characteristics of Embedded Applications (cont’d)
☞ Cost constraints: Embedded systems are very often mass products
in highly competitive markets and have to be shipped at a low cost.
☞ Safety critical:
Embedded systems are often used in life critical applications:
avionics, automotive electronics, nuclear plants, medical
applications, military applications, etc.
What we are interested in:
- Manufacturing cost
- Design cost
Factors: design time, type of components used (processor,
memory, I/O devices), technology, testing time, power
consumption, etc.
• Reliability and safety are major requirements.
In order to guarantee safety during design:
- Formal verification: mathematics-based methods to verify
certain properties of the designed system.
• Non-recurring engineering (NRE) costs (such as design cost,
masks, prototypes) are becoming very high ⇒
- It is very difficult to come out with low quantity products;
- Hardware and software platforms are introduced which are
used for several products in a family;
Petru Eles, IDA, LiTH
- Automatic synthesis: certain design steps are automatically
performed by design tools.
Petru Eles, IDA, LiTH
TDDD93
Fö “Embedded Systems”- 15
TDDD93
Fö “Embedded Systems”- 16
Why is Design of Embedded Systems Difficult?
Characteristics of Embedded Applications (cont’d)
☞ Short time to market:
In highly competitive markets it is critical to catch the market
window: a short delay with the product on the market can have
catastrophic financial consequences (even if the quality of the
product is excellent).
• Design time has to be reduced!
- Good design methodologies.
- Efficient design tools.
- Reuse of previously designed and verified (hardware and
software) blocks.
- Good designers who understand both software and hardware!
Petru Eles, IDA, LiTH
•
•
•
•
•
High Complexity
Strong time and power constraints
Low cost
Short time to market
Safety critical systems
☞ In order to achieve all these requirements, systems have to be
highly optimized.
Both hardware and software aspects have to be considered
simultaneously!
Petru Eles, IDA, LiTH
TDDD93
Fö “Embedded Systems”- 17
TDDD93
Fö “Embedded Systems”- 18
Modelling Embedded Systems
Dataflow Models
• The design flow starts from an informal description of the desired
functionality and constraints.
☞ Systems are specified as directed graphs where:
- nodes represent computations (processes);
- arcs represent totally ordered sequences (streams) of
data (tokens).
• Before the actual design is performed, a more formal abstract
model, capturing the required behaviour, is produced.
• This model is an abstraction, hiding many details and only
capturing the aspects that are most relevant for starting the actual
design flow.
• There are several modeling approaches (and modeling
languages) used for embedded system design; we give two
examples in the following: Dataflow Models and Finite State
Machines.
Petru Eles, IDA, LiTH
☞ Dataflow models are suitable for signal-processing algorithms:
- Code/decode, filter, compression, streaming video, etc.
☞ There are several models based on Dataflow: Kahn Process
Networks (KPN), Synchronous Dataflow Models (SDF), etc.
Petru Eles, IDA, LiTH
TDDD93
Fö “Embedded Systems”- 19
TDDD93
Fö “Embedded Systems”- 20
Dataflow Models (cont’d)
Dataflow Models (cont’d)
KPN model of an encoder for the Motion JPEG (M-JPEG) video
compression format:
HeaderInfo
VLE
ble
ffT
a
Hu
QTables
P2
BitRate CtrlF1
Packets
1
1
1 Biq 1
1
Add
1
1
1
sc
2
1
2
In
1
StatisticsF
TablesInfo
Petru Eles, IDA, LiTH
1 Biq 1
Fork
Video
Out
EndOfFrame
Q
Block
s
DCT
Block
1
StatisticsB
P1
Block
SDF model of a Modem:
Petru Eles, IDA, LiTH
1
Filt
1 8
Hil
2 4
2
Eq
2 2
Fork
2
1
Mul
2
2
Mul
2
Conj
2
1
2
2
2
Deci
1
2 2
Deco
1 1
Out
TDDD93
Fö “Embedded Systems”- 21
TDDD93
Fö “Embedded Systems”- 22
Finite State Machines
Finite State Machines (cont’d)
• The system is characterised by explicitly depicting its states as
well as the transitions from one state to another.
Elevator controller
• Input events {r1, r2, r3}
- ri: request from floor i.
• One particular state is specified as the initial one
r1/n
input event
r2/u1
S1
• Outputs {d2, d1, n, u1, u2}
- di: go down i floors
- ui: go up i floors
- n: stay idle
• Transitions generate outputs.
• FSMs are suitable for modeling control dominated reactive
systems (react on inputs with specific outputs; not much
computation)
Petru Eles, IDA, LiTH
initial state
r1 /
u
r2/n
S2
r1/d1
r3 /
• States and transitions are in a finite number.
• Transitions are triggered by input events.
output
d1
r 2/
u1
r 3/
2
d
2
S3
r3/n
• States {S1, S2, S3}
- Si: elevator is at floor i.
(In the model we have assumed that there
are no two requests coming simultaneously)
Petru Eles, IDA, LiTH
TDDD93
Fö “Embedded Systems” - 24
The Traditional Design Flow
It works like this (or even worse):
TDDD93
Fö “Embedded Systems”- 23
A Design Example
The system to be implemented is modelled as a
synchronous dataflow model (a task graph):
T1
T2
T3
T5
T6
• a node represents a task (a unit of functionality
activated as response to a certain input and which
generates a certain output).
• an edge represents a precedence constraint and data
dependency between two tasks.
1. Start from some informal specification of
functionality and a set of constraints (time and
power constraints, cost limits, etc.)
2. Generate a more formal model of the functionality,
based on some modeling concept (finite state
machine, data-flow, etc.).
This model is in Matlab, Statecharts, C, UML, VHDL.
Such a model is our task graph (slide 23).
3. Simulate the model in order to check the
functionality. If needed make adjustments.
Period: 42 time units
T4
T7
T8
• The task graph is activated every 42 time units ⇒ one
activation has to be terminated in time less than 42.
Cost limit: 8
• The total cost of the implemented system has to be
less than 8.
Petru Eles, IDA, LiTH
4. Choose an architecture (µprocessor, buses, etc.)
such that the cost limits are satisfied and, you hope,
that time and power constraints will be fulfilled.
5. Build a prototype and implement the system.
6. Verify the system: neither time nor power constraints
are satisfied!!!
☞ Now you are in great trouble: you have spent a lot of
time and money and nothing works!
• Go back to 4 and choose another architecture and
start a new implementation.
• Or negotiate with the customer on the constraints.
Petru Eles, IDA, LiTH
TDDD93
Fö “Embedded Systems” - 25
The Traditional Design Flow (cont’d)
Informal Specification,
Constraints
TDDD93
Fö “Embedded Systems”- 26
Modeling
The Traditional Design Flow (cont’d)
System
Model
Select Architecture
Functional
Simulation
More work
should be
done here!
• Delays in the design process
- Increased design cost
- Delays in time to market ⇒ missed market window
• High cost of failed prototypes
• Bad design decisions taken under time pressure
- Low quality, high cost products
Hardware and
Software
Implementation
not OK
What are the consequences:
Petru Eles, IDA, LiTH
Testing
Prototype
OK
Fabrication
Petru Eles, IDA, LiTH
TDDD93
Fö “Embedded Systems”- 27
TDDD93
Fö “Embedded Systems”- 28
Example
Let’s come back to the example on slide 23.
• We have the system model (task graph) which has been validated
by simulation. What next?
☞ We decide on a certain µprocessor µp1, with cost 4.
☞ For each task the worst case execution time (WCET) when
executed on µp1 is estimated.
Petru Eles, IDA, LiTH
Example (cont’d)
Task WCET
T1
4
T2
6
T3
4
T4
7
T5
8
T6
12
T7
7
T8
10
Petru Eles, IDA, LiTH
task
----------
Estimator
WCET
µprocessor
arch. model
TDDD93
Fö “Embedded Systems”- 29
TDDD93
Example (cont’d)
Fö “Embedded Systems”- 30
Example (cont’d)
☞ A schedule:
☞ We look after a µprocessor which is fast enough: µp2
Time
0 2 4 6 8 10 12 14 16 18 20 22 24 26 28 30 32 34 36 38 40 42 44 46 48 50 52 54 56 58 60 62 64
T1
T2
T4
T3
T5
T6
T7
☞ For each task the WCET, when executed on µp2, is estimated.
T8
Task WCET
Using this architecture we got a solution with:
Using this architecture we got a solution with:
• Execution time: 28 < 42
• Execution time: 58 > 42
• Cost: 15 > 8
• Cost: 4 < 8
☞ We have to try with another architecture!
☞ We have to try with another architecture!
Petru Eles, IDA, LiTH
2
3
T3
2
T4
3
T5
4
T6
6
T7
3
T8
5
Petru Eles, IDA, LiTH
TDDD93
Fö “Embedded Systems”- 31
TDDD93
Example (cont’d)
☞ For each task the WCET, when executed
on µp3 and µp4, is estimated.
µp3
µp4
Bus
Fö “Embedded Systems”- 32
Example (cont’d)
☞ Now we have to look to a multiprocessor solution.
In order to meet cost constraints we try two cheap (and slow) µps:
µp3: cost 3
µp4: cost 2
WCET
interconnection bus: cost 1
Task
Petru Eles, IDA, LiTH
T1
T2
µp3
µp4
T1
5
6
T2
7
9
T3
5
6
T4
8
10
T5
10
11
T6
17
21
T7
10
14
T8
15
19
☞ Now we have to map the tasks to processors.
µp3: T1, T3, T5, T6, T7, T8.
µp4: T2, T4.
☞ If communicating tasks are mapped to different processors, they
have to communicate over the bus.
Communication time has to be estimated; it depends on the amount
of bits transferred between the tasks and on the speed of the bus.
Estimated communication times:
C1-2: 1
C4-8: 1
Petru Eles, IDA, LiTH
TDDD93
Fö “Embedded Systems”- 33
TDDD93
Fö “Embedded Systems”- 34
Example (cont’d)
Example (cont’d)
☞ Try a new mapping; move T5 to µp4, in order to increase parallelism.
☞ A schedule:
Time
Two new communications are introduced, with estimated times:
C3-5: 2
C5-7: 1
0 2 4 6 8 10 12 14 16 18 20 22 24 26 28 30 32 34 36 38 40 42 44 46 48 50 52 54 56 58 60 62 64
µp3
T1
T3
µp4
T5
T2
T6
T7
T8
T4
☞ A schedule:
bus
C1-2
Time
C4-8
0 2 4 6 8 10 12 14 16 18 20 22 24 26 28 30 32 34 36 38 40 42 44 46 48 50 52 54 56 58 60 62 64
µp3
T1
T3
µp4
We have exceeded the allowed execution time (42)!
T6
T2
T7
T4
T8
T5
bus
C1-2
C3-5
C4-8
C5-7
The execution time is still 62, as before!
Petru Eles, IDA, LiTH
Petru Eles, IDA, LiTH
TDDD93
Fö “Embedded Systems”- 35
TDDD93
Example (cont’d)
Example (cont’d)
☞ There exists a better schedule!
Time
0 2 4 6 8 10 12 14 16 18 20 22 24 26 28 30 32 34 36 38 40 42 44 46 48 50 52 54 56 58 60 62 64
µp3
T1
T3
µp4
T6
T2
T7
T5
☞ Possible solutions:
• Change µprocessor µp3 with a faster one ⇒ cost limits exceeded
• Implement some part of the functionality in hardware as an ASIC
T8
☞ New architecture
Cost of ASIC: 1
T4
bus
µp3
µp4
Bus
C1-2
C3-5
C5-7
C4-8
Using this architecture we got a solution with:
• Execution time: 52 > 42
• Cost: 6 < 8
Petru Eles, IDA, LiTH
Fö “Embedded Systems”- 36
☞ Mapping
µp3: T1, T3, T6, T7.
µp4: T2, T4, T5.
ASIC: T8 with estimated WCET= 3
New communication, with estimated time:
C7-8: 1
Petru Eles, IDA, LiTH
ASIC
TDDD93
Fö “Embedded Systems”- 37
TDDD93
Example (cont’d)
Example (cont’d)
☞ A schedule:
Time
0 2 4 6 8 10 12 14 16 18 20 22 24 26 28 30 32 34 36 38 40 42 44 46 48 50 52 54 56 58 60 62 64
µp3
T1
T3
µp4
T6
T7
T5
T2
Fö “Embedded Systems”- 38
What did we achieve?
• We have selected an architecture.
• We have mapped tasks to the processors and ASIC.
• We have elaborated a a schedule.
T4
T8
ASIC
Extremely important!!!
Nothing has been built yet.
All decisions are based on simulation and estimation.
bus
C1-2
C3-5
C5-7
C4-8 C7-8
Using this architecture we got a solution with:
• Execution time: 41 < 42
☞ Now we can go and do the software and hardware implementation,
with a high degree of confidence that we get a correct prototype.
• Cost: 7 < 8
Petru Eles, IDA, LiTH
Petru Eles, IDA, LiTH
TDDD93
Fö “Embedded Systems” - 39
The Design Flow
Informal Specification,
Constraints
Modeling
Arch. Selection
TDDD93
Functional
Simulation
System
model
Fö “Embedded Systems”- 40
The Design Flow (cont’d)
What is the essential difference compared to the flow on slide 25?
System
architecture
Mapping
Estimation
Scheduling
not OK
Mapped and
scheduled
model
OK
Hardware and
Software
Implementation
Testing
not OK
OK
Fabrication
Petru Eles, IDA, LiTH
Prototype
• It is the inner loop which is performed before the effective
hardware/software implementation.
This loop is performed several times as part of the design space
exploration. Different architectures, mappings and schedules are
explored, before the actual implementation and prototyping.
not OK
• We get highly optimized good quality solutions in short time.
We have a good chance that the outer loop, including prototyping,
is not repeated.
Petru Eles, IDA, LiTH
TDDD93
Fö “Embedded Systems” - 42
The Design Flow (cont’d)
Informal Specification,
Constraints
Functional
Simulation
Arch. Selection
System model
Formal
Verification
System
architecture
Mapping
Estimation
Scheduling
Fö “Embedded Systems”- 41
The Design Flow (cont’d)
☞ Some additional remarks:
• Formal verification
It is impossible to do an exhaustive verification by simulation!
Especially for safety critical systems (but not only) formal
verification is needed.
• Simulation
Simulation is used not only for functional validation.
It is used also after mapping and scheduling in order to test, for
example, timing aspects.
It is used also during the implementation steps; especially
interesting: hardware/software cosimulation.
System Level
TDDD93
Modeling
not OK
Mapped and
scheduled model
OK
☞ The steps performed before the actual hardware and software
implementation represent the System Level Design Phase!
Softw. model
Simulation
Softw. Generation
Lower Levels
Petru Eles, IDA, LiTH
not OK
not OK
Simulation
Formal
Verification
Hardw. model
Hardw. Synthesis
Softw. blocks
Simulation
Testing
OK
Prototype
Hardw. blocks
Fabrication
Petru Eles, IDA, LiTH
TDDD93
Fö “Embedded Systems”- 43
TDDD93
The “Lower Levels”
• Software generation:
- Encoding in an implementation language (C, C++, assembler).
- Compiling (this can include particular optimizations for
application specific processors, DSPs, etc.).
- Generation of a real-time kernel or adapting to an existing
operating system.
- Testing and debugging (in the development environment).
☞ Several courses are teaching this part: Programming related
courses, Algorithms and data structures, Compilers, operating
systems, real-time systems, ....
Petru Eles, IDA, LiTH
Fö “Embedded Systems”- 44
The “Lower Levels” (cont’d)
• Hardware synthesis:
- Encoding in a hardware description language (VHDL, Verilog)
- Successive synthesis steps: high-level, register-transfer level,
logic-level synthesis.
- Testing and debugging (by simulation)
☞ Several courses are teaching this part: Digital design, Electronics
and VLSI related courses, Computer Architectures, ....
Petru Eles, IDA, LiTH
TDDD93
Fö “Embedded Systems”- 45
TDDD93
Fö “Embedded Systems”- 46
Bring Power Consumption into the Picture
The System Level
Why is power consumption an issue?
• Portable systems - battery life time!
☞ TDTS07: System Design and Methodology (Modeling and Design
of Embedded Systems)
• Systems with a very limited power budget: Mars Pathfinder,
autonomous helicopter, ...
• Desktops and servers: high power consumption
- raises temperature and deteriorates performance & reliability
- increases the need for expensive cooling mechanisms
• One of the main difficulties with developing high performance
chips is heat extraction.
• High power consumption has economical and ecological
consequences.
Petru Eles, IDA, LiTH
Petru Eles, IDA, LiTH
TDDD93
Fö “Embedded Systems”- 47
TDDD93
Fö “Embedded Systems”- 48
Sources of Power Dissipation in CMOS Devices
dynamic
1
2
P = --- ⋅ C ⋅ V DD ⋅ f ⋅ N SW + Q SC ⋅ V DD ⋅ f ⋅ N SW + I leak ⋅ V DD
2
Switching power
Power required to
charge/discharge
circuit nodes
Short-circ. power
Dissipation due
to short-circuit
current
C
= node capacitances
NSW = switching activities
(number of gate transitions
per clock cycle)
f
= frequency of operation
Petru Eles, IDA, LiTH
Dynamic Power/Energy
static
Leakage power
Dissipation
due to leakage
current
VDD = supply voltage
QSC = charge carried by
short circuit current
per transition
Ileak = leakage current
1
2
P = --- ⋅ C ⋅ V DD ⋅ f ⋅ N SW
2
1
2
E = P ⋅ t = --- ⋅ C ⋅ V DD ⋅ N CY ⋅ N SW
2
NCY = number of cycles needed for the particular task.
• In certain situations we are concerned about power consumption:
- heath dissipation, cooling:
- physical deterioration due to temperature.
• Sometimes we want to reduce total energy consumed:
- battery life.
Petru Eles, IDA, LiTH
TDDD93
Fö “Embedded Systems”- 49
TDDD93
Fö “Embedded Systems”- 50
Reducing Power/Energy Consumption
Reducing Power/Energy Consumption (cont’d)
☞ System Level
☞ The main sources:
• Compilation for low power: instruction selection considering their
power profile, data placement in memory, register allocation.
• Reduce supply voltage (Voltage scaling)
• Reduce switching activity (Smart digital design)
• Algorithm design: find the algorithm which is the most powerefficient.
• Reduce capacitance (Smart circuit design)
• Task mapping and scheduling.
• Reduce number of cycles (Smart algorithms design)
• Dynamic voltage/frequency scaling applied at run-time in order to
reduce power consumption by exploiting idle or low-workload
periods.
Petru Eles, IDA, LiTH
Petru Eles, IDA, LiTH
TDDD93
Fö “Embedded Systems”- 51
TDDD93
Fö “Embedded Systems”- 52
Example: Mapping for Low Energy
Mapping for Low Energy (cont’d)
τ1
τ2
τ3
τ5
Task
τ1
τ2
τ3
τ4
τ5
τ6
τ7
τ8
τ6
τ4
τ7
τ8
µp3
µp4
WCET
Energy
Consider a mapping:
µp3: τ1, τ3, τ6, τ7, τ8.
µp4: τ2, τ4, τ5.
µp3
µp4
µp3
µp4
5
6
5
3
7
9
8
4
5
6
5
3
8
10
6
4
10
11
8
6
17
21
15
10
10
14
8
7
µp3
15
19
14
9
µp4
Execution time: 52;
Time
Energy consumed: 75.
0 2 4 6 8 10 12 14 16 18 20 22 24 26 28 30 32 34 36 38 40 42 44 46 48 50 52 54 56 58 60 62 64
τ1
τ3
τ6
τ2
τ7
τ5
τ8
τ4
bus
C1-2
Bus
Petru Eles, IDA, LiTH
Communication times and energy:
C1-2: t = 1; E = 3.
C3-5: t = 2; E = 5.
C4-8: t = 1; E = 3.
C5-7: t = 1; E = 3.
Petru Eles, IDA, LiTH
C3-5
C5-7
C4-8
TDDD93
Fö “Embedded Systems”- 53
TDDD93
Fö “Embedded Systems”- 54
Mapping for Low Energy (cont’d)
Consider a mapping:
µp3: τ1, τ3, τ6, τ7.
µp4: τ2, τ4, τ5, τ8.
Execution time: 57;
Time
µp3
Mapping for Low Energy (cont’d)
Communication times and energy:
C1-2: t = 1; E = 3.
C3-5: t = 2; E = 5.
C7-8: t = 1; E = 3.
C5-7: t = 1; E = 3.
Energy consumed: 70.
Assume that we have a maximum allowed delay = 60.
0 2 4 6 8 10 12 14 16 18 20 22 24 26 28 30 32 34 36 38 40 42 44 46 48 50 52 54 56 58 60 62 64
τ1
τ3
τ6
τ2
µp4
τ7
τ5
τ4
The second mapping with τ8 on µp4 consumes less energy;
This second mapping is preferable, even if it is slower!
τ8
bus
C1-2
C3-5
C5-7
C7-8
Petru Eles, IDA, LiTH
Petru Eles, IDA, LiTH
TDDD93
Fö “Embedded Systems”- 55
TDDD93
Dynamic Power Management
☞ At run-time, the processor can be placed in different power states,
depending on the current work-load.
• Switching among multiple power states:
• idle
• sleep
• run
• When in the run state: switching among multiple voltage levels.
☞ Energy consumption is proportional to V2 (see slide 48)!!!
Petru Eles, IDA, LiTH
Fö “Embedded Systems”- 56
Dynamic Power management (cont’d)
Hardware Support (e.g. Intel Xscale Processor)
• RUN: operational
• IDLE: Clocks to the
CPU are disabled;
recovery is through
interrupt.
• SLEEP: Mainly
powered off;
recovery through
wake-up event.
• Other intermediate
states: DEEP
IDLE, STANDBY,
DEEP SLEEP
Petru Eles, IDA, LiTH
0.75V, 60mW
150MHz
1.3V, 450mW
RUN
RUN
600MHz
RUN
1.6V, 900mW
RUN
800MHz
160µs
RUN
10µs
1.5ms
10µs
IDLE
40mW
140ms
90µs
SLEEP
160µW
TDDD93
Fö “Embedded Systems”- 57
TDDD93
Conclusions
Dynamic Power management (cont’d)
☞ Switching between power states and voltage levels is not for free:
you have to consider the switching overheads (in terms of delay and
energy)
☞ For a given supply voltage there exists a maximal frequency at
which the processor can run ⇒ when you reduce the voltage the
processor becomes slower!
☞ The goal of Dynamic Power management: switch between power
states and voltage levels such that:
• Energy consumption is minimised
• QoS is not compromised
Petru Eles, IDA, LiTH
Fö “Embedded Systems”- 58
• Embedded systems are everywhere.
• They have to satisfy strong timing, safety, power, and cost
constraints.
• An efficient design flow, with iterations at the system level, is needed
in order to support the design of complex embedded systems.
• System level design steps are performed before the start of the actual
implementation of hardware and software components!
• The input to the actual design flow is an abstract model of the
system.
• Power consumption becomes a central issue of the design process.
Petru Eles, IDA, LiTH