A macro array is legal, but its allowed orientations create pin-access failure. How do you respond?
From PDVerse PnR Interview Handbook, part of the pdVerse Mentor Guide
Last updated:
Short Answer
Legality defines the space of allowed solutions (which orientations, which spacings are geometrically valid) — it doesn't guarantee every point in that space is actually routable, and a macro array is a classic place this bites you. Never force an illegal orientation just to fix pin access — that trades one hard failure (geometry/legality) for a different kind of hard failure that's equally unacceptable.
Technical Explanation
- Instead, systematically explore what's already inside the legal solution space: try each allowed orientation, adjust macro-to-macro spacing, try staggering the array instead of a strict grid, change the array insertion order, adjust which sides face each other (pin-facing strategy), and check what routing layers are available in the surrounding channels.
- Consider compiler symmetry and macro-level constraints together — some orientations that look identical geometrically can produce very different pin-access outcomes depending on which side of each macro faces its neighbor.
- Check corner access and PG pin conflicts specifically at array corners — this is where congestion and access problems concentrate in dense arrays, similar to macro-corner congestion in a single-macro floorplan.
- If access remains genuinely impossible after exhausting the legal combinations, that's the signal to change the array geometry itself (spacing, count, aspect ratio) — not to break legality rules. Legality exists for a reason (manufacturability, DRC), and no pin-access convenience justifies violating it.
Formula Or Decision Rule
Decision rule: the array proceeds only when an allowed orientation set has credible access.
What To Check
- Warning sign: A mirrored orientation is used even though the library disallows it.
- Inspect: choose one affected region, macro, row, pin, path, or net and trace the physical cause.
- Correct: Rework array order, spacing, or location and rerun macro and pin checks.
Command Checks & Actions
- set_macro_constraints -allowed_orientations <orientation_list> <macro_collection>: records allowed macro or I/O placement constraints
check_design-checks {dp_pre_macro_placement}: runs named design-planning check groups- check_pin_placement: checks pin-placement legality and access-related conditions
Run only the commands needed for this question. Save the report with the floorplan version and analysis context.
Healthy, Suspicious & Hard-stop Results
- Healthy: Do not force an illegal orientation. Test legal orientations, spacing, staggering, array order, pin-facing strategy, and surrounding routing layers; then change the array geometry if access remains impossible.
- 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 “A macro array is legal, but its allowed orientations create pin-access failure. ” 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 a mirrored orientation is used even though the library disallows it. ”
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