Multi-core WCET: combining analysis, scenarios and measurement
On a shared-resource multi-core, execution time depends on what the other cores are doing. That breaks both pure measurement and pure static analysis.
On a single core with a simple pipeline, worst-case execution time is a tractable problem. On a multi-core with shared caches, shared buses and a memory controller arbitrating between them, it stops being a property of the code.
Multi-core WCET evidence usually combines architectural analysis, controlled scenarios and measurements, because interference depends on shared resources and concurrent activity. The required balance is method- and platform-specific.
The interference problem
A function’s execution time now depends on what the other cores are doing while it runs. A cache line evicted by a neighbor, a bus transaction that has to wait, a memory controller that serves someone else first - none of these are in the code you are analyzing.
The relevant worst case may arise from a particular execution path, a particular shared-resource state, a concurrent workload, or their combination. A defensible analysis therefore makes both path assumptions and interference assumptions explicit. The search space is the product of the two dimensions.
This is why EASA AMC 20-193 exists and why it is hard to satisfy: it asks you to address interference between cores, and there is no way to do that by looking at one core’s code.
A useful way to structure the problem is as a matrix. Rows represent relevant execution paths or path classes; columns represent interference scenarios or resource-contention classes. Measurements populate observed cells. Analysis determines which unobserved cells are bounded, infeasible or still require evidence.
The report should distinguish cells that were observed, bounded analytically, argued infeasible, covered by conservatism, or left open. A single maximum value does not show which parts of the path-interference space remain unexamined.
Why pure measurement fails
Measurement tells you what happened. It cannot tell you what could happen.
If you run a test campaign and record the longest observed execution of a task, you have a high-water mark, not a bound. The interference pattern that produces the true worst case may need three subsystems to align in a way your tests never produced.
A “measured WCET” is a high-water mark, not a bound. The distinction matters because a bound is a safety property and a maximum observation is not.
Why pure static analysis is uncomfortable
Static analysis produces a real bound, by construction: it accounts for every path and assumes the worst about every uncertainty.
The difficulty is that on a multi-core there are many uncertainties, and assuming the worst about all of them independently produces a bound far above anything the system will ever do. A bound that is sound but ten times the actual worst case is unusable for dimensioning - it forces hardware that is not needed, or it gets ignored.
The hybrid approach
Take the structure and the guarantees from static value and path analysis, and the per-block execution times from measurement on the real part.
The analysis knows which paths exist and how they compose. The measurement supplies what a block actually costs on this silicon, with this cache, under this interference. The result keeps the path guarantees of the static analysis and is tight enough to be useful. Whether a block’s worst case was among the measurements cannot itself be measured; that question is addressed by the design of the measurement campaign and the assumptions of the analysis.
That is the method behind the collaboration with AbsInt: TimeWeaver uses its analysis method and assumptions to combine program information with measurement data; Accemic supplies trace-derived observations and provenance. The complete assurance argument remains a project responsibility. The joint paper at ERTS² 2024 documents the pipeline; it is on the publications page.
What measurement has to deliver for this to work
Three properties, and they are demanding:
Real silicon, real interference. Measurements from a simulation or from a single-core run do not contain the effect you are trying to bound. And a stressor is evidence only for the resource behavior it actually exercises: maximum aggregate traffic does not necessarily produce the worst latency for every victim path. Scenario selection should therefore be tied to the shared resources, arbitration policies, access patterns and temporal alignment relevant to the target function.
Long observation. An interference pattern that requires alignment of several subsystems may appear once in an hour. A measurement window of milliseconds will not see it - which brings the buffer versus live processing distinction back as a practical requirement rather than an architectural preference.
Attribution. A measured time is only useful if you know which code it belongs to, which task was running, and what else was happening. That means instruction trace with task context, not just timestamps. Multi-core timing data are useful only when the observation can be attributed to the correct core, task or execution context and correlated across the relevant clocks; the evidence record states how context identity, resets, migration, pre-emption and clock correlation are handled.
An honest note on what trace gives you
Instruction trace reconstructs control flow exactly within the valid observation scope. Time is a different matter: it arrives through occasional timestamps and cycle counts, not per instruction, and enabling those aggressively is expensive in bandwidth.
So trace-based timing is real but it is segment-based rather than instruction-precise, and the WCET result comes from combining it with static analysis rather than from the trace alone. A control-flow trace alone does not yield a worst-case bound; the bounding step comes from the analysis method.
Related: the AbsInt integration · timing and WCET in our technology section
Where this becomes a product decision
- Applicable capability: CEDARtools.SmartTrace for WCET analysis, feeding AbsInt TimeWeaver for the hybrid argument.
- Configuration check: target support, answered per configuration.
- Evidence and limits: the joint ERTS² 2024 paper on publications; sufficiency remains a project determination.
Sources
The guidance document referred to on this page:
- EASA AMC 20-193, cited by objective. AMC 20-193 is guidance for an acceptable means of compliance in its stated scope; it is not a product certification and does not prescribe one mandatory tool chain. Cite the applicable revision and objective rather than using the document name as a general performance claim.
- Kästner et al., Multi-core WCET Analysis Using Non-Intrusive Continuous Observation, ERTS² 2024 - see publications.