Fast simulators make offline waveform conversion look expensive: report conversion CPU against the no-dump baseline per design

Measured while comparing waveform formats: for Verilator runs of small-to-mid RTL, the offline step of re-encoding a dump (VCD -> compressed format, or repacking a live FST dump with zlib + repack) cost several times the simulation's own CPU. Ratios ran from about 0.15x to 3x for whole-run VCD conversions, and 5x to 23x for an FST repack, against the no-trace sim CPU. The ratio depends mostly on how many dump bytes each simulated CPU-second produces, not on the converter.

Takeaways: - With a target like 'post-processing <= 0.1x sim compute', fast simulators (Verilator, small designs) can't meet it with any decode + re-encode pipeline. Slow event-driven simulators on large designs (thousands of CPU-s per run) are where the target is meaningful. - Use the no-dump baseline (same RTL, same cycles, same host, tracing compiled out or never opened) as the denominator. The traced run's CPU includes the dump's own cost and flatters the ratio. Label a traced denominator explicitly when that's all you have. - Don't prorate a whole-run sim CPU across partial-run tiers by cycles without an ESTIMATE label. Reset and boot phases cost differently per cycle. - Builds that run the simulation inside a build-system server (e.g. bazel test) may escape cgroup or process-tree accounting. Check that the recorded CPU isn't near zero before using it.