Floorplanning & Power Planning

The first physical-design step decides the chip's shape and the fate of everything after it. Learn die and core sizing, utilization and aspect ratio, IO ring and pad placement, macro placement rules, blockages and halos, power-grid design (rings, straps, rails), voltage areas, and how floorplan quality drives timing, congestion and IR drop.

After synthesis you have a netlist: millions of cells and a few big macros (SRAMs, PLLs, analog blocks). Floorplanning decides how big the chip is, where the IOs go, where the macros sit, and how power is delivered — before a single standard cell is placed.

A good floorplan leaves room for routing, keeps connected blocks close, and gives every cell a low-resistance path to VDD and VSS. A bad one causes congestion and timing failures that no later step can fix.

An analogy

Floorplanning a chip is like planning a city: decide its boundary, place the big buildings (macros) near the roads they use, leave space for streets (routing), and lay out the power lines before building houses (standard cells).

Die, core and IO

The die is the whole piece of silicon; the core is the inner region where logic lives; the IO ring (or area-array bumps for flip-chip) connects to the package. Standard cells sit in rows of fixed height inside the core, alternating VDD and VSS rails.

Macro placement rules

Good macro placement follows data flow and leaves routing channels:

Power planning

Every cell needs low-resistance access to VDD/VSS. The power delivery network (PDN) is a mesh: a core ring, wide vertical and horizontal straps on thick upper metals, and thin rails on metal1 in each row, all connected with via stacks. Denser straps reduce IR drop and electromigration risk but consume routing tracks.

Hierarchy, voltage areas and early analysis

Large SoCs are floorplanned hierarchically: partitions become separate blocks with pin assignment and timing budgets. Power domains from UPF become voltage areas with their own switches and level shifters. Early prototype placement, congestion maps and static IR analysis validate the floorplan before committing.

Formulas

Worked example: Core sizing

Given: Cells 1.60 mm², macros 0.40 mm², U = 0.70

Find: Core side.

Answer: 1.639 × 1.639 mm

Worked example: Aspect ratio

Given: A_core = 2.686 mm², AR = 0.5

Find: Width and height.

Answer: 2.318 mm × 1.159 mm

Worked example: Dies per wafer

Given: 300 mm wafer, 3.0 mm² die (incl. scribe)

Find: Gross dies.

Answer: ≈ 23 177 dies

Sizing the core and die from synthesis area

import math

std_cell_area = 1.60      # mm^2 (from synthesis)
macro_area    = 0.40      # mm^2 (SRAMs)
utilization   = 0.70      # target standard-cell utilization
core_margin   = 0.05      # mm between core and die edge (IO ring excluded)

core = macro_area + std_cell_area / utilization
side = math.sqrt(core)
die = (side + 2 * core_margin) ** 2
print(f"core area {core:.3f} mm^2 -> {side:.3f} x {side:.3f} mm")
print(f"die area  {die:.3f} mm^2 (aspect ratio 1.0)")
for ar in (0.5, 2.0):
    w = math.sqrt(core / ar)
    print(f"aspect ratio {ar}: {w:.3f} mm wide x {w*ar:.3f} mm tall")
# core area 2.686 mm^2 -> 1.639 x 1.639 mm
# die area  3.023 mm^2 (aspect ratio 1.0)
# aspect ratio 0.5: 2.318 mm wide x 1.159 mm tall
# aspect ratio 2.0: 1.159 mm wide x 2.318 mm tall

70% utilization leaves 30% of the core for buffers inserted later, clock tree cells, and routing resources. Pushing utilization higher saves area but risks congestion.

Floorplan and power grid commands (OpenROAD-style Tcl, illustrative)

# Core 1.64 x 1.64 mm with 50 um margin, rows snapped to the site
initialize_floorplan -die_area  "0 0 1740 1740" \
                     -core_area "50 50 1690 1690" -site core_site
place_pins -hor_layers metal3 -ver_layers metal2      ;# IO pins around the edge

# Macros along the edges, pins facing the core, with halos
place_macro -macro_name u_sram0 -location {80 80}   -orientation R0
place_macro -macro_name u_sram1 -location {80 1200} -orientation MX
set_macro_extension 10                                  ;# 10 um halo

# Power grid: rails on metal1, vertical straps on metal4, horizontal on metal5
add_global_connection -net VDD -pin_pattern {^VDD$} -power
add_global_connection -net VSS -pin_pattern {^VSS$} -ground
define_pdn_grid -name core
add_pdn_stripe  -grid core -layer metal1 -width 0.17 -followpins
add_pdn_stripe  -grid core -layer metal4 -width 2.0 -pitch 50 -offset 10
add_pdn_stripe  -grid core -layer metal5 -width 2.0 -pitch 50 -offset 10
add_pdn_ring    -grid core -layers {metal4 metal5} -widths 5 -spacings 2 -core_offsets 4
pdngen

Illustrative commands in the style of OpenROAD (used by the open-source OpenLane flow); commercial tools (Innovus, ICC2) have equivalent commands. Layer names and sizes depend on the PDK.

Common mistakes

Applications

Key takeaways

Going further