Collaborative Action on Timing InterferenCes:
Summary and Perspectives at Mid-term

Claire Maiza, Lionel Rieg, Jean-Luc Béchennec, Mihail Asavoae, Dominique Blouin, Florian Brandner, Thomas Carle, Hugues Cassé, Sébastien Faucou, Pierre-Emmanuel Hladik, et al.

► To cite this version:

Claire Maiza, Lionel Rieg, Jean-Luc Béchennec, Mihail Asavoae, Dominique Blouin, et al. Collaborative Action on Timing InterferenCes: Summary and Perspectives at Mid-term. Embedded Real-Time Systems (ERTS) 2026, Feb 2026, Toulouse, France. 10.82331/ERTS.2026.27. hal-05465745

HAL Id: hal-05465745

https://hal.science/hal-05465745v1

Submitted on 19 Jan 2026

HAL is a multi-disciplinary open access
archive for the deposit and dissemination of sci-
entific research documents, whether they are pub-
lished or not. The documents may come from
teaching and research institutions in France or
abroad, or from public or private research centers.

L'archive ouverte pluridisciplinaire HAL, est
destinée au dépôt et à la diffusion de documents
scientifiques de niveau recherche, publiés ou non,
émanant des établissements d'enseignement et de
recherche français ou étrangers, des laboratoires
publics ou privés.

<figure><img src="image_1.png" /></figure>

Distributed under a Creative Commons CC BY 4.0 - Attribution - International License
# Collaborative Action on Timing InterferenCes: Summary and Perspectives at Mid-term

Claire Maiza<fnref n="1" />, Lionel Rieg², Mihail Asavoe³, Jean-Luc Béchennec⁴, Dominique Blouin⁵, Florian Brandner⁶, Thomas Carle⁷,
Hugues Cassé⁸, Sébastien Faucou⁹, Bruno Ferres¹⁰, Pierre-E. Hladik¹¹, Erwan Jahier¹², Mathieu Jan¹³, Éric Jenn¹⁴, Loïg
Jezequel¹⁵, Dumitru Potop-Butucaru¹⁶, Isabelle Puaut¹⁷, Pascal Raymond¹⁸, Christine Rochange¹⁹, Pascal Sotin²⁰, Catherine
Parent-Vigouroux²¹, Houssam-Eddine Zahaf²², Hector Chabot²³, Maha Essabyr²⁴, Louison Jeanmougin²⁵, and Hichem Rebhi²⁶

1,2,10,12,18,21,26 *Univ. Grenoble Alpes, CNRS, Grenoble INP – UGA, VERIMAG, 38000 Grenoble, France*  
*first.last@univ-grenoble-alpes.fr*

3,13 CEA LIST, 91120, Palaiseau, France
first.last@cea.fr

4,9,11,15,22 Nantes Université, École Centrale Nantes, CNRS, LS2N, UMR 6004, 44000, Nantes, France
first.last@ls2n.fr

5,6,24 LTCI, Télécom Paris, Institut Polytechnique de Paris, France, 91120, Palaiseau, France
first.last@telecom-paris.fr

7,8,19,20,25 IRIT, 31062, Toulouse, France
first.last@irit.fr

14 IRT Saint Exupéry, 31400, Toulouse, France
eric.jenn@irt-saintexupery.com

16 INRIA, 75013, Paris, France
dumitru.potop_butucaru@inria.fr

17,23 IRISA, 35000, Rennes, France
first.last@irisa.fr

## ABSTRACT

CAOTIC is an ambitious initiative aimed at pooling and coordinating the efforts of major French research teams working on timing analysis of multicore real-time systems, with a focus on interference due to shared resources. The objective is to enable the efficient use of multicores in critical systems. Based on a better understanding of timing anomalies and interference, considering the specificities of applications (structural properties and execution model), and revisiting the links between timing analysis and synthesis processes (code generation, mapping, scheduling), we target significant progresses in timing analysis models and techniques for critical systems, as well as in methodologies for their application in industry. In this paper, at project mid-term, we show the progress of the project. We also present some original work, about the use of a Tricore platform and its timing model, and discuss open questions and future work.

## 1. INTRODUCTION

CAOTIC is an ambitious initiative to pool and coordinate the efforts of major French research teams working on timing analysis of multicores (including CPU and GPU) in real-time systems.

In the field of time-critical systems, both industry and research are struggling to conciliate two antagonistic objectives: performance and dependability.

Performance requires powerful – hence complex – computation units, while dependability usually requires simplicity. When systems are subject to hard real-time constraints (such as avionics or automotive systems), it is crucial to prove that their response time complies with the system requirements. This implies being able to estimate upper bounds on tasks worst-case execution time (WCET). Unfortunately, the next generation of embedded systems will greatly complicate timing analysis due to:

* timing interference caused by computation units concurrently accessing shared resources;

* timing anomalies<fnref n="1" /> (see Section 3) inherent to modern performance-oriented micro-architectures; and

* complex interplay between timing interference and timing anomalies.

As a consequence, the WCET of a task in such systems becomes strongly dependent on other tasks executed concurrently. Adopting a conservative approach (i.e., systematically considering the most unfavorable situations) leads to a very large overestimation of the actual WCET, and thus to an under-utilization of the platform resources. One solution is to develop system design approaches that ensure that the most unfavorable situations cannot happen, thus enabling to reduce overestimation. In case such assurance cannot be obtained, work should be carried out towards identifying and/or controlling the points in the execution of tasks where unfavorable situations can occur. Finally, this information should be used to improve the

<footnote>Claire Maiza et al.. This is an open-access article distributed under the terms of the Creative Commons Attribution 4.0 License, which permits unrestricted use, distribution, and reproduction in any medium, provided the original author and source are credited.</footnote>

<footnote n="1">¹Timing anomalies are a counter-intuitive timing behavior, where a locally faster execution leads to a globally slower whole program.</footnote>
scalability and accuracy of timing analyses. Project CAOTIC
follows this agenda.

In CAOTIC we are interested in multicore architectures (includ-
ing CPU and GPU), which are found, for instance, in ground
or air transportation systems. Good examples of such hardware
platforms, with which we will experiment in CAOTIC, are the
Aurix Tricore family (Infineon), the MPPA Coolidge (Kalray),
or the Jetson family (NVIDIA).

Our first objective is to expose conditions under which timing
interference may occur and analyze the resulting impact at
different levels: micro-architecture, program, and operating
system. On the hardware side, this will require the development
of a systematic approach to the identification and analysis of
interference, using new models extending those found in the
literature, possibly also using measurements. On the software
side, the different levels of code representation will be used
and analyzed to identify the precise locations of interference.

Our second objective is to achieve a better support for inter-
ference in timing analyses and system design. At the analysis
level, the main challenge is to create compositional techniques
that are correct and scalable in the presence of interference and
anomalies. At the design level, the challenge consists in being
able to improve the control of where and when interference
occurs.

Our third and final objective is to consolidate the methods,
techniques, and tools designed or improved in the project, in
order to facilitate their transfer to industry. To this intent, we
have setup an industrial committee composed of experts from
the aeronautical, space, and automotive domains. The role of
this committee is to (i) review the project results, (ii) provide
feedback on the relevance of the results with respect to their
industrial use cases, and (iii) contributes to the dissemination of
knowledge and prepare the industrial transfer of these results.
An important and specific role of the committee is to ensure the
consistency of the hypotheses underlying the methods and tools
developed in the project with the actual industrial practices and
constraints. This allows on the one hand to ensure that the
results of the project are relevant and applicable in practice,
and on the other hand to identify potential gaps or limitations in
the methods and tools that need to be addressed. The committee
meets every two months.

CAOTIC addresses a complex problem (dealing with timing
interference and anomalies) from multiple angles. It leverages
the complementarity of the partners’ expertise, who have de-
veloped several academic tools closely related to CAOTIC:
toolboxes for static WCET analysis (OTAWA [2] from IRIT,
Heptane<fnref n="2" /> from IRISA), toolchains for hardware-software sys-
tem analysis by model-checking (tools from LS2N, LEAF tool-
box<fnref n="3" /> from CEA), synthesis and tools built around high-level
models and languages (RAMSES<fnref n="4" /> from LTCI, LOPHT [8]
from INRIA, HIPPO [16] from LS2N, MIA [29, 32] and Lus-
tre toolbox<fnref n="5" /> from Verimag). The objective is not to interface

these tools, which has already been done by some partners
before CAOTIC, but rather to study how they can complement
each other to propose better solutions, relying in particular on
the use of common and transverse case studies. We aim at using
freely accessible case studies (e.g., Rosace [26], the application
from the WATERS challenge by Bosch,<fnref n="6" /> the autonomous rover
from the Minnie project,<fnref n="7" /> or the open source autonomous vehi-
cle application Apollo<fnref n="8" />). It is our hope that, by the end of the
project, will emerge both a common vision of the problems and
possible approaches to tackle them by combining our methods
and tools, leading to less conservative timing analyses.

Compared to the state of the art in the literature and other
projects currently ongoing, CAOTIC targets several original
goals:

(i) systematically identify interference channels, including for GPU and low-level features such as arbitration and scheduling policies;

(ii) extend timing anomaly analyses to multi- and many-core platforms;

(iii) define a finer-grained software interference model using software phases and modes to generate scalable timing analysis;

(iv) use phase and mode information for synchronous lan-
guage compilation;

(v) integrate the above results into a prototype correct-by-
construction design flow for multi-core application, thus
improving the state of practice.

In this paper, at project mid-term, we show the progress of the
project (Section 2, 3 and 4). Section 3 contains also an original
discussion about timing anomalies in multi-core platforms. Sec-
tion 5 contains some original work about the configuration of a
Tricore plaform for a specific kind of critical application and
its timing model. We discuss future work in Section 6.

## 2. INTERFERENCE IN GPUs

Neural Network (NN)-based applications are currently being
adopted for various tasks (e.g., autonomous driving) in real-
time embedded systems. The computational requirements and
the parallel nature of these applications push towards the de-
ployment of Graphical Processing Units (GPUs) in real-time
systems. However, these GPUs have a very complex design
that differs greatly from traditional CPUs [1], which compli-
cates their timing analysis. In particular, the parallel nature of
GPUs, which are able to handle thousands of threads at once, re-
lies on a hierarchical architectural organization in which many
resources are shared among the threads, and thus subject to
interference. To this day, there exists no model or method that
allows the static derivation of a WCET for a program executed
by a GPU. One of the objectives of the CAOTIC project is to
lay the foundation for such an analysis.

Within the CAOTIC project, the first pursued direction on this
topic has been the modeling of a simplified version of a GPU,
in which interference in the memory subsystem is neglected.

<footnote n="2">²https://www.irisa.fr/solidor/work/heptane-demo/heptane-main.html</footnote>

<footnote n="3">³https://list.cea.fr/en/april-2-2020-leaf-verification-of-mixed-criticality-embedded-systems/</footnote>

<footnote n="4">⁴https://mem4csd.telecom-paristech.fr/blog/index.php/ramses/</footnote>

<footnote n="5">⁵https://www-verimag.imag.fr/Lustre-V6.html?lang=en</footnote>

<footnote n="6">⁶https://www.ecrits.org/forum/viewtopic.php?f=32&t=108&sid=6368c0ade69e21cfa217e724cb3c05ca</footnote>

<footnote n="7">⁷https://redmine.laas.fr/projects/minnie</footnote>

<footnote n="8">⁸https://apollo.auto/index.html</footnote>
<figure><img src="image_2.png" /><figcaption>Figure 1. Single warp phased abstraction illustration. Reproduced from [19]</figcaption></figure>

We will then integrate interference sources one by one in the model or find ways to avoid them in the software specification.

Using this model, we are able to derive an abstract representation of the timing behavior of a warp (an atomic group of 32 threads running in lockstep<fnref n="9" />) in isolation as a sequence of phases in which the warp either actively occupies resources of the GPU or is waiting for the result of a long latency operation (e.g., memory access). This is illustrated in Figure 1. The topmost part of the figure represents the execution of a sequence of instructions by a warp in isolation. Each instruction ($i_0$ to $i_3$ in the figure) starts its execution by an initiation during which its operands are retrieved, and then executes in a pipelined functional unit. Instructions using the same functional unit (denoted by colors) such as $i_1$ and $i_2$ cannot be initiated in parallel, but as all functional units are pipelined the rest of their execution is non-blocking. As a result, only the initiation latencies of the instructions are considered as an active occupation of a resource. The bottom part of the figure displays the corresponding abstract representation of the warp execution. In a first phase, the warp actively occupies resources: this corresponds to the combined initiation latencies of instructions $i_0$, $i_1$ and $i_2$. Then the warp can be considered as idle for one cycle by the rest of the kernel, as it is only executing instructions in pipelined functional units that thus cannot block the execution of other warps. Another active phase then lasts 2 cycles to account for the initiation of instruction $i_3$, and the rest of the warp's execution is non-blocking.

These phased representations are then combined using analytical formulas to derive a safe upper-bound for the execution time of all the warps composing a thread block (a logical group of threads that run on the same core –Streaming Multiprocessor– of the GPU). These formulas are inspired from classical results in Worst-Case Response Time analysis, in which the response time of a task is computed as its worst-case execution time in isolation plus various interference terms accounting for the effect of the rest of the system (higher priority tasks, concurrency in memory accesses, etc.). The worst-case execution time of the GPU program (a.k.a. kernel) can then be obtained by combining the WCETs of the thread blocks.

Formally, we represent each warp $w$ by a sequence of $\Phi^w$ phases. Each phase $\phi_i^w, i < \Phi^w$ is characterized by three

attributes: its start date $\phi_i^w.start$ relative to the start time of the thread block, its worst-case duration in cycles $\phi_i^w.dur$ and its kind $\phi_i^w.kind \in \{exec, wait\}$ that denotes whether the phase performs computations that occupy resources (exec) or is waiting for a result (wait).

One fundamental element of the execution paradigm of GPUs is to try to hide long latencies (e.g. memory access latency) by scheduling instructions of other warps. In our model, this is reflected in that a wait phase of a warp can be hidden by one or several exec phases of other warps, thus not contributing to the WCET of the thread block. However, still in our model, all exec phases of all warps are seen as competing for the acquisition of resources, and thus all their combined execution times contribute to the WCET of the block. From these two observations, we deduce that a safe (over-)estimation of the WCET of a warp $w$ is the sum of its execution time in isolation and of the worst-case duration of all the exec phases of all the other warps in the block $B$:

$$WCET(w) \leq \sum_{i=0}^{\Phi^w-1} \phi_i^w \cdot dur + \sum_{W \in B \setminus \{w\}} \left( \sum_{\phi_j^W \cdot kind = exec} \phi_j^W \cdot dur \right)$$

A safe WCET bound for the thread block is thus obtained as the maximum of the bounds obtained for all warps composing the block.

So far, we are able to extract the phased representation of warps from execution traces obtained by simulation, but part of our ongoing work is to derive them directly from the binary code of the kernel.

As the GPUs present in Commercial Off The Shelf System-On-Chips are usually poorly documented, we conducted our experiments using the Accel-Sim GPU simulator [20]. Although this simulator is not a cycle accurate model of commercial GPUs, it has been shown that its behavior is very close to that of e.g., NVIDIA GPUs in terms of performance (including number of execution cycles, number of cache misses, etc.). We started by configuring Accel-Sim to reflect our simplifying assumptions, built a model of this simulated GPU, and conducted a campaign of measurements to compare the simulated execution times to the bounds obtained by our analysis. Our experiments show that for a realistic setting, our bounds only overestimate the measured execution times by 12.31% on average, and up to 40% for the worst bench.

### 3. TIMING ANOMALIES AND PREDICTABILITY

Timing anomalies (TAs) represent a major challenge for the analysis of interference in complex modern multicore computer designs. Two forms of TAs are distinguished in the literature [23] (i) counter-intuitive TAs and (ii) amplification TAs. In the former case, a locally favorable event (e.g., a cache hit) leads to a counter-intuitive increase of the global execution time. In the latter case, a locally unfavorable event (e.g., a cache miss) leads to an increase in global execution time that is larger than the time penalty caused by that event.

Figure 2 illustrates a TA for a program consisting of four instructions (A-D) executing on an out-of-order processor. Instruction A occupies functional unit $FU_1$ for only 1 cycle in the upper trace ($\alpha$), which has a global execution time of 10 cycles.

<footnote n="9">⁹In the current implementations.</footnote>
<figure><img src="image_3.png" /><figcaption>Figure 2. Example of a Counter-Intuitive Timing Anomaly.</figcaption></figure>

The lower trace ($\beta$), however, completes after 9 cycles, despite the fact that instruction A occupied $FU_1$ for 3 cycles instead of 1. Consequently, this represents a counter-intuitive TA. It is caused by the interplay between data dependencies ($A \leftarrow B$ and $C \leftarrow D$) and constraints on functional units (instructions cannot switch to other units).

Even simple computer architectures exhibit TAs, including in-order processors [15]. The issue is that TAs make timing analysis more complicated: counter-intuitive TAs prevent from safely pruning hardware states [4] and amplification TAs threaten *compositionality*. This means that the impact of any external perturbation of a real-time task cannot be modeled as an additive term that is computed independently from its WCET. This is particularly a problem for interference in multicores, but also for preemption delays, e.g., due to cache-related preemption delays.

## 3.1. Evaluation of Definitions

In order to safely account for TAs, it is necessary to be able to understand and explain their root causes and be able to reason about their consequences. It is thus not surprising that several attempts have been made to (semi-)formally describe counter-intuitive TAs [34, 11, 28, 21, 13, 5, 4]. This naturally begs the question: which of these definitions is best suited for the CAOTIC project? A first step within the project thus was to perform a literature review and evaluate the various definitions for practicality. We identified four major classes of definitions (i) approaches based on step functions [11, 13, 5], (ii) locality-based approaches [28], (iii) causality-based approaches [4], and (iv) other approaches [34, 21]. All these definitions have been discussed during reading groups, while the former three approaches have also been evaluated, using tool support [3]. The results have been described in detail in a report of the CAOTIC project [27] and are briefly summarized here:

* Definitions that rely on step functions describe the evolution of the global execution time through incremental steps, where each instruction adds an increment representing its *latency*. The timing behavior of an instruction is thus summarized by a single number, which is not enough to capture complex, possibly concurrent, events that occur in realistic hardware. These definitions thus immediately appear unsuited.

* Most approaches lack the notion of *causality*, which establishes a causal link between the occurrence of a favorable/unfavorable event and its consequences. Consequently, these approaches are unable to distinguish cases where the global execution time is determined by unrelated events from those where the global time is actually

impacted by the favorable/unfavorable event.

* The state-of-the-art, at the time of the literature review, lacked a formal definition of amplification TAs.

The most promising definition of counter-intuitive TAs thus appears to be recent work by Binder et al. [4], which explicitly captures the timing-related relationships among events through a data structure called the *Event-Time-Dependence Graph* (ETDG).

Using the ETDG, a so-called *causal region* can be computed for favorable/unfavorable events, which consequently allows to define a scope in which effects of TAs are causally linked to the event at its origin. While the original definition is not able to capture amplification TAs, recent work – co-authored by CAOTIC members – proposed an extension for in-order processors [30] covering both counter-intuitive and amplification TAs. Ongoing work within the project currently investigates the role of the hardware’s internal state on causality, which will allow us to capture more precisely the behavior of branch predictors, for instance.

## 3.2. Timing Anomalies in Predictable Designs

Another observation from our literature review is that proposals of predictable hardware designs such as PRET [10], Patmos [31], SIC [15], or MINOTAuR [14] generally consider TAs, but without any reference to a formal and precise definition.

While Patmos was claimed to be free from TAs by design, this was not formally investigated by its original authors. Jan et al. [18] modeled the stalling logic of Patmos and verified, using bounded model checking, that a more recent instruction cannot delay an older instruction in the pipeline. This result confirms the claim that Patmos indeed does not exhibit amplification TAs.

Both SIC and MINOTAuR are based on the notion of monotonicity, which was initially coined by Wenzel et al. [34], and first formalized by Hahn and Reineke [15]. The key idea is to define a progress metric that allows to compare the progress of two executions of the same instruction sequence through the pipeline and to prove that an execution cannot overtake another. Monotonicity is generally believed to suffice to ensure the absence of TAs. However, this has not been formalized and it is not clear for which of the definitions of TAs this property actually applies.

Recent work by Rouizi et al. [30] show an amplification TA in SIC that is provoked precisely by the mechanisms that are supposed to ensure monotonicity. More precisely, SIC ensures that all bus accesses appear strictly in program order. However, this property is not ensured for cache hits that do not access the bus. Rouizi’s work also investigated whether counter-intuitive TAs are possible under SIC according to a variant of the definition of Binder et al. [4] adapted to in-order cores. The analysis, based on bounded model checking, seems to confirm that SIC indeed does not exhibit counter-intuitive TAs. However, the investigation also shows that a regular in-order core without the SIC-specific modifications does not exhibit counter-intuitive TAs either. It thus appears that SIC’s extensions only help to avoid certain, but not all, classes of amplification TAs.
**3.3. Timing Anomalies in Multicores**

Project partners furthermore investigate the interaction of TAs
with interference on shared resources in multicore platforms.
The formal definitions cited above typically focus on processor
pipelines executing instructions. The only exception is work
by Shah et al. [33], which investigates TAs in round-robin
arbitration. We will briefly discuss the short-comings of this
approach, which motivates the goal of the CAOTIC project to
investigate the occurrence (or absence) of TAs in the memory
hierarchy of (heterogeneous) multicore platforms.

**Round-Robin Arbitration:** Round-robin arbiters (revisited in Section 5.2) give access to the shared bus of a multicore system by considering the cores in the system in a cyclic and recurring fashion, according to a fixed order. The arbiter cycles through all cores according to that order, giving access to the shared bus in-turn once to each core. When the end of the order is reached, the cycle starts again from the beginning. During this processing only cores with pending request are considered, while those without a pending request are simply skipped. This scheme is easy to implement and ensures fairness among the cores in the system.

**Aggressiveness:** Shah et al. [33] identify a counter-intuitive behavior according to an *aggressiveness* metric. The metric is unfortunately not formally specified, but appears to be based on the number of memory requests (more requests means higher aggressiveness) and the distance between consecutive requests (closer means higher aggressiveness). The authors then investigate the impact of interference on the execution time of a given program. For this, the authors define *execution scenarios* where the behavior of the program under analysis is fixed, i.e., its computation times are fixed and only the latency of memory requests varies depending on the arbiter state and the memory requests of other cores in the system. Finally, execution scenarios are compared with each other according to the total execution time of the analyzed program and the level of *aggressiveness* of the co-running cores.

The authors found examples of execution scenarios where a
higher level of aggressiveness yields a shorter total execution
time compared to another execution scenario with a lower level
of aggressiveness. At first sight, this appears to be reminiscent
of counter-intuitive TAs. However, the definitions discussed
above are not directly applicable. For one, these definitions
are based on the notion of a specific event that directly im-
pacts the latency of a given instruction. The aggressiveness
measure on the other hand does not refer to a single event,
but rather the frequency in a continuous flow of events in a
time span – here actually the total execution time. This single
global aggressiveness value can be misleading, since past or
future aggressiveness is irrelevant, only the *aggressiveness* that
coincides with the memory accesses of the analyzed program
matters. This is somewhat similar to the problem of many
TA definitions discussed above: the metric is not suitable to
reason about a causal link, i.e., did the reduced aggressiveness
actually trigger the TA? In addition, the immediate impact
of these *events* is not clear, making it difficult to identify the
(un-)favorable event triggering a potential TA. Consequently,

the examples identified by the authors, when scrutinized, are
not that surprising nor counter-intuitive.

**α-Interference:** The authors then turn their attention to an-
other kind of counter-intuitive behavior, which is seemingly
related to the worst-case behavior of round-robin arbitration.
For this the authors define α-interference, which indicates that
along the program under analysis α co-running cores continu-
ously issue requests to the arbiter. The intuition of the authors
is that (i) α-interference is easy to generate, i.e., it suffices to
replace the cores by traffic generators that simply produce one
memory request after the other, and (ii) α-interference maxi-
mizes interference and thus leads to the worst-case behavior
of the analyzed program. The authors then again compare exe-
cution scenarios where the behavior of the analyzed program
is fixed but experiences interference under different levels of
α-interference.

Again, the authors identify scenarios where a higher level of
α-interference leads to a longer total execution time compared
to a scenario with a lower level of α-interference. Many of the
issues raised before for the aggressiveness metric also apply
to these scenarios. In addition, the metric itself appears to
be flawed – as noted by the authors themselves in the experi-
mental evaluation: “measured execution time in the presence
of uninterrupted interference [is] a highly unreliable WCET
candidate”. This is indeed not surprising: while α-interference
ensures that a memory request is pending (or being processed)
for each of the interfering cores at all times, it is easy to see
that this is not sufficient to maximize interference. Quite con-
trary to the claim by the authors, the counter-intuitive behavior
disappears for scenarios that actually maximize interference.

**Conclusion:** In conclusion, the examples shown by Shah et al. [33] are not convincing enough to be a frame of reference for counter-intuitive TAs in multicore systems. Moreover, it appears that TAs at the level of multicores have not been sufficiently studied and more work is needed in order to formalize the notion of TAs in such a context. As indicated above, the traditional definitions of TAs are of little help, since they are limited to specific favorable or unfavorable events that lead to a change in some observable latency. Furthermore, these traditional definitions limit quite precisely how execution scenarios are allowed to differ in order to keep them comparable. This is not the case for the work of Shah et al. [33]. As of now, which parameters of execution scenarios in multicores can be varied without compromising the ability to compare the scenarios in a meaningful manner is still an open question.

4. SOFTWARE PHASES AND MODES

Interference within a real-time task system is often represented
by a single value counting the maximum number of accesses
to the shared resources causing interference (e.g., interconnect)
over the whole execution of the task. This enables to assess the
impact of any other task on the studied task and the impact of
the current task on the rest of the system. However, depend-
ing on the organization of the task or on the code generation
method, it turns out that:

* accesses to shared resources are not uniformly distributed
<figure><img src="image_4.png" /><figcaption>Figure 3. Phases (6 main phases for st) are depicted as dashed light blue lines. Purple and black plain lines give results for state-of-the-art techniques: single number of memory accesses per phase as defined in [7] (purple lines) or single number for the entire tasks (black lines).</figcaption></figure>

along the task execution, thus exhibiting *execution phases* producing different interference patterns, and

* from one task activation to another, the presence of different *execution modes* makes the interference pattern evolve over time.

Based on this observation, our objective was to break the mono-lithic vision of the tasks and to produce a *software interference model* that captures phases and modes, to improve and simplify timing analysis and to guide code generation.

## 4.1. Identification of phases

Regarding the identification of phases, we have designed and implemented Marmot [6], a technique that extracts phases from the binary code of sequential tasks. Marmot splits the binary code of a task into a sequence of intervals, each holding a distribution of shared memory accesses, as explained below:

* *Intervals.* An interval is a subset of the code control flow graph (CFG), with a single entry-point and a single exit-point. Intervals are consecutive: the exit-point of each interval is the entry-point of the next interval in the sequence of intervals. Each interval is characterized by its WCET (considered in isolation, i.e. excluding interference delays), and a distribution of shared memory accesses in the interval, as explained just after.

* *Distribution of shared memory accesses.* For each interval, the Worst-Case number of Memory Accesses (WCMA) is defined as a distribution of shared memory accesses, through a non-decreasing step-function. The function, for any time $t$ since the start of the interval, counts the worst-case number of memory accesses that may occur since the interval start. The last point in the curve counts the maximum number of accesses in the entire interval.

An example of phases for the *st* benchmark from the TaCLE benchmark suite [12] is given Figure 3. In the example, six phases are extracted, and the distribution of memory accesses within each interval is depicted as dashed light blue lines.

Marmot builds memory access profiles in two steps.

The first step consists in decomposing the CFG into intervals. This is achieved by applying an existing technique, named StAMP [7] with no modification.

The second step calculates the distribution of memory accesses in each interval by an integer linear programming (ILP) system. The ILP system, similar to the classical IPET WCET calculation [22], estimates the worst-case number of memory accesses on any interval size from 0 to WCET. In contrast to previous work that estimates the worst-case number of events in any interval [25], our ILP system is *contextual*. It considers the different call sites of functions separately. Moreover, it separates the different behaviors regarding memory accesses in loop nests; it considers, for architectures with caches, a different number of memory accesses for the first iteration of a loop (cold cache) compared to the next iterations (warm cache). More details can be found in [6].

Preliminary experimental results show that interference-aware WCET computation and schedulability analysis can take advantage of the fine-grain intervals produced by Marmot to obtain more precise interference-aware WCET and therefore higher schedulability than coarser-grain profiles.

## 4.2. Identification of modes

As far as modes are concerned, we have first successfully verified that modes actually exist, through a manual analysis of the most complex codes from the TaCLE benchmark suite (Papabench, Debie and Rosace).

We also have worked on the design and implementation of a static analysis technique, operating on a toy C-like language, that automatically detects modes in programs. In this work, a mode consists of a restricted version of the program, called a restriction, together with a condition on the initial values of the variables such that, if this condition holds, the restriction will never be violated. For a given restriction, one can adapt the inference of sufficient conditions proposed by Antoine Miné [24] in order to construct a mode (provided that the inferred condition does not collapse to *false*). The additional difficulty we have addressed while adapting [24] was twofold. First, since the number of modes in some programs grow exponentially with the size of the program (e.g., sequences of independent *if* statements) we have developed strategies to reduce the number of modes. Second, our technique ensures that the identified modes cover all behaviors of the original program.

# 5. CONFIGURATION AND INTERFERENCE MODEL OF A TRICORE PLATFORM

In modern architectures, multicore is the key for performance. However, multiple cores often means concurrent accesses to shared resources. This implies the need of arbiters to decide which core should access the resource first, which may lead to interference, i.e., additional execution time due to concurrent accesses to a shared resource.

In [32], it has been shown that interference delays can be estimated and are a better solution than isolation. This work also showed that interference delays can be estimated more precisely when the multi-core platforms fulfill the following conditions:
* each core is fully-compositional (no timing anomaly);

* the memory space is composed of a set of local memories with the three following conditions:

(i) each core has a local memory,

(ii) each core may access all memory space,

(iii) each local memory is arbitrated separately with a predictable arbiter;

* the full memory space for applications (data and code) is small enough to use only the set of local memories.

Each multi-core platform that can be configured to fit these conditions is particularly convenient for critical applications. We show how platforms of one TriCore (TC) family — widely used in automotive — can be configured to fit these conditions.

A particular case of interference occurs in the TC platforms when there is a single core accessing a resource in consecutive cycles. In this case, one empty slot is inserted between each pair of accesses. This mechanism is called the anti-starvation policy. Originally made to avoid starvation when using a fixed-priority (FP) arbiter, this mechanism also applies to cores arbitrated using a Round-Robin policy, impacting its behavior. We called this variant the Anti-Starvation Round-Robin (ASRR). To the best of our knowledge, no prior work discusses the predictability of this mechanism nor its timing model.

We use a Multicore Interference Analysis tool called MIA<fnref n="10" /> [29, 9, 32]. It takes as input a Directed Acyclic Graph (DAG) composed of nodes representing running tasks and their related information (WCET, deadline, ...), and it estimates the Worst-Case Response Time (WCRT) of an application, including the delays due to interference.

We focus on the configuration of the TriCore (TC) 2X/3X platform [17] to fit the predictable conditions above, and on the model of its anti-starvation memory arbiter that we added to MIA.

## 5.1. Hypotheses and Configuration of TriCore Platforms

The TriCore 2X/3X platforms are highly used in various domains (notably automotive). They are composed of 3 cores, their local memories, and a crossbar interconnect.<fnref n="11" /> For simplicity, we consider a restricted model isolated from the other peripherals. We assume that the data cache is bypassed,<fnref n="12" /> which means that each load/store instruction goes through the crossbar, and that the local memory is accessed by both the owning core and the accesses from external cores. We assume that our model is timing compositional (e.g., the work presented in this Section assumes that the dynamic branch prediction in the cores is bypassed, preserving the timing compositionality of this model). We consider that the program memory is pre-loaded. Under the previous assumptions, interference delays can be estimated, and MIA can produce a time-triggered scheduling for a given application.

Figure 4 highlights the model of TC platforms that we consider. The crossbar supports parallel communications between cores.

<figure><img src="image_5.png" /><figcaption>Figure 4. TriCore 2X/3X data interactions between cores</figcaption></figure>

The official documentation [17] indicates that direct accesses through this bus incur a constant cost. Thus, on Figure 4 the crossbar is not represented specifically and is part of the edges from a core to each ASRR arbiter. Since each local memory needs an arbiter to determine which access should be granted first, concurrent accesses to shared resources inevitably cause interference. This interference delay due to the ASRR arbiter is studied in the next subsection.

## 5.2. Quantifying Interference in TriCore Platforms: the Anti-Starvation Round-Robin (ASRR) Arbiter

<figure><img src="image_6.png" /><figcaption>Figure 5. Comparison between Round-Robin and its Anti-Starvation variant (possible scheduling)</figcaption></figure>

We explore the ASRR arbitration in depth in Figure 5. We consider the case where three cores C0, C1 and C2 are asking concurrently for resp. 4, 1 and 2 accesses to a shared resource (e.g., local memory of core 0). Figure 5 represents the execution of this scenario under two different arbitration schemes: standard Round-Robin and its variant using the anti-starvation policy (ASRR). We can see that the Round-Robin arbiter grants a slot sequentially to each core that is currently requesting an access (e.g., in Figure 5, the RR arbiter grants one access to each of the 3 requesting cores, then it grants access to C2 and C0, since C1 did not request any other access to the local memory of core 0). The Anti-Starvation Round-Robin arbitration behaves like the Round-Robin arbitration when there are multiple cores trying to access the shared resource, but it introduces idle slots between each couple of consecutive interactions requested by an isolated core (e.g., C0).

As seen previously, cores may suffer from interference delays when accessing shared resources. These interference delays are directly determined by the arbitration logic [32]. In multi-core real-time analysis, these interference delays can be modeled

<footnote n="10">¹⁰[www-verimag.imag.fr/multi-core-interference-analysis.html](http://www-verimag.imag.fr/multi-core-interference-analysis.html)</footnote>

<footnote n="11">¹¹[Section 2.2, Figure 2-2: SRI Crossbar (XBAR, SRI)]</footnote>

<footnote n="12">¹²[Section 5.11.1.2: Data cache Bypass]</footnote>
with equations. We focus now on the equation for the arbitra-
tion of the TC platform that we consider (i.e., the ASRR). For
simplicity reasons, we consider that a task is represented by the
core where it is executed (i.e., a task $\tau_i$ executed on the core $c_x$
is represented as $c_x$ in the following equations).

We recall the interference delay of the RR arbiter [32]. To characterize the interference suffered by a core $c_x$ accessing the local memory of a core $c_y$, we compare its number of accesses with those of every other core $c_i$, where we denote $acc_y(c_i)$ the number of accesses from core $c_i$ to the local memory of core $c_y$. We cover the possible scenarios of the core $c_x$ being interfered with by another core $c_i$ when accessing the core $c_y$ as follows:

* Both cores make the same number of accesses concurrently (i.e., the core is interfered $acc_y(c_x) == acc_y(c_i)$ times).

* The core $c_x$ makes less accesses than the core $c_i$ (i.e., the core $c_x$ can be interfered exactly $acc_y(c_x)$ times).

* The core $c_x$ makes more accesses than the core $c_i$ (i.e., the core $c_x$ can be interfered exactly $acc_y(c_i)$ times).

Therefore, the amount of interference suffered by a core $c_x$ when accessing the local memory $y$ can be represented as the minimum of $acc_y(c_x)$ and $acc_y(c_i)$; as shown in [32], the interference is given by:

$$ \forall c_x \in \text{CORES}, \\ \text{INTERF}_y^{RR}(c_x) = \sum_{i=1, x \neq i}^{\#\text{CORES}} \min(\text{acc}_y(c_x), \text{acc}_y(c_i)) $$

Now, if we consider the Anti-Starvation variant, the behavior of
the arbiter changes when there is only one isolated core trying
to access consecutively the shared resource. In this case, an
IDLE slot is added for each consecutive access.

If one isolated core makes N consecutive accesses, there is N-1
additional IDLE slots resulting from the arbitration logic. Thus,
the possible scenarios of the core $c_x$ being interfered with by
two other cores $c_i$ and $c_j$ when accessing to the core $c_y$ are:

* $c_x$ makes at most the same number of accesses than any of the other cores $c_i$ or $c_j$, then there is no additional delay resulting from the anti-starvation policy.

* $c_x$ makes more accesses than both $c_i$ and $c_j$, the difference between $acc_y(c_x)$ and the maximum of $\{acc_y(c_i), acc_y(c_j)\}$ represents the interference resulting from the anti-starvation policy.

Therefore, the following equation computes the interference of
the ASRR arbitration scheme:

$$ \forall c_x \in \text{CORES}, \\ \text{INTERF}_y^{ASRR}(c_x) = \sum_{i=1, x \neq i}^{\#\text{CORES}} \min(\text{acc}_y(c_x), \text{acc}_y(c_i)) \\ + \max(0, (\text{acc}_y(c_x) - \max_{j \neq i}(\text{acc}_y(c_j)))) $$

This equation is composed of a first part (in violet) representing the Round-Robin model described in [32], and a second part (in orange) describing the behavior of the ASRR when an isolated core makes consecutive accesses. Please note that the second part may be null if there are no consecutive accesses from the same core.

This work presents the theoretical foundations of our model. This model has been added to MIA and may be used to estimate the worst-case response time of a critical application executed on a TriCore platform. As future work, we will study the behavior of TriCore platforms when composed in clusters (i.e., composing multiple clusters of three cores).

# 6. FUTURE WORK

This paper shows that in the first half of the CAOTIC project, we built the bricks that will be used in the second half of the project.

The next steps in the direction of enabling safe and precise WCET estimation for GPU kernels involve modeling the memory system, including the memory access coalescing mechanism that has a huge impact on the execution time, in order to upper bound the effect of interference between memory accesses in our formulas. Another aspect of our future work will be to explore code generation techniques that allow a simple decoupling between memory effects and computations in the analysis, for example with double-buffering mechanisms that exploit the shared memory of the GPUs. This is a promising approach to precisely account for interference in memory accesses while limiting the complexity of the analysis.

With regard to TAs in multicore systems, future work will focus on TAs definitions, as current definitions are not well suited to multicore architectures. One of the difficulties encountered in defining TAs in multicore systems lies in the number of sources of variability within the memory hierarchy (cache levels, interconnection, access policies, etc.) when comparing two traces. In parallel with understanding TAs in multicore systems, we will work on developing formal analysis techniques to detect TAs in multicore systems or identify patterns that can lead to TAs. Particular attention will be paid to the scalability of the analysis techniques developed.

Regarding the extraction and exploitation of phases and modes, we have defined Marmot [6], a technique that extracts fine-grain information about memory accesses in sequential tasks. Marmot operates through static analysis of tasks in binary format, from which phases are extracted. Then, distributions of shared memory accesses within each phase are generated. Our ongoing work regarding the phasing of memory accesses is to use extracted memory access profiles in scheduling strategies. The objective here is to determine if fine-grain information on memory accesses can be used to reduce the overall amount of interference, and if this provides acceptable time for schedule generation.

Regarding modes, we have demonstrated that real code contain modes, which was also confirmed by a survey filled by members of the Industrial Committee. A first technique to extract modes was designed but needs further experimentation on real cases. Our ongoing work concerns the exploitation of modes in scheduling strategies.

A longer term objective of the CAOTIC project is to define a workflow combining the analysis techniques developed in the project in order to get tighter timing guaranties. The workflow will be evaluated on real (or at least realistic) case studies under the expertise of the industrial committee.
REFERENCES

[1] Tor M. Aamodt, Wilson Wai Lun Fung, and Timothy G. Rogers. *General-Purpose Graphics Processor Architectures*. Synthesis Lectures on Computer Architecture. Morgan & Claypool Publishers, 2018.

[2] Clément Ballabriga, Hugues Cassé, Christine Rochange, and Pascal Sainrat. OTAWA: An Open Toolbox for Adaptive WCET Analysis. In Sang Lyul Min; Robert Pettit; Peter Puschner; Theo Ungerer, editor, *Lecture Notes in Computer Science*, volume LNCS-6399 of *Software Technologies for Embedded and Ubiquitous Systems*, pages 35–46, Waidhofen/Ybbs, Austria, October 2010. Springer. doi: 10.1007/978-3-642-16256-5\_6. URL https://inria.hal.science/hal-01055378.

[3] Benjamin Binder, Mihail Asavoae, Belgacem Ben Hedia, Florian Brandner, and Mathieu Jan. Is this still normal? putting definitions of timing anomalies to the test. In *International Conference on Embedded and Real-Time Computing Systems and Applications*, pages 139–148, 2021. doi: 10.1109/RTCSA52859.2021.00024.

[4] Benjamin Binder, Mihail Asavoae, Florian Brandner, Belgacem Ben Hedia, and Mathieu Jan. The role of causality in a formal definition of timing anomalies. In *International Conference on Embedded and Real-Time Computing Systems and Applications*, pages 91–102, 2022. doi: 10.1109/RTCSA55878.2022.00016.

[5] Franck Cassez, René Rydhof Hansen, and Mads Chr. Olesen. What is a Timing Anomaly? In Tullio Vardanega, editor, *International Workshop on Worst-Case Execution Time Analysis*, volume 23 of *Open Access Series in Informatics (OASICS)*, pages 1–12. Schloss Dagstuhl – Leibniz-Zentrum für Informatik, 2012. ISBN 978-3-939897-41-5. doi: 10.4230/OASICS.WCET.2012.1.

[6] Hector Chabot, Isabelle Puaut, Thomas Carle, and Hugues Cassé. Marmot: Extraction of fine-grain memory access profiles for real-time software. In *Proceedings of the 32nd International Conference on Real-Time Networks and Systems*, RTNS ’24, page 117–141, New York, NY, USA, 2025. Association for Computing Machinery. ISBN 9798400717246. doi: 10.1145/3696355.3696360. URL https://doi.org/10.1145/3696355.3696360.

[7] Théo Degioanni and Isabelle Puaut. Stamp: Static analysis of memory access profiles for real-time tasks. In *WCET 2022-20th International Workshop on Worst-Case Execution Time Analysis*, 2022.

[8] Keryan Didier, Dumitru Potop-Butucaru, Guillaume Iooss, Albert Cohen, Jean Souyris, Philippe Baufreton, and Amaury Graillat. Correct-by-construction parallelization of hard real-time avionics applications on off-the-shelf predictable hardware. *ACM Trans. Archit. Code Optim.*, 16(3), July 2019. ISSN 1544-3566. doi: 10.1145/3328799. URL https://doi.org/10.1145/3328799.

[9] Maximilien Dupont de Dinechin, Matheus Schuh, Matthieu Moy, and Claire Maïza. Scaling Up the Memory Interference Analysis for Hard Real-Time Many-Core Systems. In *DATE 2020 - Design, Automation and Test in Europe Conference*, pages 1–4, Grenoble, France, March 2020. URL https://hal.science/hal-02431273.

[10] Stephen A. Edwards and Edward A. Lee. The case for the precision timed (PRET) machine. In *Design Automation Conference*, pages 264—265. ACM, 2007. ISBN 9781595936271. doi: 10.1145/1278480.1278545.

[11] Jochen Eisinger, Ilia Polian, Bernd Becker, Stephan Thesing, Reinhard Wilhelm, and Alexander Metzner. Automatic identification of timing anomalies for cycle-accurate worst-case execution time analysis. In *International Symposium on Design and Diagnostics of Electronic Circuits and systems*, 2006. doi: 10.1109/DDECS.2006.1649563.

[12] Heiko Falk, Sebastian Altmeyer, Peter Hellinckx, Björn Lisper, Wolfgang Puffitsch, Christine Rochange, Martin Schoeberl, Rasmus Bo Sørensen, Peter Wägemann, and Simon Wegener. TACLeBench: A benchmark collection to support worst-case execution time research. In Martin Schoeberl, editor, *16th International Workshop on Worst-Case Execution Time Analysis (WCET 2016)*, volume 55 of *OpenAccess Series in Informatics (OASICS)*, pages 2:1–2:10, Dagstuhl, Germany, 2016. Schloss Dagstuhl–Leibniz-Zentrum für Informatik.

[13] Gernot Gebhard. Timing Anomalies Reloaded. In *International Workshop on Worst-Case Execution Time Analysis*, volume 15 of *Open Access Series in Informatics (OASICS)*, pages 1–10. Schloss Dagstuhl – Leibniz-Zentrum für Informatik, 2010. ISBN 978-3-939897-21-7. doi: 10.4230/OASICS.WCET.2010.1.

[14] Alban Gruin, Thomas Carle, Christine Rochange, Hugues Cassé, and Pascal Sainrat. Minotaur: A timing predictable RISC-V core featuring speculative execution. *IEEE Trans. Computers*, 72(1):183–195, 2023. doi: 10.1109/TC.2022.3200000.

[15] Sebastian Hahn and Jan Reineke. Design and analysis of SIC: A provably timing-predictable pipelined processor core. In *Real-Time Systems Symposium*, pages 469–481. IEEE, 2018. doi: 10.1109/RTSS.2018.00060.

[16] Pierre-Emmanuel Hladik, Félix Ingrand, Silvano Dal-Zilio, and Reyyan Tekin. Hippo: A formal-model execution engine to control and verify critical real-time systems. *J. Syst. Softw.*, 181:111033, 2021. doi: 10.1016/J.JSS.2021.111033. URL https://doi.org/10.1016/j.jss.2021.111033.

[17] Infineon Technologies TC27X. AURIX TC27-X D-Step Documentation. https://www.farnell.com/datasheets/3109944.pdf, 2014.

[18] Mathieu Jan, Mihail Asavoae, Martin Schoeberl, and Edward A. Lee. Formal semantics of predictable pipelines: a comparative study. In *25th Asia and South Pacific
*Design Automation Conference, ASP-DAC 2020, Beijing, China, January 13-16, 2020*, pages 103–108. IEEE, 2020. doi: 10.1109/ASP-DAC47756.2020.9045351.

[19] Louison Jeanmougin, Thomas Carle, and Christine Rochange. Bounding the WCET of a GPU thread block with a multi-phase representation of warps execution. In *37th Euromicro Conference on Real-Time Systems, ECRTS 2025, Brussels, Belgium, July 8-11, 2025*, 2025.

[20] Mahmoud Khairy, Zhesheng Shen, Tor M. Aamodt, and Timothy G. Rogers. Accel-sim: An extensible simulation framework for validated gpu modeling. In *2020 ACM/IEEE 47th Annual International Symposium on Computer Architecture (ISCA)*, pages 473–486, 2020. doi: 10.1109/ISCA45697.2020.00047.

[21] Raimund Kirner, Albrecht Kadlec, and Peter Puschner. Precise worst-case execution time analysis for processors with timing anomalies. In *Euromicro Conference on Real-Time Systems*, pages 119–128, 2009. doi: 10.1109/ECRTS.2009.8.

[22] Yau-Tsun Steven Li and Sharad Malik. Performance analysis of embedded software using implicit path enumeration. In *Proceedings of the ACM SIGPLAN 1995 workshop on Languages, compilers, & tools for real-time systems*, pages 88–98, 1995.

[23] Thomas Lundqvist and Per Stenström. Timing anomalies in dynamically scheduled microprocessors. In *Real-Time Systems Symposium*, 1999. doi: 10.1109/REAL.1999.818824.

[24] Antoine Miné. Backward under-approximations in numeric abstract domains to automatically infer sufficient program conditions. *Sci. Comput. Program.*, 93:154–182, 2014. doi: 10.1016/J.SCICO.2013.09.014. URL https://doi.org/10.1016/j.scico.2013.09.014.

[25] Dominic Oehlert, Selma Saidi, and Heiko Falk. Compiler-based extraction of event arrival functions for real-time systems analysis. In *30th Euromicro Conference on Real-Time Systems (ECRTS 2018)*. Schloss Dagstuhl-Leibniz-Zentrum fuer Informatik, 2018.

[26] Claire Pagetti, David Saussié, Romain Gratia, Eric Noulard, and Pierre Siron. The ROSACE case study: From simulink specification to multi/many-core execution. In *20th IEEE Real-Time and Embedded Technology and Applications Symposium (RTAS)*. IEEE Computer Society, 2014. doi: 10.1109/RTAS.2014.

6926012. URL https://doi.org/10.1109/RTAS.2014.6926012.

[27] CAOTIC project partners. Study of timing anomalies documented in the literature. Technical report, 2025. URL https://anr-caotic.imag.fr/.

[28] Jan Reineke, Björn Wachter, Stefan Thesing, Reinhard Wilhelm, Ilia Polian, Jochen Eisinger, and Bernd Becker. A Definition and Classification of Timing Anomalies. In *International Workshop on Worst-Case Execution Time Analysis*, volume 4 of *Open Access Series in Informatics (OASICS)*, pages 1–6. Schloss Dagstuhl – Leibniz-Zentrum für Informatik, 2006. ISBN 978-3-939897-03-3. doi: 10.4230/OASICS.WCET.2006.671.

[29] Hamza Rihani. *Many-Core Timing Analysis of Real-Time Systems*. Theses, Université Grenoble Alpes, December 2017. URL https://theses.hal.science/tel-01875711.

[30] Lilia Rouizi, Mihail Asavoae, Benjamin Binder, Lionel Rieg, and Florian Brandner. Revisiting timing anomalies in predictable in-order pipelines. In *Euromicro Conference on Real-Time Systems (ECRTS)*, Dagstuhl, Germany, 2025. Schloss Dagstuhl–Leibniz-Zentrum fuer Informatik.

[31] Martin Schoeberl, Pascal Schleuniger, Wolfgang Puffitsch, Florian Brandner, and Christian W. Probst. Towards a Time-predictable Dual-Issue Microprocessor: The Patmos Approach. In *Bringing Theory to Practice: Predictability and Performance in Embedded Systems*, volume 18 of *Open Access Series in Informatics (OASICS)*, pages 11–21. Schloss Dagstuhl – Leibniz-Zentrum für Informatik, 2011. ISBN 978-3-939897-28-6. doi: 10.4230/OASICS.PPES.2011.11.

[32] Matheus Schuh. *Implantation sûre d'applications temps-réel critiques sur plateforme pluri-coeur*. Theses, Université Grenoble Alpes, May 2022. URL https://theses.hal.science/tel-03827333.

[33] Hardik Shah, Kai Huang, and Alois Knoll. Timing anomalies in multi-core architectures due to the interference on the shared resources. In *Asia and South Pacific Design Automation Conference*, pages 708–713, 2014. doi: 10.1109/ASPDAC.2014.6742973.

[34] Ingomar Wenzel, Raimund Kirner, Peter Puschner, and Bernhard Rieder. Principles of timing anomalies in superscalar processors. In *International Conference on Quality Software*, pages 295–303, 2005. doi: 10.1109/QSIC.2005.49.