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

Transcription

1 Design&Methodologies Fö 1&2-1 Design&Methodologies Fö 1&2-2 Course Information Design and Methodology/ Embedded s Design (Modeling and Design of Embedded s) TDTS07/TDDI08 Web page: Examination: written Petru Eles Institutionen för Datavetenskap (IDA) Linköpings Universitet Lecture notes: available from the web page, latest 24 hours before the lecture. Recommended literature: petru.eles@liu.se phone: B building, 329:220 Peter Marwedel: "Embedded Design", Springer, 2nd edition, Edward Lee, Sanjit Seshia: Introduction to Embedded s - A Cyber-Physical s Approach, LeeSeshia.org, 1st edition 2011, 2nd edition Design&Methodologies Fö 1&2-3 Course Information (cont d) Lessons&Labs: Design&Methodologies Fö 1&2-4 Embedded s and Their Design Adrian Horga Institutionen för Datavetenskap (IDA) adrian.horga@liu.se B building, 329: What is an Embedded 2. Characteristics of Embedded Applications 3. The Traditional Design Flow 4. An Example 5. A New Design Flow 6. The Level 7. Course Topics

2 Design&Methodologies Fö 1&2-5 Design&Methodologies Fö 1&2-6 That s how we use microprocessors What is an Embedded? 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. Design&Methodologies Fö 1&2-7 Design&Methodologies Fö 1&2-8 A Look at Two Typical Implementation Architectures What is an Embedded? (cont d) Telecommunication on Chip Some of the main characteristics: Dedicated (not general purpose) RF A/D & D/A DSP core RAM RISC core RAM High-Speed DSP Blocks Control Logic Interface LAN Contains a programmable component Interacts (continuously) with the environment Programmable processor ASIC block (Application Specific Integrated Circuit) Standard block Memory Reconfigurable logic (FPGA) dedicated electronics

3 Design&Methodologies Fö 1&2-9 Design&Methodologies Fö 1&2-10 Distributed Embedded (automotive application) Actuators Sensors Input/Output RAM CPU FLASH Network Interface Gateway The Software Component Software running on the programmable processors: Application tasks Real-Time Operating I/O drivers, Network protocols, Middleware Gateway Design&Methodologies Fö 1&2-11 Design&Methodologies Fö 1&2-12 Characteristics of Embedded Applications Characteristics of Embedded Applications (cont d) 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 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.

4 Design&Methodologies Fö 1&2-13 Design&Methodologies Fö 1&2-14 Characteristics of Embedded Applications (cont d) 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 (cont d) 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 difficult to come out with low quantity products; - Hardware and software platforms are introduced which are used for several products in a family; Design&Methodologies Fö 1&2-15 Design&Methodologies Fö 1&2-16 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. Reliability and safety are major requirements. In order to guarantee safety during design: - verification: 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 (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). 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!

5 Design&Methodologies Fö 1&2-17 Design&Methodologies Fö 1&2-18 Why is Design of Embedded s Difficult? An Example High Complexity Strong time and power constraints Low cost Short time to market Safety critical systems T 2 T 1 T 3 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. In order to achieve all these requirements, systems have to be highly optimized. Both hardware and software aspects have to be considered simultaneously! T 4 T 5 T 6 T 7 T 8 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. Design&Methodologies Fö 1&2-19 Design&Methodologies Fö 1&2-20 The Traditional Design Flow The Traditional Design Flow (cont d) It works like this (or even worse): 1. Start from some informal specification of functionality and a set of constraints (time and power constraints, cost limits, etc.) Informal Specification, Constraints 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). Modeling Model Functional 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 satisfied and, you hope, that time and power constraints will be fulfilled. 5. Build a prototype and implement the system. 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. Testing Fabrication Select Architecture Hardware and Software Implementation Prototype More work should be done here!

6 Design&Methodologies Fö 1&2-21 Design&Methodologies Fö 1&2-22 The Traditional Design Flow (cont d) Example 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 Let s 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. Design&Methodologies Fö 1&2-23 Design&Methodologies Fö 1&2-24 A schedule: 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 task Estimator WCET μprocessor arch. model Time T 1 T 2 T 4 T 3 T 5 T 6 T 7 T 8 Using this architecture we got a solution with: Execution time: 58 > 42 Cost: 4 < 8 We have to try with another architecture!

7 Design&Methodologies Fö 1&2-25 Design&Methodologies Fö 1&2-26 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: T 1 2 T 2 3 Execution time: 28 < 42 T 3 2 T 4 3 Cost: 15 > 8 T 5 4 T 6 6 T 7 3 We have to try with another architecture! T 8 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 interconnection bus: cost 1 Task WCET μp3 μp4 For each task the WCET, when executed T on μp3 and μp4, is estimated. T T T μp3 μp4 T T Bus T T Design&Methodologies Fö 1&2-27 Design&Methodologies Fö 1&2-28 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 A schedule: Time μp3 T 1 T 3 T 5 T 6 T 7 T 8 μp4 bus T 2 T 4 C 1-2 C 4-8 We have exceeded the allowed execution time (42)!

8 Design&Methodologies Fö 1&2-29 Design&Methodologies Fö 1&2-30 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: Time μp3 μp4 bus T 1 T 3 T 6 T 7 T 8 T 2 T 4 T 5 C 1-2 C 3-5 C 4-8 C 5-7 The execution time is still 62, as before! There exists a better schedule! Time μp3 T 1 T 3 T 6 T 7 T 8 μp4 bus T 2 T 5 T 4 C 1-2 C 3-5 C 5-7 C 4-8 Using this architecture we got a solution with: Execution time: 52 > 42 Cost: 6 < 8 Design&Methodologies Fö 1&2-31 Design&Methodologies Fö 1&2-32 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 Mapping ASIC μ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 μp4 Bus A schedule: Time μp3 T 1 T 3 T 6 T 7 μp4 T 2 T 5 T 4 ASIC bus C 1-2 C 3-5 C 5-7 C 4-8 C 7-8 Using this architecture we got a solution with: Execution time: 41 < 42 Cost: 7 < 8 T 8

9 Design&Methodologies Fö 1&2-34 The Design Flow Informal Specification, Constraints Design&Methodologies Fö 1&2-33 Modeling 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 architecture model Mapping Functional 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 confidence that we get a correct prototype. Estimation Scheduling Mapped and scheduled model Hardware and Software Implementation Testing Fabrication Prototype Design&Methodologies Fö 1&2-35 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? 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: verification It is impossible to do an exhaustive verification by simulation! Especially for safety critical systems (but not only) formal verification is needed. 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.

10 Design&Methodologies Fö 1&2-38 The Design Flow (cont d) Informal Specification, Constraints Design&Methodologies Fö 1&2-37 Hardware/software codesign The Design Flow (cont d) 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 Hardware/Software codesign Level Arch. Selection architecture Estimation Softw. model Modeling model Mapping Scheduling Functional Mapped and scheduled model Hardw. model Softw. Generation Hardw. Synthesis Lower Levels Softw. blocks Testing Fabrication Prototype Hardw. blocks Design&Methodologies Fö 1&2-39 Design&Methodologies Fö 1&2-40 The Lower Levels The Lower Levels (cont d) 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) 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.

11 Design&Methodologies Fö 1&2-41 Design&Methodologies Fö 1&2-42 The Lower Levels (cont d) 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 and cosimulation tools Hardware synthesis tools - High level synthesis - RT-level synthesis - Logic synthesis - Layout and physical implementation The 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! Design&Methodologies Fö 1&2-44 Lab Assignment 1 Modeling and simulation with C. Design&Methodologies Fö 1&2-43 Course Topics at a Glance Introduction: Embedded s 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 s, Timed Automata, Hybrid Automata. Architectures and Platforms for Embedded s Design - General Purpose vs. Application Specific Architectures, Component and Platform-based Design, Reconfigurable s, Functionality Mapping. Task Scheduling -Level Power/Energy Optimization Level Arch. Selection architecture Estimation Informal Specification, Constraints Modeling model Mapping Scheduling Mapped and scheduled model Functional Softw. model Hardw. model

12 Design&Methodologies Fö 1&2-45 Design&Methodologies Fö 1&2-46 Lab Assignment 2 (only TDTS07) Lab Assignment 3 verification with UPPAAL. Design space exploration with an MPARM simulator. Informal Specification, Constraints Informal Specification, Constraints Arch. Selection Modeling model Functional Arch. Selection Modeling model Functional Level architecture Estimation Mapping Scheduling Mapped and scheduled model Level architecture Estimation Mapping Scheduling Mapped and scheduled model Softw. model Hardw. model Softw. model Hardw. model