From Manual Floorplanning to Concurrent Placement

Concurrent macro and standard-cell placement with MSV awareness and incremental tuning

From Manual Floorplanning to Concurrent Placement

Physical design has always lived with a quiet contradiction. The single decision that most strongly shapes a block's timing, congestion, and wirelength — where the large hard macros sit on the die — has traditionally been made first, by hand, and in near-total ignorance of the standard-cell logic that will eventually wrap around those macros. This chapter explains why that ordering is so costly, what changes when macros and standard cells are placed together in one optimization, and where this concurrent approach fits into the broader implementation flow. By the end you should be able to argue, in an interview, both why mixed placement exists and when you would still reach for a hand-crafted floorplan.

The Traditional Backend Reality

In the classic flow, the block-level effort begins with floorplanning. The engineer takes the netlist, the die or block outline, the I/O or pin constraints, and the list of hard macros — memory instances, register files, analog or custom IP, large multiplier arrays — and starts arranging those macros manually. They drag a memory to a corner, abut a few together to share power rails, rotate one so its pins face the logic, push another against an edge to keep it out of the routing channels. Then they run a quick trial placement of standard cells, look at a congestion map, look at a wirelength or timing estimate, and decide the floorplan is "not good enough." So they move the macros again. And again.

This loop is the heart of the problem. Each iteration is slow because it includes a real (if coarse) placement run, and the feedback it produces is indirect: a congestion heat-map tells you that something is wrong, rarely which macro to move or where. The search space is enormous. With tens of macros the experienced engineer's intuition can converge in a few days. With hundreds of macros at advanced nodes — common in modern SoC partitions packed with SRAM — manual convergence becomes impractical. There are simply too many interacting placements, too many channels to keep clear, too many pin-access and power-grid constraints to satisfy at once, for a human to explore more than a tiny fraction of the possibilities. Two further realities make this worse. First, floorplanning is usually treated as a separate stage, often owned by a different engineer or done days before placement, so the people optimizing the cells inherit the macro positions as fixed inputs. Second, the trial placements used to judge a floorplan are deliberately fast and therefore inaccurate, so a floorplan that looks fine in trial can fall apart under a real, timing-driven placement.

The QoR Risk of a Bad Floorplan

The deepest issue is timing of decisions, not timing of signals. Macro placement is the earliest large commitment in the physical flow, and everything downstream is built on top of it. A poor floorplan locks in problems before standard cells even exist:

• Congestion is largely decided by macro placement. Macros are routing blockages; the channels between them and the pin clusters on their edges dictate where wires must squeeze. A floorplan that leaves narrow channels or buries pins in a corner creates hotspots no cell-level optimization can fully undo.
• Wirelength is bounded from below by macro positions. If two macros that exchange wide buses are far apart, every connecting net pays that distance, and the logic between them is stretched to match.
• Timing inherits both. Long macro-to-macro and macro-to-logic paths become the critical paths. The placement and optimization engine can buffer and resize, but it cannot relocate a fixed macro, so it spends its effort fighting a geometry it was handed rather than improving it.

Because these costs are baked in early, they are expensive to discover late. A timing or congestion problem rooted in the floorplan often surfaces only after placement, legalization, and an initial route — hours or days of runtime later — at which point the only honest fix is to go back to the floorplan and start the manual loop again. This is the classic "throw it back over the wall" iteration that dominates schedules on macro-heavy blocks.

The Concurrent / Mixed Idea

Mixed placement — also called concurrent or co-placement — collapses the wall. Instead of fixing macros first and placing cells second, a single engine places macros and standard cells together, treating macro locations as variables in the same optimization that positions the logic. Crucially, that optimization is driven simultaneously by the same objectives that matter at every later stage: wirelength, congestion, and timing.

The conceptual win is information. In the manual flow, macro positions are chosen blind to the logic; the engineer guesses where the connected cells will end up. In the concurrent flow, the engine sees the cell cloud forming around each macro as it places it. A macro is pulled toward the centroid of the logic it talks to, nudged so its pins face that logic, and shifted out of regions that are becoming congested — all in response to the actual standard-cell distribution and the actual timing graph, evaluated together rather than in sequence. The result is macro locations chosen with full knowledge of the netlist that connects to them, which is precisely the knowledge a human floorplanner lacks.

Modern engines reinforce this with analytical placement (minimizing a global cost function over all movable objects at once), fast congestion estimation folded into the same objective, and timing awareness so that critical connections shorten as the macros settle. Macros and cells are not placed in two passes that happen to run back-to-back; they co-optimize in one solve.

What Drives the Engine

A useful interview framing is to separate what the engine optimizes from what you, the user, can push on. Every objective the engine balances has a meaning and a corresponding lever you control through constraints and settings.

The engine is continuously trading these against one another. Tighten density and you may relieve congestion but lengthen wires; weight a critical bus and you shorten it at some cost to neighbors. Mixed placement does not remove these trade-offs — it makes them visible and global, resolved by the optimizer instead of resolved guess-by-guess in the manual loop. It helps to understand how the engine balances them under the hood, because that explains both its strengths and its blind spots. Most modern engines begin with an analytical, force-directed solve: every net behaves like a spring pulling its connected objects together, and a spreading force pushes objects apart so they do not all collapse to a single point. Macros and standard cells are both movable masses in this field, so a memory connected to a dense cluster of logic is literally pulled toward that cluster's center of gravity. Congestion is folded in by inflating the apparent demand in regions where routing supply is scarce, which makes the spreading force stronger there and steers objects — macros included — away from would-be hotspots. Timing enters as extra weight on critical nets, shortening their springs so the optimizer prioritizes them. The key point for an interviewer is that these three forces act on the macros at the same time as the cells, which is the entire reason concurrent placement can find macro positions a sequential flow never would: the macro is never frozen while the logic settles around a stale guess.

Manual vs Concurrent: A Direct Comparison

macros

Information used Engineer intuition; netlist read Full netlist, live cell distribution, timing graph

Feedback loop Slow trial-place, read map, move, Single co-optimized solve

Turnaround time Days to weeks on macro-heavy Hours; one run replaces many iterations

reproduce

Best suited to Structured, regular, or constraint- Large, irregular, SRAM-dense logic blocks

Benefits and Trade-offs

The headline benefit is turnaround time. One concurrent run replaces a long chain of manual floorplan iterations, compressing what was days of move-and-retry into hours. The second benefit is QoR: because macros are positioned with knowledge of congestion, wirelength, and timing from the first moment, the starting point handed to downstream optimization is usually as good as — and frequently better than — a hand-tuned floorplan, especially on blocks where human intuition simply cannot enumerate the options. The third is effort: senior engineers are freed from pixel-level macro nudging to focus on constraints, partitioning, and sign-off. None of this makes manual floorplanning obsolete. The engine optimizes what you tell it to and respects only the constraints you give it. It does not know your unwritten conventions — that a particular memory must sit beside a specific controller for a clean clock path, that an analog macro needs a quiet corner, that an array of identical macros should be laid out in a tidy regular grid for power and verification reasons. Highly structured datapaths, channel-based memory arrays, and blocks with hard physical or hierarchical constraints are still places where a human-defined (or humanguided) floorplan wins. In practice the strongest results come from a hybrid: pin or pre-place the macros that must be placed by intent, then let the engine concurrently place the rest along with the standard cells.

There are also failure modes worth naming so you can recognize them in an interview. A concurrent solve can scatter macros — leaving them strewn across the core in positions that are individually sensible but collectively ugly, breaking the tidy rows a reviewer or the power team expects. It can place macros in orientations that are locally optimal for wirelength but inconvenient for pin access or powerrail sharing. And because the engine optimizes the objectives you weighted, a missing or mis-set constraint can produce a confident, fast, wrong result. The cure is not to abandon the flow but to constrain it: define keep-outs, group related macros, set orientation and edge-alignment rules, and reserve channels. Good mixed-placement methodology is mostly the art of encoding intent as constraints so the optimizer's freedom is bounded to the region where its judgment beats yours. A typical invocation expresses exactly that division of labor — fix what you mean to fix, then run one concurrent placement:

# Pre-place the macros that are dictated by design intent
set_macro_placement -instance u_mem_ctrl/sram0 -location {120.0 340.0} -orientation
R0
set_macro_placement -instance u_analog/pll0   -location {10.0  10.0}  -orientation R0
-fixed
# Reserve clear space and pin access around movable macros
set_placement_halo  -instances [get_macros -movable] -width 8.0
# Hand objectives to the engine, then place macros and cells together
set_placement_option -mode concurrent_macro
set_placement_option -effort high -timing_driven true -congestion_driven true
place_design -concurrent_macros

After the run you inspect the result and, if needed, adjust intent rather than hand-place — the loop is now "change a constraint, re-run" instead of "drag a macro, re-trial":

# Review what the engine decided
report_congestion -summary
report_timing      -max_paths 20
report_macro_placement
# If a region is hot, push on a lever and re-place — not a manual drag
set_placement_option -max_density 0.72
place_design -concurrent_macros -incremental

Where Mixed Placement Sits in the Flow

The cleanest way to picture mixed placement is as a fusion of the floorplan stage into placement. The stages before it — synthesis hand-off, netlist and constraint reading, power-grid and I/O setup, and the definition of any pre-placed or intent-driven macros — are unchanged. The stages after it — legalization, clock-tree synthesis, routing, and sign-off optimization — are also unchanged; they receive a placed database exactly as they would from a manual flow. What disappears is the separate,

up-front, manual floorplanning step and its iteration loop. Macro placement no longer precedes cell placement as a distinct phase; it is part of cell placement.

This is why mixed placement is so often discussed as a turnaround-time lever: it removes an entire stage boundary and the back-and-forth across it, without forcing changes to the tools and methodology on either side.

High-Level Anatomy of the Mixed Flow

The remaining chapters of this handbook walk through the concurrent flow in the order an engineer experiences it. As a preview, the anatomy looks like this: Covered

Phase What happens

Inputs & readiness Netlist, constraints, power plan, macro list, intent-driven pre- Ch. 2

Global concurrent solve Analytical placement of macros + cells under wirelength/ Ch. 3

Macro refinement & Snapping macros to grid, channels, halos, pin-access cleanup Ch. 4

Cell legalization & Standard-cell legalization, timing and congestion repair Ch. 5

The thread running through all of it is the one introduced here: macros and standard cells are decided together, under the same objectives, so that the earliest and most consequential layout commitment is made with the most information rather than the least.

Interview Q&A

makes the most consequential layout decision — macro positions — first and blind. The engineer can't see where the connected standard cells will land, so macro locations are guesses validated by slow, inaccurate trial placements. The loop is slow, doesn't scale past tens of macros, and locks in congestion, wirelength, and timing before the logic is ever placed. Problems then surface downstream and force a return to the floorplan.

cells are variables in one optimization, solved together under the same wirelength, congestion, and timing objectives — not two passes run back-to-back. Each macro is positioned in response to the live distribution of the logic connected to it and the timing graph, so its location reflects full knowledge of the netlist rather than an up-front guess.

intent isn't expressible purely through objectives: regular memory arrays that should sit in a tidy grid, analog or sensitive IP needing a specific quiet location, a memory that must abut a particular controller for a clean clock path, or hard hierarchical and physical constraints. The common practice is hybrid — pin or pre-place the intent-driven macros, then let the engine concurrently place the remaining macros and all the cells.

the floorplan stage into placement. Everything before (netlist/constraint/power setup, intent-driven preplacement) and everything after (legalization, CTS, routing, sign-off) is unchanged. What's removed is the standalone manual floorplanning step and its iteration loop. Downstream stages receive a placed database just as they would from a manual flow, which is why it's primarily a turnaround-time and QoR improvement rather than a methodology overhaul.

Key Takeaways

• Manual floorplanning makes the highest-impact layout decision first and blind, through a slow trial- and-error loop that does not scale to the hundreds of macros common at advanced nodes.
• A bad floorplan locks in congestion, wirelength, and timing before standard cells exist; downstream optimization can mitigate but not relocate fixed macros.
• Concurrent (mixed) placement co-optimizes macros and standard cells in one engine driven simultaneously by wirelength, congestion, and timing, so macros are positioned with full knowledge of the connected logic.
• The benefits are faster turnaround, comparable-or-better QoR, and far less manual effort; the trade-off is reduced direct control, so intent-driven macros are still pre-placed in a hybrid approach.
• Mixed placement fuses the floorplan stage into placement; the stages before and after are unchanged, which is what makes it a low-friction, high-leverage flow change.