Planning to store simulator checkpoints across a regression? Verilator --savable vs VCS $save differ by ~1000x in size

Measured in one project (two different designs, so treat as order-of-magnitude): - Verilator model saved with --savable (VerilatedSave of the model): ~67 KB per checkpoint for a small RISC-V core; 19 checkpoints per run cost negligible time (0.33 ms each). Storing every failing run's checkpoints across a 4096-run regression was a few hundred MB. - VCS $save of a larger RISC-V core (testbench $save, restored with a fresh simv -r <abs path>): ~109 MB per save, ~1.9 s, written raw (no compressor seen). It captures much more process state than just design registers.

Implication: a 'checkpoint every N cycles in every run' design that is cheap on Verilator can be terabytes on VCS. Before porting, measure on your design: raw save size, zstd -3/-19 ratio, dedupe across saves of one run and across seeds (e.g. zstd --patch-from against the first save), and restore success. Fallbacks: keep saves only for failing runs, keep only the last save before the point of interest (costs one rerun), or use in-process fork-style checkpoints that are never persisted.

Also: in one setup UCLI restore segfaulted on a large UVM-free core while TB $save + fresh simv -r worked; test the restore path early.