Measure the executable that actually ran
From the trace port to a coverage report: what you connect, what runs where, what you get back, and what stays untouched on the target.
In a supported configuration, you connect the trace path, identify the executable and debug information, configure the trace source, run the existing tests, and receive results for the executable that actually ran. Passive analysis inserts no coverage counters into the application; Hybrid Runtime Analysis is an explicit additional mode for otherwise unobservable condition outcomes.
Four steps from execution to evidence
- Identify the artifact. Exact executable, debug information, target, trace configuration and analysis objective.
- Observe execution. A compatible trace source and path provide the machine-level events for the reported scope - passively, or with CEDARtools.Anchor anchors where source attribution needs them.
- Validate and reconstruct. The workflow checks identity, configuration, synchronization and loss before reconstructing control flow.
- Attribute and report. Observed execution is mapped to object and source obligations; unresolved, supplemented and invalid portions remain visible.
The sections below walk the same chain in detail.
What you connect
A supported target implements a compatible instruction-trace source and exposes a trace path with sufficient bandwidth for the intended measurement. Depending on the device and board, the path may use a parallel trace port, a high-speed serial link, an on-chip sink or vendor-specific infrastructure. Whether a specific configuration is verified is answered per configuration - with a documented reference configuration, or a bounded feasibility review.
What the analysis needs
- the exact executable or program image used for the run;
- the corresponding debug and mapping information;
- the target, core and trace configuration;
- the test or operational interval to be analyzed;
- the required metric and acceptance policy; and
- where applicable, the Anchor* anchor manifest.
What runs where
- On the target: the identified executable and the processor’s trace infrastructure. In passive mode, the application contains no coverage counters or measurement runtime. In Anchor* mode, the executable contains the declared observation anchors.
- In the trace-processing system: acquisition, validity monitoring, control-flow reconstruction and aggregation. The exact partition between FPGA and host software depends on the product configuration - stage by stage on live trace processing.
- On the host: configuration, mapping, review, reporting and export to downstream tools.
How a run becomes valid evidence
Before a result is accepted, the workflow checks that the expected executable and debug information were used, that the trace source and routing match the declared configuration, and that the observation contains no untreated overflow, loss or synchronization gap within the reported scope. A run that does not meet the configured validity criteria is rejected or reported explicitly as partial evidence.
What you get back
Depending on the target, trace protocol, compiler information and analysis mode, the workflow can produce object-code execution, source statement and branch coverage, condition or MC/DC evidence, path timing and call relationships. The report distinguishes directly observed, reconstructed, mapped, supplemented and unresolved obligations. Reports as HTML and CSV, and exports into TESSY Hyper Coverage and Teamscale.
What it costs the target
In passive mode, no coverage counters or measurement runtime are inserted into the application, and no application-side coverage state is written to RAM. The trace unit must still be configured, and the trace path consumes implementation resources such as pins, bandwidth and power. Anchor* adds bounded control-flow anchors; their code-size and timing effects are measured and reported for the named build.
The trace port itself is not free of physical reality: its pins have to be available and routed, and the trace unit has to be configured. That is a board design question, and we will tell you honestly whether your board can do it.
What it does not do
It does not replace unit testing, and it does not make requirements-based testing unnecessary. It removes one specific compromise - the one where the build you measure is not the build you ship.
Not every trace configuration supports every metric. Review the target capability matrix and the measurement-validity rules before selecting a coverage or timing objective.
Next: supported targets · how the technology works in detail · integrations
Sources
The external reference on this page is: