A floorplan is the first step where a logically valid netlist gets turned into a physical plan — where boundaries, rows, macros, pins, and reserved channels actually live in physical space, obeying real technology and library rules. The best analogy is arranging rooms and hallways in a building before you furnish anything — except unlike a building sketch, every object here has to satisfy hard, mechanically-checkable rules (site grids, layer directions, spacing rules), not just aesthetic judgment.
Picture the die as the full piece of land you own, and the core as the buildable footprint inside it — the core is where your standard-cell rows and most of your implementation actually lives. The core offset is simply the gap between the die edge and the core edge on each side — and crucially, that gap doesn't have to be the same on all four sides.
Think of "total area" as a mixed bag of very different things — you can't compute a meaningful utilization number until you've sorted that bag into buckets. Separate at least these categories: standard-cell area, hard-macro area, fixed/physical-only cell area (taps, end-caps, corner cells), placeable area, reserved area, and whitespace.
Whitespace is the placeable area left over after your counted cells have been assigned their area — it's working room for optimization cells, routing access, and future ECOs, not automatically "wasted" silicon. Target utilization is just the planned fraction of placeable area you intend the explicitly counted objects to occupy — but that number is meaningless until you state exactly what's in the numerator and what's in the denominator.
The formula is simple division, but the interpretation is where people trip up: required placeable area = counted cell area / target utilisation, not the other way around. Worked example: if your counted standard cells add up to 600,000 um^2 and you want them to occupy 60% of placeable area, you need 600,000 / 0.60 = 1,000,000 um^2 of placeable area total — not 600,000 um^2 with 60% left as margin.
Target utilization is your input assumption going in; effective utilization is what actually got achieved after real exclusions (blockages, macros, halos) are accounted for; local utilization narrows the question to a specific smaller region instead of the whole block. These answer genuinely different questions, and comparing across them is meaningless unless you're using the same object classes, the same exclusions, and the same region definition each time.
Aspect ratio is simply width divided by height of the core: AR = W / H. AR = 1 is a square core; AR = 2 means the core is twice as wide as it is tall. Two floorplans can have identical area but very different shapes — a 1000×1000 µm square and a 2000×500 µm rectangle have the same area (1,000,000 µm²) but wildly different aspect ratios, and that shape difference changes everything about routing and timing.
This is one of the most basic but most-used floorplanning calculations — you know how much area your logic needs, and you've decided (for I/O, package, or routing reasons) what shape you want that area to take, and you need actual width/height numbers to build a floorplan from. Define **aspect ratio (AR)** as width divided by height (`AR = width / height`) — an AR of 1.0 means a square, an AR of 2.0 means a rectangle twice as wide as it is tall, and an AR of 0.5 means twice as tall as wide.
Don't assume all four sides of the core-to-die offset are equal — in real floorplans they often aren't, because different sides reserve different amounts of space for I/O cells, power rings, bond pads, or keepout margins. The rule is additive per axis: die width = core width + (left offset + right offset); die height = core height + (bottom offset + top offset). You add the actual measured offset on each side, not a single "the" offset doubled.
These three answer three completely different questions, and mixing them up is a common beginner mistake: a site answers "where may a cell origin legally land," a row answers "where do standard cells actually get placed," and a routing track answers "where may a wire centerline run." A site is the smallest legal placement increment — think of it as the grid unit that every standard-cell origin must snap to.
Think of standard-cell rows like bookshelves: every row has to sit in a legal orientation so a cell's power rail lines up with the row's VDD/VSS rail — flip a shelf the wrong way and books (cells) that need to sit on it simply can't. Rows commonly alternate orientation (R0/MX) from one row to the next specifically so adjacent rows can share a power rail by abutment, but that alternating pattern is a library/methodology choice, not a universal law — always check what the target library actually supports.
A hard macro (think SRAM or a hardened IP block) arrives with its size, shape, and pin locations frozen — it's furniture, not something you can reshape to fit the room. A standard cell is tiny and numerous by comparison — thousands of interchangeable Lego bricks that get arranged later, inside whatever legal rows the macro layout leaves behind.
Macro placement isn't an aesthetic exercise — it should follow the actual dataflow: which macros talk to which, how critical that connection is, and where the I/O and clock/reset sources sit. Picture "fly lines" (rubber-band connectivity lines) stretched between macros and ports — a good placement is one where those lines are short and unobstructed, giving wires a direct, legal corridor instead of a scenic detour.
Rotating a macro is like turning a cabinet around — it changes which side its doors open on, and for a macro, the "doors" are its signal and power pins. A rotation can be perfectly legal geometrically (it fits the footprint) while still pointing pins away from the logic that needs them, or misaligning power pins from the strap grid they're meant to land on.
White space between macros looks like "free routing room" on screen, but it's only usable if it actually has enough width and geometry for signal tracks, facing pins, power straps, vias, shielding, and buffers — visible space and routable space are not the same thing. Different spacing rules apply to macro-to-macro gaps, macro-to-boundary gaps, and macro-to-standard-cell gaps — treating them as one generic "keep-out" number will misjudge channel capacity.
A halo (keepout margin) is attached to a macro — like a personal-space bubble — so wherever the macro moves, the halo moves with it automatically. A placement blockage is a fixed rectangle drawn on the floorplan itself; it doesn't care what's placed nearby and it stays put even if every macro around it shifts.
Core boundary cells sit at the ends of standard-cell rows — their job is to protect and properly terminate the row edge (well, diffusion, etc.) so the row doesn't end with an invalid or DRC-violating structure. Inside/outside corner cells handle the actual corners of the core or of a voltage area — an outside corner (convex, like a normal rectangle's corner) and an inside corner (concave, like the corner of an L-shaped notch) need different cells because the geometry they're closing off is different.
These are all "connection points," but they live at very different physical and logical boundaries, and confusing them is a common source of miscommunication between floorplan, package, and RTL teams. Chip I/O (pads or bumps) are where the die physically connects to the package — their placement and rules are driven by packaging constraints (bond-wire pitch, bump grid), not by what's convenient for internal routing.
A feedthrough is a signal that enters a block, passes through it, and leaves again without ever actually being used by that block's own logic — it's just borrowing the block as a physical hallway to get somewhere else. The upside is real: routing a signal through a block can be a shortcut compared to detouring all the way around it at the top level, which can shorten wire length and improve timing for that top-level path.
Early congestion estimation is a rough, pre-route sanity check: it compares how much routing *demand* (nets that need to cross a region) exists against how much routing *capacity* (actual track resources) is available, in coarse rectangular regions across the chip. The clearest analogy is a highway system: the average traffic flow across the whole city can look totally fine while one specific junction is completely gridlocked — congestion is fundamentally a **local** phenomenon, and averaging it away at the chip level hides the real problem.
A "legal" pin just means it obeys placement rules — it's sitting somewhere the DRC deck allows. An "accessible" pin is a stronger claim: there's actually a usable route to it, on a permitted layer and track, with nothing in the way. It's the difference between a door drawn correctly on a blueprint and a door you can actually walk through — furniture (blockages, stacked shapes, neighboring PG shapes) can block a perfectly legal door.
Power rings, straps, rails, and their vias aren't free — they consume real area and real routing tracks, on the same "roads" signal wires want to use. If you plan signal channels or pin access before reserving power's footprint, you'll end up designing corridors that power later claims out from under you — so PG corridors have to be reserved early, before signal planning locks in.
A power domain is a logical concept — it says which electrical rules (supply, isolation, retention) apply to a group of cells. A voltage area is the physical fence — it says where on the floorplan those cells are actually allowed to sit. They're related but not synonyms: you can define a power domain in UPF and still get the physical implementation wrong if the voltage area's shape, alignment, or utilization doesn't actually support it.
Even before a single standard cell is placed, the floorplan is already shaping how long wires will eventually have to be — and wire length translates almost directly into estimated interconnect delay. Physical distance matters most obviously: two logically connected blocks placed far apart on the die will need longer wires than the same two blocks placed close together, even though the logic connecting them hasn't changed at all.
A screenshot of a floorplan tells you what it looks like, not whether it's actually sound — real reviewability comes from reports and saved constraints that show what the *tool* actually understands, not what the picture visually suggests. A reviewable floorplan has to demonstrate, with evidence: deliberate (not accidental) boundaries, a stated utilization number, genuinely usable rows, macro locations with a justification (not just "it fit there"), feasible routing channels, properly constrained pins, early congestion/timing evidence, reserved PG resources, voltage-area legality, and — critically — reproducible write-out (someone else can regenerate your evidence from the same inputs).
Treat target utilisation as a hypothesis you test, not a rule of thumb you copy from the last project — "70% because that's what we always use" is exactly the trap this question is probing. Start from actual counted standard-cell area, then layer on everything that eats into usable space: macro footprint and its dead channels, expected late-stage cell-count growth, physical-only cells (tap/endcap/filler), hold and clock buffering headroom, spare-cell allocation for ECO, and PG-grid reservation.
Once a handful of large hard macros dominate a block, the floorplan is no longer an area math problem — it's a packing/geometry problem, and treating it like the former is how blocks come back "infeasible" after synthesis-level area budgeting looked fine. Think of it like trying to pour sand (standard cells) around bricks (macros) already sitting in a box — the bricks' exact shape, legal rotations, which side their pins face, and the channels you must leave for routing determine the box size, not some average density number.
The real question engineers ask is: "if the netlist grows by X%, does my floorplan still work?" — this is about turning that worry into a number, not a guess. Take the current counted standard-cell area and apply the growth assumption (an RTL change, a late feature add, a resynthesis with a less-friendly library). Example: 600,000 um² growing 8% becomes 648,000 um².
Equal area is a trap if you stop there — two floorplans with identical core area can behave completely differently in routing and timing, because area only tells you total *capacity*, not *geometry* (how far things actually have to travel). Set up a fair experiment: same macro set, same constraints (SDC, PG assumptions), same evaluation settings, and only the aspect ratio (width:height) varying between the two shapes you're testing — anything less controlled and you can't attribute differences to the shape itself.
Rounding core/die dimensions isn't a cosmetic formatting step — every snap to a legal grid or row/site multiple is a real physical decision that shifts area and utilisation, so it has to be done deliberately, not left to whatever the tool defaults to. Start with the ideal core dimensions from your area math, then snap width and height to legal manufacturing grid values and to whole row/site multiples — you can't have a half-row hanging off the edge.
A "site" defines the legal placement grid a row is built on — its width, height, and which cell classes can sit there. If the row's site doesn't match what your target cells expect, the tool will refuse to legalize them even though the row visually looks fine. Start narrow: pick one cell that's failing to legalize and one row it's supposed to sit in, then directly compare their site names — this is almost always where the mismatch is hiding, rather than some deeper floorplan issue.
A row fragment reported by the tool is only "usable capacity" if a real cell can actually legally land there — the tool counting it toward total row area doesn't mean it's actually placeable. Check four things together: the fragment's legal length (can even the smallest library cell fit plus required end spacing?), its site alignment, which voltage area it belongs to, and whether nearby keepouts or halos block access to it.
Row orientation can look perfectly regular visually — alternating up/down like it should — and still be wrong for the library, because the thing that actually matters is whether VDD/VSS land on the correct rail for each row, not just whether the pattern alternates. A standard-cell library has a fixed power-rail convention baked into every cell (which rail is VDD on an "N" orientation vs. a flipped "FS" row); if the floorplan's row settings don't match that convention, cells will short or float their supply on abutment.
Macro placement isn't a puzzle of minimizing every pairwise distance — it's about arranging macros so the actual **dataflow** through the chip is short, routable, and timing-friendly, which is a different (and sometimes conflicting) goal. **Flylines** (the rat's-nest connectivity lines the GUI draws between related instances) are your first diagnostic tool — they visually show you which macros are heavily connected and should sit near each other, versus which ones barely talk and can be placed further apart without penalty.
There's no universal right answer here — it genuinely depends on where the macro's pins, its logical neighbors, and its routing needs actually point, so the decision has to be made from the connectivity data, not a rule of thumb. Edge placement tends to simplify external access (bringing signals in/out from I/O, or connecting to neighboring blocks) and keeps the central core area free and continuous for standard-cell rows — good when the macro mostly talks to the outside world.
Orientation isn't just how the macro looks on screen — rotating or mirroring it physically moves where its pins sit relative to its neighbors, which directly changes route entry points and can quietly blow up wirelength even though the macro's outline stays perfectly legal. A macro can remain fully legal (on-grid, correct footprint, no overlap) after a flip and still end up with dramatically longer routes because its pins now face away from the logic that needs them.
"Inside the core boundary" and "on a legal coordinate" are two different things — a macro can sit entirely within the die and still be parked on an illegal manufacturing-grid or block-grid location. Verification means checking the macro's origin, its boundary, its orientation, its designated alignment point, and the applicable grid (manufacturing grid, or a stricter block/FinFET grid) all together — checking any one alone isn't enough.
Start from usable routing layers and their track pitches — that's your raw supply of routing resource through the channel, per layer, per direction. Then subtract everything that eats into that raw supply before any signal net gets to use it: power/ground strap width and spacing, placement/routing blockages, via keepout margins around those straps, and any shielding requirements on sensitive nets.
A narrow passage between macros can be geometrically "open" and still be effectively useless if every entry into it is blocked — an open channel with no legal access is not usable routing/placement space. These regions concentrate routes and pins into a small area, which fragments standard-cell rows, complicates power/ground continuity, and often leaves dead space that neither cells nor wires end up using well.
The keepout type you choose expresses *which objects* get excluded and *at which stage* — the numeric margin value (how far the exclusion extends) is a completely separate decision from the type. Use `hard` when you need broad placement exclusion around the macro for essentially everything — this is the strictest, most conservative choice.
A hard blockage is the strictest: nothing gets placed inside it, period — no standard cells, no macros, honored through coarse placement, optimization, legalization, and CTS. A soft blockage is a "please don't, unless you really need to" — it stops cells during initial (coarse) placement, but later optimization/legalization steps are allowed to place inside it if that's what's needed to fix a violation.
Boundary-cell planning means selecting, for each edge type your floorplan actually has, the correct library-approved cell: left end-cap, right end-cap, top/bottom boundary cells, inside-corner cells, and outside-corner cells. These cells are selected based on the *actual* row and voltage-area geometry you have — not a generic assumption. A rectangular core needs only 4 outside corners; a core with voltage areas carved out of it needs both outside corners (at the die boundary) and inside corners (at the voltage-area notches).
I/O guides reserve legal regions for I/O driver cells, while constraints describe package, protocol, power, and matching intent. place_io applies those rules to the intended guides.
A block pin is a doorway shared between the parent design and the child block — both sides need usable, legal access to it, not just the child block's own internal convenience. Placement needs to respect legal sides, legal layers, on-track positions, and correct offsets, all driven by how the top-level dataflow actually approaches that pin — not just "whatever side has room."
A bus isn't just "a bunch of individual pins" — related signals need to reach the block boundary in an order the router can continue naturally, meaning bit 0 through bit N should land in a sequence that doesn't force the router to cross wires just to sort them out downstream. Bit ordering matters concretely: if bus bits arrive at the boundary scrambled relative to their destination order inside the block, you get extra jogs, more vias, and congestion right at the pin — exactly the kind of local congestion that's expensive to fix later.
The naive instinct is "shortest path wins," but a feedthrough is a system-level tradeoff, not a pure geometry problem — the straight line through a block can beat the detour on distance while still being the wrong engineering choice. A feedthrough is worth it when the top-level distance and timing benefit it buys clearly outweighs what it costs the block it passes through — pin budget, routing capacity, voltage-area compatibility, buffering needs, and future ECO flexibility.
A feedthrough report's raw counts are just a starting point — they tell you *how many* feedthroughs exist, not whether that's good, bad, or expected, so don't stop at the numbers. Classify every entry first: original vs. created, buffered vs. unbuffered, reused vs. redundant, pure vs. mixed, unused. Each category tells a completely different story about design health.
The whole point of an early congestion check is to compare alternatives fairly — and that's only possible if every alternative is measured with the exact same yardstick. Keep the floorplan version fixed across all comparisons — if you tweak the floorplan between runs, you can no longer tell whether congestion changed because of your real variable or because of an incidental floorplan drift.
Resist the urge to jump straight to "make the die bigger" — that's the most expensive fix and often masks (rather than solves) the actual root cause, so it should be close to your last resort, not your first move. Step 1: **confirm the data itself is trustworthy** — check that the netlist, constraints, and PG assumptions feeding the congestion estimate are actually current and correctly loaded; a stale or misconfigured input can produce a phantom hotspot that doesn't really exist.
Pitch controls repetition, offset sets the first coordinate, direction selects X or Y track lines, and width can reserve a wire width. Technology rules decide legality.
A pin sitting right at the edge of a cell or macro can still have zero legal, track-centered way to approach it — "on the boundary" and "reachable" are different claims. Debugging means pulling the pin's exact layer, side, and offset and comparing that against the track pattern (pitch/offset/direction), any blockages nearby, PG shapes in the area, spacing rules, and neighboring pins that might be crowding the same tracks.
Power and signal nets are competing for exactly the same finite set of routing tracks — reserving generous PG rings/straps without checking their impact on signal capacity is a common way to create congestion you don't discover until much later. The test is to overlay the proposed ring, strap, rail, and via corridors onto the same channel/congestion model you use for signal routing, then look at how many tracks and pin approaches remain once PG has taken its share.
Shape and size it for assigned cells, expected growth, legal rows, boundary cells, isolation/level-shifter/retention zones, switch corridors, macro compatibility, and supply access.
A slack number is meaningless in isolation — before comparing anything, lock down everything except the floorplan itself: same netlist, same SDC, same scenarios/corners, same libraries, same pre-CTS clock latency/uncertainty assumptions, same coarse placement effort, and the same parasitic estimation method for both runs. Once the environment is controlled, compare the **same named paths** across both floorplans — pick a handful of representative register-to-register and I/O paths (especially known-critical ones) and track how their slack changes, rather than just comparing aggregate WNS/TNS, which can hide which specific paths got better or worse.
The goal of this package is simple to state and easy to get wrong in practice: another engineer, with no other context, should be able to recreate the exact same physical state and understand why every decision was made. Cover both provenance and content — the exact input files and tool version used, the area assumptions behind the floorplan, the boundaries, rows/sites/tracks, macro and pin constraints, voltage areas, and every keepout/blockage placed.
Legality and quality are two separate questions, and passing one tells you nothing about the other — a legal street map can still route you into an impossible traffic jam at one intersection. Keep the legal baseline as-is — don't start ripping up the whole floorplan just because congestion is bad in one area; isolate the problem first.
Chip-average utilization is a useless number here — it's like saying a city has plenty of parking on average while one block is gridlocked. You have to zoom into the specific region and measure *its* usable area, not the die's. Usable area in that region = the physical area of standard-cell rows minus everything that eats into it: macro keepout halos, hard/soft placement blockages, voltage-area guardbands, fixed cells, and row fragments left by macro edges. Report that number with `report_design`/effective-utilization math, not the naive rectangle area.
Neither wins automatically — no single metric decides a floorplan aspect-ratio tradeoff, which is exactly why this question trips people up when they reach for "just pick whichever number is better." It's entirely normal for the two shapes to disagree in opposite directions: one aspect ratio shortens critical paths (better timing) while concentrating pins into a smaller region (worse congestion), and the other does the reverse.
Legality defines the *space* of allowed solutions (which orientations, which spacings are geometrically valid) — it doesn't guarantee every point in that space is actually routable, and a macro array is a classic place this bites you. Never force an illegal orientation just to fix pin access — that trades one hard failure (geometry/legality) for a different kind of hard failure that's equally unacceptable.
The real story here isn't "the channel broke" — it's that the earlier estimate was optimistic because it didn't yet account for PG straps that hadn't been planned when that first route succeeded. The channel's physical capacity didn't change; your model of it just became accurate. The fix is to recompute usable signal-track capacity honestly, now including PG strap widths, their spacing rules, the vias needed to connect them, and any blockages the straps introduce — this gives you the real post-PG-planning capacity, not the pre-PG estimate you were working from before.
A single uniform halo number applied to every macro is lazy and wrong — macros aren't symmetric, and a halo is a personal-space bubble that should only be as big as each side actually needs. Look at each macro edge independently: where are the pins concentrated, how many routing tracks/vias does that side need, are optimization cells (buffers, tap cells) expected to land there, and is there PG-shape traffic hugging that edge?
Start by checking the geometry of the voltage area itself — its boundary shape, whether it's rectangular or rectilinear, and whether it overlaps or nests with other voltage areas in a way that creates unusual corner cases. Check row orientation at each edge — remember standard-cell rows alternate orientation (flipped/rotated) every other row so adjacent rows share power rails, and boundary/corner cells must match that alternating pattern or they'll be flagged as wrongly oriented.
The package pin locations are usually a hard external constraint — you can't wish them away, so the real question is what floorplanning *can* still adapt to make the best of a fixed doorway. Macro locations are still yours to move — position macros to minimize the mismatch between where the package pins land and where your logical dataflow naturally wants to go.
This is a classic local-vs-global optimization conflict: the top-level integrator sees a timing win, the block owner sees a cost they didn't budget for, and neither party alone has enough information to make the call correctly. A faster route isn't automatically the right decision — "shorter and faster at the top level" has to be weighed against what it actually costs the block: pin count consumed, pin alignment disruption, routing capacity used up, buffering burden, voltage-area compatibility, and future ECO flexibility lost.
Passing legality checks proves the pin satisfies placement/geometry rules — it says nothing about whether a router can actually get a wire into it, and those are genuinely different questions. Treat this explicitly as a pin-access defect, not a legality problem, and start by reporting the pin's actual geometry alongside the nearby track grid and available routing resources on that layer.
It proves your earlier "signal-only" congestion estimate was optimistic, not that power planning is somehow the enemy — power/ground routing consumes real tracks too, and any congestion estimate that ignores PG reservation is only looking at part of the picture. Once PG straps, rings, and rails claim their share of routing resources on certain layers, the remaining capacity for *signal* routing shrinks — sometimes dramatically in specific directions or on specific layers — and that's exactly when previously-invisible congestion hotspots surface.
The core trap here: a voltage-area polygon can report plenty of raw area on paper while containing far too little actually-usable placement space — polygon area and usable area are not the same number. Diagnosis starts by comparing the assigned cell area (plus its expected growth) against what's legally placeable once you subtract legal rows, guard bands, enclosure margins, boundary-cell requirements, and isolation/level-shifter zone reservations.
Identify which named paths improved and which local resources failed, then test a change that preserves the timing benefit while relieving concentrated demand.
"Same floorplan" is a claim, not a fact — a screenshot looking identical tells you nothing about whether the underlying analysis state (tool version, options, scenario, library) actually matches. Start with provenance before comparing any numbers: was the floorplan written out from the same checkpoint, using the same tool version, and loaded with the same app options on both sides?
`initialize_floorplan` has several ways to describe the outline (fixed size, aspect ratio + utilization, explicit boundary points), and mixing incompatible assumptions across these options is the single most common cause of a surprising result. Check the control type first — are you specifying a fixed die size, a target utilization + aspect ratio, or explicit polygon coordinates? Each interprets the same numbers completely differently.
No — this is not a minor warning, and treating it as one is a common but costly mistake. "Inside the core boundary" tells you nothing about whether the macro is sitting on a legal manufacturing/block-grid coordinate. An off-grid or illegally-oriented macro can break several things at once: manufacturing/block-grid requirements, pin access, array-alignment relationships with neighboring instances, and power connectivity — any one of which is a signoff blocker on its own.
Routing tracks are defined by real technology-layer rules — they're not decorative grid lines you can regenerate arbitrarily just to make a check pass. The right first move is confirming the technology-layer definitions themselves: preferred routing direction, pitch, offset, width, whether the track set covers the full core, any restricted regions, and — importantly — whether the tracks were deliberately regenerated at some point in the flow (which can be a legitimate reason for a mismatch).
Whatever overlap or out-of-bounds condition you see visually is just the symptom — the actual bug is whichever constraint or transformation caused it, and debugging means finding that cause, not just nudging the macro back inside the boundary. Work systematically through the likely causes: stale constraints left over from an earlier floorplan iteration, a macro's fixed/movable status being wrong, orientation-dependent dimensions changing after a rotate/mirror, an unintended snap movement, a relative-location constraint pulling it out of place, a voltage-area conflict, or simply having loaded the wrong floorplan version.
Think of it like a painted parking space directly underneath a building — it still shows up as a marked space on the map, but no car can ever actually park there. Rows left under a macro or blockage are the placement-area equivalent. The danger is concrete: these rows inflate the nominal row-area / placeable-capacity number, which can mislead early utilisation and legality checks into looking healthier than the design actually is.
The uncomfortable reality of this conflict is that both constraints can be individually valid and still be jointly impossible to satisfy at the same location — this isn't a case of one side simply being wrong. Ownership resolution starts by figuring out which constraint is actually authoritative here: package/interface intent, the block pin constraint itself, the routing blockage, or the PG reservation — and that's a negotiation between whoever owns each of those, not a unilateral PD call.
The report bundling everything into one total count is the trap here — "unused," "reused," and "constraint violation" are three completely different situations lumped into a single number, and treating them as one problem leads to the wrong fix. Separate the classifications before you do anything else — an unused feedthrough is wasted resource, a reused one is often intentional efficiency, and a constraint violation is an actual correctness bug. Mixing them means you might "fix" something that was never broken.
No — a floorplan that only "works" if you ignore the power grid isn't actually a working floorplan, it's a floorplan with a deferred failure baked in. Power planning isn't an afterthought layered on top of a finished floorplan — rings, straps, rails, macro pin access, power-switch corridors, and via paths all need real reserved space, and that reservation has to happen before (or concurrently with) macro placement, not after.
This is a classic trap: the straight-line, center-to-center distance between two macros can look perfectly reasonable while the *actual legal route* between their real pins is much longer — because timing follows routable geometry, not a ruler line drawn between abstract macro centers. Start with the real pin locations, not the macro centers — if the relevant pins sit on the far sides of each macro relative to each other, the effective route is already longer than the naive center-to-center number suggested.
The core discipline here is simple to state and easy to violate under deadline pressure: decide what you're measuring and how you're measuring it *before* you look at which floorplan wins on that metric — otherwise you'll unconsciously pick the metrics that favor whichever option you already prefer. Build one scorecard with declared, written-down definitions for area/utilization, usable-row count, macro legality, channel feasibility, pin constraints, congestion, PG reservation, voltage-area legality, early timing, and change risk — and apply the exact same measurement method to both floorplans.
This is the moment where a pile of reports has to become one owned engineering decision — the gate isn't about running more checks, it's about someone actually deciding what happens next and being accountable for that call. **Proceed** only when the fundamentals are physically credible and reproducible: boundaries, rows, macro legality, feasible channels, constrained pins, feedthrough classification, tracks, PG reservation, voltage-area legality, congestion, and early timing all have to hold up, not just look fine at a glance.