Macro Placement in VLSI: Guidelines, Halos, Channels and Debug

Most blocks today contain memories, register files, analog IP or other hard macros, and those macros often take up a third to more than half of the core. Macro placement decides where these large fixed blocks sit, how they face, and how much space is left between them. Because macros cannot be resized or moved later without restarting much of the flow, macro placement sets the limits for everything that follows: power planning, standard cell placement, clock tree synthesis, routing and timing closure.

This guide explains macro placement from a physical design point of view: what a good placement has to achieve, the classic guidelines and why they work, halos, channels and blockages, how to size a channel, how tools place macros automatically, which checks to run and how to debug a poor placement. All numbers in the worked examples are illustrative, chosen to show the method, not taken from any foundry, library or project. Real track pitches, halo sizes and spacing rules come from your technology files, macro LEF and PDK documentation. Command snippets are simplified sketches, not complete scripts. Related reading on iVLSI: Floorplan, Blockages in VLSI, Power Planning in VLSI, Routing Congestion in VLSI and Physical-Only Cells in VLSI.

What is a macro?#

In physical design, a macro is any pre-built block that the place-and-route tool treats as a single fixed instance rather than as standard cells it can size and move freely. Typical examples are SRAMs and register files, ROMs, PLLs, analog or mixed-signal IP, and hardened sub-blocks.

The tool sees a hard macro through its LEF abstract (size, pins, obstructions on each metal layer, and sometimes allowed orientations) and its .lib timing model. You can move, rotate and mirror a hard macro, but you cannot change anything inside it. See LEF and Timing Library (.lib) for the details of those views.

Soft macros (synthesizable RTL) and firm macros (netlists) are flexible. They are usually placed as regions, fences or guides for groups of standard cells rather than as fixed rectangles.

Where macro placement sits in the flow#

Macro placement happens inside floorplanning, after the die or block outline, rows and I/O pins are defined and before power planning and standard cell placement:

1. Read netlist, libraries, LEF, constraints (SDC) and power intent (UPF).
2. Define core area, rows and pin placement.
3. Place macros, add halos and channel blockages, and fix them in place.
4. Insert physical-only cells (end caps, tap cells), then build the power grid.
5. Place standard cells, then CTS, routing and sign-off.

Macro placement is often iterated with steps 2 and 4: a trial placement, a quick power grid, a fast standard cell placement and an early global route, then adjustments.

What a good macro placement has to achieve#

A macro placement is a set of trade-offs between these goals:

• Short, direct connections. Macros that talk to each other, to specific logic or to I/O pins should sit near them. Long macro-to-logic wires add delay and burn routing tracks.
• Large, regular standard cell area. The space left for standard cells should be one or a few big, well-shaped regions, not narrow slivers, notches and isolated islands.
• Routable channels. Every gap between macros, and between macros and the core edge, must either be wide enough to route the signals that need to pass through it or be closed off completely.
• Clean power delivery. The power grid must reach each macro's power pins and the cells around it without starved regions.
• Legal and rule-correct. Macros must sit on legal grid locations, in allowed orientations, without overlaps, and respect spacing and keep-out rules from the macro documentation.

Classic macro placement guidelines and why they work#

The guidelines below appear in almost every physical design training course. Treat them as starting points that you check against the data flow of your design, not as laws.

The two most important habits are to look at flylines (the connections between a macro and the rest of the design) before you fix a location, and to check the result with a quick placement and global route instead of trusting the picture.

Halos, channels and blockages#

Three related constructs control the space around macros.

Halo (keep-out margin). A halo is a margin around a macro where the placer will not put standard cells. It moves cells away from the macro edge so pin access, power hookup and boundary rules have room. A halo belongs to the macro and moves with it. Some tools allow a different halo on each side, which is useful when only one side has pins.

Channel. A channel is the gap between two macros, or between a macro and the core edge. It is useful only if signals can be routed through it, which depends on its width, the layers that are free over it and how many nets need to cross it.

Placement blockages. A hard placement blockage stops all standard cells in an area; a soft blockage stops the global placer but allows buffers and legalization during optimization; a partial blockage limits density to a percentage. Blockages are drawn on the floorplan, not attached to a macro. See Blockages in VLSI for the full list.

Typical uses:

• Put a halo around every hard macro, sized for its pin side and its boundary cell needs.
• Close channels that are too narrow to route with a hard blockage, so the placer does not drop cells there.
• Use a soft or partial blockage in channels that are wide enough for routing but should hold only buffers and repeaters.
• Use routing blockages over a macro only where the macro LEF does not already block those layers.

Worked example A: sizing a channel (illustrative)#

Two SRAMs sit side by side with a vertical channel between them. A quick trial route shows that about 300 nets need to run vertically through the channel: macro pins that escape sideways plus logic that crosses from one side of the block to the other.

Assume (illustrative values):

• Vertical routing layers available in the channel: 2 (the others are used by the power grid or are horizontal).
• Track pitch on those layers: 0.1 µm.
• Target track usage in the channel: 70%, leaving room for detours, vias and pin access.
• Power straps that must also run through the channel take 10% of its width.

Tracks needed per vertical layer:

300 nets / (2 layers x 0.7) = 214 tracks per layer

Width needed for signals:

214 tracks x 0.1 µm = 21.4 µm

Adding 10% for straps gives about 23.6 µm. If each macro also carries a 2 µm halo on that side, the gap between the macro boundaries becomes about 27.6 µm. A 10 µm channel would be badly congested; a 25 µm channel would be close; about 28 µm or more leaves margin.

You may see a simpler rule of thumb on the web and in training notes, for example channel width = (number of pins x pitch x 2) / number of layers. It points in the same direction (more pins or a larger pitch need a wider channel; more layers need a narrower one) but it ignores how many nets actually cross the channel and how full the tracks can be. Use it for a first guess, then check with a global route congestion map.

Worked example B: how placement changes usable area (illustrative)#

A block has a core of 1000 µm x 800 µm (800,000 µm²). It contains 12 SRAMs, each 150 µm x 200 µm, for a macro area of 360,000 µm² (45% of the core). The standard cells need 260,000 µm².

With a 5 µm halo on every side, each macro occupies 160 µm x 210 µm, or 33,600 µm². Twelve of them take 403,200 µm², leaving 396,800 µm² for cells.

260,000 / 396,800 = 65.5% standard cell utilization

Now suppose the macros are scattered, leaving narrow channels and notches that are too small to use and must be blocked. If those unusable gaps add up to 40,000 µm², the cell area drops to 356,800 µm²:

260,000 / 356,800 = 72.9% standard cell utilization

The same netlist in the same core is now 7.4 percentage points more crowded, and the crowding is concentrated next to macros, where pin access is already hardest. This is why scattered macros so often show up later as routing congestion and hard-to-fix timing paths.

Placing macros by data flow#

Pushing every macro to the edge is not always best. A design with deep pipelines between memories and logic often places better when the floorplan follows the data flow:

• Start from the hierarchy and the dataflow: which modules talk to which macros, and how many bits wide the buses are.
• Place a memory near the logic that reads and writes it, and keep groups of memories that share a controller together.
• Keep wide buses short and straight. A 512-bit bus that crosses the block twice costs far more tracks than a few control signals.
• Put macros with I/O-facing interfaces close to the related pins.
• Keep the clock in mind: macros with tight clock pins need short, balanced clock routes, and a wall of macros can force the clock tree to detour.

Most tools can show flylines and a connectivity summary between macros and module clusters. Use them to decide groups first, then decide exact locations.

Orientation, power and other details#

Orientation. Rotating or mirroring a macro changes which edge its pins face. Some macros allow only certain orientations, because of poly direction or internal structures, so check the macro documentation before you flip it. Mirrored pairs (for example, two SRAMs facing each other across a shared logic channel) can shorten wiring to shared logic.

Power. Macro power pins usually sit on a middle metal layer, as rings or stripes. The power grid must drop vias onto them from the layers above, and lower straps and follow-pin rails normally stop at the halo. Aligning macro edges with the strap pitch avoids partial straps and missed connections. See Power Planning in VLSI for the grid side of this.

Boundary cells. Rows that end at a macro edge need end caps and tap cells like rows that end at the core edge. The halo must leave room for them. See Physical-Only Cells in VLSI.

Grid and spacing. Macros are usually snapped to a placement grid that lines them up with rows and routing tracks. Spacing rules between macros, and between macros and the core edge, come from the macro and technology documentation.

Fixing. Once a placement is accepted, set macros to fixed status so later optimization cannot move them.

How tools place macros#

Every major place-and-route tool has an automatic macro placer and also accepts manual placement through scripts or the GUI. Automatic placers typically cluster the netlist by hierarchy and connectivity, then search for macro locations that minimize wirelength while respecting outline, channel, halo and boundary goals. Results are a good starting point, and engineers usually adjust them by hand, especially for large memory arrays and analog IP.

The open-source OpenROAD project documents a hierarchical macro placer, Hier-RTLMP, run with the rtl_macro_placer command. A simplified sketch:

# Sketch only; check option names against your OpenROAD version rtl_macro_placer \ -min_channel_size {20 20} \ -target_util 0.6 \ -report_directory ./mpl_reports

In current OpenROAD documentation, -min_channel_size sets the minimum channel width and height between macros in microns, and the older -halo_width and -halo_height options are listed as deprecated in its favour. Google researchers have also published a reinforcement-learning approach to macro placement (Mirhoseini et al., Nature, 2021), which shows the topic is still an active research area.

Checks before you freeze macro placement#

Run these checks before moving on to power planning and placement:

• Legality: no overlaps, all macros on legal grid locations and in allowed orientations, inside the core.
• Halo and spacing: halos present, spacing to other macros and to the core edge meets the rules.
• Pin access: pins face their logic, and pin edges have free tracks.
• Channels: every channel is either wide enough (check with an early global route) or fully blocked.
• Standard cell area: no isolated islands or deep notches; utilization in each region is reasonable.
• Trial placement and global route: congestion map, overflow numbers and wirelength look acceptable.
• Early timing: macro-to-register and register-to-macro paths look closable with the expected wire lengths.
• Power: a trial power grid connects every macro power pin.
• Fixed status: macros are fixed so later steps cannot move them.

Debug flowchart: congestion or timing problems around macros#

When congestion or timing failures cluster around macros, work through the causes in order:

1. Is the placement legal and fixed? Overlaps, off-grid macros or macros moved by optimization must be fixed first.
2. Are hotspots in channels? Widen the channel, reduce the nets that cross it, or close it with a blockage.
3. Do pins face away from their logic? Rotate or mirror the macro (if allowed) or move it.
4. Are macro-to-logic paths long? Move the macro toward its logic, regroup by data flow, or add pipeline stages if the architecture allows it.
5. Are cells trapped in notches or islands? Block the notch or reshape the macro arrangement.
6. Are there power or boundary issues? Fix strap alignment, halo size and boundary cells.
7. Iterate: run a trial placement and global route again, and compare congestion, wirelength and timing with the previous version.

Interview Q&As#

Q1. Why are macros usually placed near the core boundary? Placing them near the edge leaves one large, regular area in the centre for standard cells, which improves placement quality and routability. The exception is a macro that mainly talks to central logic.

Q2. What is a halo, and how is it different from a placement blockage? A halo is a keep-out margin attached to a macro that moves with it. A placement blockage is drawn on the floorplan at a fixed location and is not tied to any instance.

Q3. How do you decide the channel width between two macros? Estimate how many nets must cross the channel, divide by the usable layers and target track usage, multiply by the track pitch, then add space for power straps and halos. Confirm with a global route congestion map.

Q4. What happens if a channel is too narrow? The placer may put cells there that cannot be routed, causing congestion, detours, DRCs and timing problems. Narrow channels should be widened or closed with a hard blockage.

Q5. Why should macro pins face the core? So wires from the pins reach the logic directly instead of going around the macro, which saves tracks and delay.

Q6. When would you not place a macro at the boundary? When its strongest connections are to logic in the middle of the block, or when data flow analysis shows a shorter total wirelength with the macro placed inside.

Q7. How do flylines help macro placement? They show which macros connect to which modules, pins and other macros, and how wide those connections are, so you can group related blocks and shorten wide buses.

Q8. How is macro placement checked before moving on? Legality, halos, spacing, pin orientation, channel widths, a trial placement and global route, early timing and a trial power grid.

For more practice, see Floorplan Interview Questions and Answers.

FAQ#

Is automatic macro placement good enough? It is a useful starting point and often good for simple blocks. For large memory arrays, analog IP and timing-critical designs, engineers usually review and adjust the result by hand.

How large should a halo be? Large enough for pin access, boundary cells and power hookup. The exact size comes from the macro documentation, the technology rules and experience with similar blocks.

Does macro placement affect clock tree synthesis? Yes. Macro walls can force long clock detours and make skew harder to balance. See Clock Tree Synthesis.

Summary#

• Macro placement sets the limits for power planning, placement, CTS, routing and timing, so it deserves several iterations.
• Good placements give short connections, a large regular standard cell area, routable or closed channels and clean power delivery.
• The classic guidelines (boundary placement, pins facing the core, grouping, arrays, no narrow channels or notches) work because of these goals; bend them when data flow says so.
• Halos protect macro edges, blockages control channels, and channel width should be estimated from crossing nets, layers, pitch and track usage, then checked with a global route.
• Always confirm a macro placement with a trial placement, global route, early timing and trial power grid before you fix it.

References#

• OpenROAD documentation, "Hierarchical Macro Placement" (Hier-RTLMP, rtl_macro_placer): https://openroad.readthedocs.io/en/latest/main/src/mpl/README.html
• Mirhoseini, A. et al., "A graph placement methodology for fast chip design", Nature 594, 207–212 (2021): https://www.nature.com/articles/s41586-021-03544-w
• Related iVLSI posts: Floorplan, Global Placement, Static Timing Analysis, IR Drop Analysis in VLSI