context
play

Context Embedded systems are becoming more complex every day: more - PDF document

Context Embedded systems are becoming more complex every day: more functions Giorgio Buttazzo g.buttazzo@sssup.it higher performance higher efficiency new hardware platforms Scuola Superiore SantAnna 2 Increasing complexity


  1. Context Embedded systems are becoming more complex every day:  more functions Giorgio Buttazzo g.buttazzo@sssup.it  higher performance  higher efficiency  new hardware platforms Scuola Superiore Sant’Anna 2 Increasing complexity Hardware Performance # functions Instructions per second 10 12 in a cell phone 500 AMD Phenom Intel i7 (6 cores) (6 cores) 10 10 400 Xbox 360 (3 cores) AMD Athlon Intel Pentium Pro DEC Alpha 300 10 8 Intel 486 200 Intel 386 M 68000 Intel 286 10 6 100 Intel 8080 10 4 0 year year 1980 1990 2000 2010 2020 1970 1980 1990 2000 2010 2020 Software Complexity And the Result is … Lines of code Boot time (seconds) 10 8 120 Windows Vista Windows 8 Windows XP Windows 7 Windows 2000 Linux 3.6 10 7 90 Windows NT 4.0 Linux 2.6.29 Windows 98 Linux 2.6.0 Windows 3.1 Linux 2.4.2 10 6 60 Linux 2.0 Linux 1.1.0 Unix 10 5 30 MS-DOS 3.1 MS-DOS 1.0 10 4 0 year year 1970 1980 1990 2000 2010 2020 1970 1980 1990 2000 2010 2020 1

  2. It increases with upgrades ECU growth in a car ECU = Electronic Control Unit Boot time (minutes) # ECUs 8 100 7 Windows 7 6 80 every function is encoded 5 in a different ECU 60 4 3 40 2 20 Windows 8 1 0 0 files year 0 200K 400K 600K 800K 1M 1980 1990 2000 2010 2020 upgraded Advantages of separation Problems of separation With the increasing number of ECUs, there are Separating functions in dedicated ECUs allows: problems of space, weight, energy.  easier development  easier testing  easier certification  easier maintenance How to add more functions? That's nice, but Functions Functions New platform ECUs ECU 1 A 150 A no more space 120 B ECU 2 B ECUs 90 current situation: 70 ECUs group more 60  How can we test and certify a function in the functions in the same ECU presence of other applications? 30  How can we guarantee behavior and performance 0 to get certification? year 1980 1990 2000 2010 2020 2

  3. The problem Additional problems multicore When multiple applications run on the same single core platform platform, they interfere with each other due to the A platform use of shared resources. A A A B B Interference: phenomenon for which the execution single core B platform of a task affects the one of other tasks. In the following, we will  How do we partition the applications on the available cores?  identify the causes of interference  How does the Worst-Case Execution Time ( WCET )  present possible solutions scale on multicore architecture? 14 Interference mechanisms Why do we care? Tasks may interfere for different reasons: Because interference has different negative effects:  Time: concurrent access to shared resources, as  It decreases efficiency and schedulability processing units and communication channels.  It reduces predictability  Space: due to sharing the same memory space (Cache, DRAM, Hard Disk).  It jeopardizes safety  Energy: sharing the energy source (battery).  It complicates the analysis  Temperature: eating up each other. 15 16 A simple example Priority explosion! Application A Application B  1  3 How many priority P 1 P 3 assignments satisfy  1  2  3  4 A B  2  4 both priority orders? P 2 P 4 P 1 P 2 P 3 P 4 CPU 1: speed = 1 CPU 2: speed = 1 There are 6 priority assignments that satisfy both priority orders:  1  1  1  3  3  3  Priorities must be assigned Applications A + B  4  3  3  2  1  1  Task interference can  1  2 P 1 P 2 jeopardize predictability  4  3  2  2  4  1  3  4 P 3 P 4  4  4  2  4  2  2 Platform: speed = 2 17 18 3

  4. Non trivial questions Let’s go into details C i T i C i T i  How do computation times scale in the new  1  3 P 1 P 3 2 4 2 5 platform?  2  4 P 2 P 4 4 8 6 12  Which priority order do we choose? A B  Do they all lead to a feasible schedule? RM schedule (S = 1) RM schedule (S = 1) A B  Are they different in terms of performance?  1 (2,4)  3 (2,5) 4 5 10  How can we reduce the reciprocal interference?  2 (4,8)  4 (6,12) 0 4 8 0 12 19 20 Now let’s groups them Now let’s groups them How computation times scale in the new platform? If the new platform has a fixed priority scheduler, what is the best priority order? C i T i speed = 2  1 C i T i 2 4 C i T i Assume for A  1  1  1  1  1  3  3  3  1 P 1  2 1 4 4 4 5 5 5 simplicity P 1 4 4 8 1 4  2  2  4  2 P 2  3  3  1  1 2 8 P 2 speed = 1 C i 2 8 8 5 5 4 4 12 C i ’ = s  3  3  2  4  2  3 P 3 1 5  4  1 P 3 1 5 5 8 12 8 12 4 C i T i  4  4  4  4  4  2 P 4 3 12  2  4  2  3 P 4 3 12 12 12 8 12 8 8 2 5 B  4 6 12 A+B A+B speed = 1 RM ordering (optimal) 21 22 All together are not feasible! Example on 2 cores U = 1 U = 0.9 RM schedule (S = 1) RM schedule (S = 1) RM schedule (S = 1) RM schedule (S = 1) A B A B  1 (2,4)  3 (2,5)  1 (2,4)  3 (2,5) 4 5 10 5 10  2 (4,8)  4 (6,12)  2 (4,8)  4 (6,12) 0 4 8 0 12 0 4 8 0 12 C i RM schedule (S = 2)  assuming C’ i = Rate Monotonic – First Fit or Best Fit A+B s  1 (1,4) 4 8 12 16 Core 1 (S = 1) Core 2 (S = 1)  3 (1,5) U = 0.9 U = 1 A  1  2 5 10 15  2 (2,8) B miss 4 8 8  3  4 deadline miss 16 8  4 (3,12) 0 5 10 0 12 0 12 23 24 4

  5. Course outline - 1 Course outline - 2 1. Motivation and examples 5. Multiprocessor scheduling  Architecture issues and modeling 2. Brief summary of uniprocessor analysis  Performance analysis  Scheduling paradigms 3. Interference analysis and techniques to reduce it  Temporal isolation  Task allocation and feasibility bounds  Resource reservations servers 6. Processor abstraction and interface  Hierarchical component-based systems  Efficient algorithms for the interface design.  Schedulability analysis of single components  Multiprocessor abstractions.  Resource sharing protocols for hierarchical systems  Applications models. 4. Energy-aware scheduling  Application partitioning and resource allocation Course outline - 3 7. Standards for component-based development  ARINC: a standard for avionic systems.  AUTOSAR a standard for automotive systems 8. Component-oriented programming and models  introduction to C++ patterns  UML models of components  code generation using patterns under Eclipse-EMF 9. Hypervisors  The Xen project  Guaranteeing real-time constraints on hypervisor- based systems 5

Download Presentation
Download Policy: The content available on the website is offered to you 'AS IS' for your personal information and use only. It cannot be commercialized, licensed, or distributed on other websites without prior consent from the author. To download a presentation, simply click this link. If you encounter any difficulties during the download process, it's possible that the publisher has removed the file from their server.

Recommend


More recommend