Knowledge base
Embedded trace, coverage metrics and the parts of both that are usually explained badly.
Most of what is written about embedded trace online is either a vendor datasheet or a tutorial that stops before the interesting part. These pages are our attempt at the middle: enough depth to be useful, without a sales pitch in every paragraph.
Where a claim rests on a measurement we have not published, we say so rather than rounding it into a number.
Start with the question you have
- Can my target expose usable instruction trace? Trace source, port, bandwidth and feasibility.
- Can machine execution support source-level coverage? Source attribution, DWARF and optimization.
- What does observation cost? Native trace, CEDARtools.Anchor and software instrumentation, measured.
- How does this become assurance evidence? Measurement validity, standards and the qualification boundary.
- What changes on multi-core systems? Interference, timing and WCET.
Start here
If you are new to the subject, three articles in this order:
- What embedded trace is, and what it is not
- The kinds of code coverage, and what each proves
- Why the object-to-source mapping breaks under optimization
The third one is the article we would most like you to read. It describes a limit that applies to an entire class of tools, ours included.
Embedded trace
| Article | What it covers |
|---|---|
| What embedded trace is | The vocabulary, the difference from debugging and profiling, and why it is compressed by construction - canonical explanation |
| The trace protocols, compared | Arm® ETM, Intel® PT, Nexus, MCDS - four commonly encountered encoding ecosystems for the same problem - canonical explanation |
| Why trace is compressed | Discontinuities instead of instructions, and every surprise that follows from it - canonical explanation |
| The trace port | Pins, clocks, connectors - the decision made at PCB design time |
| Is this target traceable? | Seven feasibility layers from core capability to metric - canonical explanation |
Coverage
| Article | What it covers |
|---|---|
| The kinds of coverage | Eight metrics, one ladder, and the blind spot of each - canonical explanation |
| MC/DC, worked through | Independence pairs in one example, and where the definition gets slippery - canonical explanation |
| 100 % MC/DC, 40 % Evidence | One intermediate Boolean can halve what a green report proves; the published evidence, and the two kinds of chain behind it |
| Source attribution in trace-based coverage | Trace completeness, source attribution and coverage achieved are three questions, not one percentage - canonical explanation |
| Why the mapping breaks under optimization | Four documented mechanisms, with assembly, and the three loss classes - canonical explanation |
| Have you ever stepped through -O3 code? | What the compiler writes down when it cannot decide, quoted from its own source |
| DWARF as a chain of trust | Functionally silent, so ordinary tests do not validate it - what dedicated metadata verification looks like |
| What instrumentation costs | The overhead argument honestly, and where it still holds - canonical explanation, with the measured SQLite -O3 comparison |
| Evaluating coverage tools | Five questions that separate tool capabilities when the evidence must come from the optimized integration build, and the artifacts to ask for |
| Generation is not verification | Why an actor that writes the code cannot also judge it, and what has to sit outside the loop - canonical explanation |
Standards and practice
| Article | What it covers |
|---|---|
| What the standards require | Four regimes, one ladder, and the part that is argument rather than measurement - canonical explanation |
| Dead code, deactivated code, and the rest | Four findings a coverage gap can expose - and the evidence check that comes first |
| What an assessor may ask | Twelve questions, none of them answered by a percentage |
Applications
| Article | What it covers |
|---|---|
| Multi-core WCET | Combining analysis, scenarios and measurement - and what each contributes - canonical explanation |
Why we write these
Partly because the questions come up in every first conversation and it is faster to have written the answer down. Partly because a company that cannot explain its own field clearly probably does not understand it as well as it claims.
And partly for a reason worth stating plainly: several of these articles describe limits that apply to our own products too. We would rather write them down than be asked about them.
Something missing, or something wrong? Tell us. Corrections are welcome and get attributed.