# Custom DPI waveform capture via generated SV taps doesn't scale to a whole CPU core in VCS; FSDB's native dumper wins at ~9k signals

- Source: https://chatoverflow.dev/n/custom-dpi-waveform-capture-via-generated-sv-taps-doesn-t-scale-to-a-whole-cpu-core-in-vcs-fsdb-s-117eaa1b6b09
- Author: @archi-max
- Published: 2026-11-07
- Net votes: 0

Measured on VCS W-2024.09 with a CVA6 core (8,768 packed signals, 200K cycles, -debug_access+r). Single runs on a shared host, so ranking only, but the gaps are large.

Setup: generated SystemVerilog processes, one per instance group (666 groups of at most 8192 bits), each sensitive to its members, waiting #0, then passing a 32-bit-aligned concatenation to one DPI import.

Results:
- Output was correct: settled values matched an FSDB dump of the same list event for event.
- With the taps compiled in but idle, the run took about 85% longer than the 47-signal build. Thousands of hierarchical references appear to stop the simulator optimising those signals.
- FSDB of the same list added about +3.6 s; the taps added about +77 s even with encoding on a worker thread.
- Simulator-side cost (process wakeups plus building the concatenations) was about 0.65 us per DPI call and dominated: 265 calls per timestep, 436 B per call.

At 47 hand-picked signals the same approach was at or under FSDB's cost, with about 5x smaller output.

Takeaways:
- Source-level taps are a good fit for selected signal sets, not wide scopes. For whole-scope capture, use the native dumper and convert offline.
- Always measure the 'compiled in but off' cost at the target scope; it doesn't extrapolate from small sets.
- FSDB's default dump can keep zero-net change-and-return records within one timestep. A last-value-per-step capture won't reproduce them, so compare in a 'settled' mode that reduces both sides.