System Design&Methodologies F 1&2- 1 System Design&Methodologies F 1&2- 2

Course Information

Web page: http://www.ida.liu.se/~TDTS30

System Design and Methodology/ Embedded (http://www.ida.liu.se/~TDDI08)
Systems Design (Modeling and Design of
Embedded Systems) Examination: written
TDTS30/TDDI08

Lecture notes: available from the web page, latest 24

hours before the lecture.
Petru Eles

Institutionen fr Datavetenskap (IDA)

Linkpings Universitet
Recommended literature:
email: petel@ida.liu.se
http://www.ida.liu.se/~petel Wayne Wolf: "Computers as Components. Principles of
phone: 28 1396 Embedded Computing System Design",
Morgan Kaufmann Publishers, 2001.
B building, 329:220

Peter Marwedel: "Embedded System Design",

Springer, 2nd edition, 2006.

Petru Eles, IDA, LiTH Petru Eles, IDA, LiTH

System Design&Methodologies F 1&2- 3

Course Information (contd)

Labs&Lessons&Report:
System Design&Methodologies F 1&2- 4

Daniel Karlsson Embedded Systems and Their Design

Institutionen fr Datavetenskap (IDA)
email: danka@ida.liu.se 1. What is an Embedded System
http://www.ida.liu.se/~danka 2. Characteristics of Embedded Applications
phone: 28 2419
3. The Traditional Design Flow
B building, 329:198
4. An Example

5. A New Design Flow

Soheil Samii 6. The System Level
Institutionen fr Datavetenskap (IDA)
7. Course Topics
email: sohsa@ida.liu.se
http://www.ida.liu.se/~sohsa
phone: 28 2424
Petru Eles, IDA, LiTH
B building, 329:202

Petru Eles, IDA, LiTH

 System Design&Methodologies F 1&2- 5 System Design&Methodologies F 1&2- 6

Thats how we use microprocessors

What is an Embedded System?

There are several definitions 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.

Petru Eles, IDA, LiTH Petru Eles, IDA, LiTH

System Design&Methodologies F 1&2- 7 System Design&Methodologies F 1&2- 8

A Look at Two Typical Implementation Architectures

What is an Embedded System? (contd)
Telecommunication System on Chip

Some of the main characteristics:

Interf
ace

DSP core RAM RISC core RAM

A/D
RF & LAN
D/A High-Speed Control
Dedicated (not general purpose) DSP Blocks Logic

Contains a programmable component

Programmable processor
Interacts (continuously) with the environment ASIC block (Application Specific Integrated Circuit) dedicated
Standard block electronics

Memory
Reconfigurable logic (FPGA)

Petru Eles, IDA, LiTH Petru Eles, IDA, LiTH

 System Design&Methodologies F 1&2- 9 System Design&Methodologies F 1&2- 10

Distributed Embedded System (automotive application)

The Software Component
Actuators Sensors

Input/Output Software running on the programmable processors:

RAM
CPU Application tasks
FLASH

Network Interface
Real-Time Operating System

Gateway
I/O drivers, Network protocols, Middleware

Gateway

Petru Eles, IDA, LiTH Petru Eles, IDA, LiTH

System Design&Methodologies F 1&2- 11 System Design&Methodologies F 1&2- 12

Characteristics of Embedded Applications Characteristics of Embedded Applications (contd)

What makes them special?

Time constraints:
Like with ordinary applications, functionality and user
interfaces are often very complex.
Embedded systems have to perform in real-time: if data is not
But, in addition to this: ready by a certain deadline, the system fails to perform correctly.

Time constraints - Hard deadline: failure to meet leads to major hazards.

Power constraints
- Soft deadline: failure to meet can be tolerated but quality
Cost constraints of service is reduced.

Safety
Time to market

Petru Eles, IDA, LiTH Petru Eles, IDA, LiTH

 System Design&Methodologies F 1&2- 13 System Design&Methodologies F 1&2- 14

Characteristics of Embedded Applications (contd) Characteristics of Embedded Applications (contd)

Cost constraints: Embedded systems are very often mass

Power constraints: products in highly competitive markets and have to be shipped at
a low cost. What we are interested in:
There are several reasons why low power/energy consumption - Manufacturing cost
is required:
- Design cost

Cost aspects: Factors: design time, type of components used (processor,

memory, I/O devices), technology, testing time,
High power consumption strong power supply power consumption, etc.
expensive cooling system
Non-recurring engineering (NRE) costs (such as design
cost, masks, prototypes) are becoming very high
Battery life
- It is very difficult to come out with low quantity products;
High energy consumption short battery life time - Hardware and software platforms are introduced which
are used for several products in a family;

Petru Eles, IDA, LiTH Petru Eles, IDA, LiTH

System Design&Methodologies F 1&2- 15 System Design&Methodologies F 1&2- 16

Characteristics of Embedded Applications (contd) Characteristics of Embedded Applications (contd)

Safety critical:
Short time to market:

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 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).

In order to guarantee safety during design: Design time has to be reduced!

- Good design methodologies.
- Formal verification: mathematics-based methods to verify certain
properties of the designed system. - Efficient design tools.
- Reuse of previously designed and verified (hardware
- Automatic synthesis: certain design steps are automatically and software) blocks.
performed by design tools.
- Good designers who understand both software and hardware!

Petru Eles, IDA, LiTH Petru Eles, IDA, LiTH

 System Design&Methodologies F 1&2- 17 System Design&Methodologies F 1&2- 18

Why is Design of Embedded Systems Difficult? An Example

High Complexity The system to be implemented is modelled as a task graph:

Strong time and power constraints T1 a node represents a task (a unit of functionality
Low cost activated as response to a certain input and which
generates a certain output).
Short time to market T2 T3
an edge represents a precedence constraint and data
Safety critical systems dependency between two tasks.
T T
5 6
In order to achieve all these requirements, systems have to Period: 42 time units
be highly optimized. T4 The task graph is activated every 42 time units one
T7 activation has to be terminated in time less than 42.
Both hardware and software aspects have to be
considered simultaneously! Cost limit: 8
T8
The total cost of the implemented system has to
be less than 8.

Petru Eles, IDA, LiTH Petru Eles, IDA, LiTH

System Design&Methodologies F 1&2- 19 System Design&Methodologies F 1&2- 20

The Traditional Design Flow The Traditional Design Flow (contd)

It works like this (or even worse):

Informal Specification,
1. Start from some informal specification of Constraints
functionality and a set of constraints (time
and power constraints, cost limits, etc.)
2. Generate a more formal specification of the Modeling
functionality, based on some modeling
concept (finite state machine, data-flow, etc.). Functional
Simulation
This model is in Matlab, Statecharts, C, UML, System
Model
VHDL. Such a model is our task graph (slide 18).
3. Simulate the model in order to check the More work
functionality. If needed make adjustments. Select Architecture should be
done here!
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. Hardware and
Software
5. Build a prototype and implement the system. Implementation

6. Verify the system: neither time nor power

O
K
n
o
t

constraints are satisfied!!!

Testing Prototype
Now you are in great trouble: you have spent a lot OK
of time and money and nothing works!
Go back to 4 and choose another architecture Fabrication
and start a new implementation.
Or negotiate with the customer on the constraints.

Petru Eles, IDA, LiTH Petru Eles, IDA, LiTH

 System Design&Methodologies F 1&2- 21 System Design&Methodologies F 1&2- 22

The Traditional Design Flow (contd) Example

What are the consequences:

Lets come back to the example on slide 18.
Delays in the design process
- Increased design cost We have the system model (task graph) which has been
- Delays in time to market missed market window validated by simulation. What next?

High cost of failed prototypes

We decide on a certain processor p1, with cost 4.
Bad design decisions taken under time pressure
- Low quality, high cost products For each task the worst case execution time (WCET)
when executed on p1 is estimated.

Petru Eles, IDA, LiTH Petru Eles, IDA, LiTH

System Design&Methodologies F 1&2- 23 System Design&Methodologies F 1&2- 24

Example (contd) Example (contd)

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
Task WCET task
----
T1 T2 T4 T3 T5 T6 T7 T8

T1 4 ----
T ----

2 6

T
3 4
T4 7
processor
Using this architecture we got a solution with:
T Estimator
5 8 arch. model
T6 12 Execution time: 58 > 42
T
7 7 WCET
T
8 10 Cost: 4 < 8

We have to try with another architecture!

Petru Eles, IDA, LiTH Petru Eles, IDA, LiTH

 System Design&Methodologies F 1&2- 25 System Design&Methodologies F 1&2- 26

Example (contd) Example (contd)

We look after a processor which is fast enough: p2 Now we have to look to a multiprocessor solution.
In order to meet cost constraints we try two cheap (and slow) ps:
For each task the WCET, when executed on p2, is estimated. p3: cost 3
p4: cost 2 WCET
interconnection bus: cost 1 Task
Task WCET p3 p4
Using this architecture we got a solution with: T1 2 For each task the WCET, when executed T1 5 6

T2 3 on p3 and p4, is estimated. T2 7 9

Execution time: 28 < 42 T3 2 T3 5 6

T4 3 T4 8 10
Cost: 15 > 8
T5 4 p3 p4 T5 10 11
T6 6 T6 17 21
We have to try with another architecture! T7 3 Bus T7 10 14
T8 5 T8 15 19

Petru Eles, IDA, LiTH Petru Eles, IDA, LiTH

System Design&Methodologies F 1&2- 27 System Design&Methodologies F 1&2- 28

Example (contd) Example (contd)

Now we have to map the tasks to processors. A schedule:

p3: T1, T3, T5, T6, T7, T8. 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

p4: T2, T4. p3 T1 T3 T5 T6 T7 T8

p4 T

If communicating tasks are mapped to different processors,

T2 4

they have to communicate over the bus. bus

Communication time has to be estimated; it depends on the amount C C
1-2 4-8
of bits transferred between the tasks and on the speed of the bus.

Estimated communication
We have exceeded the allowed execution time (42)!
times: C1-2: 1
C4-8: 1

Petru Eles, IDA, LiTH Petru Eles, IDA, LiTH

 System Design&Methodologies F 1&2- 29 System Design&Methodologies F 1&2- 30

Example (contd) Example (contd)

Try a new mapping; move T5 to p4, in order to increase parallelism. There exists a better schedule!
Two new communications are introduced, with estimated
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
times: C3-5: 2
p3 T1 T3 T6 T7 T8
C5-7: 1
p4 T2 T5 T4
A schedule:
bus
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 C C C C
1-2 3-5 5-7 4-8
p3 T1 T3 T6 T7 T8

Using this architecture we got a solution with:

p4 T2 T4 T5

bus Execution time: 52 > 42

C C C C
1-2 3-5 4-8 5-7

The execution time is still 62, as before! Cost: 6 < 8

Petru Eles, IDA, LiTH Petru Eles, IDA, LiTH

System Design&Methodologies F 1&2- 31 System Design&Methodologies F 1&2- 32

Example (contd) Example (contd)

Possible solutions: A schedule:

Change processor p3 with a faster one cost limits exceeded
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
Implement some part of the functionality in hardware as an ASIC
p3 T
1
T
3
T
6
T
7

New architecture p3 p4 p4 T
2 T5 T4

Cost of ASIC: 1 ASIC T8

Bus
Mapping bus
ASIC C C C C C
1-2 3-5 5-7 4-8 7-8
p3: T1, T3, T6, T7.
p4: T2, T4, T5. Using this architecture we got a solution with:
ASIC: T8 with estimated WCET= 3
Execution time: 41 < 42
New communication, with estimated time:
C :1 Cost: 7 < 8
7-8

Petru Eles, IDA, LiTH Petru Eles, IDA, LiTH

 System Design&Methodologies F 1&2- 34

The Design Flow

Informal Specification,
Constraints

System Design&Methodologies F 1&2- 33 Modeling

Functional
Example (contd) Simulation
System
Arch. Selection model
What did we achieve?
We have selected an architecture.
We have mapped tasks to the processors and ASIC. System
We have elaborated a a schedule. architecture Mapping

Extremely important!!!
Nothing has been built yet.
Estimation Scheduling
All decisions are based on simulation and estimation.
Mapped and
not OK scheduled not OK
Now we can go and do the software and hardware implementation, model
with a high degree of confidence that we get a correct prototype.
OK
Petru Eles, IDA, LiTH Hardware and
Software
Implementation

Testing Prototype
not OK
OK
Fabrication

Petru Eles, IDA, LiTH

System Design&Methodologies F 1&2- 35 System Design&Methodologies F 1&2- 36

The Design Flow (contd) The Design Flow (contd)

What is the essential difference compared to the flow on slide 20? Some additional remarks:

It is the inner loop which is performed before the Formal verification

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.
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.

Petru Eles, IDA, LiTH Petru Eles, IDA, LiTH

 System Design&Methodologies F 1&2- 38

The Design Flow (contd)

Informal Specification,
Constraints

Modeling Functional
Simulation
System Design&Methodologies F 1&2- 37

Arch. Selection System model Formal

Verification
The Design Flow (contd)

ev el
System
architecture Mapping
Hardware/software codesign

L
During the mapping step we also Estimation Scheduling

Sy stem
decide what is going to be executed
on a programmable processor Hardware/Software
not OK Mapped and not OK

Hardwa re/Sof twar e

(software) and what is going into partitioning
hardware (ASIC, FPGA). scheduled model Simulation

codesign
OK Formal
During the implementation phase,
hardware and software components Verification
have to be developed in a
coordinated way, keeping their
consistency (hardware/software
cosimulation is important here) Softw. model Simulation Hardw. model

Softw. Generation Hardw. Synthesis

Petru Eles, IDA, LiTH

Lower Levels
Softw. blocks Simulation Hardw. blocks

not OK
Testing Prototype
OK
Fabrication

Petru Eles, IDA, LiTH

System Design&Methodologies F 1&2- 39 System Design&Methodologies F 1&2- 40

The Lower Levels The Lower Levels (contd)

Software generation:
- Encoding in an implementation language (C, C++, assembler).
Hardware/software integration:
- Compiling (this can include particular optimizations - The software is run together with the hardware model
for application specific processors, DSPs, etc.). (cosim-ulation)
- Generation of a real-time kernel or adapting to an
existing operating system.
- Testing and debugging (in the development environment).
Prototyping:
- A prototype of the hardware is constructed and the software
Hardware synthesis: is executed on the target architecture.
- Encoding in a hardware description language (VHDL, Verilog)
- Successive synthesis steps: high-level, register-transfer
level, logic-level synthesis.
- Testing and debugging (by simulation)

Petru Eles, IDA, LiTH Petru Eles, IDA, LiTH

 System Design&Methodologies F 1&2- 41 System Design&Methodologies F 1&2- 42

The Lower Levels (contd) The System Level

There are available tools on the market which automatically This is a hot research area.
perform many of the low level tasks: Very few commercial tools are offered.
Mostly experimental and academic tools available.
Code generators (software model C, hardware
model VHDL)
Huge efforts and investments are currently made in order
Compilers to develop tools and methodologies for system level
Test generators and debuggers design. Ad-hoc solutions are less and less acceptable.
Simulation and cosimulation tools
Hardware synthesis tools
- High level synthesis It is the system level we are interested in, in this course!
- RT-level synthesis
- Logic synthesis
- Layout and physical implementation

Petru Eles, IDA, LiTH

Petru Eles, IDA, LiTH

System Design&Methodologies F 1&2- 43

Course Topics at a Glance

Introduction: Embedded Systems and Their Design (just finished!)

Models of Computation and Specification Languages
- Dataflow 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 Specific Architectures,
Component and Platform-based Design,
Reconfigurable Systems, Functionality Mapping.
Task Scheduling
System-Level Power/Energy Optimization

Petru Eles, IDA, LiTH