In short: Macro placement fixes large hard IP (SRAMs, PLLs, analog blocks) early in floorplan so that pins face the logic that drives them, with halos and keep-outs reserving routing and buffer space — a good macro layout turns into clean channels, short flylines, and timing that closes; a bad one strands routing resources and forces hold/setup grief that no amount of CTS can undo.
Macro placement is one of the highest-leverage decisions in physical design. A handful of large rectangles, placed in the first hours of a block's implementation, decide whether the standard-cell router has room to breathe and whether critical paths stay short enough to meet timing at the target frequency. Get it wrong and you pay for it through every downstream stage. This article walks through flylines, keep-outs, halos, the channel-versus-abutted trade-off, and how each choice ripples into routing and timing.
What counts as a macro, and why place it first
Macros are pre-hardened, fixed-size instances the place-and-route tool cannot decompose: compiled memories (single/dual-port SRAM, register files), PLLs and clock generators, analog/mixed-signal IP, SerDes, and hardened CPU or accelerator subsystems. In a modern SoC block a memory-heavy design can be 40-70% macro area, so these blocks dominate the floorplan. Because they are large and immovable once legalized, you place them before detailed standard-cell placement — this is the heart of floorplanning. Tools like Cadence Innovus, Synopsys IC Compiler II, and Siemens Aprisa all treat macro placement as a distinct, human-guided (or semi-automatic) step that precedes place_opt.
Flylines: letting connectivity drive position
A flyline is a straight rubber-band line the GUI draws from a macro pin to the centroid of the logic (or other macros) it connects to. Flylines are not real wires — they visualize net connectivity weighted by pin count. The guiding principle: orient and position each macro so its heavily-connected pins face the cells that drive or sense them. If a 32-bit data bus leaves an SRAM on its east edge but the consuming datapath sits to the west, every one of those 32 nets detours around the macro, inflating wirelength and delay.
Rule of thumb: push macros to the block boundary and leave the center open for standard cells. Memories hugging the core edge free a contiguous placement region and keep clock and data nets from crossing the die center twice.
Halo (keep-out margin) and placement blockages
A halo — Cadence calls it a halo, Synopsys a keepout margin — is a ring around a macro where standard cells are forbidden. It does two jobs: it reserves routing track access to the macro's pins (cells placed flush against the pins would block the very layers the router needs), and it gives room for spare buffers, decap, and well/implant spacing required by the macro's abutment rules. A typical halo for a mid-size SRAM is 3-8 standard-cell rows (roughly 5-15 µm on a 7-16 nm node), tuned to pin density.
Keep-outs come in flavors you should distinguish: a hard placement blockage forbids all cells; a soft blockage lets the optimizer place but not during coarse placement; a partial blockage caps density (e.g., 40%) so some buffers can still sit there. Corner keep-outs at the notches between stepped macros stop the router from trapping cells in dead-end pockets.
Channel vs. abutted placement
When two macros sit side by side you choose between leaving a channel (a routing gap) or abutting them (edges touching, halos overlapping into a shared keep-out).
| Aspect | Channel placement | Abutted placement |
|---|---|---|
| Area | Costs die area for the gap | Densest; best area |
| Routing | Channel carries feedthrough + power straps | Must route over the macro or around the pair |
| Power | Easy to drop PG straps in the channel | Relies on macro-internal rails lining up |
| Risk | Wasted space if channel too wide | Pin access + DRC pinch if too tight |
Sizing a channel is a real calculation, not a guess: estimate the nets crossing it, divide by the usable tracks per layer, and add margin for power straps and vias. A channel sized for 60 nets on two routing layers at, say, 48 tracks each will choke if 90 feedthroughs actually appear — you see it as congestion hotspots in the early global-route (trialRoute) report. Abut only macros whose facing edges have no pins (back-to-back SRAM instances are the classic case) and whose power rails align.
Watching placement come alive: iterative legalization
In practice you iterate: place by flylines, legalize, run a quick global route and a pre-CTS timing estimate, read the congestion map, nudge, repeat. Synopsys IC Compiler II's create_placement -floorplan and Innovus' place_design -concurrent_macros can automate the first pass, but experienced engineers still hand-tune memory arrays — automation rarely matches a human who understands the dataflow.
Impact on routing and timing
Everything above exists to serve two downstream realities. Routing: macros are opaque to most signal layers (only their top metal or pins are usable), so a macro is effectively a routing blockage. Poor placement creates "routing shadows" and forces detours that burn wirelength; congestion then shows up as unroutable hotspots in detailed route. Timing: wirelength is delay. A critical net that must snake around a badly oriented SRAM might add 300-500 µm of wire, translating to tens or hundreds of picoseconds of RC delay — enough to miss setup at 1-2 GHz. Macro position also sets where clock-tree leaves land, so sprawled memories inflate clock skew and insertion delay, which CTS cannot fully repair.
A macro pin facing the wrong way can add a double-detour: the net goes around the macro on the way in and again on the way out. On a timing-critical bus that single orientation mistake has sunk more than one tapeout schedule.
Teams building production RTL-to-GDS flows — the kind taught in hands-on programs at ChipXpert's VLSI training — treat macro placement as a timing exercise disguised as a geometry exercise. If you want deeper practice, our placement and routing guide picks up where this one ends.
Ready to run a real macro floorplan in Innovus and IC Compiler II? The CourseTron Physical Design course puts you on industry EDA tools with memory-heavy blocks from day one.
Frequently asked questions
What is the difference between a halo and a keep-out?
They overlap heavily. A halo is specifically the margin attached to a macro that moves with it; a keep-out (placement blockage) can be any region you declare off-limits, attached to a macro or standing alone. In most flows the macro halo is implemented as a hard placement blockage ring, so engineers use the terms interchangeably in casual speech.
How wide should a routing channel between two macros be?
Size it from net count: estimate feedthrough nets plus power straps, divide by usable tracks per layer across your routing layers, and add ~20-30% margin. A too-narrow channel causes DRC pinch and congestion; a too-wide one wastes area. Validate with an early global-route congestion report before committing.
When should I abut macros instead of leaving a channel?
Abut when the facing edges have no pins (back-to-back memory instances), the power rails align, and you need the area. Never abut pin-bearing edges — the router loses access and you invite pin-access DRC violations.
Why does macro placement affect timing so much if it happens before CTS?
Because macro position fixes wirelength for the nets touching them, and wire RC is delay. It also fixes where clock-tree leaves must reach, setting a floor on skew and insertion delay. CTS and optimization can buffer and resize, but they cannot shorten a path that geometry forces to be long.