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

2. 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

3. 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

4. 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

5. 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

6. 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

7. 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

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

9. 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

10. 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

11. 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

12. Dependency Pattern ExampleB 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

13. 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

14. 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

15. 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

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

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

18. 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

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

20. 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

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

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

23. 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

24. 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)
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:
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
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)
Proposed Design Flow and mapping of the required activities to the work program task structure

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

26. 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