1 Unit

www.jntuworld.
com
www.jwjobs.net
System Design&Methodologies
F 1&2- 1
F 1&2- 2
Course Information
System Design and Methodology/ Embedded Systems Design (Modeling and Design of Embedded Systems)
TDTS30/TDDI08
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. Petru Eles Institutionen fr Datavetenskap (IDA) Linkpings Universitet Recommended literature: email: petel@ida.liu.se http://www.ida.liu.se/~petel phone: 28 1396 B building, 329:220 Wayne Wolf: "Computers as Components. Principles of Embedded Computing System Design", Morgan Kaufmann Publishers, 2001. Peter Marwedel: "Embedded System Design", Springer, 2nd edition, 2006.
Petru Eles, IDA, LiTH
F 1&2- 3
Course Information (contd)
Labs&Lessons&Report:
System Design&Methodologies F 1&2- 4
Daniel Karlsson Institutionen fr Datavetenskap (IDA) email: danka@ida.liu.se http://www.ida.liu.se/~danka phone: 28 2419 B building, 329:198
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
Soheil Samii Institutionen fr Datavetenskap (IDA) email: sohsa@ida.liu.se http://www.ida.liu.se/~sohsa phone: 28 2424 B building, 329:202
6. The System Level 7. Course Topics
www.jntuworld.com
www.jntuworld.com
www.jwjobs.net
F 1&2- 5
F 1&2- 6
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.
F 1&2- 7
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:
RF A/D & D/A Interface DSP core RAM RISC core RAM LAN
Dedicated (not general purpose) Contains a programmable component Interacts (continuously) with the environment
High-Speed DSP Blocks
Control Logic
Programmable processor ASIC block (Application Specic Integrated Circuit) dedicated electronics Standard block Memory Recongurable logic (FPGA)
www.jntuworld.com
www.jntuworld.com
www.jwjobs.net
F 1&2- 9
F 1&2- 10
Distributed Embedded System (automotive application)

Actuators Sensors
The Software Component
Input/Output RAM CPU FLASH Network Interface Gateway
Software running on the programmable processors: Application tasks Real-Time Operating System I/O drivers, Network protocols, Middleware
Gateway
F 1&2- 11
F 1&2- 12
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 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.
www.jntuworld.com
www.jntuworld.com
www.jwjobs.net
F 1&2- 13
F 1&2- 14
Characteristics of Embedded Applications (contd) 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
Characteristics of Embedded Applications (contd) 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;
F 1&2- 15
F 1&2- 16
Characteristics of Embedded Applications (contd) 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.
Characteristics of Embedded Applications (contd) 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
F 1&2- 17
F 1&2- 18
Why is Design of Embedded Systems Difcult?

High Complexity Strong time and power constraints Low cost Short time to market Safety critical systems T1 T2 T5 In order to achieve all these requirements, systems have to be highly optimized. Both hardware and software aspects have to be considered simultaneously! T4 T7 T8 T3 T6
An Example
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.
F 1&2- 19
F 1&2- 20
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.
not OK
The Traditional Design Flow (contd)
Informal Specication, Constraints
Modeling Functional Simulation
System Model
Select Architecture
More work should be done here!
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.
Hardware and Software Implementation
Testing OK Fabrication
Prototype
www.jntuworld.com
www.jntuworld.com
www.jwjobs.net
F 1&2- 21
F 1&2- 22
The Traditional Design Flow (contd) What are the consequences:
Example
Lets come back to the example on slide 18. Delays in the design process - Increased design cost - Delays in time to market missed market window 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. We have the system model (task graph) which has been validated by simulation. What next?
F 1&2- 23
F 1&2- 24
Example (contd) A schedule:

Task WCET T1 T2 T3 T4 T5 T6 T7 T8 4 6 4 7 8 12 7 10
Example (contd)
task ---------processor arch. model
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
T8
Estimator WCET
Using this architecture we got a solution with: Execution time: 58 > 42 Cost: 4 < 8 We have to try with another architecture!
www.jntuworld.com
www.jntuworld.com
www.jwjobs.net
F 1&2- 25
F 1&2- 26
Example (contd) We look after a processor which is fast enough: p2 For each task the WCET, when executed on p2, is estimated.
Task WCET
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 WCET interconnection bus: cost 1 Task
p3 5 7 5 8 10 17 10 15 p4 6 9 6 10 11 21 14 19
Using this architecture we got a solution with: Execution time: 28 < 42 Cost: 15 > 8
T1 T2 T3 T4 T5 T6 T7
2 3 2 3 4 6 3 5
For each task the WCET, when executed on p3 and p4, is estimated.
T1 T2 T3 T4 T5 T6 T7 T8
p3
p4
We have to try with another architecture!
T8
Bus
F 1&2- 27
F 1&2- 28
Example (contd) 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 A schedule:
Time p3 p4 bus
C1-2
Example (contd)
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
T3 T2
T5 T4
T6
T7
T8
C4-8
We have exceeded the allowed execution time (42)!
www.jntuworld.com
www.jntuworld.com
www.jwjobs.net
F 1&2- 29
F 1&2- 30
Example (contd) 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 A schedule:
Time p3 p4 bus
C1-2 C3-5 C4-8 C5-7
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
Example (contd) There exists a better schedule!

Time p3 p4 bus
C1-2 C3-5 C5-7 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
T1
T3 T2
T6 T5
T7 T4
T8
T1
T3 T2
T6 T4 T5
T7
T8
Using this architecture we got a solution with: Execution time: 52 > 42 Cost: 6 < 8
The execution time is still 62, as before!

F 1&2- 31
F 1&2- 32
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: T1, T3, T6, T7. p4: T2, T4, T5. ASIC: T8 with estimated WCET= 3 New communication, with estimated time: C7-8: 1
Example (contd) A schedule:

Time p3 p4
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
T3 T2
T6 T5
T7 T4 T8
p3
p4
Bus
ASIC
ASIC bus
C1-2 C3-5 C5-7
C4-8 C7-8
Using this architecture we got a solution with: Execution time: 41 < 42 Cost: 7 < 8
www.jntuworld.com
www.jntuworld.com
www.jwjobs.net
F 1&2- 34
The Design Flow

Informal Specication, Constraints Modeling System model Functional Simulation
F 1&2- 33
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.
Arch. Selection System architecture
Mapping
Extremely important!!! Nothing has been built yet. All decisions are based on simulation and estimation.
Estimation
Scheduling Mapped and scheduled model OK Hardware and Software Implementation
Now we can go and do the software and hardware implementation, with a high degree of condence that we get a correct prototype.
not OK
not OK
not OK
Prototype
F 1&2- 35
F 1&2- 36
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.
The Design Flow (contd) 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.
We get highly optimised good quality solutions in short time. We have a good chance that the outer loop, including prototyping, is not repeated.
www.jntuworld.com
www.jntuworld.com
www.jwjobs.net
F 1&2- 38
The Design Flow (contd)

Informal Specication, Constraints Modeling
System Design&Methodologies F 1&2- 37
Functional Simulation Formal Verication
Arch. Selection
The Design Flow (contd) 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)
System model Mapping Scheduling Mapped and scheduled model OK
System Level
System architecture Estimation not OK
Hardware/Software partitioning
not OK Simulation Formal Verication
Hardware/Software codesign
Softw. model Softw. Generation Lower Levels
Simulation
Hardw. model Hardw. Synthesis
Softw. blocks not OK
Simulation
Hardw. blocks
Prototype
F 1&2- 39
F 1&2- 40
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 (cosimulation)
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
F 1&2- 41
F 1&2- 42
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!
F 1&2- 43
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

1 Unit

Enviado por

Dados do documento

Título original

Direitos autorais

Formatos disponíveis

Compartilhar este documento

Compartilhar ou incorporar documento

Opções de compartilhamento

Você considera este documento útil?

Este conteúdo é inapropriado?

Direitos autorais:

Formatos disponíveis

1 Unit

Enviado por

Direitos autorais:

Formatos disponíveis

www.jntuworld.

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

Petru Eles, IDA, LiTH

Petru Eles, IDA, LiTH

Course Information (contd)

Embedded Systems and Their Design

6. The System Level 7. Course Topics

Petru Eles, IDA, LiTH

Petru Eles, IDA, LiTH

Thats how we use microprocessors

What is an Embedded System?

Petru Eles, IDA, LiTH

Petru Eles, IDA, LiTH

A Look at Two Typical Implementation Architectures

High-Speed DSP Blocks

Petru Eles, IDA, LiTH

Petru Eles, IDA, LiTH

Distributed Embedded System (automotive application)

The Software Component

Input/Output RAM CPU FLASH Network Interface Gateway

Petru Eles, IDA, LiTH

Petru Eles, IDA, LiTH

Characteristics of Embedded Applications

Characteristics of Embedded Applications (contd)

Petru Eles, IDA, LiTH

Petru Eles, IDA, LiTH

Petru Eles, IDA, LiTH

Petru Eles, IDA, LiTH

Petru Eles, IDA, LiTH

Petru Eles, IDA, LiTH

Why is Design of Embedded Systems Difcult?

Petru Eles, IDA, LiTH

Petru Eles, IDA, LiTH

The Traditional Design Flow

The Traditional Design Flow (contd)

Informal Specication, Constraints

Modeling Functional Simulation

More work should be done here!

Hardware and Software Implementation

Petru Eles, IDA, LiTH

The Traditional Design Flow (contd) What are the consequences:

Petru Eles, IDA, LiTH

Petru Eles, IDA, LiTH

Example (contd) A schedule:

task ---------processor arch. model

Petru Eles, IDA, LiTH

Petru Eles, IDA, LiTH

We have to try with another architecture!

Petru Eles, IDA, LiTH

Petru Eles, IDA, LiTH

We have exceeded the allowed execution time (42)!

Petru Eles, IDA, LiTH

Petru Eles, IDA, LiTH

Example (contd) There exists a better schedule!

The execution time is still 62, as before!

Petru Eles, IDA, LiTH

Example (contd) A schedule:

Petru Eles, IDA, LiTH

The Design Flow

Arch. Selection System architecture

Scheduling Mapped and scheduled model OK Hardware and Software Implementation

Petru Eles, IDA, LiTH

Petru Eles, IDA, LiTH