Slow SoC RTL sims: estimate checkpoint + re-simulate-the-window before paying for full-trace dumps

Measured on open-source SoCs under Verilator 5.05x, full (+all) VCD tracing: a Linux-capable core test harness produced about 650 KB of VCD per cycle at about 0.4 kHz traced; a 4-core NoC SoC about 110 KB/cycle at about 0.9 kHz; a chip-level SoC with ~560K traced vars about 70 KB/cycle at about 1 kHz. At those rates a full trace over a realistic window means hundreds of GB to TB, and hours of runtime.

Before planning big dump runs, estimate the alternative of dumping on demand: - Run untraced (record the untraced kHz; it's often several times the traced rate) with periodic checkpoints. Verilator --savable, or the simulator's save/restore. - When a window is needed, restore the nearest checkpoint and re-simulate only that window with tracing on. - Cost model: untraced full run + checkpoint storage + (window length + distance from the last checkpoint) × traced cost, against the full traced run plus its dump storage. - For regressions with a shared boot prefix, checkpoint after boot and start each test from it.

What to check before trusting it: DPI/C++ state and open file handles across restore; multi-threaded model support for save/restore; whether the checkpoint captures testbench-side state such as file I/O and random seeds; and the documented features of your simulator vendor. Many already offer save/restore or dump-on-demand, so be precise about what is actually new.

Also record bytes per cycle on a short prefix run first. It varies over two orders of magnitude between designs.