1 / 38

Abstract RTOS Modelling for Multi-Processor SoC using SystemC

Abstract RTOS Modelling for Multi-Processor SoC using SystemC. Prof. Jan Madsen Informatics and Mathematical Modelling Technical University of Denmark Richard Petersens Plads, Building 321 DK2800 Lyngby, Denmark. 3. 2. 1. 4. 1. 2. 3. 4. os. mapping. a. b. c. c. a. b.

edesiree
Télécharger la présentation

Abstract RTOS Modelling for Multi-Processor SoC using SystemC

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Abstract RTOS Modelling for Multi-Processor SoC using SystemC Prof. Jan Madsen Informatics and Mathematical Modelling Technical University of Denmark Richard Petersens Plads, Building 321 DK2800 Lyngby, Denmark

  2. 3 2 1 4 1 2 3 4 os mapping a b c c a b Motivation Jan Madsen

  3. 1 2 Break processes to increase parallelism 3 Cluster processes to reduce communication deadline b a a 2 & 3 1 b Principles of mapping Partitioning/clustering Allocation Mapping Scheduling Communication 1 3 2 Jan Madsen

  4. rtos rtos rtos rtos b c d a network Motivation Jan Madsen

  5. rtos rtos rtos rtos b c d a network Uni-processor ... Jan Madsen

  6. rtos a Uni-processor ... Frameworkto experiment with different RTOS strategies Focus on analysis of timingand resource sharing Abstract software model, i.e. no behavior/functionality Easyto create tasks and implement RTOS models Based on SystemC Jan Madsen

  7. rtos a System model Jan Madsen

  8. rtos System model Jan Madsen

  9. rtos System model Jan Madsen

  10. Task messages: ready finished RTOS commands: run preemept Resume task rtos links scheduler System model Jan Madsen

  11. rtos identifier offset period WCET priority System model - SystemC pa = new task("task_a",1,50,3,12,0,ready); registerTask(pa); pb = new task("task_b",2,40,2,10,0,ready); registerTask(pb); pc = new task("task_c",3,30,1,10,0,ready); registerTask(pc); Jan Madsen

  12. Aim: Adding tasks without having to create seperate communication links Uses the SystemC master-slave library If two tasks send a message at the same time – they are executed in sequence, but in undefined order Global ”clock” is used to keep track of time clock rtos Link model Jan Madsen

  13. r1 s1 e1 d1 T1 o1 r1 = time at which task becomes released (or active) s1 = time at which task starts its execution e1 = worst case execution time (WCET) d1 = deadline, task should complete before this! T1 = period, minimum time between task releases o1 = offset (or phase) for first released Task model 1 Jan Madsen

  14. !run Cp>0 Cp==0 ready ready idle Cr==0 finish run !resume !preempt preempt & Cr>0 running preempt resume Task model Jan Madsen

  15. new_state state Task model - SystemC SC_MODULE(perTask){ sc_outmaster<message_type> out_message; sc_inslave<message_type> in_command; sc_in_clk clock; sc_event newStateEvent; void next_state(); void update_state(); void get_comm_from_scheduler(); SC_HAS_PROCESS(perTask); perTask(sc_module_name name_, int id_, ...) : sc_module(name_),id(id_), ...) { SC_METHOD(next_state); sensitive << newStateEvent; SC_METHOD(update_state); sensitive << clock; SC_SLAVE(get_comm_from_scheduler,in_command); } private: t_state state, new_state; Jan Madsen

  16. Aim: Simple way to describe the scheduling algorithm Scheduler should only handle one message at a time Rate-monotonic scheduling preemptive WCET d=T Fixed priority rtos scheduler Scheduling model Jan Madsen

  17. Scheduling model - SystemC Rate monotonic scheduling • ti: message received from from task i • tj: message from task j with highest priority from ready list • tk: message of the currently running task void RM_scheduler::doSchedule() { ti = in_message; if (ti.comm==ready) { Q.push(ti); } else { tk.id = 0; } tj = Q.top(); if (tj.id != 0) { if (tk.id != 0) { if (tk < tj) { out_command = *(preemptTask(&tk, &Q)); tk = tj; out_command = *(runTask(&tj, &Q)); } else { } } else { tk = tj; out_command = *(runTask(&tj, &Q)); } } else { } } Jan Madsen

  18. 2 1 3 3 2 1 An example Ti ei priority 50 12 1 40 10 2 30 10 3 50 p1 40 p2 30 p3 0 10 20 30 40 50 60 Jan Madsen

  19. 2 1 3 50 p1 40 p2 30 p3 0 10 20 30 40 50 60 An example Jan Madsen

  20. r1 s1 d1 emin emax Extending the task model • Varying execution times [emin:emax] 1 T1 Jan Madsen

  21. r1 s1 d1 Extending the task model • Varying execution times [emin:emax] • Context switching • Data dependencies 1 T1 Jan Madsen

  22. synchronizer scheduler Data dependencies Jan Madsen

  23. synchronizer allocator scheduler Resource sharing Jan Madsen

  24. rtos rtos rtos rtos b c d a network Multi-processors Jan Madsen

  25. rtos rtos rtos rtos b c d a network Multi-processors Jan Madsen

  26. rtos rtos rtos rtos b c Multi-processors Jan Madsen

  27. synchronizer scheduler scheduler Multi-processors Jan Madsen

  28. 4 2 2 1 2 3 1 1 4 3 3 4 os os a b Example Jan Madsen

  29. 2 4 RM RM 1 1 3 a 2 0 2 4 6 8 10 12 14 16 3 b 4 0 2 4 6 8 10 12 14 16 Dynamic scheduling os os a b Jan Madsen

  30. 2 4 3 1 Changing synchronization protocol RM EDF 1 a 2 os os a b 0 2 4 6 8 10 12 14 16 3 b 4 0 2 4 6 8 10 12 14 16 Jan Madsen

  31. Multi-processing anomalies • Assume a set of tasks optimally scheduled on a multiprocessor system with: • fixed number of processors • fixed execution times (ei) • precedence constraints • Then • changingthe priority list • increasingthe number of processor • reducing execution times • weakening the precedence constraints • May increase the scheduling length! Jan Madsen

  32. 2 1 2 1 3 5 4 3 4 5 1 2 a a b b 3 4 5 Example of anomalies Task 2 and 4 are sharing a resource, i.e. mutually exclusion Reduce e1 of task 1 Jan Madsen

  33. Consequences of anomalies • Tasks may complete before their WCETs • So most on-line scheduling algorithms are subject to experience anomalies • Simple but inefficient solution: • Have tasks completing early idle Jan Madsen

  34. 1 2 3 5 2 1 4 mx my mz 3 4 5 os os os a b c L1 L2 S1 S2 S3 L3 Network-on-Chip extension mx: S1,L3,S3,L2,S2 Jan Madsen

  35. Network-on-Chip model Jan Madsen

  36. 1,2 a 3b 4,5 c 3b 4,5 c 1,2 a 3b 4,5 c 1,2 a L1 L2 L1 L2 L3 L4 L3 a 1 2 a a 1 2 L1 L1 z x 3 b Timing Aware b b 3 4 c y x L2 L2 z y 1 2 2 2 x z bus c c 4 4 L3 L3 x y z 5 5 5 5 5 5 bus a 1 2 1 a 2 QoS Aware Any traffic from a has higher priority a 2 1 L1 L1 z x 3 b 3 b b 3 y x L2 5 4 c L2 z c 5 4 y z x c 5 4 bus x L3 z 1 1 L3 y a a a 2 L1 y x z L1 Allocation Aware Swap task on PEs to: 2,3 | 4,5 | 1 b 4 b b 3 c L2 L3 x z x c c y x z bus L3 z x L4 y 3 3 4 4 3 1 Design space exploration Jan Madsen

  37. Summary • Simple SystemC based framework to study the dynamic behavior of a task set running under the supervision of an abstract RTOS • Synchronizer to handle data dependencies • Extension to multi-processor/RTOS systems • Network-on-Chip extension (new) • Not covered, • Allocator to handle resource sharing • Power estimation/profile • Multi-processing anomalies (in your slides) Jan Madsen

  38. References • Scheduling in Real-Time SystemsF. Cottet, J. Delacriox, C. Kaiser, Z. MammeriJohn Wiley & Sons, 2002 • Real-Time SystemsJ. W. S. LiuPrintice Hall, 2000 • Real-Time Systems and Programming LanguagesA. Burns, A. WellingsAddison-Wesley, 2001 (third edition) • System Design with SystemCT. Grotker, S. Liao, G. Martin, S. SwanKluwer, 2002 Jan Madsen

More Related