Skip to content

Floorplanning

Richard Huang edited this page Aug 3, 2026 · 2 revisions

Floorplanning

Floorplanning is where the netlist becomes geometry. It fixes the die and core size, places the hard macros, assigns boundary pins, and reserves space for power and routing. Everything downstream — Placement, Clock Tree Synthesis, Routing, Timing Closure — optimizes inside the box floorplanning draws.

Rule of thumb: most of a block's final quality is decided before a single standard cell is placed. Optimization engines work within the floorplan; they cannot undo it.


Objectives

  • Performance — keep timing-critical connections physically short
  • Power — short wires mean less switching capacitance
  • Area — hit target utilization without wasting silicon between macros
  • Congestion — leave enough routing resource everywhere, not just on average
  • Reliability — avoid current hotspots that become IR drop problems

Where It Fits

flowchart LR
    A[Synthesis<br/>Genus] --> B[Floorplanning]
    B --> C[Power Planning]
    C --> D[Placement]
    D --> E[CTS]
    E --> F[Routing]
    style B fill:#2d6a9f,color:#fff
Loading

Before: a gate-level netlist and Design Constraints. After: a DEF that Power Planning builds the grid into.


Key Concepts

Concept What it is Why it matters
Die vs. core Die includes seal ring and pads; core is where cells go The gap between them holds the power ring — budget it or re-floorplan later
Utilization (cell area + macro area) / core area Start at 65–70%; above ~85% most designs stop routing
Aspect ratio core height / width Square minimizes worst-case internal distance; stay near 1.0 unless integration forces otherwise
Macro placement Position + orientation of SRAMs and IP The highest-leverage decision in the whole flow
Halo Keepout margin around a macro Reserves room for pins to escape; size in routing tracks (~10–20), not microns
Blockage Region where cells can't be placed Use partial (density cap) far more often than hard
Region / fence Binds cells to an area Fences are required for power domains; guides are advisory

Why Wire Length Dominates

An unbuffered wire's delay grows with the square of its length. Adding repeaters makes it linear — but linear with a real cost in area, leakage, and power.

So: buffering converts a bad wire into an expensive wire. It never makes it a short one. This is why moving two macros closer together beats any amount of downstream optimization.

This is worse in FinFET nodes, where lower-metal resistance has scaled badly and local interconnect delay now rivals gate delay.


Macro Placement Guidelines

  • Orient before you position. Decide which edge the pins must face, then pick coordinates. An SRAM feeding a compute array should have its data pins facing that array.
  • Follow the dataflow. If A feeds B, put A next to B. Make the block diagram literally true in geometry.
  • Keep channels binary. A gap between macros is either wide enough to be useful (≥ 20–30 routing tracks) or blocked entirely. Never leave an accidental thin strip.
  • Stagger, don't grid. Aligned macro corners funnel routing into hotspots.
  • Script it. Your netlist will change many times. A GUI-placed floorplan has to be redone by hand every time; a parameterized script regenerates in seconds.

Cadence Innovus Flow

Innovus needs -stylus for Common UI (unlike Genus, where it's the default):

# 1. Import
read_mmmc mmmc.tcl                          ;# modes × corners for timing
read_physical -lef {tech.lef sram.lef}      ;# layers, rules, cell abstracts
read_netlist design.mapped.v                ;# from Genus
init_design

# 2. Define the box
create_floorplan -core_density_size 0.70 1.0 40 40 40 40
#                                 util  AR  L  B  R  T (microns)

# 3. Place macros
place_inst u_kv_sram_0 {120.0 340.0} R0 -fixed
create_place_halo -insts u_kv_sram_0 -halo_deltas {10 10 10 10}

# 4. Soften congestion
create_place_blockage -area {700 200 900 400} -type partial -density 40

# 5. Pins
edit_pin -pin {data_out[*]} -side North -layer {M4 M5} -fixed_pin

# 6. Evaluate — this loop is the actual work
place_design -prototype
route_design -global_detail
report_congestion -hotspot
report_timing -max_paths 20

# 7. Save
write_def -floorplan -io floorplan.def

Iterate steps 2–6 until congestion is clean. A floorplan is never right the first time.


Inputs and Outputs

Inputs Outputs
Gate-level netlist (Genus) Floorplan DEF
Technology LEF (layers, rules) Innovus database (.enc)
Cell LEF (macro/cell abstracts) Congestion map
Liberty .lib (timing, power) Prototype timing report
SDC (Design Constraints) Macro placement report
MMMC views, RC corners Pin locations for the parent level
UPF (power intent) Utilization / area summary

No SPEF yet — nothing is routed, so floorplan timing uses estimated parasitics. Treat it as directional, not authoritative.


Metrics

Metric Target If it's bad
Core utilization 65–70% initial, 75–85% final Shrink logic, re-bank SRAM, or grow the die
Global route overflow ~0% with no hotspots Spread macros, add partial blockages
WNS Within 10–20% of target at floorplan Move macros on the critical path closer
Macro area fraction 30–60% for memory-heavy blocks Re-bank into fewer, larger instances
Aspect ratio 0.8–1.25 Extremes hurt CTS skew and routing

Common Problems

Problem Root cause Fix
Congestion at macro corners Routing detours converge there Enlarge halo, rotate macro, stagger corners
Cells stranded in a thin channel Accidental narrow gap Widen to ≥ 20 tracks or block it entirely
Long detours on memory paths Pins face the wrong way Change orientation (MX / MY / R90)
Doesn't fit the die Optimistic synthesis area estimate Escalate to architecture early — this is a real finding
Floorplan breaks after RTL change Macros hand-placed by name Regenerate from a parameterized script

Best Practices

  • Start looser than you think you need — tightening is easy, discovering unroutability at detail route is not
  • Review congestion maps, not congestion averages; averages hide the failures
  • Re-run prototype timing after every change; revert anything that makes the top path worse
  • Remember Power Planning will consume routing resource you haven't spent yet
  • Version-control the script, not just the DEF
  • Set a floorplan freeze milestone and defend it

See also: Design Constraints · Power Planning · Placement · Physical Design

Clone this wiki locally