Peter Poplavko, Saddek Bensalem, Marius Bozga Mixed-Critical Systems Design with Coarse-grained Multi-core Interference Rany Kahil, Peter Poplavko, Saddek Bensalem, Marius Bozga

Motivation Autonomous systems need to adapt to unpredictable situations - adaptive resource management => give resources to critical functions in emergency mixed-criticality – switch to emergency mode even in the middle of a schedule Multi-core systems we consider compute-intensive and hence multi-core applications there are no clear “winners” / standards for scheduling on multi-cores need in high-level concurrency language for programming middleware interference : parasitic influences between multiple cores task dependencies are more challenging to handle on multi-cores => Need in mixed-criticality / interference / task-dependency aware resource management in high-level concurrency language Proposed Design Flow and mapping of the required activities to the work program task structure

Plan Our approach to three dimensions of the problem: Resource management in concurrency programming language – BIP Timing-critical system design with task dependencies – MoC Controlling multi-core interference at task level – -model Design flow Conclusions and Future Work Proposed Design Flow and mapping of the required activities to the work program task structure

Plan Our approach to three dimensions of the problem: Resource management in concurrency programming language – BIP Timing-critical system design with task dependencies – MoC Controlling multi-core interference at task level – -model Design flow Conclusions and Future Work Proposed Design Flow and mapping of the required activities to the work program task structure

SW Model Automata SW Model Compiled to a “Concurrency Language” The BIP Framework SQR_Start S1 Arrive reset x SQR_Finish Deadline when [ x = T ] Task Controller ( T ) void SQR_Init() { index = 0; } void SQR_Execute() { XIF_Read(&x, &x_valid); if (x_valid) { y = x * x; YIF_Write(&y); index = index + 1; provided interface period T discrete transition continuous transition port when [x = T] timing condition [ valid ] data condition reset x timing action y := x*x data action multi-port connector state SW Model Automata required interfaces

BIP Representation of the System Distr. System Node ? TC1 Resource Manager TC2 TC3 Dependency Pattern (MoC) Remote Node T1 Output Queue Inpuit Queue Network T2 T1 T2 T3 Proposed Design Flow and mapping of the required activities to the work program task structure

Mixed Criticality Resource Managament Normal Mode Emergency Mode Shared Resources Shared Resources HI LO mode switch HI Proc. Cores HI LO Proc. Cores HI LO Utilization, % Utilization, % HI - high critical tasks LO – low-critical tasks Proposed Design Flow and mapping of the required activities to the work program task structure

Resource Manager in BIP: Example Proposed Design Flow and mapping of the required activities to the work program task structure

Plan Our approach to three dimensions of the problem: Resource management in concurrency programming language – BIP Timing-critical system design with task dependencies – MoC Controlling multi-core interference at task level – -model Design flow Conclusions and Future Work Proposed Design Flow and mapping of the required activities to the work program task structure

Task dependency patterns (Models of Computation) Common Scheduling = Independent Task Model (ITM) however tasks are functionally dependent therefore, the schedule needs manual adjustments (problematic) The most expressive task model = Task Automata Model (TAM) can model virtually any dependencies problems: TAM schedulability analysis is not scalable Our approach: ITM < Dependency Pattern (MoC) < TAM we use TAM language (“BIP”) to represent dependency patterns this results in a scalable (though MoC-specific) schedulability analysis Proposed Design Flow and mapping of the required activities to the work program task structure

Our Current MoC: FPPN Common Scheduling = Independent Task Model (ITM) however tasks are functionally dependent therefore, the schedule needs manual adjustments The most expressive task model = Task Automata Model (TAM) can model virtually any dependencies problems: TAM schedulability analysis (e.g. UPPAAL) is not scalable Our approach: ITM < FPPN < TAM we use TAM language “BIP” and follow FPPN dependency patterns in it scalable, though FPPN-specific, schedulability analysis Fixed Priority Process Network (FPPN) - connected periodic / sporadic tasks - access data samples in time-stamp and precedence-consistent order Sink1 200ms Source1 Stage1 100ms Stage2 FPPN scheduling - static task graph - precedence-aware utilization - DAG scheduling heuristics - end-to-end latency constraints Proposed Design Flow and mapping of the required activities to the work program task structure

Dependency Pattern Example B A T=100 C=60 B T=200 C=60 shared 100 200 time A1 B1 A2 Wanted Schedule: (access order to shared buffer): End-to-end A-to-B latency Lmax = 120 The “language” of possible task sequences, e.g. (ABA)* Proposed Design Flow and mapping of the required activities to the work program task structure

Scheduling with Dependency Patterns (MoCs) Offline Scheduling Tool A [0,100] b [0,200] Task Graph A B Resource Manager Dependency Pattern Extract Schedule Constraints TCtrl1 TCtrl2 TCtrl3 TCtrl4 Task1 Task2 Task3 Task4

Plan Our approach to three dimensions of the problem: Resource management in concurrency programming language – BIP Timing-critical system design with task dependencies – MoC Controlling multi-core interference at task level – -model Design flow Conclusions and Future Work Proposed Design Flow and mapping of the required activities to the work program task structure

Interference Interference Interference occurs in multi-core systems Shared hardware resources: global bus, IO, even FPU,… Shared logical resources: critical regions in OS services Fine-grain (sporadic) and coarse-grain (concentrated) fine-grain= basic blocks coarse-grain: “superblocks” Consequences Uncontrolled interference => tasks take more cycles than WCET Over-controlled interference => run tasks fully sequentially We choose “something in the middle” Proposed Design Flow and mapping of the required activities to the work program task structure

Interference in Scheduling -  Model coarse-grain interference  suppose: superblock followed by execution-block if scheduled at the same time – interference controlled interference: schedule J1 after J3 “resource” BIP representation logical resource = “engine” (controllers + RTE) Resource Manager Dependency Pattern Task1 TCtrl1 Task2 TCtrl2 Task3 TCtrl3 Task4 TCtrl4 Resource Manager Dependency Pattern Task1 TCtrl1 Task2 TCtrl2 Task3 TCtrl3 Task4 TCtrl4 processors engine superblock = BIP transition, cost  other coarse-grained block: (e.g. of L2, FPU, etc) add controller, implement as BIP transition(s) not modeled: fine-grained interference: nevertheless, time-triggered schedule => improved predictability Proposed Design Flow and mapping of the required activities to the work program task structure

Plan Our approach to three dimensions of the problem: Resource management in concurrency programming language – BIP Timing-critical system design with task dependencies – MoC Controlling multi-core interference at task level – -model Design flow Conclusions and Future Work Proposed Design Flow and mapping of the required activities to the work program task structure

novelties and limitations: Design Flow novelties and limitations: task graph extraction Multi-Core Platform Task Automata Generator ( Dependency Patterns + Tasks) Res Man. Configuration BIP Compiler Task Model + Resource Manager (BIP) BIP RTE Static Schedule SW Model Interface Structure Functional-Code (C) Offline Scheduler Task Graph  interference model added scheduling with  model WIP as task migration not yet supported in BIP RTE WIP Proposed Design Flow and mapping of the required activities to the work program task structure

Application Specification in SW Model 25ms split 25ms B 25ms Proposed Design Flow and mapping of the required activities to the work program task structure

Task Graph Extraction Ji : Ai = 0, Di = 25 ms ,  = 1 ms SW Model Interface Structure Functional-Code (C) Task Graph J1 A [1] (12) ms J2 split [1] (1) ms J3 B [1] (6) ms Ji : Ai = 0, Di = 25 ms ,  = 1 ms Proposed Design Flow and mapping of the required activities to the work program task structure

Modeling Engine Interference in Task Graph Start S1 Arrive reset x Finish Deadline when [ x = T ] Task Controller arri (0) ddli (0) insert TC transition nodes Ji (Ci) Ji (Ci) BIP Engine (or Shared Res)  fini (0) insert  nodes Core k Ji nodej (Cj) nodej (Cj) engj () Time

 interference model added Static Schedule  interference model added Proposed Design Flow and mapping of the required activities to the work program task structure

Code Generation SW Model core0 cPeriodicSourcesplit core0 cRelDlSinksplit core0 cPeriodicSourceprocessb core0 cRelDlSinkprocessb core0 cPeriodicSourceprocessa core0 cRelDlSinkprocessa core0 xmailbox_ins core0 xmailbox2_ins core0 Prec_split_processb core0 Prec_split_processa core1 split_ins core1 processa_ins core2 processb_ins Multi-Core Platform Task Automata Generator ( Dependency Patterns + Tasks) BIP Compiler Task Model Resource Manager (BIP) BIP RTE SW Model Interface Structure Functional-Code (C) Dependency Pattern Task1 TCtrl1 Task2 TCtrl2 Task3 TCtrl3 Proposed Design Flow and mapping of the required activities to the work program task structure

Simulation on Workstation Multi-Core Platform Task Automata Generator ( Dependency Patterns + Tasks) BIP Compiler Task Model (BIP) BIP RTE SW Model Interface Structure Functional-Code (C) assert@SW Modelvm:~/poplavko/MCS_TOOLS/SW Model2bip/examples/parallelproc/fppn$ ./fppn-dolc_SWModel.bip.x --realtime --limittime 25 Running "realtime" mode BIP multi-threaded engine. Version: Engines: MixedCriticalSystems@6808 No. of atoms in system = 13 No. of threads in system = 3 Limit time = 25 ====> LAUNCH: <==== scheduler [0] BIP_Top.cPeriodicSourceprocessb.Arrive|BIP_Top.cRelDlSinkprocessb.Arrive|BIP_Top.Prec_split_processb.ArriveB [0,0] eager scheduler [0] BIP_Top.cPeriodicSourceprocessa.Arrive|BIP_Top.cRelDlSinkprocessa.Arrive|BIP_Top.Prec_split_processa.ArriveB [0,0] eager scheduler [0] BIP_Top.cPeriodicSourcesplit.Arrive|BIP_Top.cRelDlSinksplit.Arrive|BIP_Top.Prec_split_processb.ArriveA|BIP_Top.Prec_split_processa.ArriveA [0,0] eager scheduler [0] BIP_Top.cPeriodicSourcesplit.Start|BIP_Top.split_ins.Start|BIP_Top.Prec_split_processb.StartA|BIP_Top.Prec_split_processa.StartA [0,25ms] eager scheduler [1ms211us] BIP_Top.split_ins.DOLC_write_p_PROC_XIF_Write_call|BIP_Top.xmailbox_ins.Write [_,_] eager scheduler [1ms212us] BIP_Top.xmailbox_ins.WriteAck|BIP_Top.split_ins.DOLC_write_return [_,_] eager USER_PROCESS> --------------------------------------- USER_PROCESS> Split wrote 212.000000 scheduler [1ms261us] BIP_Top.split_ins.DOLC_write_p_PROC_XIF_Write2_call|BIP_Top.xmailbox2_ins.Write [_,_] eager scheduler [1ms295us] BIP_Top.xmailbox2_ins.WriteAck|BIP_Top.split_ins.DOLC_write_return [_,_] eager USER_PROCESS> Split wrote(2) 2120.000000 Proposed Design Flow and mapping of the required activities to the work program task structure

Execution on Target Platform core0 cPeriodicSourcesplit core0 cRelDlSinksplit core0 cPeriodicSourceprocessb core0 cRelDlSinkprocessb core0 cPeriodicSourceprocessa core0 cRelDlSinkprocessa core0 xmailbox_ins core0 xmailbox2_ins core0 Prec_split_processb core0 Prec_split_processa core1 split_ins core1 processa_ins core2 processb_ins Multi-Core Platform Task Automata Generator ( Dependency Patterns + Tasks) BIP Compiler Task Model (BIP) BIP RTE SW Model Interface Structure Functional-Code (C) Executing on LEON4 Proposed Design Flow and mapping of the required activities to the work program task structure

Conclusions We have presented a work-in-progress design flow for mixed-critical multi-cores We have prototype tools and examples Future work on multi-cores Finalize support of task migration Finalize integration of offline scheduler and (online) resource manager Integration with WCET measurement tools Full support of bandwidth interference ( beyond  model) Integration with interference measurement tools Handling cache interference Proposed Design Flow and mapping of the required activities to the work program task structure