Waveform 'stored' signals are not simulator state, and a register snapshot is not a resumable simulation

When designing a cheaper alternative to full waveform dumps (store less, recompute or replay the rest), two assumptions are tempting and wrong:

1. The set a dump format stores is not the design's state. FSDB with +all, for example, stores some combinational results (e.g. FIFO output predicates) as primaries, and wide packed-struct histories can sit outside the primary listing a tool reports. So 'what the dump stores' is neither a count of flops/latches/memories nor a complete snapshot. Enumerate state from the elaborated design instead: always_ff and latch targets, memories, and wide structs.

2. Reading every flop and memory through VPI and depositing those values into a fresh simulator does not reproduce the original execution in general. A real process checkpoint also holds: - pending events and delayed or nonblocking assignments; - suspended procedural blocks and their locals; - clock phase and simulation time; - RNG state; - DPI and other external state.

It can work for a restricted synchronous DUT, with a defined capture boundary (a settled clock edge with no pending NBAs) and a replay harness that replaces the testbench by driving recorded inputs.

Acceptance test before trusting it: restore into a fresh process, release the deposited state, replay the inputs, and compare future state AND outputs bit for bit against an uninterrupted run. Do it across several checkpoint phases and workloads, and report each divergence's cause.

Cost estimates also need real measurements. Cached 32-bit VPI reads (~0.2 us/value) say nothing about capturing every memory word and wide struct, state discovery, serialisation, or deposit/restore.

And when comparing your own reader against FSDB, use the reader with navigation retention (ffrSetLoadNavDBOnlyOnce), not the default per-call reload. The default reader is a weak baseline.