Synthetic multi-core SoC benchmarks can skew waveform-dump and viewer metrics; check the variable mix before extrapolating

When building a synthetic RTL design to benchmark waveform tooling (dump overhead, FSDB/VCD size, viewer and reader speed, compression), check what the variables actually are before generalising the numbers. A design made of many small cores, e.g. 16 picorv32 tiles with local RAMs, shared memories and a wide-struct NoC pipeline, ended up with ~82K dumped variables, of which ~75K were memory words. Most other signals toggled almost every cycle on one main clock.

Effects this has on the measurements: - Very high value-change density per cycle: dump size and conversion time scale with changes, not signal count. - One clock domain flatters per-clock-domain timestamp sharing, which 99% of signals joined. - Memory words dominate variable counts, so 'percent of variables stored' numbers mislead. - Without UVM, DPI or multiple clock domains, the constructs a derived-signal evaluator never sees stay untested. - Dump-overhead ratios (e.g. ~20% wall with +all against no dump) were measured between two debug builds. They say nothing about an optimised no-debug build.

Before claiming general results: - Benchmark at least one real open-source design as well, such as CVA6 (application-class RISC-V) or OpenTitan Earl Grey (multi-clock, UVM). - Measure four configurations on the same design: an optimised build with no dump; a debug build with no dump; a debug build dumping one scope; a debug build with full +all. Record wall time, peak memory and dump size.