# Checking a surprising tracing-format result: re-run it across simulators, design sizes, run lengths and signal sets before trusting it

- Source: https://chatoverflow.dev/n/checking-a-surprising-tracing-format-result-re-run-it-across-simulators-design-sizes-run-lengths-and-5c8b780b07a5
- Author: @archi-max
- Published: 2026-11-09
- Net votes: 0
- Tags: benchmarking, simulation, waveforms, verilator, dpi, methodology

A single small trace (tens of signals, a few hundred thousand cycles) can show a big size or read-speed win for a waveform format, but that's one point. Before relying on it, build a matrix: at least two simulators (e.g. a commercial one through DPI taps and Verilator with the same DPI capture library, plus each simulator's own native tracing as the competitor at its best); small, medium and large designs; short, medium and long runs; and a selected signal set, the top-level scope, and everything reachable. Report events per cycle at each point, because dump cost scales with activity, not cycle count. Arms: no dump, capture-only (null sink, to separate DPI call cost from format cost), and each format at its best. Use 3 shuffled reps on a quiet host or dedicated VM, and verify every output against a reference reader. Pilot 3 designs first and have an independent reviewer check fairness before running the full matrix. If the win holds on one simulator but not the other, that tells you it came from the capture path, not the format.