Presentation is loading. Please wait.

Presentation is loading. Please wait.

Technische universiteit eindhoven Department of Electrical Engineering Electronic Systems Platform-based Design 5KK70 MPSoC Controlling the Parallel Resources.

Similar presentations


Presentation on theme: "Technische universiteit eindhoven Department of Electrical Engineering Electronic Systems Platform-based Design 5KK70 MPSoC Controlling the Parallel Resources."— Presentation transcript:

1 technische universiteit eindhoven Department of Electrical Engineering Electronic Systems Platform-based Design 5KK70 MPSoC Controlling the Parallel Resources

2 Electronic Systems 2 Contents  GPUs  PicoChip  Real-Time Scheduling basics  Resource Management

3 Electronic Systems 3 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

4 Electronic Systems 4 GPU DirectX 10 pipeline

5 Electronic Systems 5 NVIDIA GeForce 6800 3D Pipeline

6 Electronic Systems 6 GeForce 8800 GPU 330 Gflops, 128 processors with 4-way SIMD

7 Electronic Systems 7 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!

8 Electronic Systems 8 Pico Chip

9 Electronic Systems 9 Pico Chip

10 Electronic Systems 10 Pico Chip

11 Electronic Systems 11 Fault-Tolerance

12 Electronic Systems 12 Pico Chip

13 Electronic Systems 13 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

14 Electronic Systems 14 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)

15 Electronic Systems 15 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

16 Electronic Systems 16 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.

17 Electronic Systems 17 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.

18 Electronic Systems 18 Recap of FPS  Fixed Priority Pre-emptive Scheduling (FPPS)  A basic scheduling model  Analysis  Example  Optimality of RMS and DMS

19 Electronic Systems 19 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.

20 Electronic Systems 20 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

21 Electronic Systems 21 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.

22 Electronic Systems 22 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

23 Electronic Systems 23 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 11 1030.3 22 19110.58 33 5650.09

24 Electronic Systems 24 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

25 Electronic Systems 25 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.

26 Electronic Systems 26 Non-Preemptive Systems (Akash Kumar)  State-space needed is smaller  Lower implementation cost  Less overhead at run-time  Cache pollution, memory size Task

27 Electronic Systems 27 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

28 Electronic Systems 28 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

29 Electronic Systems 29 Unpredictability – Variation in Execution Time P1 P2 P3 50 A B 49 A B

30 Electronic Systems 30 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

31 Electronic Systems 31 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

32 Electronic Systems 32 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

33 Electronic Systems 33 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

34 Electronic Systems 34 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

35 Electronic Systems 35 Admission Control P1 P2P3 Typing Sms Video Conf Play MP3 Resource Reqmt Exceeded!

36 Electronic Systems 36 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

37 Electronic Systems 37 Budget Enforcement (Polling) Performance goes down! Resource Manager Better than required! New job enters! job suspended! job resumed!

38 Electronic Systems 38 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

39 Electronic Systems 39 Performance without Resource Manager

40 Electronic Systems 40 Performance with RM – I (2.5m cycles)

41 Electronic Systems 41 Performance with RM – II (500k cycles)


Download ppt "Technische universiteit eindhoven Department of Electrical Engineering Electronic Systems Platform-based Design 5KK70 MPSoC Controlling the Parallel Resources."

Similar presentations


Ads by Google