What should an initial floorplan input contain?
From PDVerse PnR Interview Handbook, part of the pdVerse Mentor Guide
Short Answer
Think of the initial floorplan DEF/script as the physical envelope and ground rules that everything downstream (placement, routing) has to operate inside — it's the "site plan" before any construction begins. Typical contents: die and core geometry, legal standard-cell rows and sites, the routing track grid, macro positions and orientations, port/pin locations, and any relevant placement or routing blockages.
Technical Explanation
- Think of the initial floorplan DEF/script as the physical envelope and ground rules that everything downstream (placement, routing) has to operate inside — it's the "site plan" before any construction begins.
- Typical contents: die and core geometry, legal standard-cell rows and sites, the routing track grid, macro positions and orientations, port/pin locations, and any relevant placement or routing blockages.
- Don't assume one DEF file captures everything — voltage areas, macro keepouts, placement bounds, and power-planning constraints are often carried through separate mechanisms, not bundled into the same file.
- Get the terminology straight: die area is the overall chip or block boundary; core area is the region actually intended for implementation; rows define the legal grid where standard cells can sit; tracks define the routing grid. These are related but distinct pieces of information.
- Macro orientation matters more than it looks — flipping or rotating a macro moves its pins and can change its access to the power/ground network, so orientation isn't a cosmetic detail.
- Placement blockages and routing blockages restrict entirely different resources and are not interchangeable — a region blocked for placement doesn't automatically block routing, and vice versa.
- Here's the practical gotcha in ICC2 specifically:
read_defis incremental by default. Some single-valued constraints get overwritten by a new read, while some geometry accumulates instead of replacing. That means reading a new revision of a DEF is not automatically a clean replacement of old floorplan intent — decide deliberately whether you want to merge or fully replace, and verify the result rather than assuming.
Command Checks & Actions
read_def -syntax_only block.defPerforms a check-only validation of the DEF before committing it to the design, catching structural problems in the floorplan file itself before they become design-state problems.
read_def block.defImports placement area, port locations, cell locations, blockages, site rows, and routing tracks from the floorplan DEF -- the actual list of what a floorplan input needs to contain.
check_duplicates -removeConfirms no duplicate shapes or vias exist in the design after reading the floorplan, a cleanup check specifically recommended after a DEF import.
Common Mistake
The Trap: Equating utilization with total die area occupancy without stating which areas and exclusions are used.
Follow-up Question & Model Response
"What if no DEF is supplied?"
Candidate Model Response: Create and validate a floorplan from approved physical requirements; a pre-existing DEF is not mandatory for every new design.
Practical Example
Tapeout Scenario: A memory placed flush against a port edge may leave insufficient channel space for its signal pins. The file can be syntactically valid yet create a routability problem that should be corrected before detailed placement.
PnR Flow Mentor Guide
Master the Physical Design Implementation Flow
Read the complete 8-chapter PnR Flow Mentor Guide free on the web — library setup through placement, clock tree synthesis, routing, chip finishing, hierarchical implementation, and ECO, all the way to stream-out.
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