Timing and WCET
Execution times measured on real silicon over long observation windows - the measurement half of hybrid worst-case timing analysis.
Processor trace can provide path and timing observations from the executing target when the trace configuration supplies the required control-flow and time correlation. Those observations are measurements, not automatically safe upper bounds. They can support measurement-based analysis, hybrid WCET workflows and investigations of multi-core interference when combined with the assumptions and coverage required by the chosen method.
The multi-core problem
On a single core with a simple pipeline, worst-case execution time is tractable. On a multi-core with shared caches, shared buses and a memory controller that arbitrates between them, the execution time of a piece of code depends on what the other cores are doing. The observed or analyzed worst case can depend on both the execution path and the interference pattern produced by concurrent activity; neither dimension should be treated as sufficient on its own.
EASA AMC 20-193 addresses the assurance concerns introduced by multi-core interference. A measurement and analysis workflow can contribute evidence relevant to those objectives; use of a workflow does not by itself establish compliance.
What measurement contributes
A trace-based observation gives you the actual execution times of actual paths, under actual interference, on the actual part - and it can keep doing so for hours or days rather than for the length of a capture buffer, subject to continuous trace delivery and validity monitoring.
That matters specifically for interference: a pattern that only shows up when three subsystems align may never appear in a five-second capture and may appear several times in a week-long test campaign.
Each timing result identifies the clock or timestamp basis, core and context attribution, start and end events, trace discontinuities, target configuration, workload and executable. Where a value combines trace timing with another clock source, the correlation method and uncertainty are stated.
What measurement does not contribute
Observed maximum is not WCET. It is the largest value seen in the stated observations. A WCET claim additionally requires an argument about path coverage, hardware states, interference, measurement uncertainty and the analysis method used to bound unobserved cases.
A defensible upper bound comes from the project’s selected timing-analysis method. In the described TimeWeaver workflow, static analysis combines with measured path and interference information - the measurement makes the bound tight enough to be useful instead of merely safe; other projects may use a different accepted method. How that combination works with AbsInt TimeWeaver
Limits that determine the timing result
Timing precision is protocol- and implementation-dependent. Not every instruction-trace configuration carries cycle-accurate information, and reconstructed control flow alone does not establish exact execution time. The supported-target matrix states the timing capability verified for each configuration.
On AURIX™
For Infineon® AURIX™ the measurement side is CEDARtools.SmartTrace, using the vendor’s MCDS mechanism (TC3xx and TC4xx).