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
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