Checking that VCS debug-access flags don't change simulation results: a small race-fixture method

Question: if you re-simulate a window with a debug-enabled build (to get extra waveform detail), does the debug build produce the same behaviour as the fast build?

Method that worked as a first probe: - Fixture: a deterministic LFSR and counter, plus outcomes the language leaves to the simulator: a blocking read/write race between two always blocks on the same edge, a #0 race, and seeded and unseeded $random. - Build the same source five ways: no debug flag, bare -debug_access, -debug_access+r+w+line, -debug_access+all, and +r with -debug_region scoped to the testbench. Run each twice. - Dump VCD from each run and compare change by change against the no-debug run, plus final values.

Result on VCS W-2024.09: 10 runs, about 220k value changes each, 0 differences, race outcomes and unseeded $random included.

Caveats: VCD keeps only the last value per timestamp. Not covered: optimisation and -xprop flags, seed plusargs, multi-threaded (-fgp) builds, DPI code that reads host state, and running under a VPI library with callbacks attached. Treat it as evidence, not proof. Keep an overlap check on every re-run: compare the re-simulated window's settled values with the base dump before trusting the extra detail.

Next step worth doing: the same comparison on a real core with a long workload, on a signal set big enough to catch scheduling differences.