DRC and LVS Flow Sequencing

Why DRC and LVS Need a Deliberate Order

Design rule checking and layout versus schematic checking answer different questions. DRC evaluates whether layout geometry satisfies the manufacturing rules represented by a qualified deck. LVS extracts devices and connectivity from that layout, then compares the extracted representation with an approved source netlist. Neither result substitutes for the other, and waiting until the final database is assembled to run both creates avoidable schedule risk.

A useful sequence follows design maturity. Early checks should be fast, local, and sensitive to the errors most likely to be introduced at that stage. Later checks should expand hierarchy, rule coverage, and input control until the final runs use the complete signoff configuration. This approach does not weaken signoff. It moves defect discovery closer to defect creation while preserving authoritative full-chip checks at the end.

Sequencing also improves diagnosis. If geometry is broadly clean before a full LVS comparison, extraction noise and accidental opens are less likely to obscure structural mismatches. If connectivity is checked after meaningful layout changes, a geometrically legal repair cannot silently alter the intended circuit. The objective is therefore a repeated loop rather than one permanent choice between DRC first and LVS first.

Start with Local and Incremental DRC

During block construction, targeted DRC gives immediate feedback on routing, via, enclosure, width, spacing, and boundary interactions. Runs can be limited to changed regions or selected rule groups when the verification methodology supports those modes. The reduced scope shortens feedback without claiming that the block is signoff clean. Designers can correct systematic problems before they are replicated across hierarchy.

Incremental checks are especially valuable after floorplan adjustments, power-grid edits, pin movement, route optimization, or manual layout repair. Each operation can introduce a distinct class of geometric issue. Recording the run scope and deck mode prevents a partial result from being mistaken for a complete result. A clean window or rule subset is evidence about that scope only.

At hierarchy boundaries, teams should also inspect interactions that a cell-only run cannot see. Abutment, top-level routing, fill, seal structures, and neighboring voltage domains may create new conditions after integration. The sequence should therefore progress from local DRC to assembled-block DRC and eventually to full-chip DRC. Early locality accelerates correction, while expanding scope protects against interface defects.

Bring Up LVS When Inputs Become Comparable

LVS becomes productive when the layout can be extracted and the source representation has a defined comparison point. The source may be a schematic-derived or implementation-derived netlist according to the project methodology, but its identity must be explicit. Power and ground naming, global-net treatment, device parameters, black boxes, and hierarchy handling should be controlled rather than adjusted informally until a run appears clean.

An initial LVS run is often a bring-up exercise. Large unmatched groups may indicate a missing connection, incorrect source version, extraction setup problem, or hierarchy mismatch. Teams should first distinguish setup failures from design failures. Fixing the run environment before chasing individual devices avoids edits based on misleading comparisons.

Once the setup is stable, LVS can run alongside DRC closure. This is more effective than postponing connectivity verification until every geometric marker is gone. Many DRC violations do not prevent useful extraction, and an early LVS result can expose opens, shorts, swapped terminals, missing devices, or parameter discrepancies while the responsible engineer still has context. The qualification of the deck and approved flow still governs which intermediate results are actionable.

Use a Coupled Repair Loop

DRC and LVS closure should be treated as a coupled loop because a fix in one domain can affect the other. Adding a via to repair connectivity changes geometry. Moving metal to resolve spacing may break a connection. Editing a device shape can alter extraction or recognized parameters. After each meaningful repair batch, teams should rerun the check that found the issue and the complementary check at an appropriate scope.

Repair batches should remain small enough to isolate regressions. A useful handoff records the database revision, run configuration, error class, edited region, expected effect, and required reruns. This is more reliable than passing screenshots or marker totals without context. Marker counts can change when deck settings, hierarchy, or filtering changes, so they are not sufficient proof that the same problem set improved.

Teams should prioritize root causes that produce many downstream markers. One broken power connection can create a large LVS mismatch group, while one repeated routing pattern can create numerous DRC hits. Correcting the generating condition before treating every symptom reduces churn. After the root fix, regenerate reports rather than manually reconciling stale marker lists.

Expand to Full-Chip Verification

As blocks converge, the verification scope must expand to include interactions that are invisible in isolation. Full-chip DRC checks top-level geometry, block boundaries, assembled power networks, and other integration-dependent structures covered by the selected deck. Full-chip LVS checks that the extracted chip-level connectivity and recognized devices correspond to the approved source across hierarchy.

Run inputs should be versioned together. The layout, source netlist, rule deck, layer map, extraction options, waiver data, and invocation settings form one verification configuration. If any critical input changes, the prior report may no longer describe the current candidate. Automation should preserve this binding and make stale results easy to reject.

Runtime constraints may justify staged execution, but staging should be explicit. Teams can use hierarchical or incremental methods supported by their qualified flow, then reserve complete runs for integration milestones and release candidates. A partial run must retain its scope label. Final approval should rely on the project-defined signoff modes, not on an accumulation of unrelated local passes.

Freeze, Review, and Sign Off

Final DRC and LVS runs should start from a controlled release candidate after planned layout edits are frozen. The run should use approved decks and settings, a known source netlist, and documented handling for intentional exceptions. Reports need enough provenance for another engineer to identify the exact inputs and reproduce the decision.

A clean result means the configured run found no unresolved violations in its defined scope. An accepted result may include reviewed waivers where project policy permits them, but a waiver is not the same as deleting or hiding a marker. Each exception should retain its rule, location, rationale, owner, approval, and applicability to the current database. Changes to the affected geometry or deck should trigger re-evaluation.

Release review should confirm both technical outcomes and process integrity. Verify that DRC and LVS refer to the same intended layout revision, that the LVS source is the approved comparison target, that required checks completed, and that reports are archived with their configuration. If a late repair is unavoidable, return to the coupled loop: rerun affected local checks, then repeat the required full signoff checks. This disciplined sequence turns DRC and LVS from separate end-stage gates into continuous controls throughout ASIC implementation.