System Design&Methodologies
Fö 1&2- 1
System Design&Methodologies
Fö 1&2- 2
Course Information
System Design and Methodology/
Embedded Systems Design
(Modeling and Design of Embedded Systems)
Web page: http://www.ida.liu.se/~TDTS07
http://www.ida.liu.se/~TDDI08
Examination: written
TDTS07/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: petru.eles@liu.se
http://www.ida.liu.se/~petel71/
phone: 28 1396
B building, 329:220
Peter Marwedel: "Embedded System Design",
Springer, 2nd edition, 2011.
Edward Lee, Sanjit Seshia: “Introduction to Embedded
Systems - A Cyber-Physical Systems
Approach”, LeeSeshia.org, 1st edition 2011,
2nd edition 2015.
Petru Eles, IDA, LiTH
Petru Eles, IDA, LiTH
System Design&Methodologies
Fö 1&2- 3
Course Information (cont’d)
Lessons:
Ivan Ukhov
Institutionen för Datavetenskap (IDA)
email: ivan.ukhov@liu.se
B building, 329:232
System Design&Methodologies
Embedded Systems and Their Design
1. What is an Embedded System
2. Characteristics of Embedded Applications
3. The Traditional Design Flow
Labs
Adrian Horga
Institutionen för Datavetenskap (IDA)
email: adrian.horga@liu.se
B building, 329:198
4. An Example
5. A New Design Flow
6. The System Level
7. Course Topics
Petru Eles, IDA, LiTH
Petru Eles, IDA, LiTH
Fö 1&2- 4
System Design&Methodologies
Fö 1&2- 5
System Design&Methodologies
That’s how we use microprocessors
Fö 1&2- 6
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
RF
• Dedicated (not general purpose)
• Contains a programmable component
A/D
&
D/A
DSP core
RAM
High-Speed
DSP Blocks
RAM
Control
Logic
LAN
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
RISC core
Interface
Some of the main characteristics:
Petru Eles, IDA, LiTH
System Design&Methodologies
Fö 1&2- 9
System Design&Methodologies
Distributed Embedded System (automotive application)
Actuators
Fö 1&2- 10
The Software Component
Sensors
Input/Output
Software running on the programmable processors:
RAM
• Application tasks
CPU
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 (cont’d)
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
☞ 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.
• Safety
• Time to market
Petru Eles, IDA, LiTH
Petru Eles, IDA, LiTH
System Design&Methodologies
Fö 1&2- 13
System Design&Methodologies
Characteristics of Embedded Applications (cont’d)
Fö 1&2- 14
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.
☞ Power constraints:
There are several reasons why low power/energy consumption is
required:
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.
• Cost aspects:
High power consumption  strong power supply
expensive cooling 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;
• Battery life
High energy consumption  short battery life time
Petru Eles, IDA, LiTH
Petru Eles, IDA, LiTH
System Design&Methodologies
Fö 1&2- 15
System Design&Methodologies
Characteristics of Embedded Applications (cont’d)
☞ Safety critical:
Embedded systems are often used in life critical applications:
avionics, automotive electronics, nuclear plants, medical
applications, military applications, etc.
Fö 1&2- 16
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).
• 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.
- Automatic synthesis: certain design steps are automatically
performed by design tools.
Petru Eles, IDA, LiTH
• 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
System Design&Methodologies
Fö 1&2- 17
System Design&Methodologies
Fö 1&2- 18
Why is Design of Embedded Systems Difficult?
•
•
•
•
•
An Example
The system to be implemented is modelled as a task graph:
High Complexity
Strong time and power constraints
Low cost
Short time to market
Safety critical systems
T1
T2
☞ In order to achieve all these requirements, systems have to be
highly optimized.
• 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.
T3
T5
T6
Period: 42 time units
T4
• The task graph is activated every 42 time units  one
activation has to be terminated in time less than 42.
T7
Both hardware and software aspects have to be considered
simultaneously!
Cost limit: 8
T8
Petru Eles, IDA, LiTH
• The total cost of the implemented system has to be
less than 8.
Petru Eles, IDA, LiTH
System Design&Methodologies
Fö 1&2- 19
System Design&Methodologies
The Traditional Design Flow
Fö 1&2- 20
The Traditional Design Flow (cont’d)
It works like this (or even worse):
Informal Specification,
Constraints
1. Start from some informal specification of
functionality and a set of constraints (time and
power constraints, cost limits, etc.)
Modeling
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 18).
System
Model
3. Simulate the model in order to check the
functionality. If needed make adjustments.
Select Architecture
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.
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
not OK
5. Build a prototype and implement the system.
Hardware and
Software
Implementation
Testing
OK
Fabrication
Petru Eles, IDA, LiTH
Prototype
Functional
Simulation
More work
should be
done here!
System Design&Methodologies
Fö 1&2- 21
System Design&Methodologies
Fö 1&2- 22
Example
The Traditional Design Flow (cont’d)
What are the consequences:
Let’s come back to the example on slide 18.
• Delays in the design process
- Increased design cost
- Delays in time to market  missed market window
• We have the system model (task graph) which has been 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 (cont’d)
Example (cont’d)
☞ A schedule:
Task WCET
T1
4
T2
6
T3
4
T4
7
T5
8
T6
12
T7
7
T8
10
Time
task
----------
Estimator
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
μprocessor
arch. model
T2
T4
T3
T5
T6
Using this architecture we got a solution with:
• Execution time: 58 > 42
WCET
• Cost: 4 < 8
☞ We have to try with another architecture!
Petru Eles, IDA, LiTH
Petru Eles, IDA, LiTH
T7
T8
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
☞ For each task the WCET, when executed on μp2, is estimated.
Task WCET
Using this architecture we got a solution with:
• Execution time: 28 < 42
• Cost: 15 > 8
☞ We have to try with another architecture!
T1
2
T2
3
T3
2
T4
3
T5
4
T6
6
T7
3
T8
5
☞ 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
☞ For each task the WCET, when executed
on μp3 and μp4, is estimated.
μp3
μp4
Bus
Petru Eles, IDA, LiTH
μp4
5
6
T2
7
9
T3
5
6
T4
8
10
T5
10
11
T6
17
21
T7
10
14
T8
15
19
Petru Eles, IDA, LiTH
System Design&Methodologies
Fö 1&2- 27
System Design&Methodologies
Fö 1&2- 28
Example (cont’d)
☞ 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
μp3
T1
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
T5
T2
T6
T7
T4
bus
C1-2
C4-8
We have exceeded the allowed execution time (42)!
Petru Eles, IDA, LiTH
T8
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.
Two new communications are introduced, with estimated times:
C3-5: 2
C5-7: 1
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
T1
T7
T5
T8
T4
bus
T3
μp4
T6
T2
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
T3
μp4
☞ A schedule:
Time
☞ There exists a better schedule!
T6
T2
T7
T4
C1-2
C3-5
C5-7
C4-8
T8
Using this architecture we got a solution with:
T5
bus
• Execution time: 52 > 42
C1-2
C3-5
C4-8
C5-7
• Cost: 6 < 8
The execution time is still 62, as before!
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:
• 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
μp3
μp4
New communication, with estimated time:
C7-8: 1
Petru Eles, IDA, LiTH
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
Bus
☞ Mapping
μp3: T1, T3, T6, T7.
μp4: T2, T4, T5.
ASIC: T8 with estimated WCET= 3
☞ A schedule:
Time
T6
T2
T7
T5
T4
T8
ASIC
bus
C1-2
ASIC
C3-5
C5-7
C4-8 C7-8
Using this architecture we got a solution with:
• Execution time: 41 < 42
• Cost: 7 < 8
Petru Eles, IDA, LiTH
System Design&Methodologies
Fö 1&2- 34
The Design Flow
Informal Specification,
Constraints
System Design&Methodologies
Modeling
Fö 1&2- 33
Example (cont’d)
What did we achieve?
• We have selected an architecture.
• We have mapped tasks to the processors and ASIC.
• We have elaborated a a schedule.
Arch. Selection
System
model
System
architecture
Mapping
Estimation
Scheduling
Extremely important!!!
Nothing has been built yet.
All decisions are based on simulation and estimation.
not OK
☞ Now we can go and do the software and hardware implementation,
with a high degree of confidence that we get a correct prototype.
Mapped and
scheduled
model
OK
Functional
Simulation
not OK
Hardware and
Software
Implementation
Petru Eles, IDA, LiTH
Testing
not OK
Prototype
OK
Fabrication
Petru Eles, IDA, LiTH
System Design&Methodologies
Fö 1&2- 35
System Design&Methodologies
The Design Flow (cont’d)
What is the essential difference compared to the flow 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.
Petru Eles, IDA, LiTH
Fö 1&2- 36
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.
Petru Eles, IDA, LiTH
System Design&Methodologies
Fö 1&2- 38
The Design Flow (cont’d)
Informal Specification,
Constraints
Functional
Simulation
Arch. Selection
System model
Formal
Verification
System
architecture
Mapping
Estimation
Scheduling
Fö 1&2- 37
The Design Flow (cont’d)
• Hardware/software codesign
Hardware/Software
partitioning
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
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).
System Level
System Design&Methodologies
Modeling
not OK
Mapped and
scheduled model
OK
Softw. model
Simulation
Softw. Generation
Lower Levels
Petru Eles, IDA, LiTH
Simulation
Formal
Verification
Hardw. model
Hardw. Synthesis
Softw. blocks
Simulation
Testing
OK
Prototype
not OK
not OK
Hardw. blocks
Fabrication
Petru Eles, IDA, LiTH
System Design&Methodologies
Fö 1&2- 39
System Design&Methodologies
The “Lower Levels” (cont’d)
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).
• 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)
Petru Eles, IDA, LiTH
Fö 1&2- 40
• Hardware/software integration:
- The software is “run” together with the hardware model (cosimulation)
• Prototyping:
- A prototype of the hardware is constructed and the software is
executed on the target architecture.
Petru Eles, IDA, LiTH
System Design&Methodologies
Fö 1&2- 41
System Design&Methodologies
Fö 1&2- 42
The System Level
The “Lower Levels” (cont’d)
• This is a hot research area.
• Very few commercial tools are offered.
• Mostly experimental and academic tools available.
☞ 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
☞ 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!
Petru Eles, IDA, LiTH
Petru Eles, IDA, LiTH
System Design&Methodologies
Fö 1&2- 44
Lab Assignment 1
• Modeling and simulation with SystemC.
System Design&Methodologies
Informal Specification,
Constraints
Fö 1&2- 43
Course Topics at a Glance
Modeling
Functional
Simulation
Arch. Selection
System model
Formal
Verification
System
architecture
Mapping
Estimation
Scheduling
• 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, Hybrid 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
• Introduction: Embedded Systems and Their Design (just finished!)
not OK
• System-Level Power/Energy Optimization
Mapped and
scheduled model
OK
not OK
Simulation
Formal
Verification
Petru Eles, IDA, LiTH
Softw. model
Petru Eles, IDA, LiTH
Simulation
Hardw. model
System Design&Methodologies
Fö 1&2- 45
System Design&Methodologies
Lab Assignment 2 (only TDTS07)
Fö 1&2- 46
Lab Assignment 3
• Formal verification with UPPAAL.
• Design space exploration with an MPARM
simulator.
Informal Specification,
Constraints
Modeling
Functional
Simulation
Arch. Selection
System model
Formal
Verification
System
architecture
Mapping
Estimation
Scheduling
not OK
Mapped and
scheduled model
OK
Softw. model
Petru Eles, IDA, LiTH
Simulation
not OK
Simulation
Formal
Verification
System Level
System Level
Informal Specification,
Constraints
Modeling
Functional
Simulation
Arch. Selection
System model
Formal
Verification
System
architecture
Mapping
Estimation
Scheduling
not OK
Mapped and
scheduled model
OK
Hardw. model
Softw. model
Petru Eles, IDA, LiTH
Simulation
not OK
Simulation
Formal
Verification
Hardw. model