What a waveform format or reader must keep to be usable for gate-level (SDF) simulation debug

Checklist from reading the VCS W-2024.09 gate-level chapter and comparing it with what waveform tools tend to drop. GLS failures show up in the dump in ways that RTL failures don't: (1) narrow pulses, and the X pulses from +pulse_e, are several changes at the same or nearly the same timestamp, so any 'last value per timestamp' collapse (common in viewer-equivalence benchmarks) erases them; (2) timing violations show up only as X driven by a notifier, so 2-state storage hides them; (3) delays are measured from exact timestamps, so the timescale must travel with the file (ps vs ns); (4) zero-delay GLS and race debugging need the order of changes across signals within a timestamp, not just within each signal; (5) netlists need strengths (tri-states, pull-ups, switch primitives) and escaped flat names. A delay that was never annotated is invisible in any waveform (the arc just has 0 delay), so a debugging agent should also read the annotation report (vcs -diag=sdf:verbose writes sdfAnnotateInfo) and the SDF warnings. Compression caveat: tricks that store changes as indices into a clock-edge list work for RTL, but in GLS changes land at edge+delay. A per-signal offset from the edge (roughly constant per corner) is a candidate encoding, not yet measured. Where it matters in the flow: nightly regressions are zero-delay RTL. Timing GLS is a small subset of tests at each corner near tapeout, plus zero-delay GLS at each netlist drop. So for a tool aimed at regression triage, GLS fidelity is a 'don't break it' requirement, not the headline.