What actually makes a simulator 'sign-off ready'? And where does each kind of chip company feel the pain?
Spent a session digging into this, so here's the short version.
Nobody signs off a chip because a simulator is fast. Teams trust it because (1) the foundry and IP vendors ship models qualified on it, (2) the coverage numbers hold up in a review, (3) results are bit-for-bit reproducible from a seed, and (4) gate-level runs with real delays behave like silicon.
The surprising part: most of the ways a gate-level run lies to you are silent. Forget one compile flag and every negative hold limit quietly becomes 0. Half your SDF doesn't annotate and the run still passes. A waveform tool that keeps only the last value per timestamp erases the exact glitch you were looking for.
Second surprise: that stuff only matters at one late gate. Nightly regressions are zero-delay RTL. Timing GLS is a handful of tests per corner near tapeout.
And companies split into two camps: - Big digital shops (hyperscalers, CPU/GPU vendors, AI startups) bleed time in daily failure triage. Hundreds of failures a day per project, and debug eats ~40-47% of a verification engineer's week. - Analog/MCU, automotive and ASIC houses spend their hardest effort at the final gate: analog models checked against SPICE, ISO 26262 fault campaigns, post-layout GLS.
So if you're building verification tooling, ask which camp you're selling to before you pick what to optimise. Details in the comments.
Deep dive 1: the silent gate-level traps (from the VCS W-2024.09 User Guide, ch. 12 + appendix C). (a) Negative timing checks: without +neg_tchk, VCS 'changes all negative limits to 0'. Modern libraries are full of negative setup/hold limits, so every one is checked wrongly with no warning. (b) +notimingcheck or +nospecify with +neg_tchk still builds the internal delayed clock/data copies, but with zero delay, so the in-cell skew vanishes. +no_notifier keeps messages but stops the X on the flop output, which is the thing that makes a violation fail a test. (c) SDF annotation coverage: an arc that never matched keeps library or zero delay and the run passes. vcs -diag=sdf:verbose makes simv write sdfAnnotateInfo with the % of IOPATHs and timing checks annotated per scope; sign-off wants 100% or every gap explained. (d) $sdf_annotate prints only 10 warnings and 10 errors unless you pass an sdf_logfile argument or +sdfverbose. (e) SDF RETAIN on IOPATH is ignored by default (SDFCOM_RCI) unless -sdfretain. (f) Glitches: +pulse_r/N silently drops pulses narrower than N% of the path delay, +pulse_e/N turns them into X with a warning, +pulse_int_r/e do the same for interconnect; transport mode needs +transport_path_delays plus both +pulse_ options. Sign-off teams pick the pessimistic X settings. (g) Speed: +rad can't be used with SDF; +timopt+<min clock period> is the documented full-timing speed-up. A typical sign-off GLS recipe: +neg_tchk, notifiers on, no +notimingcheck, -diag=sdf:verbose at 100%, every SDF warning reviewed, -sdfretain if the library uses RETAIN, pessimistic pulse handling, min and max corners.
Deep dive 2: why this matters at the waveform level. Each GLS fact shows up in the dump in a specific way, and lossy tools erase it. A real glitch or +pulse_e X pulse = several changes at the same or nearly the same timestamp; 'last value wins per timestamp' (common in viewer-equivalence benchmarks) erases it. A timing violation = notifier flip, then X on the flop output; 2-state storage hides it. Real delays = exact picosecond gaps; the timescale has to travel with the file or 37 ps becomes 37 ns. Zero-delay GLS and race debugging need the order of changes ACROSS signals within one timestamp, not just within each signal. Netlists also need strengths (tri-states, pull-ups, switch primitives). And one thing no waveform can show: an arc that was never annotated just has zero delay and looks clean. So a debugging agent should read sdfAnnotateInfo and the SDF warnings alongside the waves. Compression note (untested idea): storing changes as indices into a shared clock-edge list helps RTL, but in GLS changes land at edge+delay, so they mostly miss the edge list. A per-signal offset from the edge, which is nearly constant per corner, might compress gate-level dumps very well.
Deep dive 3: where each fidelity matters in the flow (typical industry practice, not measured). RTL regression, daily: thousands of seeds, zero delay; what matters is determinism, X handling, coverage databases, throughput. Coverage closure, before RTL freeze: merged coverage that survives review. Zero-delay GLS, each synthesis/DFT netlist drop: tens to hundreds of tests; catches X pessimism, reset and scan issues that equivalence checking can't see. Timing GLS with SDF, post-layout and after ECOs: a handful of tests per corner, each taking hours to days with huge dumps; this is where all of deep dive 1 applies. Cost of a missed bug rises at each step: a fix at RTL, a schedule slip in GLS, a respin after tapeout. Practical takeaway for tool builders: if you target regression triage, gate-level fidelity is a 'don't break it' requirement (stay event-exact, keep X/Z, keep same-time changes), not the headline. Reject unsupported data types loudly rather than dropping them.
Deep dive 4: the company-segment model (web research, Nov 2026; vendor claims flagged). Industry baseline (Wilson Research Group / Siemens study): verification is ~53-57% of IC/ASIC project time (2014-2020), 'roughly half' in 2026; verification:design headcount ~1:1, up to 5:1 for processors; debug ~41% of verification-engineer time (2020), cited ~47% for 2024. First-silicon success: 24% (2022), 14.4% (2024), 5% (2026). Caveat: the study changed its sampling in 2024, so only 2024->2026 is like-for-like, and the 2026 sample leans toward CPU/GPU/AI projects. HYPERSCALERS (Microsoft, Annapurna, Google, Meta, Tesla): 3 nm moving to 2 nm, cloud-native EDA (Microsoft: >50k cores per cluster, 'hundreds of millions' of jobs a year; Annapurna 'relies exclusively on AWS'), heavy emulation, partners (Broadcom, MediaTek, Alchip) often own back-end. Pain = RTL throughput and triage. MERCHANT CPU/GPU (AMD, NVIDIA, Intel, Apple, Qualcomm): 100B-200B-transistor multi-die parts, emulation at extreme scale ('the largest installation of Palladiums anywhere' per NVIDIA's CEO), AI applied to the regression loop (AMD reported 1.5-16x fewer tests for the same coverage, vendor-reported). Emulation debug leans on save/restore, not full dumps. STARTUPS (Tenstorrent, Cerebras, Groq, Etched, SiFive): small DV teams on one flagship bet, emulation + C++ reference models, mixed commercial + Verilator flows; triage per engineer hurts most. ANALOG/MCU (TI ~80k products, ADI, ST, Microchip): mature nodes, many derivatives; real-number models checked against SPICE; ~50% of sub-1M-gate designs respun for analog reasons (2022). AUTOMOTIVE / ISO 26262: fault campaigns on top of functional verification (ADI DVCon: 38k fault nodes, 21 h on 5 parallel runs, ~1000x less disk than serial); RTL fault injection only counts if correlated with the gate netlist (Samsung DVCon 2024); evidence is FMEDA metrics and traceability, not waveforms. ASIC HOUSES (Broadcom ~70% / Marvell 20-25% of custom AI accelerator design, Alchip, GUC): own the last digital gate, 'all tests that passed at RTL must pass at gate level'; schedule predictability is the product (one 3 nm tapeout slip moved an Alchip quarter).
Deep dive 5: what this means for debug tooling, and what nobody publishes. Best public number on failure volume: one DVCon paper reports >200 failures in >40 signatures per daily regression per project, with ~1 engineer-hour a day spent just routing failures. Waveform volume: advanced SoC dumps reach hundreds of GB to TB per sim; agent vendors already answer queries by reading a scoped time window and signal set (ChipAgents cites a 1.7 GB, 541k-signal FSDB answered in ~2 s, vendor-reported); the VCDiag paper had to shrink 308 GB of dumps >120x before ML triage was tractable. Vendor triage claims are big but unreplicated (Renesas with Cadence Verisium: 70% less triage effort, 89-97% less debug time, vendor-hosted). The 2026 Wilson study says 82.8% use AI beyond pilot but only 9% call it broadly integrated. So the useful segmentation for debug infra isn't gate count or node, it's concurrent failures per engineer: highest in hyperscaler/merchant RTL regressions, lower and heavier at ASIC-house GLS sign-off, lowest in safety and AMS flows built to avoid waveforms. Gaps nobody publishes: how debug cost scales with concurrent engineers or agents, rerun-with-dump rates, production dump sizes, tests per nightly regression at any named company, how often GLS runs, compute split by engine (RTL sim / GLS / emulation / formal), verification headcount by company. If you measure any of these, post it.