A VCD records every transition — and keeps every one. Value Change Dump and its extended form are the currency of power analysis and activity-driven signoff, but a full-chip dump can reach hundreds of gigabytes. What you dump, when, and in which format decides whether the power numbers arrive on time.
| Format | What it captures | Where it is used |
|---|---|---|
| VCD (IEEE 1364) | Value changes, ASCII | RTL and gate debug, toggle activity |
| eVCD | + port direction and drive strength | Bidirectional ports, ATE and test vectors |
| FSDB / binary dumps | Compressed value changes | Large gate sims — faster, smaller |
| SAIF | Toggle counts and static probability | Averaged RTL and gate power estimation |
| TCF / vendor activity | Tool-native activity | Direct import into power tools |
| UPF-aware SAIF | Activity with power intent | Multi-voltage and power-gated analysis |
A VCD is the simplest possible record of a simulation: every time any watched signal changes, the value and the timestamp are written out as text. That simplicity is also its cost. A full-chip, full-run VCD reaches tens to hundreds of gigabytes, the simulation itself slows by a large factor while the dump is open, and most of what is captured is never read. The discipline is to dump only the scope and the time window that carry the activity you actually need.
Scope and window are the two controls that matter. Dumping is limited to the blocks of interest — with the hierarchy level and instance passed to $dumpvars — and to a representative interval, opened and closed with $dumpon and $dumpoff around the traffic that represents real operation. A steady-state window a few thousand cycles long usually characterises power far better, and far more cheaply, than a whole regression run captured indiscriminately.
Gate-level activity has one extra requirement: it is only meaningful when the netlist is back-annotated with SDF, so that delays and the glitches they produce are represented. RTL power estimation can work from averaged, statistical activity — which is what SAIF is for — while gate-level power for signoff wants the real value changes, timed, so peak power and vector-specific behaviour are visible. Choosing the averaged path or the vector path is the first decision, because it decides everything downstream.
$dumpvars.$dumpon around a representative interval and close it with $dumpoff; a steady-state window beats a whole run.When port direction and drive strength matter — bidirectional buses, tri-state resolution, and test or ATE vector work. For ordinary toggle activity and power estimation on unidirectional logic, plain VCD — or better, a compressed binary dump converted to SAIF — is enough.
The activity is read into a power tool, directly or after conversion to SAIF (averaged) or a vendor activity format. RTL power uses statistical, averaged activity; gate-level power uses the value-change dump with SDF back-annotation for glitch-accurate, vector-based numbers.
Scope and window the dump — record only the blocks and the interval that carry the activity you care about — prefer a compressed binary format and convert, and use SAIF where an averaged number will do. A full-chip, full-run VCD is rarely the right artifact.
Written for engineers. Share it with one.
Tell us the specification, the constraint and the deadline. Programmes that cross silicon, radio, embedded and AI are where Faststream is strongest.