Physical Verification Handoff Discipline

Why handoff discipline matters

Many teams treat physical verification as a set of tool runs rather than a quality contract. That mindset delays issue discovery until late in the cycle, when owners have already changed context and decisions become expensive. A disciplined handoff converts this into a sequence of deterministic checkpoints with explicit owners, expected outputs, and reproducible commands. The goal is not to reduce engineering rigor; it is to ensure no one has to guess which run, deck, or waiver was valid for which revision. When verification work is handed across teams, a clear protocol prevents duplicated effort and accidental divergence. It also makes retrospectives efficient, because each failed deck has documented intent, root-cause status, and expected next action.

This discipline is especially important when many parallel activities touch the same layout block. Even a tiny ambiguity in naming, environment, or rule selection can create subtle, high-cost inconsistencies. By fixing that ambiguity up front, teams preserve engineering time for actual fixes instead of administrative recovery.

Build a fixed baseline before any tapeout run

Start with a versioned baseline that includes the design context, process assumptions, and rule deck selection. In practice, this means every team shares one source-of-truth metadata file for each verification campaign: revision hash, block name, target corner assumptions, and any temporary environment constraints. This alone eliminates a common failure mode where two teams compare outputs generated from similar-looking inputs but different unseen defaults.

• Capture immutable context: design database location, signoff database hash, PDK release identifier, and tool binary provenance.
• Lock checker presets: DRC/LVS decks, hierarchy mode, and reported error filters.
• Document expected outputs: severity thresholds, block-level pass criteria, and approval boundaries.

Create reusable DRC checkpoints

DRC success quality improves when the run is split into staged checkpoints. The first checkpoint checks structure and hierarchy stability. The second validates spacing and width families. The final checkpoint performs full-rule convergence with strict diffing against the previous stable baseline. This makes regression behavior observable rather than mysterious.

For every checkpoint, store a small evidence packet: command log, runtime summary, and error ledger with severity labels. Teams often focus on pass/fail dashboards and ignore why each warning exists. A robust packet allows quick triage. Some warnings are expected and can be cleared by explicit design intent changes, while others indicate immediate blocker conditions.

Never normalize away recurring warnings without traceability. Instead, link each allowed exception to owner, reason, and expiry. If context changes, the exception review should happen before the run is reopened.

Treat LVS as conformance, not a checkbox

LVS is the gate that confirms logical intent survived physical implementation. Treating it as a final status flag can miss important mismatches that are fixable earlier. A practical protocol verifies hierarchy mapping, net name intent, and boundary cell consistency before full LVS execution. This reduces random deltas and makes failures repeatable.

• Run a pre-check that highlights unexpected hierarchy flattening and pin-level mismatches.
• Review critical net mappings in a small subset before full convergence.
• Require design owner sign-off for every LVS-discovered functional intent change.

When LVS outputs do not match expectations, teams should start with a small, controlled rerun rather than broad resets. Narrow experiments preserve confidence and often reveal which assumption changed first. This is where the handoff board becomes useful: each rerun hypothesis maps directly to one recorded owner and one expected acceptance condition.

Run a strict waiver and exception loop

Waivers are useful when they are controlled. They are harmful when they become silent assumptions. Define one ledger per campaign that captures root cause, evidence, owner, and review date. Every entry should include a short path to close. This keeps the waiver from turning into technical debt.

When the waiver list grows, separate risk classes. Cosmetic geometry expectations, process-compatibility anomalies, and known tool quirks are handled differently and must be reviewed by different owners. This distinction prevents mixing unrelated issues and creating false urgency. A simple consequence-oriented taxonomy can reduce meeting time and improve closure predictability because everyone knows the expected evidence and decision owner for each exception.

Close with a release-ready verification summary

Before handoff, publish a single summary document that mirrors the run sequence. It should include input snapshot, tool versions, checks performed, exception list, and unresolved risks. Add a short decision log: what changed, why, and what will be rechecked in the next run. This is the difference between an archived report and a usable release artifact.

A clean release packet should be minimal enough to review in one pass and detailed enough to reproduce. Include links to rerun scripts, exact output locations, and a clear status per bucket: passed, blocked, monitor, and deferred. With this structure, a follow-up team can restart quickly with confidence, and you avoid the common scenario where historical context is buried in scattered messages.

Use a consistent review board for each run

One practical control is a shared release board with fixed columns and hard deadlines. Each row maps one verification item, and each column has a single source of truth, so disputes move from opinion to evidence. This reduces repeated status uncertainty when teams synchronize before tapeout milestones.

• Input parity: design revision, PDK signature, and top-level run script are aligned.
• DRC state: checkpoint history and waiver impact are explicitly documented.
• LVS state: netlist equivalence checks and hierarchy expectations are up to date.
• Exception status: each open waiver has an owner, priority, and closure condition.
• Evidence quality: logs and reports are readable by any engineer on call.

When this board is complete and each column is current, teams move from argument to execution quickly. If any row stays blocked too long, freeze promotion decisions until the blocker is either resolved or explicitly deprioritized with sign-off. This keeps the schedule visible and protects downstream integration windows.