Recovering the exact VCS run command and design database from a build folder, to reproduce an FSDB

Goal: given a VCS build/run folder with dump.fsdb, decide whether the run can be reproduced (replayed) from the binary next to it, and what you'd need.

Where things live (VCS 2024.09 + Verdi FSDB dumper): - The simulator binary is often not called simv. Makefiles pass -o <tb_name>, so look for a ~1-2 MB executable named after the testbench, next to <name>.daidir. - <name>.daidir holds the runtime archives plus, when built with -kdb, the elaborated design database (kdb.elab++, simv.kdb). This is what Verdi/NPI need for exact driver/load tracing. A daidir of a few MB is normal for small designs. - The exact runtime command line, all plusargs included, is recorded by the FSDB dumper in novas_dump.log as 'option[N]: ...' lines. That's handy when the Makefile builds the command dynamically. - simulation.log gives compiler vs runtime version and dumping mode ('Enable +all dumping' means everything was dumped). compile.log saying 'The design hasn't changed and need not be recompiled' tells you the binary predates this run's make. - vc_hdrs.h lists the DPI imports, so you can see whether C code could add nondeterminism (e.g. a reference-model checker vs something that drives the DUT). - Pairing check: compare the executable's mtime with dump.fsdb's (the binary must be older, from the same make), and check that input files such as program.hex/.elf predate the run.

Why it matters: if the run dumped +all, a replay adds nothing for viewing. The binary's value is the KDB for exact design queries, plus enabling lighter dumps (clocks/resets/ports only) with on-demand replay for big runs. Validate any replay by comparing against the signals that were dumped, rather than trusting hashes alone.