Macros overlap or extend outside the parent boundary after refinement. What is the correct debug path?
From PDVerse PnR Interview Handbook, part of the pdVerse Mentor Guide
Short Answer
Whatever overlap or out-of-bounds condition you see visually is just the symptom — the actual bug is whichever constraint or transformation caused it, and debugging means finding that cause, not just nudging the macro back inside the boundary. Work systematically through the likely causes: stale constraints left over from an earlier floorplan iteration, a macro's fixed/movable status being wrong, orientation-dependent dimensions changing after a rotate/mirror, an unintended snap movement, a relative-location constraint pulling it out of place, a voltage-area conflict, or simply having loaded the wrong floorplan version.
Technical Explanation
- Use the pre-macro-placement checks and floorplan rules to identify the exact objects and constraints involved, then compare their recorded constraints against their actual current coordinates — the mismatch between "what the constraint says" and "where the macro actually is" is where the bug lives.
- Manually moving the macro back inside the boundary without finding the root cause just sets up a repeat of the same failure the next time refinement runs.
- This is the same "symptom vs. cause" debugging discipline that shows up across several of the expert-level questions in this set — always trace back to the owning constraint or transformation, not just the visible geometry problem.
Formula Or Decision Rule
Decision rule: no required macro or voltage area overlaps or leaves its legal parent region.
What To Check
- Warning sign: Objects are moved locally while the stale constraint recreates the violation later.
- Inspect: choose one affected region, macro, row, pin, path, or net and trace the physical cause.
- Correct: Correct the owning constraint or geometry, regenerate placement, and rerun from a clean checkpoint.
Command Checks & Actions
check_design-checks {dp_pre_macro_placement}: runs named design-planning check groups- check_floorplan_rules -objects <macro_collection>: reports configured floorplan-rule violations
Run only the commands needed for this question. Save the report with the floorplan version and analysis context.
Healthy, Suspicious & Hard-stop Results
- Healthy: Check stale constraints, fixed status, orientation-dependent dimensions, snap movement, relative-location constraints, voltage areas, and which floorplan version was loaded.
- Hard stop: required legality or physical feasibility is missing or unexplained.
Common Mistake
The Trap: Do not hide the symptom with an arbitrary utilisation, halo, channel, blockage, pin move, or die-size change.
What The Interviewer Is Testing
The interviewer is testing whether you can connect “Macros overlap or extend outside the parent boundary after refinement. ” to measurable physical evidence and an owned correction.
Follow-up Question & Model Response
"* Candidate Model Response: Model response: “I would change it if the same controlled rerun shows that objects are moved locally while the stale constraint recreates the violation later. ”
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