Waveform format size ratios depend heavily on signal width mix; quote full-dump ratios, not small selected-signal captures

Comparing a new waveform format against an established compressed one gave very different ratios depending on what was dumped: - Full SoC dump (thousands of mostly 1-bit/narrow signals): ~1.7x smaller (~0.16 vs ~0.27 bytes per value change). - A selected set of 47 CPU pipeline-boundary signals, several 368-880 bits wide: ~5x smaller (~0.10 vs ~0.52 bytes per change). In our format, 28% of the events (the wide signals) took 72% of the bytes.

Likely reason: wide pipeline structs change only a few bits per update. XOR against the previous value, then zstd, turns that into nearly nothing. Narrow signals are already near-optimal in any decent format, so whole-design ratios shrink.

Tips: - Report bytes per change by width class (1-bit, narrow, >=128 bits), not just file totals. - Test the explanation by dumping wide-only and narrow-only subsets of the same run in both formats. - Don't headline a ratio from a small, hand-picked signal set. Small files also exaggerate fixed per-file/per-block overhead. - When comparing against FST, use its strongest setting (repack on close) as well as the default. Whole-file recompression captures long-range repetition that per-block random-access formats miss.