Floorplan in ICC2: A Mentor Guide

Opening promise

What you will be able to do after this chapter

By the end of this chapter you will be able to take a linked, checkable ICC2 block with no shape at all, and turn it into a die with a legal core, rows, and routing tracks; hard macros placed where a reviewer would expect them; a compiled power network; and pins assigned on the right sides, in the right order — and you will be able to prove each of those claims with the tool's own reports, not your impression of the layout view.

Concretely, you will be able to: create an initial floorplan with initialize_floorplan and explain what "core" and "die" mean as distinct, related boundaries; define rows and routing tracks and tell a legal site grid from an illegal one; place hard macros relative to one another with a named, reproducible offset instead of dragging them by eye; reserve space with the correct blockage strength for the stage you actually need to affect; compile a first power network and insert a power switch into a switched domain; assign block-level pins with defensible side, spacing, and layer rules; and compute utilization the way the tool computes it, not by eyeballing a picture.

None of this is about memorizing flags. It is about building the same mental model of "the floorplan is ready" that a design planning lead uses when deciding whether a block is safe to hand to placement — so that when placement congestion or a routing DRC shows up two stages later, you already know which floorplan decision to go back and question first.

Why this stage matters

Why this stage matters in the full flow

A floorplan is the one decision in the whole flow that almost nothing downstream can cleanly undo. Placement can be re-run. Clock tree synthesis can be re-balanced. Routing can be re-attempted with different effort. But a die that is too small for its macros, a macro placed against the wrong edge, or a power ring that leaves a corner starved is a geometry problem, and geometry problems propagate forward as congestion, timing closure difficulty, and IR drop — not as a clean error message at the stage that actually caused them.

This is also the first stage in this guide that produces something you can look at and be wrong about. A floorplan that looks reasonable in the layout view can still have macros placed without a real keepout margin, rows that do not actually align to the site grid at every macro edge, or a power network that is topologically fine but electrically thin in one quadrant. The habit this chapter builds — report before opinion — matters more here than anywhere so far, because floorplan mistakes are the ones a whiteboard sketch cannot catch.

Stage boundary

What enters, what must leave

What does not leave this stage: standard cells placed, a clock tree, or detailed routing. Those belong to Placement and Optimization, Clock Tree Synthesis, and Routing, in that order. This chapter's exit gate is a shape the placer can trust, not a placed design.

Prerequisite knowledge

What you should already be comfortable with

• Everything from Preparing the Design: a linked block, committed power intent where applicable, and a first set of physical and optimization constraints.
• Basic geometry: rectangles, offsets, and the idea of a coordinate grid with an origin at the lower-left.
• What a hard macro is — a pre-designed, fixed-shape block such as an SRAM or a PHY — as distinct from a standard cell.
• Basic Tcl, as used throughout this guide: variables, lists, and running a command with options from icc2_shell.

You do not need prior floorplanning experience. Where this chapter uses a term for the first time, it defines it before relying on it.

Learning objectives

By the end of this chapter, you will be able to…

• Explain the difference between the die boundary and the core boundary, and create an initial floorplan with initialize_floorplan using either as the control reference.
• Define rows and routing tracks, and use report_tracks to confirm what a track command actually created.
• Distinguish channeled, abutted, and narrow-channel floorplan styles, and say what each one costs and buys you.
• Place a hard macro relative to another object with set_macro_relative_location, and run floorplan-stage placement with create_placement -floorplan.
• Choose the correct placement blockage strength for the stage you actually need to affect, and explain why "it shows up in the layout view" is not proof a blockage is doing what you think.
• Compile a first power network with compile_pg and insert a power switch into a switched domain with create_power_switch.
• Set block-level pin constraints and place pins with a defensible, reviewable rationale for every side, layer, and spacing choice.
• Compute achieved core utilization the way the tool computes it, and use modify_die_area to correct a die that misses its target.

Beginner mental model

Think of it as laying out an unfurnished apartment's floor plan

Analogy. In the last chapter you confirmed the lease and checked the utilities. Now you actually draw the floor plan: where the walls go (the die and core boundary), where the floorboards run (rows and tracks — the grid everything else will snap to), where the built-in furniture goes that cannot move once installed (hard macros — the SRAM and DDR PHY), where the electrical wiring and breaker panel go (the power network), and where the doors and windows are cut into the walls (pins). You still are not moving in the everyday furniture — the standard cells — that is next chapter's job. What you need here is a floor plan a contractor could bid on without guessing.

Engineering translation. "Drawing the walls" is initialize_floorplan, choosing whether you are dimensioning the core or the die. "Floorboards" is create_track and derive_tracks, which must align to the site grid the technology file defines. "Built-in furniture" is macro placement, most defensibly done with set_macro_relative_location so a second engineer can see exactly why a macro sits where it does. "Wiring" is compile_pg and, for switched domains, create_power_switch. "Doors and windows" is pin assignment with set_block_pin_constraints and place_pins.

Readiness checklist

Before you open icc2_shell

• You have a target core utilization or a fixed die size from design planning, not a guess.Evidence: a one-line utilization or dimension target, with its source named.
• You know which hard macros exist and have at least a rough placement intent for each one.Evidence: a macro table with names, sizes, and either fixed coordinates or a relative-placement rule.
• You know which power domains are switched, and which strategy each one should compile against.Evidence: confirmation from the power architecture owner, matching the UPF committed in the previous chapter.
• You have a pin intent table for this block's sides, layers, and spacing, even in draft form.Evidence: a pin table from the interface owner, or your own draft awaiting review.

Concepts in dependency order

Building the shape, one dependency at a time

1. Flow boundary and the floorplan database model

Everything in this chapter operates on the same block object the previous chapter linked and saved — floorplanning does not create a new design, it adds physical geometry to an existing one. Before this chapter, the block has no die, no core, no rows, no tracks: every coordinate-based command in this chapter would either error or silently operate on an undefined space. The first real action in this chapter, initialize_floorplan, is what gives the block a coordinate system at all.

Once a floorplan exists, ICC2 tracks it as a set of distinct, related objects: a die boundary, a core boundary, a site array (rows), and independently-managed routing tracks per layer. Commands that change one of these do not automatically change the others — resizing the die does not resize the core unless you ask it to, and neither resizes the routing tracks, which is why modify_die_area and create_track/derive_tracks stay separate concerns throughout this chapter.

2. Channeled, abutted, and narrow-channel floorplans

ICC2 supports three named floorplan styles for hierarchical designs with multiple blocks. A channeled floorplan leaves open space between blocks so the tool can place top-level standard cells and route freely in the gap. An abutted floorplan pushes blocks directly against one another, leaving no room for top-level cells; this avoids wasted area but usually requires over-the-block routing and much more careful clock and feedthrough planning. A narrow-channel floorplan is a deliberate middle ground: some block edges abut, while a narrow channel is reserved only where a specific purpose — typically top-level clock routing — actually needs one.

Figure 3 — Channeled, abutted, and narrow-channel floorplan styles

3. Creating the initial floorplan

initialize_floorplan is the command that gives a linked block its first die boundary, core boundary, site array, and wire tracks in one step. It accepts a -control_type of either core (the default) or die: with core, you specify the core's dimensions and the tool adds the core offset outward to compute the die; with die, you specify the die's dimensions and the tool subtracts the core offset inward to compute the core. Either the exact side lengths (-side_length) or a target utilization (-core_utilization) can drive the sizing, and non-rectangular shapes — L, T, and U — are supported through -shape for designs that need them.

For Nimbus‑8, the core dimension is already fixed by the project's floorplan target at 3.20 mm × 3.20 mm, so this chapter uses -control_type core with an explicit -side_length and a modest -core_offset for the die-to-core margin, rather than deriving the die from a utilization target. Utilization arithmetic, below, shows how utilization is used here in reverse — as a validation check on the achieved density, not as the input that sized the die.

4. Rows, site arrays, and routing tracks

initialize_floorplan creates a default site array and a first set of tracks, but real designs routinely need to redefine tracks explicitly — for a nondefault routing rule, a specific pitch, or a layer the default pass did not cover correctly. create_track creates tracks on a named layer with an explicit pitch (-space), track count, and starting offset; remove_tracks clears existing tracks before a clean re-creation; report_tracks reports the direction, start point, count, and pitch of every track set in the design, which is the only reliable way to confirm a track command did what you intended rather than what you typed.

Where track constraints have already been defined (through set_track_constraint, out of this chapter's scope but worth knowing by name), derive_tracks generates tracks automatically from those constraints across one or more layers, which is less error-prone than hand-specifying pitch and offset per layer once a project has standardized its track rules.

Figure 4 — Die and core anatomy with a rows-and-tracks inset

Figure 5 — Row and track pitch detail

5. Adjusting die size, aspect ratio, and utilization target

A floorplan is rarely right on the first attempt. modify_die_area resizes the core or die of an existing floorplan without starting over: by an explicit scaling factor on area, height, or width; by a target -core_utilization, which the tool uses to compute how much resizing is needed; or by -sizing_type, which fixes one dimension (width, height, or aspect ratio) while the tool solves for the other. -fixed_edges lets you pin specific sides so a resize grows only in the direction you intend, which matters when a macro or pin is already placed against an edge you do not want to move.

6. Utilization arithmetic: from cell area to achieved density

Utilization is not a setting you choose once and trust — it is a measured ratio the tool computes from real geometry with report_utilization: the standard-cell and macro area actually present, divided by the core area actually defined. For Nimbus‑8, working from this guide's fixed teaching numbers (9.90 million standard cells, 72 SRAM macros, one DDR PHY macro, on a 3.20 mm × 3.20 mm = 10.24 mm² core), the worked example below computes an achieved utilization of roughly 82%, with macro area alone accounting for about 24% of the core.

Figure 6 — Floorplan utilization arithmetic

This is also where a target utilization set earlier (as a -core_utilization argument to initialize_floorplan or modify_die_area) gets checked against reality: those commands use the target to size or resize the die before anything is placed; report_utilization tells you what actually landed once macros and standard cells occupy real space.

7. Setting macro constraints and keepouts

Hard macros carry their own constraint surface, separate from ordinary placement blockages: a macro can be given an orientation, a legal placement region, and a keepout margin using the same create_keepout_margin command introduced in Preparing the Design. In a floorplan context, that margin is almost always what keeps the placer from butting a standard cell directly against a macro's pin edge, which is one of the most common sources of legalization failures once real placement begins.

8. Relative macro placement

set_macro_relative_location is the command that makes macro placement reviewable instead of anecdotal: it fixes a target macro's position as a named offset from a named anchor object's corner, rather than an absolute coordinate a second engineer has no way to sanity-check without re-deriving it. The target can be a hard macro or a macro array; the anchor can be another hard macro, a block, an I/O pad, a voltage area, or the core area itself if no anchor is given. report_macro_relative_location confirms the constraint is recorded exactly as intended before anything is placed against it.

Figure 7 — Macro relative placement: target, anchor, corner, and offset

9. Running floorplan-stage placement

Defining relative-placement constraints does not, by itself, place anything — create_placement -floorplan is the command that actually executes macro placement, honoring every set_macro_relative_location constraint in force and applying floorplan-tuned effort and congestion controls distinct from ordinary coarse placement. This is also the point where application options such as plan.macro.style (on-edge, freeform, or an automatic mix) and plan.place.auto_create_blockages (automatic thin-channel blockage creation between macros) start to matter, though this chapter treats their defaults as adequate for Nimbus‑8 and flags them by name for later tuning rather than covering every option in depth.

10. Reserving space with placement blockages

Placement blockages, introduced for physical constraints in the previous chapter, do real work at the floorplan stage: reserving a region for a future macro that has not been placed yet, protecting a thin channel between two hard macros from being silently filled with standard cells, or capping density near a pad ring margin with a partial blockage instead of forbidding placement outright. The strength you choose determines which later stages honor it — a distinction that matters more here than anywhere else in the flow, because a floorplan-stage blockage chosen at the wrong strength quietly stops protecting its region the moment legalization or optimization runs.

Figure 8 — Placement blockage strength gallery

11. Power planning interfaces: domains, PG nets, and routing mode

Floorplan is where the power intent committed in the previous chapter becomes physical. connect_pg_net, already introduced for logical PG connectivity, is the same command used here as the entry point into physical power planning — without real connectivity in place, there is nothing for a compiled power network to attach to. From there, the design's PG routing mode (which strategy patterns are legal, and on which layers) is set up through the power planning strategy commands this chapter treats as configuration, deferring their full option surface to the reference documentation, and used directly by compile_pg in the next concept.

12. Building the power network: rings, mesh, and rails

compile_pg is the single command that builds the actual power and ground network — straps, rings, macro connections, standard-cell connections, and vias — from one or more named power planning strategies you have defined in advance. It supports an -ignore_drc escape hatch for exploratory passes, a -show_phantom preview mode, and an -undo option for backing out a strategy that did not work, but the default, careful path is: define a strategy, compile it, and check the result before moving on.

Figure 9 — Power ring, mesh, and standard-cell rail pattern

13. Inserting power switches for switched domains

A switched power domain needs an actual switch cell between its unswitched input supply and the switched rail its cells connect to — create_power_switch defines that cell: its domain, its input and output supply ports, its control port (the signal that turns it on and off), and optionally an acknowledge port, on/off states, and resistance characteristics for the cells it represents. This is a UPF-adjacent, power-architecture-defined object, not a purely physical one — the switch's electrical behavior comes from the power intent, and floorplanning is where it becomes a real, placeable, physical cell.

Figure 10 — Power switch inserted in a switched power domain

14. Block pin constraints and pin placement

Block-level pin rules are set with set_block_pin_constraints: which layers pins may use, how much spacing separates adjacent pins, how much keepout distance protects a block's corners, and which sides are allowed or explicitly excluded. The reference documentation itself flags set_block_pin_constraints as scheduled for retirement in favor of create_block_pin_constraint in later releases — both exist in this release, and this chapter uses the still-current command while naming its replacement, exactly the kind of transition worth knowing about before it surprises you in a release upgrade. place_pins is the command that actually places pins — on specified cells, nets, pins, or ports — honoring every constraint set beforehand, with a -legalize option for adjusting existing pin placement into compliance rather than starting over.

Figure 11 — Block pin constraints: sides, spacing, and corner keepout

15. Validating the floorplan before handoff

The floorplan exit gate rests on the same principle as the previous chapter's: prove it, do not assume it. report_utilization confirms achieved density against the target. Floorplan rule validation (density, spacing, enclosure, and area rules for advanced technology nodes, covered by name here since this guide's teaching node does not require deep coverage of them) catches geometry that violates a technology-specific constraint the layout view will not visually flag. Power network integrity checks — named here, detailed further in later chapters where routing makes them fully actionable — catch missing vias and connectivity gaps. Together with the reports in Reports and how to read them, these are what actually justify a handoff to Placement and Optimization.

Command cards

The commands worth knowing cold

Every card below follows the same eight-point shape used throughout this guide, and every syntax line has been checked against the ICC2 Tcl command reference for this release. Where your installed release differs, trust man <command> over this page.

Die, core, and rows Sizing and utilization Macro placement Reserving space Power planning Pin assignment

Worked example

Nimbus‑8: floorplanning a teaching design end to end

Continuing from the previous chapter's saved checkpoint: 9.90 million standard cells, 72 SRAM macros, one DDR PHY hard macro, a 3.20 mm × 3.20 mm core target, and four clocks. This chapter works the single-voltage path for Nimbus‑8 itself; the switched-domain power-switch flow is exercised on Lyra‑2 in the mini lab below, reusing the PD_SWITCHED domain already established for it.

Step 1 — reopen the checkpoint

icc2_shell> open_lib ../libs/nimbus8_lib
icc2_shell> current_block
{nimbus8_top}

Proof: current_block returns the same block the previous chapter saved, confirming this chapter is building on validated state, not a fresh unlinked design.

Step 2 — initial floorplan

icc2_shell> initialize_floorplan -control_type core \
   -side_length {3200 3200} -core_offset {40 40 40 40}
/* core fixed at 3.20mm x 3.20mm per teaching target; 40um core_offset on every side */

Proof: a floorplan report shows a 3200 × 3200 (micron) core and a 3280 × 3280 die, and the layout view shows a nonzero core area for the first time in this guide.

Step 3 — rows and tracks

icc2_shell> remove_tracks -all
icc2_shell> create_track -layer METAL3 -space 0.5
icc2_shell> report_tracks
Layer          Direction     Start         Tracks    Pitch          Attr
------------------------------------------------------------------------
METAL3             Y         0.250          6398     0.500       default

Proof: the reported pitch and direction match what was requested; the track count is consistent with a 3.20 mm core at a 0.5 µm pitch, not a stale default from initialization.

Step 4 — macro constraints and relative placement

icc2_shell> create_keepout_margin -outer {10 10 10 10} nimbus8_ddrphy
icc2_shell> set_macro_relative_location \
   -target_object [get_cells nimbus8_sram_01] -target_orientation R0 -target_corner bl \
   -anchor_object [get_cells nimbus8_ddrphy] -anchor_corner tl \
   -offset {0.0000 20.0000} -offset_type fixed
icc2_shell> report_macro_relative_location

Proof: report_macro_relative_location lists the constraint with the exact target, anchor, corners, and offset intended — before anything has actually moved.

Step 5 — run floorplan placement

icc2_shell> create_placement -floorplan

Proof: the layout view shows the DDR PHY macro and its relatively-placed SRAM neighbor at the intended offset; report_macro_relative_location re-run against actual placed coordinates confirms the constraint was honored, not just recorded.

Step 6 — reserve the routing channel and check utilization

icc2_shell> create_placement_blockage -boundary {{1550 200} {1650 3000}} \
   -type hard -name ddrphy_channel_reserve
icc2_shell> report_utilization -verbose
Utilization: 81.9%

Proof: the reported utilization matches the arithmetic worked out in Utilization arithmetic — roughly 82%, not an assumed or carried-forward target number.

Step 7 — power network

icc2_shell> connect_pg_net -automatic
icc2_shell> compile_pg -strategies {core_ring core_mesh std_cell_rail}
/* single-voltage: one strategy set covers the whole core */

Proof: a power network integrity report shows zero missing vias, and the layout view shows a ring at the core perimeter, a mesh crossing the interior, and rails at every standard-cell row.

Step 8 — pin assignment

icc2_shell> set_block_pin_constraints -allowed_layers {M2 M3 M4 M5 M6 M7 M8 M9} \
   -pin_spacing 5 -corner_keepout_num_tracks 5
icc2_shell> place_pins -self

Proof: a pin report shows every top-level port placed, on an allowed layer, with the specified spacing and corner keepout honored.

Step 9 — checkpoint

icc2_shell> save_lib nimbus8_lib
Saving library 'nimbus8_lib'
1

Checkpoint / rollback point: this is the floorplan Placement and Optimization will build on. Treat the return value 1 as confirmation, the same discipline carried from the previous chapter.

Figure 12 — Nimbus‑8 floorplan exit snapshot

Visual inspection guide

What to look for in the GUI

As in the previous chapter, no screenshots are supplied — the habit of looking with intent outlasts any static picture. After each step above, open the layout view and check:

• After initialize_floorplan: does the core outline match the 3.20 mm × 3.20 mm teaching dimension, with a visibly distinct die boundary offset outward by the core offset?
• After track creation: zoom in far enough to see individual track lines, and confirm the pitch visually matches the numeric value reported — a pitch off by a factor of ten is a common, easy-to-miss unit mistake.
• After macro placement: does the SRAM macro placed relative to the DDR PHY actually sit at the offset you specified, not just "somewhere nearby"?
• After compile_pg: toggle power/ground layers on their own, separate from routing layers, and confirm ring, mesh, and rail all appear as distinct, connected tiers, not a single undifferentiated mass.
• After place_pins: confirm pins landed on the sides and layers you specified, and that no pin sits inside a keepout margin or placement blockage you defined earlier.

Reports and how to read them

Reading proof, not just running commands

Stage completion checklist

The Floorplan exit gate

This is the same checklist a careful design planning reviewer would use before approving a handoff to Placement and Optimization. Every item names its evidence; "looks fine" is not evidence.

• Die and core boundaries match the intended dimensions and control type.Evidence: a floorplan report compared line by line against the design planning target.
• Rows and tracks are legal on every layer that matters, with no stale or default track sets left unreviewed.Evidence: report_tracks output for every layer touched.
• Every hard macro is placed with a traceable constraint, not a manual coordinate.Evidence: report_macro_relative_location matching the macro placement table.
• Every macro carries a real keepout margin at the correct strength.Evidence: keepout report or get_attribute check on every macro.
• Placement blockages are named, scoped, and set to the strength that actually protects the stage intended.Evidence: get_placement_blockages reviewed strength by strength.
• Achieved utilization is measured, documented, and reconciled with the target.Evidence: report_utilization -verbose output kept with the checkpoint.
• The power network is compiled with no missing vias or unresolved connectivity gaps.Evidence: power network integrity report reviewed line by line.
• Every switched domain has a real, correctly associated power switch.Evidence: power switch report matching the power architecture owner's domain list.
• Block pin constraints match the interface specification, and every pin is placed accordingly.Evidence: report_block_pin_constraints and the post-placement pin report, both checked.
• Floorplan rules for the target technology node are validated, or findings are tracked.Evidence: floorplan rule validation output, or an issue register entry for anything outstanding.
• Saved checkpoint, logs, reports, and manifest are reproducible.Evidence: a second engineer can open_lib your saved checkpoint and reproduce the same reports.

Mini lab

Lab: inserting a power switch into Lyra‑2's PD_SWITCHED domain

Lyra‑2, the small multivoltage teaching design from the previous chapter's mini lab, already carries two power domains — PD_ALWAYS_ON and PD_SWITCHED — and a DEF with a floorplan already defined, including a region reserved for PD_SWITCHED. This lab picks up exactly there: PD_SWITCHED has a physical home, but nothing yet actually switches it. All numbers remain synthetic teaching data.

Setup

• Lyra‑2's design library, with its committed UPF (lyra2.upf) and the DEF-derived floorplan reopened from the previous chapter's checkpoint.
• Confirmation from the power architecture owner of the intended control signal name and polarity for PD_SWITCHED.

Tasks

1. Reopen the Lyra‑2 checkpoint and confirm the PD_SWITCHED voltage area still resolves correctly with report_voltage_areas -verbose.
2. Define a power switch with create_power_switch for PD_SWITCHED, with an unswitched input supply, a switched output supply, and a control port matching the owner's specification.
3. Compile the power network for both domains with compile_pg, using a strategy set that covers PD_ALWAYS_ON and PD_SWITCHED separately.
4. Run a power network integrity check and resolve or document every finding.
5. Save the checkpoint and write a one-paragraph handoff note, as if for a reviewer who has not seen this lab, stating the control polarity you used and why.

Expected observations

The switched rail inside PD_SWITCHED should show no power connectivity until the switch's control port is driven active; if your first compile_pg pass reports a connectivity gap on the switched rail, check whether the switch was defined before or after connect_pg_net ran for that domain — sequencing this incorrectly is a common first-attempt mistake, not a tool defect.

Cleanup

Close the library with close_lib once you have confirmed the saved checkpoint reopens cleanly with open_lib in a fresh session, the same discipline as the previous chapter's lab.

Interview questions

25 questions worth being able to answer cold

Glossary

Terms used in this chapter

Abutted floorplan

A floorplan style with no channel between blocks; blocks touch directly.

Channeled floorplan

A floorplan style with open space between blocks for top-level cells and routing.

Checkpoint

A saved, reopenable state of a design library on disk, written with save_lib.

Core boundary

The inner region of a floorplan holding standard cells and macros.

Core offset

The margin between the die boundary and the core boundary.

Core utilization

The fraction of core area occupied by standard-cell and macro area, either as a target or as a measured, achieved figure.

Die boundary

The outer physical edge of the chip.

Keepout margin

A region around a fixed object, inner or outer, where no other cell may be placed. Carried forward from Preparing the Design; used heavily around macros in this chapter.

Narrow-channel floorplan

A floorplan style mixing abutted edges with a channel reserved only where a specific purpose needs one.

Placement blockage

A named region with a declared strength limiting what may be placed inside it. Strength determines which stages honor it.

Power ring

A power and ground network tier running around the core perimeter.

Power mesh

A coarser power and ground network tier crossing the core's interior on upper metal layers.

Power switch

A cell inserted between an always-on supply and a switched domain's rail, controlled by a defined control port.

Relative placement constraint

A rule fixing one macro's position as an offset from a named anchor object's corner.

Routing track

A line on a routing layer, at a defined pitch, that wires on that layer are expected to align to.

Site array / row

The grid of legal standard-cell placement sites, laid out as horizontal rows.

Standard-cell rail

The finest tier of the power network, feeding individual standard-cell rows.

Switched domain

A power domain whose supply can be turned off by a power switch under control-signal direction.

Self-check questions

Test yourself before moving on

1. Explain, in one sentence each, what changes between -control_type core and -control_type die on initialize_floorplan.
2. A macro you constrained with set_macro_relative_location is not where you expect after create_placement -floorplan. Name two things you would check before assuming the constraint is wrong.
3. Why does this chapter recommend defining routing tracks before running macro placement, not after?
4. You need a region to stay clear of standard cells through legalization and CTS, not just coarse placement. Which blockage strength do you use, and why not soft or partial?
5. Explain why report_utilization is described in this chapter as a measurement, and a target -core_utilization value as a plan.
6. Name the three tiers of a compiled power network, and state which failure mode — not a routing error — a gap in any tier produces.

Answers

1. With core, your dimensions apply to the core and the offset is added outward to compute the die. With die, your dimensions apply to the die and the offset is subtracted inward to compute the core.
2. Whether create_placement -floorplan was actually re-run after the constraint was added, and whether the constraint's anchor and target corners were set as intended, via report_macro_relative_location.
3. Because redefining tracks after macros are placed can shift the effective pitch relative to macro pins already positioned against the old grid.
4. Hard. Soft, partial, and category blockages bind coarse placement only, by default, and stop protecting a region once legalization or optimization runs.
5. The target value sizes the die before anything is placed; only report_utilization, run after macro and standard-cell placement, reflects what actually occupies the core.
6. Ring, mesh, and rail. A gap at any tier shows up as IR drop, not as a routing error.

Part summary

What to carry forward

Sign-off checklist

Before you call this stage done

This is the same eleven-item exit gate from earlier in this chapter, repeated here as the final gate before handoff. See Stage completion checklist for the full evidence requirements attached to each item.

• Die and core boundaries match the intended dimensions and control type.
• Rows and tracks are legal on every layer that matters.
• Every hard macro is placed with a traceable constraint.
• Every macro carries a real keepout margin at the correct strength.
• Placement blockages are named, scoped, and set to the correct strength.
• Achieved utilization is measured, documented, and reconciled with target.
• The power network is compiled with no missing vias or unresolved gaps.
• Every switched domain has a real, correctly associated power switch.
• Block pin constraints match the interface specification, and pins are placed accordingly.
• Floorplan rules for the target technology node are validated, or findings are tracked.
• A saved checkpoint, with logs, reports, and manifest, reproduces cleanly for a second engineer.

Last word

Last word and bridge to Placement and Optimization

This chapter drew the shape everything else in this guide will be built inside of. That shape is now mostly fixed: the die will not casually resize again, hard macros will not casually move, and the power network's topology is set. What comes next fills that shape in. When placement congestion looks worse in one corner of the die than everywhere else, or a net refuses to route cleanly near a macro edge, the first productive move is almost always back here: is the keepout margin really what you think it is, is the blockage strength really what the stage in question honors, is the power mesh really covering that region.