The trace protocols, compared
Four commonly encountered encoding ecosystems for the same problem. What each one transmits, how each signals exceptions, and where each becomes awkward.
Every trace protocol solves the same problem: transmit enough information that a decoder holding the program image can reconstruct the executed instruction sequence, using as little bandwidth as possible.
They arrive at noticeably different answers.
Protocol names alone do not establish the implemented feature set. Optional timing, context, data-trace, filtering and transport capabilities vary by implementation and configuration - and an encoding protocol is a different layer from the physical transport that carries it, so the two are compared separately rather than as though they were the same thing.
Four ecosystems you will commonly meet
This page compares four commonly encountered ecosystems, as examples of the encoding models in use - it is not an exhaustive taxonomy, and within each ecosystem the implemented behavior depends on the architecture revision and the enabled options.
Arm® CoreSight™ ETM and the newer ETE encode the outcomes of protocol-defined P0 elements as an atom stream - E and N elements - and emit address, exception, context and synchronization information as required by the architecture revision and enabled options. An E or N atom should not be equated mechanically with “branch taken / not taken” across revisions, and return targets may be transmitted explicitly or inferred through an enabled return-stack mechanism. The atom stream is remarkably dense: a long run of conditional outcomes costs about one bit each.
Intel® PT is a bitstream protocol with the same idea in different clothing: TNT packets carry taken/not-taken decisions, TIP packets carry indirect branch targets, PSB packets mark stream boundaries for synchronization, and OVF marks overflow. It is engineered for very high compression on x86.
Nexus (IEEE-ISTO 5001) is message-based and open. Each message carries a TCODE identifying its type, an SRC field identifying the source core - which is how multi-core works here - and fields such as instruction count and unique address. Branch history is carried in a HIST field. Nexus is common in automotive microcontrollers and is transported over parallel MDO pins, serial links or into memory.
Infineon® MCDS on AURIX™ is the vendor’s own trace solution and is message-based as well, following the same discontinuity-oriented idea: transmit where the flow broke, let the decoder walk the straight lines.
Its message-level documentation is restricted and available under NDA, so this page stays at the level of the model rather than the wire format. If you are building against it, the reference manual comes through Infineon’s tool vendor program - and we can discuss the practical consequences with you under the same terms.
The same three questions
Read across the four and the differences reduce to how each answers three questions.
| Question | Arm ETM/ETE | Intel PT | Nexus | MCDS |
|---|---|---|---|---|
| How is a conditional branch signaled? | atom stream (E / N) | TNT bit | HIST bits or message | NDA |
| How is an indirect branch signaled? | address packet, often compressed against the previous address | TIP packet | unique address field | NDA |
| How does the decoder resynchronize? | periodic synchronization packets | PSB boundary | sync messages | NDA |
The table names the common model of each family; the exact packet types, context fields and resynchronization sequences are revision- and configuration-specific.
Two consequences follow.
Conditional branches are cheap, indirect branches are expensive. A conditional outcome costs about a bit. A computed jump or a virtual call costs an address - potentially a full one. A return may cost an address as well, unless an enabled return-stack mechanism lets the decoder infer the target. Workloads dense in indirect control flow produce far more trace than their instruction count suggests.
Synchronization is not free either. Sync points let a decoder join a running stream and recover after loss. What exactly they carry - address, context, timing fields - is revision- and configuration-specific, but in every family they are among the more expensive packets. Their frequency is a tuning parameter that trades robustness against bandwidth.
The instrumentation-shaped siblings
Two more show up in the same documentation and are often confused with instruction trace.
ITM provides software-generated instrumentation trace: the program writes to a register and a message appears in the stream. STM can combine such software stimulus with hardware event sources, where the implementation supports them. The software-stimulus side is instrumentation, with all that implies - it costs runtime, it changes the binary, and it only tells you what someone chose to emit. It is genuinely useful for marking phases and events, and it is not a substitute for instruction trace.
DWT is data watchpoint and trace: it can report accesses to selected addresses. Its data-trace features are optional and vary by core implementation - low volume if you select carefully, very high volume if you do not. There is a well-known trick in this corner - watching the RTOS current-task pointer to recover task identity on parts that cannot emit context-ID packets.
RISC-V®: the standard arrived before the sources
RISC-V® has two ratified instruction trace protocols, and they relate differently to the ecosystems above. N-Trace belongs to the Nexus lineage described earlier; E-Trace, the efficient trace specification, is a distinct protocol family with its own encoding model. Decoder and tool support exists for both, but it is a property of the specific core, encoder and decoder combination, not of the protocol name - check the concrete configuration rather than the specification’s ratification status.
The gap in that ecosystem is not the protocol. Implementing a RISC-V® core or ISA does not require a particular trace encoder, and a usable system additionally needs control, integration and transport components - so availability depends on the chosen core, SoC and platform implementation. That is one reason we published our own trace encoder IP as open source.
What this means when you choose a part
Three questions, in this order:
- Is there an instruction trace source at all? Not every part has one, and not every part that has one exposes it.
- How does it leave the chip? Parallel pins, serial link, or into memory. This decides your bandwidth ceiling and your board layout.
- What does the toolchain support? A ratified protocol with no decoder is a document.
The concrete answers per part are on our supported targets page, with status shown rather than implied.
Before a board schematic is frozen, write down the answers to these three questions for the concrete part you are considering - trace source, exit path, decoder support - and keep them with the design record.
Next: why trace data is compressed, and what it costs · the trace port: how the stream leaves the chip
Sources
The protocol behavior described above is taken from the vendor specifications themselves:
- Embedded Trace Macrocell Architecture Specification, ETMv1.0 to ETMv3.5 (Arm IHI 0014Q);
- Embedded Trace Macrocell Architecture Specification, ETMv4.0 to ETMv4.6 (Arm IHI 0064);
- Intel 64 and IA-32 Architectures Software Developer’s Manual, volume 3C, chapter on Intel Processor Trace;
- IEEE-ISTO 5001-2012, the Nexus 5001 Forum standard;
- RISC-V Processor Trace specification (E-Trace).
Infineon’s MCDS is covered by a non-disclosure agreement; this article therefore names only what Infineon has published itself.