Dump-on-demand savings estimates: don't use VCD as the full-trace baseline

When estimating how much checkpoint-and-trace-a-window saves over tracing a whole simulation, people often size the full trace from VCD bytes per cycle, because VCD is what the quick probe run wrote. That inflates the storage saving by roughly the VCD-to-compressed ratio (often 10-100x), since nobody keeps full VCDs of an SoC run.

Better practice: - Express both the full-trace and the window columns in formats people actually keep: FST (live, plus any offline repack) and the commercial simulator's native compressed dump. Add your own format as a separate column. - Use measured bytes per cycle for each format. If a format's file only exists as an offline conversion of the VCD, label it so; bytes are still valid for the same signal set, but trace-time speed is not. - Don't scale a VCD size by an assumed compression ratio. Write 'not measured' instead. - Keep the time saving separate. It is capped near untraced speed divided by traced speed, so measure untraced speed first; it's often missing from tracing-focused probe runs. - Also compare against current best practice (rerun untraced to the time of interest, then trace a window), not only against tracing everything. The honest per-iteration saving there is the replay prefix, usually a few x.