Live trace processing
What happens between the trace port and the evidence: live decoding, control-flow reconstruction and processing, at line rate.
In brief
A trace processor decodes and analyzes the trace stream while it arrives, instead of recording it for later. Control-flow reconstruction and coverage counting run in FPGA fabric, at line rate within the verified sustained-processing envelope of the named configuration, while the target keeps running - which is why the observation duration is not limited by the capacity of a raw-trace capture buffer.
From the trace port into the box
The trace stream from the target arrives over Aurora, PCIe® or a parallel port. Inside the CEDARbox, a Zynq™ UltraScale+™ MPSoC reconstructs the control flow and maintains the coverage counters - in the FPGA fabric, at line rate.
Processor, not streamer
That is the difference between a trace processor and a trace streamer. A streamer’s capture buffer sets a hard limit on how long you can observe. A trace processor works continuously, so the observation duration is not limited by the capacity of a raw-trace capture buffer. Sustained operation depends on the verified input rate, selected analysis, trace continuity, counter capacity and configured retention policy.
The architecture is patented
The processing architecture behind this decomposes the trace stream into independently resolvable units, processes them in parallel and consolidates the results back into execution order.
Certain aspects of the trace-data-processing architecture are covered by granted patents. The precise scope of protection is determined by the applicable claims, read with the description and drawings, and by the law of the relevant jurisdiction.
The patents, with claims and grant status · Talk to us about licensing options
From expert trace to development feedback
The objective is not another proprietary trace view.
Live processing turns execution into structured, machine-readable evidence while the target keeps running. That evidence can feed downstream coverage, timing and assurance tools - and it can feed the next automated development iteration.
Traditional trace remains invaluable for expert diagnosis. But when software can be generated and changed at machine speed, a workflow that requires a human to navigate every trace becomes a latency bottleneck.
CEDARtools® moves that interpretation step into the processing chain: execution is reconstructed continuously and transformed into explicit metrics, validity state and open gaps that software can consume directly.
Trace becomes an observation API for the development loop.
See the integration model · Explore CEDARtools.Forge
What runs where
Acquisition, protocol handling, reconstruction and metric aggregation are partitioned between FPGA logic and host software according to the configured application. The product documentation identifies which stages execute in hardware for each supported mode.
Related: the hardware