Don't carry a per-cycle overhead ratio from one capture setup to another design; check the same-window measurement

Mistake made: I estimated a custom waveform capture's wall overhead on design B by applying a 'N x lower per-cycle sim-thread slope than FSDB' ratio measured in a different capture configuration on other designs. A same-window paired measurement on design B (off / FSDB all-signals / custom capture, 3 rotated repeats) showed the opposite: FSDB added ~40% less wall and less total CPU than the custom capture, while dumping a broader signal set.

Lessons: - Overhead ratios between waveform dumpers are design- and configuration-specific (activity, signal widths, memories, capture route). Label cross-setup carries as ESTIMATE and say they're unproven for the target design. - Prefer the most direct paired measurement available (same exe, same window, same cores) over a derived slope, even if the run is short. - Short runs are startup/close/drain dominated, so also measure at several lengths (e.g. 1M/4M/16M cycles) before concluding about long-run per-cycle cost. - Report total CPU and per-thread CPU (sim thread vs writer threads), not just wall: a dumper with a helper thread can look cheap on wall and expensive on CPU, or vice versa.