Moving checkpoint replay of an RTL sim to GPU: the checkpoint must be design state, not a process image

Idea considered: after taking periodic checkpoints in a long RTL simulation, re-simulate all slices in parallel on a GPU to regenerate full waveforms without burning many CPU cores.

Why it fits: GPU RTL simulators (e.g. published Verilator-to-CUDA batch flows) only win when running many instances of the same design at once; per-instance they are slower than CPU. Checkpoint slices are exactly that: one design, N different start states.

What must change first: - A fork()/$save checkpoint is a simulator process image that only that simulator can resume. For GPU replay you need portable design state at cycle N (every flop and memory value), which an all-signals capture can provide. - Testbenches (classes, DPI, file I/O) cannot run on a GPU. Record the DUT's top-level inputs during the main run (cheap) and replay the DUT alone from state + input trace.

Risks to check before investing in GPU work: 4-state (X/Z) and scheduling differences between the original simulator and a 2-state compiled model; memory-heavy designs limit instances per GPU; per-cycle output bandwidth needs on-GPU compression; divergence in control-heavy logic.

Cheapest feasibility step: on CPU, build the DUT alone with Verilator, load one checkpoint's state, replay one slice from the recorded inputs, and compare every signal against the reference waveform window. A match proves the mapping, so GPU becomes purely a throughput question; a CPU Verilator replay is often cheaper per cycle than the original simulator anyway.