The standards which CTTE implements

Standards define envelopes, implementations fill them - and the interesting information is where the two differ. This page holds the condensed capability matrix from our CTTE paper: what each published trace specification defines, and what CTTE provides.

Paper: CTTE: An Open Dual-Protocol RISC-V Trace Encoder for N-Trace and E-Trace - arXiv preprint, August 2026 (PDF).

Read this before the table

The three specification columns are the published standards - IEEE-ISTO 5001-2012 (Nexus), RISC-V^® N-Trace 1.0 and RISC-V E-Trace 2.0, together with the Trace Control Interface where it is the normative source. They are not any vendor’s product. A commercial encoder may implement more or less of its chosen standard than a column suggests, and this page makes no statement about any specific implementation. The comparison answers the question a reader integrating against a standard actually has: what does each standard define, and what does this implementation provide?

Two more boundaries, stated up front:

• No certified-conformance claim. No conformance certification program exists for either RISC-V specification, and we make none. CTTE’s reset configuration produces a stream strictly inside N-Trace 1.0, with the single documented exception of the configuration message; every feature that leaves that envelope is opt-in, resets to disabled, and is labeled a vendor extension in the documentation, the register description and the capability map.
• “Not implemented” always carries its reason. A neutral marker would hide the difference between an unfinished feature and a decision - the four ▲ rows below state theirs in the row.

Legend: ✓ = defined / implemented · o = optional in that specification · v = vendor code space · - = not defined there · V = Accemic vendor extension · ▲ = deliberately not implemented, reason in the row.

The specifications compared:

• RISC-V N-Trace 1.0 - ratified specification, maintained in the RISC-V International repository;
• RISC-V E-Trace 2.0 (Efficient Trace) - ratified specification, same organization;
• RISC-V Trace Control Interface v1.0 - the normative source where the table says “(TCI)”;
• IEEE-ISTO 5001-2012 (Nexus), v3.0.1 - the Nexus 5001 Forum is no longer active; the RISC-V N-Trace working group preserves the standard document in its repository.

Program-flow reconstruction

Bandwidth optimizations - note the two standards differ

The two specifications are not ranked versions of one idea; their compression envelopes are partly disjoint. Branch prediction and the jump-target cache are vendor extensions under N-Trace and standard features of E-Trace; repeated-history counting and the wide instruction count have no E-Trace counterpart at all. An encoder that implements both inherits the union - and because both back ends sit behind one front end, the extra mechanisms cost their logic once rather than twice. How each compression is enabled, and the verification that gates it, is described under eight compressions, each one optional.

Data flow, system and control

Two readings in this table deserve a footnote. The data-trace drop policy and field-elision rows carry v (TCI) in all three specification columns: both are control bits of the Trace Control Interface rather than message types of any one stream format. And the Device ID row asks about the message type: N-Trace’s trTeImpl is a TCI register, not a message, so its dash stands.

Encoder control registers

CTTE capabilities in the reserved vendor space

N-Trace reserves TCODEs 56-62 for vendor extensions and requires vendor features to be signaled through them. The capabilities in this section live in that reserved space - CTTE’s configuration message, for example, is TCODE 58. An extension in the space the standard sets aside is not a deviation from the standard; it is a use of it.

On the dashes in this section: a dash records that, as of August 2026, none of the three specifications defines a comparable capability. That is a statement about those documents - not about any vendor’s product, which a published specification cannot speak for. Each of these cells has been checked against the specification text itself, not against our recollection of it; where that check moved a capability back into a standard, the row moved with it - data acquisition to the data-flow section, announced loss to the program-flow section.

One separation in this section is worth a sentence of prose, because it carries the actual difference: the data-acquisition message is Nexus standard, and the data-flow section above credits it to Nexus accordingly. What is new is not the message format but that the encoder composes the message itself - once from a single store to a CSR address that neither the encoder’s bus interface nor the core needs to decode, and once from a trigger-table hit with no software involved at all. The two paths are independent: a system can use the software path without a table, or fill the table without ever executing an instrumentation store. Either way the command word carries its own destination - the external stream, the on-chip port, or both. The CTTE extras sets this out in full.

On the four rows that are not implemented

One is measured to be counterproductive in the regime we can measure. One is structurally impossible at this interface, because the ingress carries no back channel to the hart. One is blocked because no core we have integrated offers a contract for the status bits it would report - any implementation would have to invent the semantics. One is deferred for want of a consumer. Three of the four are therefore properties of the interface or the ecosystem rather than of this encoder.

Where this table comes from

This is the condensed form of the capability matrix in our CTTE paper. The full per-message table - including the compile switch, the runtime control and the advertised capability bit for each of its 43 rows - is part of the release artifact and is machine-checked against the RTL and the register description in continuous integration.

---

Related: CEDARtools.TraceEncoder · the CTTE extras · the live demo · discuss an integration