Place DRC and LVS at distinct decision points
DRC and LVS are related physical-verification activities, but they provide different evidence. Design rule checking evaluates shapes and relationships between shapes against constraints encoded in an approved rule deck. Layout versus schematic comparison extracts connectivity and recognized devices from layout, then compares that representation with a controlled source netlist. A useful ASIC flow therefore treats them as separate checkpoints rather than combining them into one vague clean status.
During implementation, targeted DRC catches local width, spacing, enclosure, overlap, and related geometric problems while changes are inexpensive. Targeted connectivity review can reveal opens, shorts, missing pins, and device-recognition problems around edited regions. These incremental runs accelerate feedback, but they do not replace qualified signoff because their scope, hierarchy, or rule selection may be limited.
At integration boundaries, block owners should provide results tied to an exact delivered layout. Top-level teams then check interactions that block-level runs cannot fully establish, including boundary geometry, power connections, top-level routing, fill, and assembly effects. Final DRC and LVS checkpoints use the release candidate and the approved run configuration. Their purpose is not merely to produce reports; it is to establish reviewable evidence for a specific design state.
Bind every checkpoint to controlled inputs
A checkpoint is meaningful only when its inputs are identifiable. For DRC, bind the layout revision, top cell, rule-deck release, technology mapping, hierarchy mode, boundary policy, and any required auxiliary data. For LVS, also bind the source-netlist revision, device models, include files, global-net conventions, parameter tolerances, reduction policy, and black-box treatment. Record tool and configuration identities according to the project qualification process.
Do not describe a result as current after any bound input changes. A routing fix can invalidate both geometry and connectivity evidence. A source-netlist update may require a new LVS comparison even when layout did not change. A deck or configuration update can alter interpretation without any design edit. Explicit invalidation rules prevent stale green indicators from following a newer release candidate.
Use a run manifest or equivalent record to capture these identities before launch. Paths alone are weak evidence when files can be replaced, so revision identifiers or digests are preferable where the flow supports them. Preserve launch configuration, completion status, summaries, logs, and result databases together. If an input is unavailable or a report is incomplete, mark the checkpoint blocked or unknown instead of translating missing evidence into zero violations.
Use staged checks without weakening signoff
Efficient flows use several verification scopes. An interactive or windowed check helps an engineer evaluate a local edit. A cell-level run checks the complete affected master. A block-level run verifies delivered hierarchy under block assumptions. A top-level run evaluates integrated context. Each stage should be named clearly so that a limited run cannot be mistaken for full-chip signoff.
DRC can often begin before the design is complete, provided exclusions and incomplete regions are explicit. Early checks are valuable for repeated rule patterns, boundary construction, special routing, and cell-abutment behavior. LVS becomes increasingly useful as source and layout connectivity stabilize, although extraction checks can still expose recognition and labeling errors earlier. The two activities may run concurrently; neither must be assigned a universal first position.
Gates between stages should test prerequisites rather than rely on informal confidence. A block handoff might require successful tool completion, no unreviewed errors in the declared scope, approved waiver references, and a manifest matching the delivered data. A final gate should additionally confirm that all required regions and rule groups were enabled. This staged approach preserves rapid feedback while keeping the final claim narrow, reproducible, and based on the qualified scope.
Coordinate ownership across implementation teams
Physical verification crosses design boundaries, so ownership must be decided before reports arrive. Block teams usually own defects inside their delivered cells. Integration teams own top-level routing, assembly, and interactions introduced during integration. Methodology or verification teams maintain approved configurations and help interpret rule behavior, while designated approvers control waivers. Project policy should resolve exceptions such as shared power structures or generated fill.
Route an issue with enough identity for another engineer to reproduce it. A DRC item should include the rule identifier, hierarchy path, location or marker reference, run identity, and a concise assessment. An LVS item should identify the mismatch class, compared objects, hierarchy, cross-reference entry, and relevant source and layout identities. A screenshot may illustrate the symptom, but it cannot replace the navigable result or authoritative report.
After a correction, update the owning design artifact and rerun every affected checkpoint. Avoid patching only a flattened signoff copy when the source of ownership lies in a reusable master. Track whether a fix changes geometry, connectivity, hierarchy, or configuration so downstream teams know which evidence is stale. Clear ownership and invalidation reduce repeated triage and prevent a local clean result from being promoted beyond the scope it actually covered.
Define completion as evidence, not a number
A completed DRC checkpoint requires more than a displayed violation count. Confirm that the tool completed normally, expected rule groups ran, required design regions were included, result data is readable, and all remaining markers have an approved disposition. Some projects distinguish clean, waived, accepted by policy, blocked, and failed states. Preserve those distinctions rather than compressing them into pass or fail without context.
An LVS checkpoint likewise requires a valid extraction and comparison, expected top cells and ports, recognized device classes, and a documented final comparison status. Investigate unexpected empty sections, missing hierarchy, or abnormal extraction summaries even if a headline appears favorable. Comparison policies such as device reduction, parameter tolerance, virtual connections, and black boxes are part of what the result proves and must remain visible to reviewers.
The final handoff should connect each conclusion to the exact release candidate, reports, result databases, approved waivers, owners, and review status. Automation can validate manifests, required files, status fields, uniqueness, and freshness, but it should fail closed when evidence is absent. With separate DRC and LVS checkpoints, controlled inputs, explicit scope, and durable records, ASIC teams can move quickly without confusing a convenient intermediate run with physical-verification signoff.