The conversation about tape-out respins usually starts with cost figures that are technically accurate but strategically misleading. Yes, a mask set at 5nm can run $15-30M. Yes, NRE at advanced nodes is expensive. But for the early-stage ASIC teams we talk to most often — teams building their first or second custom silicon, targeting 16nm or 28nm process nodes — the respin economics are different, and the decision about where to invest in verification should be different too.
A respin at 28nm costs roughly $300K-800K in mask NRE plus the schedule delay. For a team on a 12-month chip development cycle, a 3-month respin delay is a schedule impact that often exceeds the direct NRE cost in terms of competitive and fundraising consequences. The goal isn't to eliminate all risk of a respin — some bugs will always escape to silicon — it's to eliminate the classes of bugs that are cheapest to catch in pre-silicon verification and most expensive to find post-silicon.
Which Violation Classes Actually Cause Respins
The EDA research community has published post-mortem analyses of silicon bug distributions across a number of projects, and the pattern is consistent enough to be useful for planning purposes. Functional bugs caught in simulation make up the largest volume of pre-silicon issues, but they're also the ones that simulation-based verification methodologies are designed to catch. The classes that slip through to silicon — and therefore cause respins — skew heavily toward structural categories:
CDC (clock domain crossing) hazards account for a disproportionately large share of post-silicon bugs relative to their pre-silicon detection rate. Published post-mortem surveys from DAC and ICCAD proceedings consistently show CDC bugs in the top three causes of respins across multiple process generations. The reason: functional simulation doesn't reliably trigger metastability; formal CDC analysis requires complete design context; and the interaction between asynchronous domain boundaries and system-level timing is genuinely hard to exercise in testbench scenarios.
Reset strategy violations — specifically, resets that are asynchronous in some paths and synchronous in others, or reset trees with fan-out that creates unbalanced deassertion timing — show up in roughly 15-20% of reported silicon bugs in digital design post-mortems. These are almost always detectable in static analysis at RTL; they're underrepresented in simulation coverage because reset scenarios are often not fully exercised in the test suite.
Timing closure assumptions in RTL — combinational cones that are deeper than the clock period allows, multi-cycle paths without corresponding constraints — force either architecture changes in the backend (which introduces functional risk) or timing violations that get signed off at the wrong operating point. The result shows up as silicon that passes characterization but fails in the field under corner conditions.
X-propagation bugs — uninitialized state elements, X-pessimism in gate-level simulation masking real unknowns, reset sequences that leave state machines in X — are a perennial source of post-silicon functional failures that look like intermittent bugs in the field. X-propagation from RTL simulation is inherently optimistic; the gate-level behavior is pessimistic; and neither extreme tells you what the actual silicon will do.
Where Static Analysis Fits in the Cost-Benefit Equation
The standard argument for static analysis is "catch bugs earlier, when they're cheaper to fix." This is true but vague. The more useful framing is: which violation classes can static analysis reliably catch, and what's the cost-of-catch comparison against the next available verification method?
For CDC hazards, the comparison is static CDC analysis vs. functional simulation. A complete CDC analysis at RTL will identify every asynchronous domain crossing in the design, check for synchronizer presence, verify synchronizer topology correctness, and flag reconvergence paths. This takes minutes. A functional simulation that exercises enough scenarios to expose a CDC metastability hazard — if it can be constructed at all — takes days of simulation runtime and testbench development, and may still miss the hazard if the timing overlap doesn't occur in the simulated scenarios.
For reset strategy violations, the comparison is static analysis vs. formal verification. Formal reset verification is more complete, but requires a formal environment setup that most teams only build for sign-off, not for weekly checks. Static analysis catches the structural violations — unbalanced reset trees, mixed asynchronous/synchronous resets in the same flip-flop domain, missing reset coverage on state elements — in a fraction of the formal setup time, at the cost of not proving the full reset behavior.
For X-propagation, static analysis is complementary to simulation, not a replacement. Static analysis can identify which state elements lack reset coverage and which always-blocks have ambiguous initialization behavior. Simulation-based X-propagation checks (VCS's xprop mode, Questa's X-propagation pessimism) can then be targeted at the high-risk areas that static analysis identified.
The Verification Investment Prioritization Framework
Given the violation class distribution and the relative costs of different verification methods, here's how we think about where to invest pre-silicon verification effort for an ASIC team at an early stage:
High ROI — static analysis at every checkin: RTL lint for structural violations, CDC analysis for domain crossing topology, reset tree analysis for deassertion consistency. Combined runtime under 15 minutes for a mid-size block. Catches the violation classes with the worst detection rate in simulation and the highest cost if they reach silicon. Cost-per-bug-caught is low because the analysis is fast and the bugs it catches are expensive to fix later.
Medium ROI — targeted formal verification for safety-critical blocks: Not full-chip formal sign-off (which is prohibitive without a dedicated formal team), but block-level formal checks on the highest-risk state machines, arbiters, and protocol controllers. A 2-4 week formal effort on the 5-10 blocks that carry the most functional risk is a better investment than running formal on everything.
Standard ROI — simulation for functional coverage: This is necessary and non-negotiable, but it's also the area most teams already invest heavily in. The marginal return on adding more simulation hours, beyond standard UVM testbench coverage closure, is lower than the return on adding the static analysis layer for teams that don't already have it.
A Note on What Static Analysis Can't Prevent
We're not saying that running static analysis eliminates respin risk. It doesn't. A significant fraction of post-silicon bugs are system-level integration issues, power delivery problems, yield sensitivity to process corners, or protocol compliance failures that require actual silicon behavior to reproduce. None of these are addressable by RTL static analysis.
The goal of the static analysis layer is to eliminate the set of respin causes that are: (a) detectable from the RTL before synthesis, and (b) structurally difficult to catch in simulation. That set is real and significant. Taking it off the table doesn't guarantee a first-pass silicon success, but it meaningfully narrows the tail of respin causes to the ones that are genuinely hard to avoid.
Building the Business Case Internally
For verification leads trying to justify tooling investment to a management chain that's skeptical of pre-silicon spend, the most effective framing we've seen is a specific one: name a violation class that caused a problem in a previous project, identify what it would have taken to catch it earlier, and compute the schedule impact of the late catch versus the cost of the tool that would have caught it earlier.
A CDC bug that caused a one-month respin delay at $200K/month of team time has a clear cost. If a static CDC analysis tool costs $X/year and would have flagged that crossing in the first week of RTL development, the ROI calculation is straightforward. The challenge is that teams tend to remember the bugs that escaped to silicon but not the bugs that static analysis caught silently three years ago. Building a record of "violations caught by static analysis before they became simulation bugs" is worth doing, because that record is the only empirical evidence available for the next tooling decision.
That's why we log every violation catch with its rule class and the stage at which it was found — so teams can look back at their Fpgawright history and answer the question: "what would we have paid if these had been caught at gate-level STA instead of at RTL checkin?"