CEDARtools.TraceEncoder - open trace encoder IP for RISC-V^®

Everything else on this site is about what you do with a trace stream. This page is about where the stream comes from - and on RISC-V, that has been the missing piece.

In brief

CEDARtools.TraceEncoder (CTTE), formerly published as C-Trace, is synthesizable RTL that sits next to a RISC-V core in your SoC or FPGA. It takes the core’s instruction-trace interface - the retirement signals - as its input and emits a standard encoded trace stream: N-Trace or E-Trace, selected per encoder instance. It is the trace source, not a complete trace subsystem; the supported protocol subset, optional features, input assumptions and downstream dependencies are stated by release.

Evidence status: every numerical claim on this page is tied to a source release and a public record naming the build parameters, tool versions, test set and result artifacts, published with the repository’s verification/ assets. Measured values without such a record are not quoted on this page.

The RTL, testbenches and verification assets are public: inspect the repository.

Release status: the tagged release (v1.0.0 on GitHub), its public verification records and the paper preprint are published; the repository is authoritative for the current version.

Discuss a commercial license or integration · Open the live demo · The CTTE extras

A trace source is increasingly more than a debug feature. It can become the observation channel through which verification tools and automated development systems understand what the real processor executed - where that leads.

The integration gap

Many Arm^®-based SoCs integrate CoreSight^™ components, and other processor families provide their own trace infrastructure - Infineon^®‘s MCDS is one example. Instruction trace remains implementation- and configuration-dependent everywhere: the required trace source, routing and output path must be present in the actual SoC and board.

RISC-V has ratified standard instruction-trace protocols and a common Trace Control Interface. Those specifications do not automatically place a compatible encoder in every core or SoC. An integrator still needs an encoder that implements the required protocol subset and connects correctly to the processor, control interface and downstream trace system.

Available implementations differ in openness, protocol subset, integration interface and published verification evidence. CEDARtools.TraceEncoder publishes the RTL and review artifacts for the stated release scope: the RTL is readable, the tests are readable, and the numbers below are measured rather than quoted from a datasheet.

Both protocols, chosen per instance

N-Trace and E-Trace split the RISC-V tool landscape. Supporting only one means your toolchain choice is dictated by the encoder. CEDARtools.TraceEncoder implements both. The protocol is selected per encoder instance at synthesis time, not multiplexed at runtime - so a multi-core SoC can run mixed protocols instance by instance, and a design that needs only one does not pay for the other in logic.

A leg is one named end-to-end run - a scenario such as exceptions, interrupts or resynchronization, or a single compression feature - decoded and compared against the reference sequence. The verification record names the twelve.

The multi-core funnel handles both framings and tags every source, so one decode run separates them again.

Eight compressions, each one optional

Every compression is a synthesis parameter and a run-time CSR gate, and every one is off by default - so the stream stays byte-compatible with strict standard tooling until you decide otherwise. Reduction has been measured per workload class, but those figures are not yet tied to a release-pinned record naming the build parameters, tool versions and workloads - so this page does not quote them. What each mechanism does is documented below; the measured effect per workload follows with the corresponding release record. In the named verification configuration, the decoded program-counter sequence agreed with the reference sequence over the stated test set, with no unaccounted loss reported by the monitored interfaces. What that result covers, and what it does not, is set out under Verification below.

Both instruction-trace modes are available (HTM and BTM), alongside ownership messages for context and privilege changes, event syncs, data trace, DAQ and the filter and comparator set.

The stream can describe itself. With the configuration message the decoder configures itself from the stream with no prior knowledge - which makes a capture artifact self-contained. If you have ever received a trace file without knowing how the encoder was set up, you know why that matters.

Two capabilities neither standard specifies

The standards define how execution becomes a compressed trace stream. Two CTTE capabilities sit outside that scope - and they are the ones instrumentation-heavy and in-fabric designs tend to care about most:

A software-visible capture interface (ACT-CAP / ACT-ST). A pair of CSR ranges through which running software - or a configured trigger - injects captures directly into the trace stream: the current program counter, a direct data value, data with its address, fetch- and access-threshold events, an explicit control-flow sync point. The records travel in-band as standard data-acquisition messages, ordered with the surrounding control flow - console-free visibility from inside the running system, through the same port as the trace.

An uncompressed AXI-Stream output. Next to the encoded trace stream, a separate 96-bit AXI-Stream output carries uncompressed instrumentation records for consumers inside the fabric - on-chip processing that should not have to decompress a protocol stream first.

Both are marked as Accemic extensions in the matrix of implemented standards, in the section for capabilities beyond either standard. The full account - including what is standard underneath these two capabilities and what is ours on top - is on The CTTE extras.

From 2,106 LUTs upward - same RTL

Identical source, configured through build profiles, synthesized for the AMD Zynq^™ UltraScale+^™ MPSoC (Kria^™ KV260). What is not needed is not synthesized.

Switching features back on from the slim base has been measured as well; those delta figures are not yet tied to a public record, so this page does not quote them. The two profile rows above are covered by the release record. You can decide where on that curve your design sits, and you can see the price before you commit.

A Linux^® boot, recorded end to end

The strongest evidence we have is not a benchmark. It is a full Linux boot on a CVA6, captured as a trace stream and decoded.

At that density the whole boot is roughly 55 MB of trace, derived from the two measured figures above rather than measured separately.

Linux 6.12.19 runs to the login prompt, the console session is interactive, and the entire boot is in the capture.

The demonstration establishes operation for the stated core, SoC integration, RTL parameters, software image and workload. It is a useful integration test, not a general conformance or performance proof for all Linux systems.

Four bring-up defects the trace found

This is the part that is hard to convey in a feature list.

• Hart ID stuck. The capture ends on a branch into a hang loop: the firmware never found its hart. Not one console character.
• Load-reserved / store-conditional dead. Every compare-and-exchange without effect - the bus lock signals were left open.
• Kernel header compressed. An endless loop in the trap handler and zero PCs in the kernel: the EFI magic at the start of the image is a compressed instruction, which this core configuration cannot execute.

• No address protection. The traced core could reach the entire address space. Now there is an address barrier with an error slave.

A debugger halts the core, and a printf needs a console that works. The trace needed neither.

Cores it has run on

The encoder’s input is the core’s instruction-trace interface, TIP or ITI - the retirement signals. A core can be connected when it exposes them at its boundary, directly or through a thin adapter.

Different ingress situations on purpose - partner cores, the upstream-standardized instruction-trace interface, a Trace-Control-Interface shim and a netlist-level integration. Licensed third-party cores are integrated, not redistributed. Multiple encoder instances run concurrently, merged into a single stream and separated again in one decode run.

Verification - the part we would want to see from a vendor

93.42 % of RTL lines were exercised directly by tests (4,972 of 5,322), measured across three build profiles. Every remaining line was dispositioned as auto-classified trivial or covered by an accepted waiver; zero lines remained undispositioned.

The public verification record identifies the directly exercised lines, the auto-classification rules, each accepted waiver and the release to which the result applies.

• 46 test benches across 40 scripts and 3 build profiles.
• Three profiles measured separately. The default profile compiles E-Trace away entirely - measuring only that profile would have silently reported code that was never built. Finding that cost us a round and uncovered a second RTL bug, which is exactly why it is worth saying out loud.

• Cross-validated. A second encoder and an independent CPU model produce the same reconstructed PC sequence. Cross-checking independent encoders increases confidence only to the extent that their implementations and dependencies are independent; the verification record identifies shared specifications, shared test data, derived code, common libraries and any common assumptions that could produce correlated errors.
• Lossless, scoped. Every compression had to prove it is byte-neutral when switched off before it was checked in - in the named verification configuration and test set.

Encoder/decoder agreement is not sufficient on its own. Verification also covers protocol-conformance rules, reset and resynchronization behavior, exception and privilege transitions, filtering, overflow or backpressure behavior, parameter boundaries and integration with the processor trace input.

Publicly inspectable RTL, verification assets, licensing information and provenance can simplify an integrator’s review compared with an implementation whose internal design and verification evidence are unavailable. The actual assurance benefit depends on the reviewed release and project use.

Where the IP comes from

Every distributed RTL file was developed by Accemic in Germany and carries Accemic copyright under the repository’s declared licenses. The provenance statement is supported by the repository history, contributor records, dependency inventory and REUSE metadata; the license inventory has exactly four entries. SPDX headers identify the declared licensing of a file; they are not by themselves a complete originality or freedom-to-operate analysis. For programs with origin requirements, the repository records above are the basis of an origin declaration and are available on request.

Verification-only dependencies, reference decoders and derived tools are listed separately from shipped RTL, with origin, license, version and purpose. A verification dependency can affect the strength of the evidence even when it is not delivered in the product.

Developed in part within TRISTAN (CHIPS Joint Undertaking, grant 101095947) and with funding from the German BMBF (16MEE0273 / 16MEE0276).

Under the open license the RTL stays inspectable; proprietary delivery goes through the commercial route.

Seen in public

Albert Schulz presented C-Trace - An Open-Source RISC-V Trace Encoder and its Ecosystem at the ADTC / EDA Workshop in May 2026: the integration path from the Trace Ingress Port and Trace Control Interface to Nexus (IEEE-ISTO 5001) output streams, and the ecosystem around the encoder - decoder and FPGA reference demonstrator, developed within the European TRISTAN project.

Why open

Because a trace ecosystem needs a trace source, and RISC-V does not have enough of them. We make our living further down the chain - capture, reconstruction, analysis. An encoder more people can actually instantiate makes that chain worth more to everyone on it, including us.

The RTL is published under CERN-OHL-S-2.0. A commercial Accemic license is available for integrators whose product cannot meet its reciprocity obligations, and for projects that need a defined commercial delivery and support scope; both cover the same RTL. Build tooling is ISC-licensed and the documentation CC BY 4.0.

What integration takes

Integration requires a compatible processor trace input, clock/reset and configuration strategy, sufficient buffering and downstream bandwidth, defined overflow behavior, a transport path and a decoder that supports the configured protocol subset. The reference design and acceptance test identify each interface.

The repository is public. The integration questions that come up most often are the retirement semantics of your core’s trace port and whether the port is exposed at all. Ask us - we would rather the IP get used than sit there.

Available review artifacts

• release RTL and parameter documentation;
• license and provenance inventory;
• requirements and protocol-compliance matrix;
• verification plan and test inventory;
• coverage and mutation or fault-injection results where available;
• synthesis and timing records for reference configurations;
• known limitations and unresolved issues;
• integration acceptance test.

Vendor-specific message types are Accemic extensions and imply no claim of standard conformance; with the extensions disabled the stream is byte-identical to the standard reference.

Accemic Technologies GmbH is not affiliated with, endorsed by, or certified by RISC-V International. RISC-V is a trademark of RISC-V International. The other marks named on this page are attributed on our trademarks page.

---