initialize_floorplan produces an invalid or unexpected boundary. What do you check?
From PDVerse PnR Interview Handbook, part of the pdVerse Mentor Guide
Short Answer
initialize_floorplan has several ways to describe the outline (fixed size, aspect ratio + utilization, explicit boundary points), and mixing incompatible assumptions across these options is the single most common cause of a surprising result. Check the control type first — are you specifying a fixed die size, a target utilization + aspect ratio, or explicit polygon coordinates? Each interprets the same numbers completely differently.
Technical Explanation
- g. "square die") versus what was actually computed — a ratio-based specification can produce a very different rectangle than you pictured if the underlying area assumption was off.
- Check boundary points directly if you passed explicit coordinates — a single misplaced coordinate or an unclosed polygon can silently produce an unexpected shape.
- Verify orientation and offsets — a flipped or rotated boundary spec, or an unaccounted-for offset, can shift the entire floorplan relative to where you expected it.
- Check whether retained objects (from an existing floorplan you didn't intend to fully reset) or the site definition itself are influencing the result — an old boundary that was intentionally (or accidentally) preserved from a previous run is a very common silent cause.
- Compare the requested geometry against
report_design, row creation results, grid snapping, and any imported physical constraints — and always verify units before recalculating by hand, since a unit mismatch alone can produce a boundary that's off by a large, obvious-looking factor.
Formula Or Decision Rule
Decision rule: boundary and core dimensions must match the documented calculation after legal snapping.
What To Check
- Warning sign: The command is rerun repeatedly with guessed offsets.
- Inspect: choose one affected region, macro, row, pin, path, or net and trace the physical cause.
- Correct: Return to one declared geometry method, clear conflicting assumptions, regenerate, and report.
Command Checks & Actions
initialize_floorplan-control_type <core_or_die> -shape R -side_length {<side_a> <side_b>} -core_offset <offset>: creates the initial die, core, rows or site array, and tracks from declared controlsreport_design-floorplan: reports the floorplan state understood by the tool
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 control type, shape, side lengths or ratios, boundary points, orientation, offsets, retained objects, site definition, and whether an old boundary was intentionally kept.
- 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 “initialize_floorplan produces an invalid or unexpected boundary. ” 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 the command is rerun repeatedly with guessed offsets. ”
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