Floorplanning Overview
Floorplanning is the foundational stage of any physical design flow. It’s often called the art of ASIC layout because it directly shapes how well the chip will perform in terms of timing, area, power, and routing efficiency.
A well-planned floorplan leads to:
- ✅ Higher performance
- ✅ Better routability
- ✅ Reduced IR drop and congestion
- ✅ Optimized die area
Floorplanning focuses on key decisions like:
- 📍 Placement of IO pads and macros
- 📏 Defining the core area and utilization
- ⚡ Planning power delivery with rings and straps
- 🚧 Reserving space using keep-out zones and blockages
✅ Inputs Required Before Floorplanning
| 📁 Input Type | Description |
|---|---|
| 🧩 Netlist (.v) | Gate-level netlist from synthesis |
| 🧱 Tech File (.techlef) | Design rules and metal layer definitions |
| ⏱ Timing Libraries (.lib) | Cell delay, setup/hold, timing arcs |
| 📐 Physical Library (.lef) | Cell dimensions, pin locations, blockages |
| 📏 Constraints (.sdc) | Clock definitions, IO timing constraints |
| ⚡ TLU+ Files | RC parasitic models for extraction |
Blueprint-Style Visual Layout
🧱 Macro & Hard IP Placement
Explore how macro alignment, symmetry, and pin accessibility affect the quality of your layout.
Symmetry and Alignment
Place macros symmetrically to maintain timing balance and avoid layout imbalances.
Pin Accessibility
Ensure pins are reachable. Avoid corners where routing is tight and indirect.
Keep-Out Margins
Reserve spacing for buffers, decap cells, and routing tracks around macros.
Avoid Congestion Hotspots
Distribute macros evenly. Prevent choke points and heat zones.
Macro Orientation Rules
Follow orientation rules (R0, MX, MY) for legal and optimal placement.
🧠 Floorplanning: Key Interview Concepts
Q: How can you say the floorplan is good?
A: A good floorplan should meet the following constraints:
- ✅ Minimize total chip area
- ✅ Make routing easy and congestion-free
- ✅ Satisfy timing and power delivery constraints
Q1: What is floorplanning? How can you say that your floorplan is good?
Q2: What are the inputs and outputs of the floorplan stage?
Q3: What are the floorplan control parameters?
Q4: How will you determine the distance between two macros?
Q5: What are the guidelines for placing macros?
Q6: What are the key steps that must be considered during floorplanning?
Q7: What issues can arise from a poor floorplan?
Q8: How can you estimate the area of a block?
Q9: How do you decide pin location in block-level design?
Q10: What are blockages, halos, and keep-out margins?
Common Tools
- Synopsys ICC2 / Fusion Compiler
- Cadence Innovus
- Mentor Olympus-SoC
🧠 Real-Time Floorplanning Challenges
🔧 Macro Orientation Caused Routing Congestion
Problem: I placed two SRAM macros close together to save wirelength. But during trial route and congestion analysis, a red hotspot appeared between them. The congestion map showed routing tracks were heavily blocked in that region.
Why It Happened: I didn’t account for the macro pins facing each other. The pins were located on the inner edges, which meant all the standard cells routed between them were trying to access tight pin locations from both sides — leading to severe congestion.
How I Solved It: I opened the congestion map view in Innovus and noticed that >90% of available tracks were being used near that area. I rotated one macro 180° so both macros had pins facing outward. Then I added a 5µm physical-only blockage between them. This gave the router more open channels. I validated the fix by re-running global route and checking congestion overlays. My mentor also suggested checking pin accessibility via report_pin_accessibility. The fix reduced congestion significantly.
🔧 IR Drop Issues in Corner Standard Cells
Problem: After initial power planning, the IR drop report showed that some standard cells in the chip’s corners had voltages dropping below the allowed limit. It was confusing, because power straps looked evenly distributed.
Why It Happened: The corners were isolated from primary straps due to routing blockages, and via drops were higher in those zones. Also, tap cells and filler rows didn’t get proper power routing in those edges.
How I Solved It: I ran EM/IR analysis using Voltus and overlaid the IR drop map. With help from the power engineer, I found the corner vias were underutilized. I manually inserted wider VDD/VSS straps in corners using create_power_straps -nets {VDD VSS} and increased via count using add_via_array. I also disabled routing blockages temporarily to allow power net extension. After rechecking IR, all cells were now within the voltage spec. Lesson: corners often get neglected in uniform grid planning — they need special attention.
🔧 Clock Port Misplacement Affected Skew
Problem: During CTS, one of the clock groups showed huge insertion delay (~1200ps) from the clock port to the leaf cells. The skew was above 500ps, which violated constraints.
Why It Happened: The clock port was placed near the IO corner and far from the central clock spine. The buffers inserted couldn’t balance the long route to multiple sequential cells.
How I Solved It: I analyzed the timing path using report_clock_tree and traced the clock net on the layout viewer. I saw that the port was too far from any other sink. I moved the port closer to the core and aligned it along the main horizontal strap. After that, I re-ran CTS using create_clock_tree_spec and saw delay reduced to 300ps and skew under 100ps. My senior explained that early-stage port placement directly affects CTS QoR — this was a valuable learning.
🔧 88% Core Utilization Created Legalization Problems
Problem: We initially set the block utilization to 88% to meet tight area targets. But during placement and timing ECO, it became a nightmare — the tool couldn’t find legal sites to insert buffers, and hold violations increased.
Why It Happened: Too little whitespace meant no margin for buffer insertion, spare cell usage, or legal cell swaps. Even filler cells had trouble fitting in narrow gaps.
How I Solved It: After discussing with my mentor, we reduced the floorplan utilization to 75%. In Innovus, I adjusted the core area using edit_core_area and redefined row utilization via floorplan -core_util 0.75. I also inserted dedicated filler and spare cell rows between macro islands. The placement tools now had room to move, and hold buffer insertion succeeded. This experience taught me that core utilization must balance timing flexibility, not just die size.
🔧 Forgot Keepout Margin Around Macros
Problem: Standard cells were getting placed right next to macros, and later in the flow, I got placement DRCs and pin accessibility issues.
Why It Happened: I didn’t set any keepout margins — areas where no other cells should be placed near macros. The router couldn’t access some macro pins due to blockage from standard cells.
How I Solved It: I created a physical-only blockage around each macro using create_placement_blockage -type soft -bbox. I also applied 5µm margin on all four sides, depending on pin locations. After this, standard cells were automatically restricted from overlapping. The DRCs vanished. My mentor emphasized this is a must for every macro with tight pin density.
🔧 Wrong Use of Routing Blockage Caused Legalization Failures
Problem: Legalization failed in one region with a strange tool error — “no legal site for placement.” I was confused because the floorplan looked empty in that zone.
Why It Happened: I had accidentally applied routing blockages instead of placement blockages. The tool thought it could place cells, but during legalization, it found those locations were invalid for standard cells.
How I Solved It: I opened the blockage view and found I had set create_routing_blockage instead of create_placement_blockage -type hard. I corrected it and also marked the macro top and bottom rows as “unplaceable”. After that, legalization worked. I learned that every blockage has a purpose — and it’s important to label them right, or tools will act unexpectedly.
🔧 Missing Tie Cells Raised Functional Warnings
Problem: Post-placement DRC showed floating logic inputs, with warnings saying "missing tie-high" and "tie-low cell not defined". I hadn’t added any of these cells.
Why It Happened: Some nets in the netlist were tied to constant 1 or 0 — but not using proper cells. This creates unreliable voltage and could lead to functional bugs.
How I Solved It: I checked the netlist and marked which nets were constant-driven. I then inserted tie-high and tie-low cells from the standard cell library using add_tie_cell commands in the floorplan phase. I also grouped these cells into special tie cell rows to avoid placement near clocks. After that, re-running DRC gave a clean pass.p>