Answer with mechanism, pitfall, regression check, and release judgment. At 10+ years, a correct definition is not enough.
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.
[INT][PD]
Q: What usually breaks first when integration contracts are weak?
A:
Interface assumptions: pin maps, obstructions, and constraint compatibility drift across teams.
FOLLOW-UP TRAP: Blaming router randomness before checking contracts.[INT][PD]
Q: Why is scan reordering a physical-design concern?
A:
It changes route demand, coupling, and sometimes functional timing near reordered chain segments.
FOLLOW-UP TRAP: Treating scan as purely logical with no physical side effects.[INT][PD]
Q: How do you prove a bump swap is safe?
A:
Show preserved logical mapping, package escape feasibility, and unchanged/acceptable IR-SI impact.
FOLLOW-UP TRAP: Approving swaps from spreadsheet-only review.[INT][PD]
Q: Which report best catches unstable block drops?
A:
A manifest diff that includes LEF/DEF/netlist/liberty hashes and interface compatibility checks.
FOLLOW-UP TRAP: Tracking only version labels without content hashes.[INT][PD]
Q: When should lockup latches be revisited?
A:
Whenever scan domain crossings or skew assumptions change after floorplan/CTS evolution.
FOLLOW-UP TRAP: Keeping original lockup plan despite topology shifts.[INT][PD]
Q: What indicates scan-chain optimization is overfitting?
A:
Improved chain metrics but worsening functional WNS/hold or localized congestion.
FOLLOW-UP TRAP: Declaring success from chain length alone.[INT][PD]
Q: How do you reduce package/PD ping-pong near tapeout?
A:
Freeze a milestone-based interface contract with explicit no-swap and escalation rules.
FOLLOW-UP TRAP: Allowing ad hoc bump edits until final week.[INT][PD]
Q: What is a strong ESD integration signoff statement?
A:
Clamp coverage and return-path integrity validated per domain with clean ERC classes and documented exceptions.
FOLLOW-UP TRAP: ESD is fine because pad count looks normal.[INT][PD]
Q: Why do IP abstract diffs belong in integration review?
A:
Small abstract changes can alter pin access and route congestion even when macro area stays constant.
FOLLOW-UP TRAP: Assuming area equality means integration safety.[INT][PD]
Q: What is the first triage for top-level assembly failures?
A:
Check latest block intake diffs, interface checks, and merge script provenance before rerouting.
FOLLOW-UP TRAP: Launching full-chip reruns immediately.[INT][PD]
Q: How can DFT and package teams conflict indirectly?
A:
Scan/DFT routing demand can compete with IO/power escape paths shaped by package bump planning.
FOLLOW-UP TRAP: Reviewing DFT and package plans in separate silos.[INT][PD]
Q: What belongs in an integration readiness dashboard?
A:
Interface mismatch count, block-drop stability, scan physical QoR, bump/package blockers, and IO/ESD status.
FOLLOW-UP TRAP: Only timing and DRC headline numbers.[INT][PD]
Q: Why is deterministic assembly scripting critical?
A:
It ensures reproducibility across teams and prevents hidden merge drift between review and signoff runs.
FOLLOW-UP TRAP: Manual assembly with undocumented edits.[INT][PD]
Q: What is a red flag in chip-level assembly meetings?
A:
Teams discussing symptoms without shared revision identifiers for their artifacts.
FOLLOW-UP TRAP: Assuming everyone looked at the same build.[INT][PD]
Q: How do you evaluate third-party IP readiness quickly?
A:
Validate abstract consistency, timing model compatibility, power intent alignment, and boundary DRC/LVS checks.
FOLLOW-UP TRAP: Relying on vendor release notes alone.[INT][PD]
Q: When do you block an IP drop?
A:
When abstract/timing/power contract changes are undocumented or regress integration metrics beyond thresholds.
FOLLOW-UP TRAP: Merging first and hoping to patch later.[INT][PD]
Q: What is the practical difference between interface bug and optimization bug?
A:
Interface bug violates contract assumptions; optimization bug tunes QoR within a valid contract.
FOLLOW-UP TRAP: Treating both with generic place-route option sweeps.[INT][PD]
Q: How do you keep integration QA interview answers senior-level?
A:
Frame decisions using contracts, trade-off metrics, and rollback-safe execution plans.
FOLLOW-UP TRAP: Answering with tool switches and no governance logic.[INT][PD]
Q: Why should package constraints appear in PD checklists?
A:
Package escape and bump limits directly bound physical feasibility and signoff risk.
FOLLOW-UP TRAP: Treating package feedback as post-tapeout concern.[INT][PD]
Q: What is the best defense against late integration surprises?
A:
Continuous contract validation with versioned manifests and targeted intake checks before global reruns.
FOLLOW-UP TRAP: Periodic mega-integration events only.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.
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 answer5/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.
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.
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.
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>Interview performance is structured closure thinking under time pressure. Explain not only the preferred fix, but what margin or schedule you are spending to get it.
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?
"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>."Always connect the concept back to a measurable signoff artifact.
A fix is not complete until you can name the regression checks.
Optimizing by habit instead of reading the current report.
Forgetting that a local fix can regress timing, routing, power, or PV elsewhere.