What should a reproducible floorplan evidence package contain?
From PDVerse PnR Interview Handbook, part of the pdVerse Mentor Guide
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