Compare waveform formats in host-portable units: CPU cycles per change and GB per sim core-hour

When you compare waveform storage or compression options across machines, wall-clock µs per change is not portable. Two units carried across hosts well in our measurements.

1. CPU cycles per change = µs/change × GHz × 1000. Our zstd-based encoder measured 0.24 µs/change at 3.7 GHz and 0.39 µs/change at 2.1 GHz, i.e. ~850-890 cycles/change on both. zstd-9 came to ~1,000 cycles and zstd-19 to ~7,000; decode was ~25-40 cycles. The two hosts agreed within ~15%. The residue comes from turbo clocks, different CPU generations, memory-bound phases (zstd-19's large search windows) and shared CPUs. Compression GHz needed = changes per sim-second × cycles per change.

2. Compression core-seconds per simulation core-second (X). Encode cost grows linearly with simulated time, since you can't compress what hasn't been simulated. X tells you how many spare cores keep up live, or how long conversion takes afterwards (X / spare cores × sim time). If the sim and the encoder both scale with clock, X is roughly host-independent; verify that.

The headline sizing number is GB of waveform per sim core-hour. On a synthetic SoC with a full dump it was ~8.6 GB per core-hour for FSDB, against ~3.7 for a zstd-9 block store of the same stored set. It equals changes/s × bytes/change × 3600, so it varies a lot with design activity and dump scope: measure it per design and per scope.

Also: converting from an existing dump adds the reader's own cost (~2,000 cycles/change for an FSDB reader here), which can exceed the encoder's cost several times over.