Verification In Chip Design Flow

The ASIC design flow takes a chip from a written specification to a physical die ready for fabrication. If you are not familiar with the overall flow, read ASIC Design Flow first — this article assumes you know the stages and focuses exclusively on where verification fits in, what each verification activity does at each stage, and how design and verification teams hand off work to each other.

10 min read | Beginner Level

What You'll Learn

• Which verification activity runs at each stage of the ASIC flow
• Why verification planning starts at specification, not at RTL
• What gate-level simulation actually verifies — and why timing is STA's job, not GLS's
• What feature freeze, code freeze, and design freeze mean for the verification team

Verification Across the Design Flow

Verification is not a single activity that happens after the design is written — it runs in parallel with every stage of chip development. The diagram below shows the standard ASIC stages on the left and the corresponding verification activity on the right. The shaded lower rows indicate back-end stages where functional verification's role is limited.

Verification Planning — Starts at Specification

The verification team's first job is not to write a testbench — it is to read the design specification and produce a verification plan (Vplan). The Vplan maps every specified feature to a set of test scenarios, coverage goals, and sign-off criteria before a single line of RTL is written.

Starting verification planning this early serves two purposes. First, it forces the verification engineer to read the spec closely enough to find ambiguities and underspecified corner cases — at the point where fixing them costs nothing. A misunderstood interface protocol caught in the Vplan review is a comment in a document; the same misunderstanding caught after tapeout is a re-spin. Second, it gives the DV team a running start: when the first RTL blocks arrive, the testbench architecture and coverage model are already designed.

In practice, the Vplan is a living document. It is written against the initial spec and updated as the design evolves. Features added late, or interface changes after RTL coding has begun, require Vplan updates — which is one reason feature freeze is such an important milestone.

RTL Coding — The Heaviest Verification Phase

Once RTL coding begins, three verification activities run in parallel — none of them wait for the others:

• RTL simulation is the dominant activity. Blocks are handed to the verification team as they are completed, and simulation begins immediately at block level. As blocks pass block-level sign-off they move to subsystem-level simulation, and eventually to full SoC simulation. Constrained random testbenches run on compute farms overnight; coverage reports are reviewed weekly; bugs are filed and re-verified as RTL fixes arrive. This continues until all coverage targets are met and the regression suite is clean.
• Formal verification runs in parallel on focused blocks where exhaustive proof is valuable: arbiters, reset logic, protocol checkers, FIFO boundary behavior. Formal often finds bugs that simulation would take millions of random seeds to reach, and it does so early — during block-level verification when fixes are cheap.
• Emulation and FPGA prototyping come online as the full SoC design matures. RTL simulation is too slow to run a complete software stack; an emulation platform runs the same RTL thousands of times faster, allowing software teams to develop and debug device drivers months before silicon exists.

Synthesis — Verification Continues in Parallel

Synthesis converts the signed-off RTL into a gate-level netlist using standard cells from the target technology library, and runs in parallel with ongoing DV activity — it is not a hard stop for the verification team. RTL simulation, coverage closure, and formal verification continue during synthesis; the two tracks proceed simultaneously.

Any functional bugs found by the DV team after synthesis has begun present a new challenge: fixing the RTL and re-synthesizing is expensive because it restarts the implementation flow. Instead, late-found bugs are assessed for whether they can be fixed directly as a netlist ECO — spare cells wired up or logic restructured at the gate level — without touching RTL. If the bug requires an RTL change that cannot be ECO'd cleanly, a resynthesis is unavoidable.

Functional equivalence checking (LEC — Logic Equivalence Checking) is also run after synthesis to formally prove the netlist is logically equivalent to the RTL, catching any functional change the synthesis tool may have introduced. This is typically owned by the implementation team rather than the functional DV team.

Place and Route — Gate-Level Simulation

After place and route, parasitic extraction produces an SDF (Standard Delay Format) file containing wire and gate delays derived from the actual physical layout. Static Timing Analysis (STA) uses this data to exhaustively verify that every path in the design meets setup and hold requirements — STA is the authoritative tool for timing signoff, not simulation.

Gate-level simulation (GLS) serves a different purpose: it confirms that the post-P&R netlist is functionally correct. The SDF file is back-annotated into the simulation not to prove timing — STA already does that — but to expose functional issues that only appear when real delays are present:

• X-propagation — uninitialized or metastable signals that RTL simulation masks with optimistic assumptions can corrupt downstream logic when real gate delays are included
• Clock gating and reset glitches — narrow pulses or glitches that zero-delay RTL simulation ignores may latch incorrectly when gate delays are applied
• Functional divergence from RTL — synthesis and P&R optimizations can occasionally alter logic behavior in subtle ways; re-running key regression tests on the netlist catches any such divergence

GLS runs only a targeted subset of the full regression because gate-level simulation is significantly slower than RTL simulation. Selected tests prioritize reset sequences, clock gating paths, and any scenarios known to be sensitive to real-delay behavior.

One important case where GLS is essential: after an ECO (Engineering Change Order). Late-stage bugs or timing fixes are patched directly in the netlist — spare cells are wired up or metal layers are rerouted — without touching the RTL, because re-synthesizing from RTL would undo all the P&R work. At this point the RTL and netlist have diverged: the RTL no longer describes the actual implementation. GLS on the ECO'd netlist is the only way to confirm the patch behaves correctly, since the RTL cannot be simulated to verify it.

Place and Route — Back-End Takes Over

Place and route converts the netlist into a physical layout, and the primary activities shift from functional verification to physical and timing verification: DRC (Design Rule Check), LVS (Layout vs Schematic), and final static timing analysis with extracted parasitics. These are back-end activities owned by the physical design team, not the functional DV team.

The functional DV team's role at this stage is largely complete. If a functional bug is discovered during physical signoff — rare, but it happens — an Engineering Change Order (ECO) is raised, the RTL patch is applied, the affected blocks go back through GLS, and the physical implementation is updated.

Tapeout — Final Sign-Off Regression

Before the GDSII file is released to the foundry, the verification team runs a final sign-off regression: the complete regression suite against the exact RTL snapshot being taped out. Every test must pass. Any failure, however minor it appears, must be resolved — either by fixing the RTL or by filing a formal waiver with documented justification.

The sign-off regression is also the verification team's confirmation that the RTL snapshot is correct and matches the design intent. A tapeout performed against an accidentally incorrect RTL snapshot — wrong revision, uncommitted fix, wrong parameter — is one of the most costly mistakes possible. The final regression run is the last line of defense.

Key Handoff Milestones

Three formal milestones coordinate the transition between phases and protect downstream teams from upstream changes: