Download presentation
Presentation is loading. Please wait.
Published byClement Copeland Modified over 9 years ago
1
technische universiteit eindhoven Department of Electrical Engineering Electronic Systems Embedded Computer Architecture 5KK73 MPSoC Controlling the Parallel Resources
2
Electronic Systems flexibility efficiency DSP Programmable CPU Programmable DSP Application specific instruction set processor (ASIP) Application- specific processor
3
Electronic Systems 3 Contents GPUs revisited PicoChip Real-Time Scheduling basics Resource Management
4
Electronic Systems 4 GPU basics Synthetic objects are represented with a bunch of triangles (3d) in a language/library like OpenGL or DirectX plus texture Triangles are represented with 3 vertices A vertex is represented with 4 coordinates with floating-point precision Objects are transformed between coordinate representations Transformations are matrix-vector multiplications
5
Electronic Systems 5 GPU DirectX 10 pipeline
6
Electronic Systems 6 NVIDIA GeForce 6800 3D Pipeline
7
Electronic Systems 7 GeForce 8800 GPU 330 Gflops, 128 processors with 4-way SIMD
8
Electronic Systems 8 GPU: Why more general-purpose programmable? All transformations are shading Shading is all matrix-vector multiplications Computational load varies heavily between different sorts of shading Programmable shaders allow dynamic resource allocation between shaders Result: Modern GPUs are serious competitor for general-purpose processors!
9
Electronic Systems 9 Pico Chip
10
Electronic Systems 10 Pico Chip
11
Electronic Systems 11 Pico Chip
12
Electronic Systems 12 Fault-Tolerance
13
Electronic Systems 13 Pico Chip
14
Electronic Systems 14 Real-time systems (Reinder Bril) Correct result at the right time: timeliness Many products contain embedded computers, e.g. cars, planes, medical and consumer electronics equipment, industrial control. In such systems, it’s important to deliver correct functionality on time. Example: inflation of an air bag
15
Electronic Systems 15 Example: Multimedia Consumer Terminals DVD CDx front end YC interface IEEE 1394 interface DVB Tuner Cable modem CVBS interface VGA RF Tuner (by courtesy of Maria Gabrani)
16
Electronic Systems 16 Example: High quality video & real time original up-scaled Rendered stream: 60 Hz (TV screen) Input stream: 24 Hz (movie) TV companies invest heavily in video enhancement, e.g. temporal up-scaling
17
Electronic Systems 17 Example: High quality video & real time original up-scaled Input stream: 24 Hz (movie) TV companies invest heavily in video enhancement, e.g. temporal up-scaling displayed Deadline miss leads to “wrong” picture. Deadline misses tend to come in bursts (heavy load). Valuable work may be lost.
18
Electronic Systems 18 Real-time systems Guaranteeing timeliness requirements: real-time tasks with timing constraints scheduling of tasks Fixed-priority scheduling (FPS) is the de-facto standard for scheduling in real-time systems. FPS: supported by commercially available RTOS; analytic and synthetic methods.
19
Electronic Systems 19 Recap of FPS Fixed Priority Pre-emptive Scheduling (FPPS) A basic scheduling model Analysis Example Optimality of RMS and DMS
20
Electronic Systems 20 FPPS: A basic scheduling model Single processor Set of n independent, periodic tasks 1, …, n Tasks are assigned fixed priorities, and can be pre-empted instantaneously. Scheduling: At any moment in time, the processor is used to execute the highest priority task that has work pending.
21
Electronic Systems 21 FPPS: A basic scheduling model Task characteristics: period T, (worst-case) computation time C, (relative) deadline D, Assumptions: non-idling; context switching and scheduling overhead is ignored; execution of releases in order of arrival; deadlines are hard, and D T; 1 has highest and n has lowest priority. No data-dependencies between tasks
22
Electronic Systems 22 FPPS: Example Worst-case response time WR for task 3: First point in time that 1, 2, and 3 are finished time 0102030405060 Task 1 Task 3 Task 2 12 1 6543 23 WR 3 = 56 WR 2 = 17 WR 1 = 3
23
Electronic Systems 23 FPPS: Analysis Schedulable iff: WR i D i for 1 i n Necessary condition: Sufficient condition for RMS: U LL(n) = n (2 1/ n – 1), i.e. i > j iff T i < T j ; D i = T i.
24
Electronic Systems 24 FPPS: Analysis Otherwise, i.e. U 1 and not RMS, or n (2 1/ n – 1) < U < 1 and RMS exact condition: Critical instant: simultaneous release of i with all higher priority tasks WR i is the smallest positive solution of
25
Electronic Systems 25 FPPS: Example Task set Γ consisting of 3 tasks: Notes: RM priority assignment and D i = T i (RMS); U 1 + U 2 + U 3 = 0.97 1, hence Γ could be schedulable; Utilization bound: U( n ) LL( n ) = n (2 1/ n – 1): U 1 + U 2 = 0.88 > LL(2) 0.83, therefore U (3) > LL(3), hence another test required. TaskPeriod T Computation time C Utilization U 11 1030.3 22 19110.58 33 5650.09
26
Electronic Systems 26 FPPS: Example Time line time 0102030405060 Task 1 Task 3 Task 2 12 1 6543 23 WR 3 = 56 WR 2 = 17 WR 1 = 3
27
Electronic Systems 27 FPPS: Optimality of RMS and DMS Priority assignment policies: Rate Monotonic (RM): i > j iff T i < T j Deadline Monotonic (DM): i > j iff D i < D j Under arbitrary phasing: RMS is optimal among FPS when D i = T i ; DMS is optimal among FPS when D i T i, where optimal means: if an FPS algorithm can schedule the task set, so can RMS/DMS.
28
Electronic Systems FPPS not suitable for multimedia multiprocessor!! Assumptions: context switching and scheduling overhead is ignored; No longer true deadlines are hard, and D T; No longer true 1 has highest and n has lowest priority: No prorities No data-dependencies between tasks: not true Single processor: not true 28
29
Electronic Systems 29 Non-Preemptive Systems (Akash Kumar) State-space needed is smaller Lower implementation cost Less overhead at run-time Cache pollution, memory size Task
30
Electronic Systems 30 Why FPS doesn’t work for “future” high-performance platforms Heavy-duty DSPs: Preemption not supported If it was: Context switching is significant Data-dependencies not taken into account Multi-processor
31
Electronic Systems 31 Related Research – Feasibility Analysis Preemptive Non-Preemptive Homogeneous MPSoC [Liu, Layland, 1973] Heterogeneous MPSoC [Jeffay, 1991] [Baruah, 2006] [, 2020??] A B C D P1P2P3 P4P5P6
32
Electronic Systems 32 Unpredictability – Variation in Execution Time P1 P2 P3 50 A B 49 A B
33
Electronic Systems 33 Problem No good techniques exist to analyze and schedule applications on non- preemptive heterogeneous systems Resource Manager proposed to schedule applications such that they meet their performance requirements on non- preemptive heterogeneous systems
34
Electronic Systems 34 Our Assumptions Heterogeneous MPSoC Applications modeled as SDF Non-preemptive system – tasks can not be stopped Jobs can be suspended Lot of dynamism in the system Jobs arriving and leaving at run-time Variation in execution time Very simple arbiter at cores A2 B2 C2 D2 Job Task
35
Electronic Systems 35 Resource Manager Resource Manager Reconfigure to meet above quality milliseconds Local Processor Arbiter Task level micro sec A B Core Application QoS Manager Application level few sec
36
Electronic Systems 36 Architecture Description Computation resources available are described Each processor can have different arbiter In this model First Come First Serve mechanism is used Resource manager can configure/control the local arbiters: to regulate the progress of application if needed P1P2P3 Resource Manager Local Arbiter
37
Electronic Systems 37 Resource Manager Responsible for two main things Admission control Incoming application specifies throughput requirement Execution-time and mapping of each actor Repetition vector used to compute expected utilization RM checks if enough resources present Allocates resources to applications if admitted
38
Electronic Systems 38 Admission Control P1 P2P3 Typing Sms Video Conf Play MP3 Resource Reqmt Exceeded!
39
Electronic Systems 39 Resource Manager Admission control Budget enforcement When running, each application signals RM when it completes an iteration RM keeps track of each application’s progress Operation modes ‘Polling’ mode ‘Interrupt’ mode Suspends application if needed
40
Electronic Systems 40 Budget Enforcement (Polling) Performance goes down! Resource Manager Better than required! New job enters! job suspended! job resumed!
41
Electronic Systems 41 Experiments A high-level simulation model developed POOSL – a parallel simulation language used A protocol for communication defined System verified with a number of application SDF models Case study done with H263 and JPEG application models Impact of varying ‘polling’ interval studied
42
Electronic Systems 42 Performance without Resource Manager
43
Electronic Systems 43 Performance with RM – I (2.5m cycles)
44
Electronic Systems 44 Performance with RM – II (500k cycles)
Similar presentations
© 2025 SlidePlayer.com. Inc.
All rights reserved.