DRC and LVS Closure Evidence

Closure Evidence Connects Results to a Design Revision

DRC and LVS are different rule checks in an ASIC physical verification flow, but both produce the same management challenge: a result is meaningful only when it can be traced to the inputs that created it. A clean summary copied into a message does not establish which layout database, source netlist, rule deck, or run options were used. Closure evidence supplies that missing chain.

A practical evidence package binds each run to an immutable design revision or a controlled release identifier. It records the tool mode, approved deck version, relevant switches, hierarchy choices, and input paths without exposing credentials. It also preserves the machine-generated report rather than replacing it with a manually typed count. This distinction matters because a later layout update can invalidate an earlier clean run even when the block name remains unchanged.

The goal is not to archive every temporary file. The goal is to retain enough authoritative material for a reviewer to answer three questions: what was checked, under which approved conditions, and how were all reported results resolved? Treating those questions as release criteria makes DRC and LVS status reproducible instead of conversational.

Keep DRC and LVS Claims Separate

DRC evaluates layout geometry against manufacturing and design constraints encoded in a rule deck. Typical checks address spacing, width, enclosure, density, area, and interactions between layers. LVS starts from another premise. It extracts electrical devices and connectivity from layout, then compares that representation with the intended source netlist. Its findings commonly involve unmatched nets, devices, ports, parameters, or hierarchy.

Because the checks answer different questions, evidence must not collapse them into a single generic statement such as physical verification passed. A DRC-clean layout can still have incorrect connectivity. An LVS-matched layout can still violate geometric rules. Even when one tool launches both jobs, each conclusion needs its own input identity, completion state, result summary, and exception record.

Use explicit labels in trackers and release documents. DRC closure should state the geometric verification outcome. LVS closure should state the comparison outcome and identify both sides of the comparison. This wording prevents a clean result in one domain from being mistaken for approval in the other, especially during fast handoffs between implementation, verification, and signoff owners.

Build a Minimum DRC Evidence Package

Begin DRC evidence with the layout revision and the approved runset or deck revision. Include the process option, top cell, hierarchy mode, and any switches that materially change rule execution. Preserve the final completion summary and enough log context to prove that the run finished normally. A report with no violations is not reliable if the log shows missing layers, an aborted phase, or disabled rule groups.

For a nonzero result set, organize findings by stable rule identifier rather than by screenshots. Each remaining marker should map to one of three states: fixed in the bound layout revision, accepted under an approved exception, or still open. An accepted result needs an owner, rationale, scope, and approval reference. Broad notes such as known issue are not closure because they do not define where or why acceptance applies.

Include checks for deck completeness and output integrity. Confirm that expected rule groups ran, output files are readable, and summaries agree with the detailed database. Where density or fill checks use a different stage, name that stage explicitly. The resulting package should let another engineer distinguish a truly clean run from a run that merely omitted relevant verification.

Build a Minimum LVS Evidence Package

LVS evidence must identify both compared representations. Record the exact layout revision and the exact source netlist revision, along with the top cell and any hierarchy mapping. Capture extraction options, device recognition settings, reduction rules, and approved black-box treatment when those choices influence comparison. Preserve the extraction and comparison completion summaries so that matched does not hide an incomplete setup.

The final report should make the comparison status unambiguous. If mismatches occurred during closure, retain a concise disposition history by mismatch class. Unmatched ports may indicate naming or interface problems, while device or parameter differences may point to extraction, layout, or schematic intent. Shorted and open nets usually need connectivity-focused investigation. Categorization helps demonstrate that the team addressed root causes rather than repeatedly changing options until a match appeared.

Any intentional difference requires controlled documentation. Examples can include approved source transformations, modeled devices, or hierarchy boundaries, but acceptance must be specific to the project setup. The evidence should show who reviewed the treatment and where it applies. Avoid declaring equivalence from visual similarity or a partial report; the authoritative comparison output remains the basis for closure.

Use a Traceability Matrix for Review

A compact traceability matrix makes the package reviewable without weakening its detail. Give each DRC rule class or LVS mismatch class a row with the originating report reference, current disposition, owner, evidence link, and approval reference when needed. Keep machine results authoritative; the matrix is an index, not a replacement. Stable references allow reviewers to move from a summary claim to the exact supporting record.

Revision binding belongs in every row or in a clearly inherited package header. If a fix changes layout or source data, mark prior evidence superseded and require a run against the new revision. Do not copy a closure decision forward merely because the issue description looks similar. For hierarchical designs, identify whether evidence applies to a block, an assembly context, or the full chip, since clean block runs do not automatically prove top-level closure.

Useful review gates check completeness before technical approval. Verify that all expected runs exist, all required rule groups completed, every result has a disposition, exceptions are approved, and evidence links resolve. Then confirm that the DRC and LVS conclusions refer to compatible release inputs. These simple controls expose stale reports and mixed revisions before they become signoff ambiguity.

Automate Collection Without Automating Approval

Automation can reliably collect run metadata, calculate report digests, confirm expected artifacts, and populate a traceability index. It can also reject packages with malformed reports, missing completion markers, unknown deck revisions, stale inputs, or unresolved records. These are deterministic checks and should fail closed when required data is unavailable.

Approval decisions need a different boundary. A script should not convert an unknown state to zero violations, infer that an exception is valid, or select the newest report after a failed run. It should preserve unavailable values as unavailable and require an authorized owner to approve intentional residual findings. If an external tracking update has an ambiguous outcome, automation should not retry blindly; the package can record that status for reconciliation.

Generate evidence as an atomic artifact when possible. Write a temporary package, validate its schema and references, calculate a digest, and then publish it under a release-specific identifier. Store timestamps in a defined timezone and include the producing workflow version. These practices protect against partial writes and make later modifications detectable while keeping the technical judgment visible and attributable.

Review Closure at the ASIC Handoff

At handoff, reviewers should start with scope rather than counts. Confirm the intended process configuration, design hierarchy, release revision, source netlist, and required rule decks. Next, verify normal run completion and inspect any warnings that could reduce coverage. Only then should the team evaluate clean summaries or approved residual results.

Review DRC and LVS independently, then check their relationship. The layout used for LVS should correspond to the release being claimed for DRC, and the compared source should be the intended logical reference. If later fixes alter geometry or connectivity, apply the project rerun policy and supersede affected evidence. A closure package should make these dependencies visible rather than relying on memory.

Finish with ownership and retention. Every exception needs an accountable approver, every open issue needs a named owner, and every final claim needs an accessible authoritative report. Retain the package alongside the release record so implementation, verification, and downstream teams share the same baseline. This disciplined evidence model complements flow sequencing, waiver governance, and signoff checkpoints by proving exactly what each DRC and LVS conclusion covers.