Presentation is loading. Please wait.

Presentation is loading. Please wait.

Technische universiteit eindhoven Department of Electrical Engineering Electronic Systems Embedded Computer Architecture 5KK73 MPSoC Controlling the Parallel.

Similar presentations


Presentation on theme: "Technische universiteit eindhoven Department of Electrical Engineering Electronic Systems Embedded Computer Architecture 5KK73 MPSoC Controlling the Parallel."— Presentation transcript:

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 11 1030.3 22 19110.58 33 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)


Download ppt "Technische universiteit eindhoven Department of Electrical Engineering Electronic Systems Embedded Computer Architecture 5KK73 MPSoC Controlling the Parallel."

Similar presentations


Ads by Google