What should a reproducible floorplan evidence package contain?
From PDVerse PnR Interview Handbook, part of the pdVerse Mentor Guide
Last updated:
Short Answer
The goal of this package is simple to state and easy to get wrong in practice: another engineer, with no other context, should be able to recreate the exact same physical state and understand why every decision was made. Cover both provenance and content — the exact input files and tool version used, the area assumptions behind the floorplan, the boundaries, rows/sites/tracks, macro and pin constraints, voltage areas, and every keepout/blockage placed.
Technical Explanation
- Include the reports and check results that validated the floorplan at the time, plus images of the layout state, any waivers granted, and a write-out of the design that reloads cleanly without manual patching.
- Keep reports in separate files per check rather than one giant dump, and preserve object names, tool versions, active scenarios, the exact command options used, and the measurement settings applied — these details are what actually let someone reproduce the run, not just the final numbers.
- Treat this package the way you'd treat a lab notebook for a regulated experiment — the discipline of writing it down is what protects you when someone asks "why does the floorplan look like this" six months later.
Formula Or Decision Rule
Decision rule: reopen the written floorplan from the approved checkpoint and reproduce key counts and checks.
What To Check
- Warning sign: Only a screenshot or manually edited checkpoint exists.
- Inspect: choose one affected region, macro, row, pin, path, or net and trace the physical cause.
- Correct: Write the floorplan, archive reports, reload it, and compare the same readiness matrix.
Command Checks & Actions
write_floorplan-output <output_dir>: writes reproducible floorplan information to filesreport_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: Include input and tool provenance, area assumptions, boundaries, rows/sites/tracks, macro and pin constraints, voltage areas, keepouts/blockages, reports, check results, images, waivers, and a write-out that reloads cleanly.
- 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
” 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 only a screenshot or manually edited checkpoint exists. ”
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