Treat waivers as bounded engineering decisions
DRC and LVS rule checks in ASIC flows produce different kinds of evidence, so their exceptions should not be managed as a generic list of items to ignore. A DRC result identifies geometry that a rule deck classifies against width, spacing, enclosure, density, antenna, or other encoded constraints. An LVS result identifies a difference between extracted layout representation and the intended source representation, including connectivity, recognized devices, ports, or compared parameters. A waiver must state which conclusion is being accepted and why that acceptance is safe within a defined scope.
The waiver record should begin with an exact result identity. For DRC, that may include the rule identifier, marker or result reference, coordinates, hierarchy path, and affected layers. For LVS, it may include the mismatch class, compared objects, hierarchy path, cross-reference entry, and relevant device or net names. Bind the record to the completed run and its layout, source netlist, rule deck, technology data, and configuration. A copied marker description without those identities can drift away from the design state that reviewers actually examined.
Acceptance is not the same as removal. Preserve the original result and add a disposition rather than altering reports to make the issue disappear. The disposition should explain the technical rationale, applicable constraints, owner, approver, review date, and invalidation conditions. This keeps the verification evidence auditable and allows later runs to distinguish a known, reviewed condition from a newly introduced problem.
Require evidence appropriate to each check
A DRC waiver request should demonstrate the physical context around the marker. Review enough surrounding geometry and hierarchy to determine whether the apparent exception depends on abutment, cell orientation, top-level routing, fill, seal structures, or an intentional construct covered by project policy. Identify the exact rule interpretation and avoid assuming that two similarly worded markers have the same cause. If the rule deck provides categories or explanatory text, preserve the relevant identifier while treating the approved deck as authoritative.
An LVS waiver requires comparison-specific evidence. Establish whether the mismatch arises from an intentional source-layout difference, a permitted device representation, parameter tolerance, hierarchy treatment, black-box policy, global-net convention, or another controlled comparison setting. Confirm that extraction completed and that the waived item is not a symptom of a wider open, short, missing device, or incorrect include file. A favorable local interpretation cannot compensate for an incomplete comparison or an unexpected change in extraction scope.
Both types of request should include reproducible navigation to the result database or report, not only prose and images. A reviewer should be able to open the bound run, locate the item, inspect related objects, and verify the proposed rationale. When required evidence is unavailable, the correct status is blocked or pending rather than approved. Unknown context must never be translated into a clean result or a zero count.
Separate request, review, and approval roles
The engineer who understands the issue should prepare the request, but project policy should define who can approve it. Separating preparation from approval creates a deliberate challenge point. The reviewer checks technical evidence, scope, precedent, and invalidation rules; the approver accepts responsibility for applying the disposition to the stated release. On small teams, one person may perform more than one role, but the record should still show which decision was made at each stage.
Ownership should follow the source of the condition. A block owner may resolve or request disposition for geometry inside a delivered block, while an integration owner handles top-level interactions and assembly effects. Methodology teams can clarify qualified configurations and rule interpretation. Design, reliability, process, or verification authorities may be required for particular rule classes. Routing every request to one undifferentiated queue hides the expertise and authority needed for a sound decision.
Use a controlled status model such as proposed, under review, approved, rejected, superseded, expired, and withdrawn. Do not allow a proposed item to suppress a signoff result. Record reviewer comments and revised evidence without overwriting the prior decision trail. If one request covers repeated instances, define the matching criteria narrowly and prove that each matched instance satisfies them. Broad text-based suppression can conceal unrelated markers that happen to share a rule name.
Bind validity to design and flow changes
Every waiver needs explicit invalidation conditions. A layout edit near a DRC marker can change spacing, enclosure, connectivity, or neighboring context. An LVS item can change after either the layout or source netlist changes. Updates to rule decks, extraction settings, device mappings, reduction policy, tolerances, hierarchy handling, or technology files can also alter what a result means. A calendar expiration is useful, but input-based invalidation is essential because technical context can change before the date arrives.
Store stable revision identifiers or digests for bound artifacts where the flow supports them. Paths and filenames alone are weak controls because their contents may be replaced. At each candidate release, compare the current run manifest with the waiver bindings. If a critical identity differs, move the item back to review or require a newly generated request. Avoid automatically carrying approval from a block run into a top-level run when boundary conditions or hierarchy expansion differ.
Revalidation does not always require rewriting the rationale from the beginning. The process can link a new review to prior evidence, then document the current run, unchanged assumptions, and renewed approval. However, the new decision must remain explicit. Automation can help by detecting stale bindings, duplicate result identities, missing approvers, expired records, and unmatched markers. It should fail closed when the current design state or waiver state cannot be read reliably.
Close signoff with a waiver reconciliation
Before release, reconcile completed DRC and LVS results against approved dispositions. Confirm that every required run finished normally, expected rules and design regions were included, reports are readable, and the run identities match the release candidate. Then match each remaining item to one current waiver using authoritative identifiers and scope. Unmatched results, ambiguous matches, stale approvals, or duplicate claims should block closure until resolved.
Report raw results and dispositions separately. Useful release evidence shows which checks are clean, which contain approved items, which remain under review, and which are blocked or failed. Do not subtract approved markers from a total and present the remainder without preserving the original count and disposition set. For LVS, preserve the comparison summary and extraction evidence alongside any accepted differences. For DRC, retain the navigable result database and rule-level disposition mapping.
The final package should connect the release manifest, run logs, result databases, reports, waiver records, approval history, and reconciliation output. Access controls should prevent unapproved edits while allowing reviewers to trace each decision. After release, retain the evidence according to project policy and mark superseded waivers so they cannot silently attach to later designs. A disciplined waiver process lets teams handle justified exceptions without weakening the distinction between verified results, approved engineering decisions, and unavailable evidence.