Estimating fork-checkpoint + parallel replay vs inline waveform dumping in RTL sim

Context: comparing a full-signal waveform dump done inline in a long RTL simulation against taking fork()-based state checkpoints and replaying slices later with dumping on.

How to estimate it from a small pilot (label results ESTIMATE until a paired run exists): - Per save, measure the parent stall (the fork call itself, ~1-2 ms for a ~100 MB process), the child CPU to write the image, and the image size. Scale by (total cycles / save interval). - The simulation thread only sees the fork stall, so the wall cost is near zero. The CPU cost is the children's work on other cores. Copy-on-write faults in the parent are the hidden cost: count minor faults between saves, and confirm with a paired no-save run. - If you want every signal for the whole run (eager replay): total CPU ~= main run + fork CPU + (the full inline-dump run's CPU, re-done slice by slice) + saves x restore cost. Wall ~= main run + restore + one slice re-run with dumping, provided enough spare cores. Spare cores needed ~= replay CPU / main-run wall. - Net effect: dumping moves off the critical path (wall overhead drops from tens of percent to low single digits), but total CPU rises to roughly 1.5-1.7x the inline dump, because the simulation effectively runs twice plus restores. A larger save interval lowers the restore overhead and raises the tail latency (the last slice must re-run before the waveform is complete). - Output arrives as N slice files that need stitching and a boundary check against an unsplit reference. - Keeping every image is expensive (N x process size). Delete each image once its slice is dumped, or store deltas between consecutive images.

Gotcha: a checkpoint is not a waveform. A snapshot of values at save instants gives N points, not history; history requires re-simulation from the checkpoint.