How do you make the final proceed-or-stop decision?
From PDVerse PnR Interview Handbook, part of the pdVerse Mentor Guide
Short Answer
This is a broader version of the floorplan gate decision — it applies whenever a stage handoff (SDC readiness, linking, structure review) needs an accountable "go / no-go" rather than just a pile of passed checks. Proceed only when provenance genuinely matches — the constraints, netlist, and libraries you're reviewing actually correspond to the version you think they do, not a stale or mismatched set.
Technical Explanation
- Linking has to actually resolve — every reference in the design has to bind to a real object, with no silent unresolved references lurking in the log.
- ) and that classification has to match expectations.
- SDC semantics need an actual review, not just a syntax check — clocks, I/O constraints, exceptions, and scenario coverage all have to represent the intended design behavior, and intent is something a human has to confirm, not something a parser can verify.
- Any waivers in the mix need clear ownership and reproducibility — someone's name is on each waiver, and another engineer should be able to reproduce the evidence behind it from the same handoff data.
- The underlying discipline: this is a readiness check, and its output should be something another engineer can independently reproduce from the same starting handoff — if they can't get the same answer you did, the review wasn't actually complete.
What To Check
- Warning sign: One hard-stop defect remains but schedule pressure treats it as a warning.
- Inspect: Keep at least two possible causes open, then use one named object and the active mode or scenario to separate them.
- Correct: Record the decision matrix, return hard stops, archive reports and waivers, reopen the final checkpoint, and reproduce the gate once.
Command Checks & Actions
check_design-checks {netlist unbound dp_pre_floorplan}: runs the selected design-readiness checks- check_netlist: reports structural connectivity problems
check_timing: finds missing or inconsistent timing setup- report_clocks: shows clock definitions and relationships
- report_scenarios: shows the MCMM scenario matrix and analysis status
- report_exceptions: shows timing exceptions and their scope
report_case_analysis: shows constants applied for the active modereport_disable_timing: shows timing arcs that cannot propagate
Run the commands in order. Each line answers a separate part of the check.
Healthy, Suspicious & Hard-stop Results
- Expected: Proceed only when provenance matches, linking resolves, structure is classified, SDC semantics are reviewed, clocks/I/O/exceptions/scenarios provide intended coverage, and waivers are owned and reproducible.
- Stop before floorplanning when required logic or timing coverage is missing or unexplained.
Common Mistake
The Trap: Do not assume the check passed just because ICC2 continued. Fix or narrowly justify the named objects, then rerun the same command.
What The Interviewer Is Testing
Be ready to explain why this matters before floorplanning.
Follow-up Question & Model Response
Model response: “I would save the report, inspect one affected object in the correct block and scenario, and make or request this correction. ”
Physical Design & Planning Handbook
Master ASIC Physical Design Planning & Floorplanning
Dive into 14 comprehensive chapters covering netlist sanity, FinFET grids, macro placement, power grids, CTS, and timing budgeting.
Offline PDF Bundle
Want all 1109 questions offline?
Get the complete 4-book PDF bundle (PnR, STA, MMMC, Low Power) with a clickable table of contents - no ads, no internet needed.
Continue practising