---

CTTE implements both ratified RISC-V^® trace formats, and treats that as the baseline rather than the goal. The capabilities that matter most sit outside either envelope - the extras that turn a conformant encoder into a measurement instrument. Each of them is marked V in the matrix of implemented standards, row by row against what the standards define - and anything either standard already defines stays out of this list, even where CTTE implements it well.

Instrument and configure without touching the bus

CTTE’s hardware-supported instrumentation (HSI) rests on two mechanisms, and they carry separately: Accemic CEDARtools^® CSR access protocol (ACT-CAP) and Accemic CEDARtools Smart Trigger (ACT-ST).

Software can raise a trace message, and configure the encoder itself, with ordinary store instructions. What makes that unusual is the register those stores go to: it does not exist. The address is not decoded by the encoder’s bus interface, and the processor does not have to implement it either. The only requirement on the integration is that the access does not raise an exception.

Every data access is visible to the encoder on the trace ingress port, so a write to the designated address is observed there, including which address was written. Functionally the store behaves like a NOP for the program: no peripheral to implement, no driver, and no bus response the scheme depends on - the integration only has to ensure the access does not fault. From that the encoder composes a complete trace message on its own, carrying a tag and up to 192 bits of payload.

The scheme is two-stage, and that is what makes it more than a message trigger: the first write selects a control register by index, the second writes it. The encoder’s control registers are therefore reachable at run time, from the running program, without any bus access. A system can reconfigure its own trace subsystem between phases of a test; where the implementation context calls for it, access-control mechanisms can gate what a given privilege level may reach.

What can be sent this way: an immediate value, a register value, the current program counter, wall-clock time, CPU cycles. The command also carries its own destination, so the same event goes to the external trace stream as a standard message, to the on-chip event port as an uncompressed beat, to both, or stays inside the encoder.

Timestamps are the case where this pays off most visibly. Conventional encoders emit them sporadically, and usually not where they are needed; raising the rate inflates bandwidth until the stream overflows and gaps appear. Here a timestamp can be forced exactly where it carries information - at a decision, at a phase boundary - instead of rigidly after n branches without regard to the structure of the control flow.

There is precedent for software-visible trace stimuli: Arm^®‘s CoreSight^™ System Trace Macrocell (STM architecture specification) traces system activity through memory-mapped stimulus ports with a shared global timestamp. The difference is where the cost sits: a stimulus port is a mapped bus write, while the ACT-CAP command is a store to an address that no bus decodes and no core needs to implement.

The same message, without touching the program

The identical message can be composed by hardware, from a table entry rather than from an instruction. When execution reaches a configured address, the encoder builds and sends the record on its own: the program is not modified, not recompiled and not slowed down, and no software runs to produce it.

The table is searched at one lookup per cycle, and its size is chosen at synthesis time - a tree of n levels holds 2^n - 1 entries, which is 1023 in our standard configuration, reported to software in a capability register. Instrumentation points are therefore not an architectural resource to be rationed but a table to be sized and filled. Each entry carries its own command word, so what is captured and where it goes is configured per trigger. The table is locked while tracing runs, and read-back stays available, so a debugger can inspect the table of a running session without unlocking it.

The two mechanisms are independent. A system can use the software path without a table, or fill the table without ever executing an instrumentation store. Together they cover uses that normally require rebuilding the program - branch coverage and MC/DC data collection among them. The practical consequence is that a probe can be added to a running, unmodified production binary, including one whose source is unavailable, and removed again by clearing a register.

The message itself is standard: data acquisition is defined by IEEE-ISTO 5001-2012 as a public message, and we say so rather than claiming it as our own. What is different here is that the encoder composes one on its own, from a store to an address nobody decodes or from a table hit with no software involved at all - and that the same record can go, alternatively or in addition, out on the AXI-Stream port to another CPU in the fabric for control-flow-integrity checking or runtime verification.

An uncompressed event port for consumers inside the device

None of the three specifications defines an output beside the trace port - their subject is the message format and its control. This port is also the capability on this page with the most consequence for what comes next.

Alongside the standard trace stream, CTTE exposes an uncompressed on-chip event output: one beat per event, self-describing, carrying an identifier and its payload. A consumer on that port needs no protocol decoder, no branch-predictor mirror and no program image. It reads a beat and acts.

Two things follow. First, a runtime monitor or control-flow-integrity checker can live in the same fabric as the core it observes and work at the rate events arrive, rather than after a capture is transferred to a host. Second, routing an event to the on-chip port does not perturb the external stream, so an existing offline workflow and its evidence remain valid while a monitor is added.

Why that matters as software becomes machine-generated

Review-based assurance assumes a human author whose intent can be interrogated. As more code is generated rather than written, that assumption weakens, and the evidence that a system does what was intended increasingly has to come from observing the running system instead of from reading its source.

That shifts non-intrusive processor trace from a debugging aid towards the measurement instrument an acceptance argument rests on, and it puts an unusual demand on the trace source: it is the one component in the chain that is never allowed to be quietly wrong. The properties above are the answer to that demand rather than a feature list. Loss that announces itself keeps a generated program from being scored against a stream that quietly lost the interesting part. An instrumentation probe that costs the program one store - or none at all - makes it affordable to put evidence exactly where a question is. And an in-fabric event port is what lets a check run while the system runs, rather than in a later batch on a workstation.

Where that reasoning leads for the rest of the toolchain is set out under what we do differently.

One front end, two ratified formats

RISC-V has two ratified processor-trace formats, and they split the tool landscape: some toolchains speak N-Trace, others speak Efficient Trace. An encoder that implements one of them has chosen your toolchain for you.

CTTE implements both, from a single protocol-agnostic front end. The back end is an elaboration parameter, so a design that needs one format does not carry the logic of the other, and a multi-core SoC can run different formats on different instances. The shared front end has a second effect that matters more than the convenience: the two formats can be compared on the same recorded execution, under the same configuration, which is otherwise impossible to do fairly.

What we can tell you about loss that a specification cannot

Every specification requires that loss be announced, and all three define how. None of them says how long recovery takes, or where the threshold sits at which loss begins. We measured both.

Recovery is not a distribution but a constant: across 3,305 announced-loss episodes, the distance from the error message to the re-anchoring synchronization was one message, four bytes and zero instructions, with no spread at all. That follows from construction rather than from a favorable sample, because the encoder emits the re-anchor as the next message. The constant is measured across six simulation streams and four compression configurations - and not yet claimed for board streams or the E-Trace back end.

The threshold is not where a mean-rate calculation puts it. A sink able to absorb about a tenth more than the encoder offers on average still loses trace, because the offer arrives in bursts, and below that point the loss fraction does not ramp, it steps.

And the announcement is not a gauge. The number of error messages peaks at around half loss and falls again as loss grows, so a consumer judging trace quality by error density gets its most reassuring reading exactly where most of the control flow is missing. The stream tells you that trace was lost, never how much; quantifying it requires a reference execution.

One adjacent note, stated plainly: where a core supplies no process context, CTTE derives a process key and reports it in band - and the comparator and filter registers used for scoping are standard, defined by the Trace Control Interface; we do not present them as ours.

Make life easy for the decoder

A recurring failure mode with configurable encoders has nothing to do with the encoder itself: a capture gets decoded under the wrong assumptions. A stream produced with a compression feature enabled is not decodable by a decoder that does not run the matching model, and nothing in a bare byte stream says which features were active. The usual mitigation is an out-of-band configuration file that has to survive alongside the capture.

CTTE makes the stream self-describing instead. A configuration message carries a format version, the compiled-in capability map, the runtime-enabled subset and the structural parameters a decoder needs to instantiate the compression models - taken from the same constants the implementing hardware consumes, so the advertised sizes cannot drift from the built encoder. A decoder configures itself from the stream; a decoder that does not know the message still frames it correctly and skips it. And the verification gate behind this is stated the way we state gates: a decoder invoked without any feature flags, configuring itself purely from the stream, must reconstruct the same program counters as the same decoder invoked with explicit flags - and a deliberately mismatched negative control must diverge.

Evidence you can check

The RTL, the register sources, the testbenches, the formal properties and the build scripts are published with the release. The verification argument is stated with its limits attached: which streams, which configurations, which counter-proofs, and where a result is a model rather than a measurement.

That is a deliberate position rather than a courtesy. An encoder is a measurement instrument, and an instrument whose own evidence cannot be reproduced is not one. The matrix of implemented standards is part of the same discipline: rows that are not implemented carry their reason, and rows that describe another standard are checked against that standard’s text rather than against our recollection of it.