Physical Design · All levels
Physical Verification Tricky Q&A
20+ senior Physical Verification interview questions.
Q&A bank
Answer with mechanism, pitfall, regression check, and release judgment. At 10+ years, a correct definition is not enough.
Senior answer rubric
Start with the failing metric and analysis context.
Explain the physical or constraint mechanism.
Name the cheapest evidence-gathering experiment.
Choose a bounded fix and state what it can regress.
Close with signoff, waiver, or escalation criteria.
Why can DRC-clean still fail LVS?
[INT][PD]
Q: Why can DRC-clean still fail LVS?
A:
DRC validates geometry constraints, while LVS validates extracted connectivity and device equivalence.
FOLLOW-UP TRAP: Treating DRC zero as functional connectivity proof.What is the first artifact you open in a PV triage meeting?
[INT][PD]
Q: What is the first artifact you open in a PV triage meeting?
A:
A delta dashboard showing DRC/LVS/ERC trend by revision and deck version.
FOLLOW-UP TRAP: Looking at raw violation lists without revision context.How do you choose between fixing one violation and fixing a generator script?
[INT][PD]
Q: How do you choose between fixing one violation and fixing a generator script?
A:
Use cluster frequency and recurrence; high-repeat patterns usually indicate generator-level defects.
FOLLOW-UP TRAP: Optimizing single hotspots while systemic source remains.When is an LVS open likely a hierarchy issue?
[INT][PD]
Q: When is an LVS open likely a hierarchy issue?
A:
When identical opens repeat across many instances at the same boundary pin contract.
FOLLOW-UP TRAP: Flattening everything before checking interface contracts.What must accompany every approved PV waiver?
[INT][PD]
Q: What must accompany every approved PV waiver?
A:
Rule ID, exact location, rationale, owner, approver, and revalidation trigger/expiry.
FOLLOW-UP TRAP: Recording waiver reason only in chat or meeting notes.Why can antenna fixes regress LVS?
[INT][PD]
Q: Why can antenna fixes regress LVS?
A:
Diode insertion or reroutes can alter device count, naming, or connectivity if compare views are not synchronized.
FOLLOW-UP TRAP: Assuming antenna edits are electrically isolated from LVS.How do you validate fill impact on timing quickly?
[INT][PD]
Q: How do you validate fill impact on timing quickly?
A:
Compare pre/post-fill extraction on a stable critical-path set and map slack deltas to RC changes.
FOLLOW-UP TRAP: Running fresh STA and blaming random path movement.What does a healthy DRC debug workflow optimize for?
[INT][PD]
Q: What does a healthy DRC debug workflow optimize for?
A:
Violation class collapse rate per run, not raw edit count.
FOLLOW-UP TRAP: Counting engineer-hours as progress metric.Which PV classes are usually hard no-waiver gates?
[INT][PD]
Q: Which PV classes are usually hard no-waiver gates?
A:
Critical LVS shorts/opens and fatal ERC classes tied to electrical safety/reliability.
FOLLOW-UP TRAP: Allowing blanket waivers for schedule pressure.Why log deck and extraction versions in every report?
[INT][PD]
Q: Why log deck and extraction versions in every report?
A:
Because report interpretation depends on deck semantics and extraction options; traceability prevents false comparisons.
FOLLOW-UP TRAP: Comparing reports from different decks as if equivalent.How do you triage 1,000 DRC violations in one hour?
[INT][PD]
Q: How do you triage 1,000 DRC violations in one hour?
A:
Build Pareto by rule and region, assign top clusters, and defer outliers after systematic fixes.
FOLLOW-UP TRAP: Round-robin individual violations across engineers.What proves a hierarchical LVS fix is complete?
[INT][PD]
Q: What proves a hierarchical LVS fix is complete?
A:
Representative instance root cause is resolved and repeated instance cluster collapses in parent run.
FOLLOW-UP TRAP: One local instance passes while siblings still fail.How do you prevent fill from breaking analog margins?
[INT][PD]
Q: How do you prevent fill from breaking analog margins?
A:
Use keep-outs, layer restrictions, and post-fill extraction checks on sensitive nets/devices.
FOLLOW-UP TRAP: Applying digital fill defaults over analog islands.What should be in a tapeout PV readiness memo?
[INT][PD]
Q: What should be in a tapeout PV readiness memo?
A:
Hard-gate status, residual risks, waiver ledger summary, deck provenance, and approval signatures.
FOLLOW-UP TRAP: Only final violation counts with no ownership.How do you spot false progress in PV closure?
[INT][PD]
Q: How do you spot false progress in PV closure?
A:
Counts oscillate across runs or migrate between rule classes without net reduction in risk.
FOLLOW-UP TRAP: Celebrating temporary drops without trend analysis.When do you re-run full LVS versus incremental?
[INT][PD]
Q: When do you re-run full LVS versus incremental?
A:
Use incremental for localized validated edits; full LVS for extraction/deck changes or widespread topology edits.
FOLLOW-UP TRAP: Always running incremental even after deck changes.Why track residual PV risk even when gates are green?
[INT][PD]
Q: Why track residual PV risk even when gates are green?
A:
Near-threshold metrics and approved exceptions can still impact yield or schedule in downstream revisions.
FOLLOW-UP TRAP: Assuming green dashboard means zero operational risk.What is the best response to 'just waive and tapeout'?
[INT][PD]
Q: What is the best response to 'just waive and tapeout'?
A:
State hard-gate policy, classify remaining violations, and escalate only bounded exceptions with approvals.
FOLLOW-UP TRAP: Accepting schedule pressure as technical justification.How can report checksums help PV governance?
[INT][PD]
Q: How can report checksums help PV governance?
A:
They verify the exact artifacts reviewed and prevent accidental substitution before signoff.
FOLLOW-UP TRAP: Trusting filenames like final_v7_latest.What makes PV debug interview answers senior-level?
[INT][PD]
Q: What makes PV debug interview answers senior-level?
A:
Clear mechanism, metric-based prioritization, risk framing, and reproducible regression plan.
FOLLOW-UP TRAP: Listing tool commands without decision logic.How to drill this Q&A bank
Use each question as a two-minute mock. The target answer is not an essay; it is a structured closure response with a metric, mechanism, risk, and follow-up check.
Answer template
MECHANISM: what physical effect or tool step is involved
WHEN: where it appears in the flow
PITFALL: one wrong junior answer
CHECK: report/map/checklist item that proves the answerScoring
5/5: metric, mechanism, experiment, regression, and release decision named without prompting.
4/5: technically correct and names regression, but misses ownership or escalation criteria.
3/5: correct concept but no decision framework.
1/5: tool command or buzzword with no mechanism.
Principal-level review bar
Q&A bank pages in this course should be read like real closure review material. For a 10+ year PD engineer, the bar is not remembering terminology; it is making a release-quality decision under ambiguity.
What excellent looks like
Names the failing metric, corner/mode, database tag, and analysis switches before proposing a fix.
Separates data, constraint, physical, tool, and methodology root causes instead of treating all failures as optimization problems.
Chooses experiments by information gain and reversibility, not by habit.
States regression blast radius across timing, route, power, PV, DFT, package, and tapeout manifest.
Turns recurring failures into methodology guardrails, dashboards, or checklist items.
Closure note template
STAFF / PRINCIPAL CLOSURE NOTE
Context:
stage: <pre-CTS | post-CTS | post-route | post-fill | signoff>
tag: <database / netlist / SDC / library stack>
failing metric: <exact report line>
affected scope: <block / hierarchy / path group / power domain / region>
Hypotheses:
H1: <most likely physical or constraint mechanism>
H2: <competing explanation>
H3: <methodology or input-data issue>
Decision:
next experiment: <cheap check that can falsify H1>
fix candidate: <minimal reversible change>
rollback trigger: <metric that says the fix is wrong>
regression set: <timing / route / power / PV / DFT / package>
escalation owner: <team or reviewer>Tradeoffs a senior engineer must discuss
Technical tradeoff
Physical verification is the manufacturing and connectivity gate. Explain not only the preferred fix, but what margin or schedule you are spending to get it.
Cross-team tradeoff
What must RTL, synthesis, CAD, STA, DFT, package, IP, or foundry agree to before this decision is final?
Which artifact becomes the source of truth after the decision: report, waiver, manifest, ECO script, or methodology deck?
What is the cost of being wrong: one rerun, ECO churn, mask risk, performance loss, or silicon escape?
Leadership communication
"The current blocker is <metric> in <corner/mode/stage>. The leading cause is <mechanism>. I recommend <fix> because it is bounded and reversible. The regression surface is <domains>. If it fails, we escalate to <owner> with <evidence>."Key takeaways
Always connect the concept back to a measurable signoff artifact.
A fix is not complete until you can name the regression checks.
Common pitfalls
Optimizing by habit instead of reading the current report.
Forgetting that a local fix can regress timing, routing, power, or PV elsewhere.