ExpertQuestion 24 of 161

When should PD return the handoff instead of editing locally?

From PDVerse PnR Interview Handbook, part of the pdVerse Mentor Guide

Short Answer

The dividing line is authority, not difficulty: if the defect lives in functional connectivity, synthesis structure, the library release, interface timing intent, or mode definitions, PD editing it locally is out of scope even if PD technically could patch around it. A local PD-side fix to one of these categories risks quietly diverging from the design's actual golden intent โ€” the netlist or constraint set PD is working from stops matching what synthesis/RTL/architecture actually meant.

Technical Reference DiagramWhen should PD return the handoff instead of editing locally?

Technical Explanation

  • The professional move is to identify the defect precisely, name the objects involved, and return it to whoever owns that domain โ€” synthesis owns the netlist structure, the library team owns library releases, architecture/verification owns interface and mode intent.
  • This connects directly to the other "readiness check" questions in this set (stale objects, missing scenarios) โ€” recognizing "this isn't mine to fix" is a distinct, valuable PD skill, separate from actually knowing how to fix downstream problems.
  • Returning a handoff isn't a failure or a delay tactic โ€” it's the correct outcome when the alternative is a local patch that hides a defect until it resurfaces worse, later, somewhere harder to trace.

What To Check

  • Warning sign: A local edit silences the tool but creates a fork from synthesis or STA signoff intent.
  • Inspect: Keep at least two possible causes open, then use one named object and the active mode or scenario to separate them.
  • Correct: Package the smallest reproducer, exact objects, commands, logs, and expected-versus-actual evidence for the owner.

Command Checks & Actions

  • current_block: confirms the active design block
  • check_netlist: reports structural connectivity problems
  • check_timing: finds missing or inconsistent timing setup

Run the commands in order. Each line answers a separate part of the check.

Healthy, Suspicious & Hard-stop Results

  • Expected: Return defects in functional connectivity, synthesis structure, library release, interface timing intent, or mode definitions to their authoritative owner.
  • 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

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.

See what's inside the bundle
PnR Flow Physical Design Mentor Guide โ€” eight chaptersPnR Flow Mentor GuideEight chapters, library setup through to stream-out.