System Design and Methodology/ Embedded Systems Design (Modeling and Design of Embedded Systems)

System Design&Methodologies F 1&2- 1
Petru Eles, IDA, LiTH

System Design and Methodology/
Embedded Systems Design
(Modeling and Design of Embedded Systems)
TDTS30/TDDI08
Petru Eles
Institutionen fr Datavetenskap (IDA)
Linkpings Universitet
email: petel@ida.liu.se
http://www.ida.liu.se/~petel
phone: 28 1396
B building, 329:220
Course Information
Web page: http://www.ida.liu.se/~TDTS30
(http://www.ida.liu.se/~TDDI08)
Examination: written
Lecture notes: available from the web page, latest 24
hours before the lecture.
Recommended literature:
Wayne Wolf: "Computers as Components. Principles of
Embedded Computing System Design",
Morgan Kaufmann Publishers, 2001.
Peter Marwedel: "Embedded System Design",
Springer, 2nd edition, 2006.
Course Information (contd)
Labs&Lessons&Report:
Daniel Karlsson
email: danka@ida.liu.se
http://www.ida.liu.se/~danka
phone: 28 2419
B building, 329:198
Soheil Samii
email: sohsa@ida.liu.se
http://www.ida.liu.se/~sohsa
phone: 28 2424
B building, 329:202
Embedded Systems and Their Design
1. What is an Embedded System
2. Characteristics of Embedded Applications
3. The Traditional Design Flow
4. An Example
5. A New Design Flow
6. The System Level
7. Course Topics
www.jntuworld.com
www.jntuworld.com
www.jwjobs.net
Thats how we use microprocessors
What is an Embedded System?
There are several denitions around!
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.
Some focus on what it is built from:
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.
What is an Embedded System? (contd)
Some of the main characteristics:
Dedicated (not general purpose)
Contains a programmable component
Interacts (continuously) with the environment
A Look at Two Typical Implementation Architectures
Telecommunication System on Chip
LAN RF
DSP core RAM RISC core RAM
Control
Logic
High-Speed
DSP Blocks
Programmable processor
ASIC block (Application Specic Integrated Circuit)
Standard block
Memory
Recongurable logic (FPGA)
dedicated
electronics
A/D
&
D/A
I
n
t
e
r
f
a
c
e
www.jntuworld.com
www.jntuworld.com
www.jwjobs.net
Distributed Embedded System (automotive application)
Sensors Actuators
Gateway
Gateway
CPU
RAM
FLASH
Input/Output
Network Interface
The Software Component
Software running on the programmable processors:
Application tasks
Real-Time Operating System
I/O drivers, Network protocols, Middleware
Characteristics of Embedded Applications
What makes them special?
Like with ordinary applications, functionality and user interfaces
are often very complex.
But, in addition to this:
Time constraints
Power constraints
Cost constraints
Safety
Time to market
Characteristics of Embedded Applications (contd)
Time constraints:
Embedded systems have to performin 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.
www.jntuworld.com
www.jntuworld.com
www.jwjobs.net
Power constraints:
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
Cost constraints: Embedded systems are very often mass products
in highly competitive markets and have to be shipped at a low cost.
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.
Non-recurring engineering (NRE) costs (such as design cost,
masks, prototypes) are becoming very high
- It is very difcult to come out with low quantity products;
- Hardware and software platforms are introduced which are
used for several products in a family;
Safety critical:
Embedded systems are often used in life critical applications:
avionics, automotive electronics, nuclear plants, medical
applications, military applications, etc.
Reliability and safety are major requirements.
In order to guarantee safety during design:
- Formal verication: mathematics-based methods to verify
certain properties of the designed system.
- Automatic synthesis: certain design steps are automatically
performed by design tools.
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 nancial consequences (even if the quality of the
product is excellent).
Design time has to be reduced!
- Good design methodologies.
- Efcient design tools.
- Reuse of previously designed and veried (hardware and
software) blocks.
- Good designers who understand both software and hardware!
www.jntuworld.com
www.jntuworld.com
www.jwjobs.net
Why is Design of Embedded Systems Difcult?
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!
An Example
T
1
T
8
T
5
T
7
T
3
T
6
T
4
T
2
The system to be implemented is modelled as a task graph:
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.
Period: 42 time units
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.
The Traditional Design Flow
It works like this (or even worse):
1. Start from some informal specication of
functionality and a set of constraints (time and
power constraints, cost limits, etc.)
2. Generate a more formal specication of the
functionality, based on some modeling concept
(nite state machine, data-ow, etc.).
This model is in Matlab, Statecharts, C, UML, VHDL.
Such a model is our task graph (slide 18).
3. Simulate the model in order to check the
functionality. If needed make adjustments.
4. Choose an architecture (processor, buses, etc.)
such that the cost limits are satised and, you hope,
that time and power constraints will be fullled.
5. Build a prototype and implement the system.
6. Verify the system: neither time nor power constraints
are satised!!!
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.
The Traditional Design Flow (contd)
System
Model
Hardware and
Software
Implementation
Prototype
Fabrication
Informal Specication,
Constraints
Functional
Simulation
Modeling
Testing
More work
should be
done here!
Select Architecture
OK
n
o
t

O
K
www.jntuworld.com
www.jntuworld.com
www.jwjobs.net
The Traditional Design Flow (contd)
What are the consequences:
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
Example
Lets come back to the example on slide 18.
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.
Example (contd)
task
- - - -
- - - -
- - - -
processor
arch. model
Estimator
WCET
Task WCET
T
1
4
T
2
6
T
3
4
T
4
7
T
5
8
T
6
12
T
7
7
T
8
10
Example (contd)
A schedule:
Using this architecture we got a solution with:
Execution time: 58 > 42
Cost: 4 < 8
We have to try with another architecture!
T
1
38 40 42 44 46 48 50 52 54 56 58 60 62 0 2 4 6 8 10 12 14 16 18 20 22 24 26 30 32 34 28 36
Time
64
T
2
T
4
T
3
T
5
T
6
T
7
T
8
www.jntuworld.com
www.jntuworld.com
www.jwjobs.net
Example (contd)
We look after a processor which is fast enough: p2
For each task the WCET, when executed on p2, is estimated.
Execution time: 28 < 42
Cost: 15 > 8
We have to try with another architecture!
Task WCET
T
1
2
T
2
3
T
3
2
T
4
3
T
5
4
T
6
6
T
7
3
T
8
5
Example (contd)
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
interconnection bus: cost 1
For each task the WCET, when executed
on p3 and p4, is estimated.
p3 p4
Bus
Task
WCET
p3 p4
T
1
5 6
T
2
7 9
T
3
5 6
T
4
8 10
T
5
10 11
T
6
17 21
T
7
10 14
T
8
15 19
Example (contd)
Now we have to map the tasks to processors.
p3: T
1
, T
3
, T
5
, T
6
, T
7
, T
8
.
p4: T
2
, T
4
.
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:
C
1-2
: 1
C
4-8
: 1
Example (contd)
A schedule:
We have exceeded the allowed execution time (42)!
T
1
38 40 42 44 46 48 50 52 54 56 58 60 62 0 2 4 6 8 10 12 14 16 18 20 22 24 26 30 32 34 28 36
Time
64
T
3
T
5
T
6
T
7
T
8 p3
p4
bus
T
2
T
4
C
1-2
C
4-8
www.jntuworld.com
www.jntuworld.com
www.jwjobs.net
Example (contd)
Try a new mapping; move T
5
to p4, in order to increase parallelism.
Two new communications are introduced, with estimated times:
C
3-5
: 2
C
5-7
: 1
A schedule:
The execution time is still 62, as before!
T
1
38 40 42 44 46 48 50 52 54 56 58 60 62 0 2 4 6 8 10 12 14 16 18 20 22 24 26 30 32 34 28 36
Time
64
T
3
T
5
T
6
T
7
T
8 p3
p4
bus
T
2
T
4
C
1-2
C
4-8
C
3-5
C
5-7
Example (contd)
There exists a better schedule!
Execution time: 52 > 42
Cost: 6 < 8
T
1
38 40 42 44 46 48 50 52 54 56 58 60 62 0 2 4 6 8 10 12 14 16 18 20 22 24 26 30 32 34 28 36
Time
64
T
3
T
4
T
6
T
7
T
8 p3
p4
bus
T
2
T
5
C
1-2
C
5-7
C
3-5
C
4-8
Example (contd)
Possible solutions:
Change processor p3 with a faster one cost limits exceeded
Implement some part of the functionality in hardware as an ASIC
New architecture
Cost of ASIC: 1
Mapping
p3: T
1
, T
3
, T
6
, T
7
.
p4: T
2
, T
4
, T
5
.
ASIC: T
8
with estimated WCET= 3
New communication, with estimated time:
C
7-8
: 1
p3 p4
Bus
ASIC
Example (contd)
A schedule:
Execution time: 41 < 42
Cost: 7 < 8
T
1
38 40 42 44 46 48 50 52 54 56 58 60 62 0 2 4 6 8 10 12 14 16 18 20 22 24 26 30 32 34 28 36
Time
64
T
3
T
4
T
6
T
7
T
8
p3
p4
bus
T
2
T
5
C
1-2
C
5-7
C
3-5
C
4-8
C
7-8
ASIC
www.jntuworld.com
www.jntuworld.com
www.jwjobs.net
Example (contd)
What did we achieve?
We have selected an architecture.
We have mapped tasks to the processors and ASIC.
We have elaborated a a schedule.
Extremely important!!!
Nothing has been built yet.
All decisions are based on simulation and estimation.
Now we can go and do the software and hardware implementation,
with a high degree of condence that we get a correct prototype.
The Design Flow
System
model
Hardware and
Software
Implementation
Prototype
Fabrication
Constraints
Functional
Simulation
Modeling
Testing
Arch. Selection
System
architecture
Mapping
Estimation
Mappedand
scheduled
model
Scheduling
OK
not OK not OK
OK
not OK
The Design Flow (contd)
What is the essential difference compared to the ow on slide 20?
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.
We get highly optimised good quality solutions in short time.
We have a good chance that the outer loop, including prototyping,
is not repeated.
Some additional remarks:
Formal verication
It is impossible to do an exhaustive verication by simulation!
Especially for safety critical systems (but not only) formal
verication 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.
www.jntuworld.com
www.jntuworld.com
www.jwjobs.net
Hardware/software codesign
During the mapping step we also
decide what is going to be executed
on a programmable processor
(software) and what is going into
hardware (ASIC, FPGA).
During the implementation phase,
hardware and software
components have to be developed
in a coordinated way, keeping their
consistency (hardware/software
cosimulation is important here)
Hardware/Software
partitioning
H
a
r
d
w
a
r
e
/
S
o
f
t
w
a
r
e
c
o
d
e
s
i
g
n
System model
Prototype
Fabrication
Constraints
Functional
Simulation
Modeling
Testing
Arch. Selection
System
architecture
Mapping
Estimation
Mapped and
scheduled model
Scheduling
OK
not OK not OK
OK
not OK
Formal
Verication
Softw. model Hardw. model
Simulation
Formal
Verication
Softw. Generation Hardw. Synthesis
Softw. blocks Hardw. blocks Simulation
Simulation
S
y
s
t
e
m

L
e
v
e
l
L
o
w
e
r

L
e
v
e
l
s
The Lower Levels
Software generation:
- Encoding in an implementation language (C, C++, assembler).
- Compiling (this can include particular optimizations for
application specic processors, DSPs, etc.).
- Generation of a real-time kernel or adapting to an existing
operating system.
- Testing and debugging (in the development environment).
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)
The Lower Levels (contd)
Hardware/software integration:
- The software is run together with the hardware model (cosim-
ulation)
Prototyping:
- A prototype of the hardware is constructed and the software is
executed on the target architecture.
www.jntuworld.com
www.jntuworld.com
www.jwjobs.net
The Lower Levels (contd)
There are available tools on the market which automatically perform
many of the low level tasks:
Code generators (software model C, hardware model VHDL)
Compilers
Test generators and debuggers
Simulation and cosimulation tools
Hardware synthesis tools
- High level synthesis
- RT-level synthesis
- Logic synthesis
- Layout and physical implementation
The System Level
This is a hot research area.
Very few commercial tools are offered.
Mostly experimental and academic tools available.
Huge efforts and investments are currently made in order to
develop tools and methodologies for system level design.
Ad-hoc solutions are less and less acceptable.
It is the system level we are interested in, in this course!
Course Topics at a Glance
Introduction: Embedded Systems and Their Design (just nished!)
Models of Computation and Specication Languages
- Dataow Models, Petri Nets, Discrete Event Models,
Synchronous Finite State Machines & Synchronous Languages,
Globally Asynchronous Locally Synchronous Systems,
Timed Automata
Architectures and Platforms for Embedded Systems Design
- General Purpose vs. Application Specic Architectures,
Component and Platform-based Design, Recongurable
Systems, Functionality Mapping.
Task Scheduling
System-Level Power/Energy Optimization
www.jntuworld.com
www.jntuworld.com
www.jwjobs.net

System Design and Methodology/ Embedded Systems Design (Modeling and Design of Embedded Systems)

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

System Design and Methodology/ Embedded Systems Design (Modeling and Design of Embedded Systems)

Uploaded by

Copyright:

Available Formats

System Design&Methodologies F 1&2- 1

Petru Eles, IDA, LiTH

You might also like