DRC Baseline and Waiver Discipline

Why Design Rule Checking Deserves a Baseline

Design rule checking is often treated as a final gate: run the deck, fix what is red, ship the database. Teams that operate this way tend to discover late that their violation list was never actually shrinking, only shifting. A baseline discipline changes the question from “how many violations remain” to “what changed since the last known-good run.”

A baseline is a reference state where every open violation is understood, owned, and either scheduled for a fix or formally waived. New runs are diffed against that reference. Anything that appears fresh is investigated the same day, because fresh violations are almost always cheaper to fix before downstream steps build on top of them.

Building a Clean-Tree Reference

The first practical step is producing a clean tree: a full-chip DRC run on a frozen database snapshot, with the exact tool version, deck revision, and option switches recorded alongside the results. Without those pinned inputs, comparing two runs is guesswork, since deck updates alone can introduce or retire violations.

Store the reference results with the same care as source code. A violation database, a summary count per rule, and the run command line should be archived together. When a later run diverges, the first diagnostic question is whether the inputs changed, and the archived command line answers it in minutes.

Categorizing Violations by Root Cause

A flat violation count is nearly useless for planning. Categorization is what turns the list into work. Most teams settle on four buckets:

• Real geometry errors — the layout genuinely violates a manufacturing constraint and needs an edit.
• Deck or tool artifacts — the violation is a known false positive for that deck revision, documented and waivable.
• Interaction effects — violations that only appear at full-chip assembly, typically from placement or routing density, not from any single block.
• Process-option sensitivity — rules that fire only under specific mask option combinations.

Each category has a different owner and a different fix path, which is why the split matters more than the total. A large count dominated by one repeatable artifact is less dangerous than a small count of scattered real errors.

Waivers as Engineering Records

A waiver is not an excuse to stop looking at a violation. It is an engineering record that says: this violation was reviewed, here is why it is acceptable, here is who approved it, and here is when it will be revisited. A waiver without an owner and an expiry date is a hidden defect with a longer name.

Good waiver hygiene has three parts. First, the waiver references the exact rule number, layer, and location it covers, so a deck update that changes the rule invalidates it visibly. Second, foundry-required exceptions carry written approval from the foundry, not just an internal decision. Third, the waiver list is reviewed on a cadence — waivers inherited from previous projects are the most common source of stale assumptions surviving into new silicon.

Density, Fill, and Process-Dependent Rules

Modern processes enforce windowed density rules: within every sliding window of a given size, each layer must stay between a minimum and maximum fill fraction. These rules interact with metal fill insertion, which means DRC, fill, and extraction are not independent steps. Fill added to satisfy density changes parasitics, and the extracted netlist used for signoff must reflect the fill that will actually be manufactured.

The practical discipline is to sequence the loop deliberately: run density analysis, insert fill with the same settings intended for tapeout, then re-run DRC and re-extract. Treating fill as a free post-step that can be redone later quietly invalidates earlier timing and DRC evidence.

Reliability Checks Beyond Geometry

Standard DRC decks usually include antenna checks, which flag gates whose metal connections collect charge during plasma etching faster than diffusion paths can dissipate it. Antenna violations are fixed by reordering routing layers, adding jumps to higher metals, or inserting protection diodes — each of which touches connectivity, so they belong in the same regression loop as the geometric checks rather than a separate late review.

Voltage-dependent spacing, same-net rules, and width-table transitions round out the family of checks that depend on more than raw coordinates. They are also the checks most likely to behave differently across tool versions, which is another reason to pin versions in the baseline.

Automating DRC in Regression

DRC earns the most when it runs automatically rather than on request. A regression wrapper that runs the deck on a scheduled basis, diffs results against the baseline, and reports only the delta gives the team a continuously meaningful signal. The report that matters is short: new rules firing, rules whose counts grew, and waivers that no longer suppress anything.

Keep the wrapper boring and deterministic: fixed run directory, recorded command line, machine-readable results, and a nonzero exit when the diff is non-empty so the regression cannot silently pass. The value is not in the tooling sophistication but in the comparability of runs over weeks.

Working Across Corners and Options

A database intended to support multiple mask options or multiple process corners must be checked for every combination that will be manufactured. Violations frequently appear only in one option, because option layers alter which spacing table applies. The baseline should therefore record not just one clean run but one clean run per shippable configuration.

This is also where categorization pays off a second time: an option-specific violation is usually a systematic deck or placement issue that, once understood, is fixed in one place rather than patched per configuration.

Handoff Criteria for DRC Signoff

Signoff is a claim of evidence, so the DRC portion of a signoff package should be checkable by someone who did not run it. A defensible package contains: a complete full-chip run on the final database, zero violations outside the reviewed waiver list, foundry approvals attached where the process requires them, density and antenna results included, and the archived tool, deck, and command-line record that lets the run be reproduced.

When any of those pieces is missing, the honest status is not “done with a caveat” but “not closed.” Ambiguity at handoff is exactly what baseline discipline exists to prevent, because every downstream consumer of the database inherits it silently.

A Practical Starting Checklist

Teams adopting this discipline can start small. Freeze a snapshot, run the deck with recorded inputs, and spend one session categorizing every remaining violation into the four root-cause buckets. Convert every accepted violation into a waiver with an owner and an expiry. That categorized, waivered state becomes the baseline.

From there, add a scheduled diff run and a rule that fresh violations are investigated before new work builds on the affected cells. Within a few cycles the violation list stops being a source of dread and becomes what it should be: a live, truthful map of the gap between the current database and a manufacturable one.