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/ (http://www.ida.liu.se/~TDDI08)
Embedded 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 för Datavetenskap (IDA)

Linköpings 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 (cont’d)

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

Daniel Karlsson Embedded Systems and Their Design

Institutionen för 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 för 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

That’s 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? (cont’d)
Telecommunication System on Chip

Some of the main characteristics:

DSP core RAM RISC core RAM
Interface

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
electronics
Standard block
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
• Real-Time Operating System
Network Interface

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 (cont’d)

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 ready
But, in addition to this: 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 of
• Cost constraints 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 (cont’d) Characteristics of Embedded Applications (cont’d)

☞ Cost constraints: Embedded systems are very often mass products
☞ Power constraints: 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 is - Manufacturing cost
required: - Design cost

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

memory, I/O devices), technology, testing time, power
High power consumption ⇒ strong power supply 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 (cont’d) Characteristics of Embedded Applications (cont’d)

☞ 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.
• Design time has to be reduced!
In order to guarantee safety during design:
- Formal verification: mathematics-based methods to verify
certain properties of the designed system.
- Automatic synthesis: certain design steps are automatically
performed by design tools.
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).
- 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 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:

T1
• Strong time and power constraints • 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.
T5 T6
☞ In order to achieve all these requirements, systems have to be Period: 42 time units
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 (cont’d)

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, VHDL. System
Model
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
not OK

6. Verify the system: neither time nor power constraints

are satisfied!!!
Testing Prototype
☞ Now you are in great trouble: you have spent a lot of OK
time and money and nothing works!
• Go back to 4 and choose another architecture and Fabrication
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 (cont’d) Example

What are the consequences:

Let’s 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 validated
- Delays in time to market ⇒ missed market window 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 (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
Task WCET task
T1 4 ---- T1 T2 T4 T3 T5 T6 T7 T8
----
T2 6 ----
T3 4
T4 7 Using this architecture we got a solution with:
Estimator µprocessor
T5 8 arch. model
T6 12 • Execution time: 58 > 42
T7 7
WCET
T8 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 (cont’d) Example (cont’d)

☞ 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 T1 5 6
☞ For each task the WCET, when executed
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 T5 10 11
µp3 µp4
T6 6 T6 17 21
T7 3 T7 10 14
☞ We have to try with another architecture! T8 5
Bus
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 (cont’d) Example (cont’d)

☞ 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 T2 T4
☞ If communicating tasks are mapped to different processors, they
have to communicate over the bus. bus
Communication time has to be estimated; it depends on the amount C1-2 C4-8
of bits transferred between the tasks and on the speed of the bus.

Estimated communication times:

We have exceeded the allowed execution time (42)!
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 (cont’d) Example (cont’d)

☞ 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 times: 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
Time
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 C1-2 C3-5 C5-7 C4-8

µp3 T1 T3 T6 T7 T8
Using this architecture we got a solution with:
µp4 T2 T4 T5

bus • Execution time: 52 > 42

C1-2 C3-5 C4-8 C5-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 (cont’d) Example (cont’d)

☞ 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 T1 T3 T6 T7

☞ New architecture µp3 µp4 µp4 T2 T5 T4

Cost of ASIC: 1 ASIC T8
Bus
bus
☞ Mapping C1-2 C3-5 C5-7 C4-8 C7-8
ASIC
µ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:
C7-8: 1 • Cost: 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 (cont’d) 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!!! Scheduling

Estimation
Nothing has been built yet.
All decisions are based on simulation and estimation.
Mapped and
scheduled
☞ Now we can go and do the software and hardware implementation, not OK model not OK
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 (cont’d) The Design Flow (cont’d)

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

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

 System Design&Methodologies Fö 1&2- 38

The Design Flow (cont’d)

Informal Specification,
Constraints

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

Arch. Selection System model Formal

Verification

System Level
The Design Flow (cont’d)
System
architecture Mapping
• Hardware/software codesign

During the mapping step we also Estimation Scheduling

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

codesign
Hardware/Software
(software) and what is going into partitioning Mapped and
hardware (ASIC, FPGA). scheduled model Simulation
During the implementation phase,
OK Formal
hardware and software Verification
components have to be developed
in a coordinated way, keeping their
consistency (hardware/software
cosimulation is important here) Softw. model Simulation Hardw. model

Petru Eles, IDA, LiTH

Softw. Generation Hardw. Synthesis

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” (cont’d)

• Software generation:
- Encoding in an implementation language (C, C++, assembler). • Hardware/software integration:
- Compiling (this can include particular optimizations for - The software is “run” together with the hardware model (cosim-
application specific processors, DSPs, etc.). 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 is
• Hardware synthesis: 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” (cont’d) The System Level

☞ There are available tools on the market which automatically perform • This is a hot research area.
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)
• Compilers ☞ Huge efforts and investments are currently made in order to
• Test generators and debuggers develop tools and methodologies for system level design.
• Simulation and cosimulation tools Ad-hoc solutions are less and less acceptable.
• Hardware synthesis tools
- High level synthesis
- RT-level synthesis It is the system level we are interested in, in this course!
- 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