One of the hardest questions in chip design is knowing when verification is truly finished. Running more tests always feels safer, but projects have tapeout deadlines, and silicon cannot wait forever. Sign-off criteria exist to answer this question objectively — they define a concrete set of gates that must all be cleared before the team declares verification complete and hands the design to the physical implementation flow.
11 min read | Intermediate Level
What You'll Learn
- What the key sign-off gates are and what each one requires
- How coverage targets, bug status, and regression results combine into a sign-off decision
- What waivers are, when they are acceptable, and how they are documented
- Who is responsible for each gate and what the sign-off approval process looks like
Sign-Off is a Multi-Gate Decision
No single metric can declare verification done on its own. A design that passes all regression tests but has only 60% functional coverage has not been adequately tested. A design with 100% coverage but two open Critical bugs is not ready to tape out. Sign-off requires every gate to be cleared simultaneously — or explicitly waived with documented justification.
Gate 1 — Code Coverage
Code coverage is collected automatically by the simulator and tracks which lines, branches, expressions, and signal toggles in the RTL were exercised during simulation. Before sign-off, the team reviews the coverage report and sets a closure target for each metric type.
Typical industry targets sit between 90% and 100%, but the exact threshold is block-dependent. A block implementing a simple counter may be expected to reach 100% branch coverage. A complex SoC interconnect with many rarely-triggered error paths may have a pre-agreed target of 95%, with documented waivers for the remaining 5%.
Not all coverage misses represent bugs waiting to be found. Some are genuinely unreachable code — dead logic left from a previous design revision, or error handlers that can only trigger under physical conditions (voltage drop, radiation) that simulation cannot model. These are waived, not chased.
Waivers
A waiver is a documented decision that a specific coverage miss is acceptable and does not require a new test. Every waiver must include: which coverage point was missed, why it is unreachable or not worth testing, and who approved the decision. Waivers are reviewed by the DV lead and, for critical paths, by the design lead as well. A waiver is not a shortcut — it is a formal acknowledgement of a known gap.
Waivers that are not reviewed and approved are a sign-off risk. If a coverage miss is waived without justification and the same scenario later causes a post-silicon escape, the waiver becomes evidence of a process failure.
Gate 2 — Functional Coverage
Functional coverage is defined by the DV engineer in the verification plan (Vplan) and tracks whether the scenarios that matter to the design specification were actually exercised — not just whether the RTL lines were reached.
The sign-off target for functional coverage is typically 95–100%, with any unmet bins requiring a waiver. The Vplan is the reference: every covergroup and coverpoint defined in the plan must either be closed or have an approved waiver explaining why the scenario is unreachable or out of scope.
Functional coverage closure is often the hardest gate to clear. Late in a project, the remaining open bins tend to be rare corner cases — back-to-back error conditions, maximum-depth FIFO operations under simultaneous read and write pressure, or specific FSM state combinations that constrained random testing rarely hits naturally. These are exactly the scenarios most likely to contain bugs, which is why they are not simply waived without investigation.
Quick Check
Q: Functional coverage is at 97% with three weeks left before sign-off. The three remaining uncovered bins all relate to a reset-during-burst scenario on the AXI interface. The DV lead proposes waiving them because "reset during a burst is unlikely in real usage." Is this a reasonable waiver justification?
Show Answer
No — this is a weak justification. "Unlikely in real usage" is not the same as "unreachable." A reset during an active burst is a legitimate error-recovery scenario that could occur in a real system under power management or fault conditions. If the DUT's behaviour under this scenario is not verified, it is an untested risk. The right action is to write a directed test forcing reset mid-burst, verify the DUT recovers correctly, and close the bins properly rather than waiving them.
Gate 3 — Assertion Pass Rate
Concurrent SVA assertions embedded in the testbench act as always-on checkers throughout simulation. Before sign-off, the requirement is that every assertion passes on every test in the sign-off regression — zero assertion failures allowed.
Assertion failures that appear only under specific seed conditions or in corner-case tests must be investigated and resolved, not ignored. The only legitimate reason to waive an assertion failure is if the assertion itself is found to be incorrectly written — in which case it is fixed, not waived away.
Assertions on critical paths — bus protocol handshakes, FSM state transition legality, FIFO overflow/underflow guards — carry zero-waiver policies at most companies. An assertion failure on a critical path that is waived without RTL investigation is treated as an open bug, not a clean sign-off.
In addition to assert properties, cover properties should also be checked. If a cover property was written to verify that a positive scenario occurs and it never fires across the entire regression, that is a signal the scenario was never exercised — equivalent to a functional coverage miss.
Gate 4 — Zero Open Critical and Blocking Bugs
The bug tracker must show zero open Blocking (S1) or Critical (S2) bugs before sign-off. This is a hard gate — there is no coverage number or waiver process that compensates for a known functional failure in the design.
Major (S3) bugs may be carried past sign-off if a waiver is approved, typically when the bug affects only an extreme corner case with no known real-world impact, a workaround exists that is documented in the datasheet, and both the DV lead and the design lead agree in writing. Minor (S4) bugs are commonly waived at sign-off. The decision is always logged in the bug tracker and reviewed by the project manager.
Carrying an open S2 bug past sign-off by reclassifying it as S3 without genuine justification is a process violation. Severity must reflect functional impact, not schedule pressure. Misclassified bugs are a leading cause of post-silicon escapes.
Gate 5 — Regression Green
The full sign-off regression suite — which includes smoke tests, block-level tests, integration tests, and any seeds that caught real bugs during the project — must pass 100% against the final, frozen RTL commit before sign-off is granted.
This means the regression must be run against the exact RTL version that will be handed to the synthesis flow. Any RTL change made after the regression run — even a one-line comment fix — invalidates the regression result and requires a re-run. This is enforced by tying the regression run to a specific Git commit hash, which is recorded in the sign-off documentation.
Run the sign-off regression at least twice against the final RTL to confirm it is deterministically green. A regression that passes once but fails on a second run with a different global seed indicates an intermittent testbench issue that must be resolved before sign-off.
Gate 6 — Vplan Closure
The verification plan written at the start of the project is the contract between the design and verification teams. Sign-off requires that every feature listed in the Vplan is accounted for — either fully verified with closing coverage evidence, or waived with a written justification.
Vplan closure is reviewed jointly by the DV lead and the design lead. The design lead confirms that the specification has not changed in ways that make previously closed items invalid. The DV lead confirms that the coverage evidence maps correctly to the Vplan features. Any feature that was added to the design after the Vplan was written must be either added to the Vplan and verified, or explicitly noted as out of scope with a justification.
The Sign-Off Approval Process
Once all gates are cleared, the sign-off process itself is a formal review rather than an automatic green light. The typical flow is:
- DV engineer prepares a sign-off report summarising coverage numbers, open bug counts, waiver list, and regression results for their block
- DV lead reviews the report, checks that all waivers are justified, and confirms the regression was run against the correct RTL commit
- Design lead reviews open bug waivers and confirms the Vplan reflects the final specification
- Project manager records the sign-off decision and the RTL commit hash in the project database — this becomes the legal record that verification was completed to the agreed standard
At SoC level, block-level sign-offs feed into an integration sign-off, which in turn feeds into the full-chip sign-off before tapeout. Each level has its own regression suite and coverage targets — block sign-off does not automatically mean the chip is ready to tape out.
Quick Check
Q: A block's sign-off regression is run and passes 100%. The design team then makes a one-line RTL fix to address a minor timing comment. The DV lead says the regression result still counts because "it was only a comment change." Is this correct?
Show Answer
No. Any change to the RTL — including comments, whitespace, or formatting — produces a new Git commit hash. The sign-off regression must be tied to a specific commit, and a new commit means the regression must be re-run. In practice, a comment-only change is extremely low risk, but the process must be followed: re-run regression against the new commit and update the sign-off documentation with the correct hash. Skipping this step means the documented sign-off does not match the actual taped-out RTL.
Common Mistakes
Mistake 1: Signing off on coverage numbers without checking what was waived.
Wrong: Reporting "98% functional coverage — sign-off approved" without reviewing whether the 2% waived bins include any safety-critical scenarios.
Right: Every waiver is reviewed line by line during the sign-off meeting. Coverage percentage alone is meaningless without understanding what is behind the unmet bins.
Why? The 2% that was waived may include the exact scenario that will cause a post-silicon escape. Coverage numbers look clean on a dashboard; the waivers list is where the real risks are hidden.
Mistake 2: Running the sign-off regression against an intermediate RTL commit, not the final one.
Wrong: Submitting sign-off documentation referencing a regression run from three days ago while the RTL has had two more fixes committed since then.
Right: Freeze the RTL first, then run the sign-off regression against the frozen commit, and record that exact commit hash in the sign-off report.
Why? RTL changes introduce regression risk. A regression run against an older commit says nothing about whether the current RTL is clean.
Mistake 3: Treating block sign-off as equivalent to chip sign-off.
Wrong: Assuming that because all blocks have individually signed off, the chip is ready to tape out.
Right: Block sign-off is a prerequisite for integration sign-off, not a replacement for it. Interface bugs, clock domain crossing issues, and multi-block interaction bugs only appear at the integration and system simulation level.
Why? Block-level verification tests each block in isolation. The connections between blocks — address decoding, arbitration, power sequencing — are only exercised at integration level. These are a common source of post-silicon escapes even when all block sign-offs are clean.
Practice Exercise
Challenge: Assess Sign-Off Readiness
A DV engineer presents the following status for a memory controller block at the sign-off review meeting:
- Statement coverage: 100%, branch coverage: 96%, toggle coverage: 91%
- Functional coverage: 93% — seven bins uncovered, all relating to simultaneous read and write under FIFO-full conditions
- Assertion pass rate: 100% across all tests
- Open bugs: 0 S1, 0 S2, 1 S3 (read latency one cycle longer than spec under maximum frequency — workaround documented in datasheet), 2 S4
- Regression: 100% pass on commit
a7f3c91 - Vplan: all features verified except the seven uncovered functional coverage bins
Which gates are clear, which are not, and what needs to happen before sign-off can be granted?
Hint
Go through each gate in order. For the gates that are not clearly met, decide whether a waiver is appropriate or whether more verification work is required.
Sample Answer
Clear gates:
- Code coverage: 96% branch and 91% toggle are reasonable — review the specific misses and waive if genuinely unreachable.
- Assertion pass rate: 100% — clear.
- Open bugs: zero S1/S2. The S3 bug with a documented datasheet workaround is a candidate for a waiver approved by DV lead and design lead. The two S4 bugs are standard waiver candidates.
- Regression: 100% on a specific commit — clear, provided no RTL changes occur after this point.
Gate requiring action:
- Functional coverage at 93% with seven uncovered bins on simultaneous read/write under FIFO-full is not a straightforward waiver. FIFO-full under simultaneous traffic is a realistic stress scenario, not a theoretical edge case. The right action is to write a directed test forcing this condition, verify correct behaviour, and close the bins before sign-off. If after investigation the scenario is genuinely unreachable given the system architecture, a waiver can be approved — but that must be confirmed, not assumed.
- Vplan closure is blocked by the same seven bins — it becomes clear once functional coverage closes.
Summary
In this article, you learned:
- Sign-off requires all gates to be cleared simultaneously: code coverage, functional coverage, assertion pass rate, zero S1/S2 bugs, regression green, and Vplan closure
- Waivers are acceptable only with documented justification reviewed and approved by the DV lead and design lead — they are formal decisions, not shortcuts
- The sign-off regression must be run against the final frozen RTL commit; any subsequent RTL change requires a re-run
- Block sign-off feeds into integration sign-off, which feeds into chip sign-off — each level has its own gates and regression suite
