Achieving Predictable Multicore Execution of Automotive Applications Using the LET Paradigm

Size: px

Start display at page:

Download "Achieving Predictable Multicore Execution of Automotive Applications Using the LET Paradigm"

Ralph Chapman
5 years ago
Views:

1 Achieving Predictable Multicore Execution of Automotive Applications Using the LET Paradigm Alessandro Biondi and Marco Di Natale Scuola Superiore Sant Anna, Pisa, Italy

Lack of appropriate modeling for partitioning applications Legacy SW with causality implicitly verified on single core Need for a

2 Introduction The introduction of safety-critical functions in automotive systems, together with the advent of multicore platforms, brings the need to rethink the development and execution paradigms for embedded functionality Several issues in switching to multicores Lack of appropriate modeling for partitioning applications Legacy SW with causality implicitly verified on single core Need for a portable timing model Achieving timing predictability is not trivial plus increasingly stringent legal regulations and certifiability requirements 2

3 Logical Execution Time Logical Execution Time (LET) introduced as a method to eliminate output jitter and provide determinism in the implementation of control algorithms [Henzinger et al. 2003] LET can be realized with different scheduling strategies provided that the desired semantic is respected Classical design prone to large input/output jitter LET input output/action 3

4 Logical Execution Time Recent renewed attention on LET by automotive industry Several players are adopting LET to provide deterministic end-toend latencies of chains of communicating tasks LET seems a promising solution to also solve other issues in the design and development of real- systems (e.g., SW portability, interface with control engineers, etc.) 5ms Task 10ms Task 20ms Task Example from Dirk Ziegenbein s talk at Dagstuhl seminar on LET 4

5 This Talk 1 Scheduling strategy for realizing LET communication in multicore platforms to achieve execution predictability 2 Implementation on Aurix Tricore TC275 and evaluation with a pseudo-realistic case study (WATERS Challenge 2017 by Bosch) 5

6 Platform & System Model Partitioned Fixed-Priority Scheduling periodic tasks with constrained deadlines T2 T1 T5 T4 T3 T7 T6 T8 CPU 0 CPU 1 CPU 2 CPU 3 core local memory (scratchpad) LM 0 LM 1 LM 2 LM3 Crossbar global memory GM provides point-to-point communication between each core and memory 6

7 Inter-task Communication l Tasks communicate by means of labels, i.e., atomic shared variables (size processor word) Realistic applications include thousands of labels, as witnessed by the 2017 WATERS Challenge data provided by Bosch Communications through labels originate causality dependencies and task chains, typically also across different cores 10ms, CPU#0 l l Task 1 Task 2 Task 3 l 5ms, CPU#2 l l 20ms, CPU#0 7

8 LET AS AN OPPORTUNITY TO CONTROL MEMORY CONTENTION

9 Memory contention Contention in accessing shared memories strongly harms the predictability of software running upon multicores Any- access to shared memories carries considerable pessimism in timing/schedulability analysis We like simple models a sustainable analysis have to consider that memory accesses are ordered such that contention is maximized Bounds on worst-case response s tend to be large CPU #0 under analysis Contention delay Memory access CPU #1 CPU #2 9

10 Controlling Memory Contention Selling point: scheduling LET communication at the beginning of periodic instances allows localizing the access to shared memories in precise windows Such windows are determined by the tasks periods they are hence predictable (off-line) and can host explicit arbitration to avoid contention 10

Realizing LET Communication Local copies of data allocated in the scratchpads Shared copies allocated in the global memory LET communication stack moves data from global to local

11 Realizing LET Communication Local copies of data allocated in the scratchpads Shared copies allocated in the global memory LET communication stack moves data from global to local memories and viceversa LET comm read write Task Preemptable task execution with contention-free accesses to local memory CPU 0 CPU 1 CPU 2 CPU 3 l LM 0 LM 1 LM 2 LM3 Crossbar GM l 11

12 Realizing LET Communication Understanding & Modeling the timing of LET communications Coordination of LET communications across cores (controlling the access to global memory) 12

13 LET Timing: Logical View Understanding LET timing: not all reads and writes are actually necessary Write (output) Read (input) τ 1 producer τ 2 consumer (undersampling) τ 3 consumer τ 4 producer (oversampling) 13

14 LET Timing: Scheduling LET task τ 1 producer τ 2 consumer (undersampling) τ 3 consumer τ 4 producer (oversampling) 14

15 LET Tasks LET task τ 1 producer τ 2 consumer τ 3 consumer Generalized Multi-Frame (GMF) Task Variable frames with different inter-arrival and (undersampling) execution s Each frame consists in a set of read/write operations Frames are cyclically repeated and can be determined off-line as a function of the tasks periods and the communication map τ 4 producer (oversampling) 15

16 Realizing LET Communication Understanding & Modeling the timing of LET communications Coordination of LET communications across cores (controlling the access to global memory) 16

17 LET Tasks: Synchronization One GMF Task running at the highest priority in each core to implement LET communication Access to shared memory is regulated by lightweight spin-based synchronization CPU #0 CPU #1 CPU #2 Write (output) Read (input) Busy waiting 17

18 LET Tasks: Synchronization One GMF Task running at the highest priority in each core to implement LET communication Access to shared memory is regulated by lightweight spin-based synchronization Write Read Update shared copy of data (copy from local memory to global memory) Read shared copy of data (copy from global memory to local memory) Avoid contention when accessing the global memory (explicit synchronization) removing pessimism in the analysis Limited jitter X Potential priority inversion due to high-priority communication 18

LET and AUTOSAR RTE The GMF tasks implementing the LET communication can be automatically generated as part of the AUTOSAR RTE Our approach is prone for being implemented in a modelbased design flow

19 LET and AUTOSAR RTE The GMF tasks implementing the LET communication can be automatically generated as part of the AUTOSAR RTE Our approach is prone for being implemented in a modelbased design flow Integration within AUTOSAR RTE takes care of mirroring local copies according to the LET paradigm RTE offers an API to access the local copies Local copies are accessed with explicit communication RTE LET task from global to local from local to global Application Contention-free accesses to local memory τ i 19

20 IMPLEMENTATION

abstract model introduced before RTOS: Implementation based on ERIKA Enterprise v2

21 Implementation Reference platform: Infineon Aurix TC275 Asymmetric Tricore with scratchpads Widely adopted by the automotive industry Can be configured to match the abstract model introduced before RTOS: Implementation based on ERIKA Enterprise v2 OSEK certified De-facto representative of the typical behavior of AUTOSAR Oses Open-source 21

22 Aurix TC27x Global memory Local (scratchpad) data memories source: TC27x datasheet 22

23 Implementation (1) The implementation required facing with three major issues: 1. Synchronization of task activations across cores Solved using remote procedure call (RPC) features available in ERIKA Single r connected to an OSEK counter handled in CPU #0 CPU #0 uses RPC to activate the tasks in all the cores by means of OSEK alarms (inter-core interrupts are leveraged) HW Timer INT OSEK counter CPU 0 CPU 1 CPU 2 RPC RPC 23

24 Implementation (2) The implementation required facing with three major issues: 2. Realization of GMF tasks Memory vs. trade-off Possible approach: scheduling table Potentially needs to store information up to the hyper-period It would introduce a lot of duplicate information Hint: We are dealing with specific instances of GMF tasks! Leveraging some analytical properties of LET timing, GMF tasks can be implemented with counters for each pair of communicating tasks Need to keep track to the next activation LET task Need to determine which communications must be performed 24

25 Implementation (3) The implementation required facing with three major issues: 3. Inter-core synchronization to access global memory Similar strategy as for Mellor-Crummey & Scott locks Spin variables allocated to local scratchpads Each core can directly access all local scratchpads, hence making notification of a spinning core easy (baton passing) Need to pay attention to achieve sequential consistency (barriers with DSYNC) spin CPU 0 CPU 1 CPU 2 CPU 3 LM0 LM1 LM2 LM3 notify Crossbar GM 25

cores of the TC275 ~5000 labels (atomic variables) used by the tasks to communicate Experimental setup Infineon

26 Case Study Implementation tested with a case study Mock application generated from the model provided by Bosch for the WATERS 2017 challenge representative of an engine control application ~20 tasks partitioned into the three cores of the TC275 ~5000 labels (atomic variables) used by the tasks to communicate Experimental setup Infineon TriBoard v2 with 200MHz ERIKA Enterprise v2.7 HIGHTECH Aurix C compiler v4.6 Lauterbach PowerTrace-II & PowerDebug 26

27 Code Generation WATERS 2017 Challenge provided by Bosch Amalthea model (XML) Parser & Model transformation Code Generator Mock Application (.c/.h) RTOS configuration (OIL/.c) RTE to access labels (.c/.h) LET communication stack (.c/.h) 27

28 Experimental Results The adoption of the LET paradigm significantly increase determinism - it s an additional system feature! From a scheduling (timing) perspective, our realization faces with two conflicting trends Worst-case delays due to memory contention are reduced. Pessimism is removed by design and schedulability analysis is simplified. High priority workload is required to perform LET communications, which may harm latency-sensitive tasks (priority inversion). 28

Experimental Results What s the impact of the proposed approach in

Despite the benefits in controlling memory contention, is the

Exec first frame of LET tasks (most expensive) Footprint (in bytes)

29 Experimental Results What s the impact of the proposed approach in terms of run- overhead and memory footprint? Despite the benefits in controlling memory contention, is the priority inversion introduced by LET communication harmful? Exec first frame of LET tasks (most expensive) Footprint (in bytes) +7.5% (can be lower for a real appplication) Mostly due local copies of labels and code of LET communication 29

30 OTHER CONTRIBUTIONS LET semantic options & analysis

31 Memory-aware RTA Objective: extend the response- analysis for partitioned fixed-priority scheduling to explicitly account for delays due to memory contention Analysis design principles: 1. Use a simple task model (no execution traces) Contention-free WCET Period and deadline Per-job max. number of accesses to global memory 2. Do not inflate WCETs but rather account for contention at the stage of response- analysis [inflation-free analysis, Brandenburg 2013] Provides a taste of the impact of any- memory accesses on response s Still, it is affected by considerable intrinsic pessimism 31

32 Memory-aware RTA With the proposed approach the analysis is simplified: Standard RTA for partitioned fixed-priority scheduling plus a high-priority GMF task Parameters of the GMF tasks can be derived as a function of Periods of the periodic tasks Labels accessed by each task Configuration of the inter-core synchronization mechanism LET Task Task 1 Task 2 32

33 Clarifications on LET Semantics Warning: different scheduling decisions for LET communications may lead to completely different LET semantics! The order with which read and write operations are performed is really important Different orders also lead to different worst-case end-to-end latencies in task chains A clear formalization of the adopted semantic is needed to avoid misunderstanding when talking about LET To shed the light on possible pitfalls, the paper also discusses three different LET semantic options, focusing on the impact of scheduling decisions on end-to-end latencies 33

Conclusions Presented a scheme for practical implementation and analysis of LET communication for multicore systems LET taken as an opportunity to control memory contention

negligible The only concern may be the increase of footprint There are a lot of open problems and possible improvements Future works Ad-hoc schedulability analysis under the

34 Conclusions Presented a scheme for practical implementation and analysis of LET communication for multicore systems LET taken as an opportunity to control memory contention Implemented upon ERIKAv2 on Infineon Tricore TC275 and tested with a case study based on WATERS 2017 Challenge model Take-away messages Impact on run- overhead has been found negligible The only concern may be the increase of footprint There are a lot of open problems and possible improvements Future works Ad-hoc schedulability analysis under the proposed scheme Holistic synthesis methodology that optimizes label placement, the generation of the LET communication stack, # of buffers, and possibly the runnable placement 34

35 Thank you! Alessandro Biondi

Partitioned Fixed-Priority Scheduling of Parallel Tasks Without Preemptions

Partitioned Fixed-Priority Scheduling of Parallel Tasks Without Preemptions *, Alessandro Biondi *, Geoffrey Nelissen, and Giorgio Buttazzo * * ReTiS Lab, Scuola Superiore Sant Anna, Pisa, Italy CISTER,