Placement and Optimization 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 legal, checkable Floorplan — die and core sized, macros placed, power compiled, pins assigned, but not one standard cell placed — and turn it into a fully placed, legalized, timing- and congestion-optimized design ready for clock tree synthesis, using the same command whether you run it as one step or five.

Concretely, you will be able to: run place_opt end to end and explain what each of its five internal stages actually does; run the same work as discrete steps with create_placement and legalize_placement when you need that control; steer placement with timing-driven, congestion-driven, and buffering-aware options instead of accepting whatever the default gives you; enable IR-drop-aware placement, concurrent clock and data optimization, and physical guidance from Design Compiler when a design calls for them; bank single-bit registers into multibit cells; pull a cluster of logic toward a fixed anchor with magnet placement; and prove every one of these worked with report_placement, report_utilization, and a placement status query — not with an impression of the layout view.

As with every chapter in this guide, the goal is not memorizing flags. It is building the same judgment a placement lead uses when deciding whether a design is actually ready for clock tree synthesis, so that when a CTS or routing problem shows up two stages later, you already know whether it traces back to a placement decision made here.

Why this stage matters

Why this stage matters in the full flow

Floorplan decided whether the design fits. Placement and Optimization decides whether it works — whether timing closes, whether the design is routable without heroics, whether power density stays sane, and whether area is spent efficiently. This is the stage where most of a project's timing and congestion story actually gets written, because it is the first point where every one of a design's millions of standard cells has a real, specific location and a real, specific set of neighbors.

It is also the stage most beginners underestimate, because place_opt looks like a single command. It is not one decision; it is five, each with its own job, each capable of being run alone when a specific problem calls for it. Treating it as "run place_opt and see what happens" is how a design ends up re-run three or four times with no clearer idea of what changed between attempts than at the start.

Stage boundary

What enters, what must leave

What does not leave this stage: a real clock tree (only a temporary, optional trial clock tree used internally, if enabled, and discarded before clock tree synthesis), or detailed routing. Those belong to Clock Tree Synthesis and Routing, in that order. This chapter's exit gate is a fully placed, timing-checked design a clock tree can be built on top of — not a routed one.

Prerequisite knowledge

What you should already be comfortable with

• Everything from the Floorplan chapter (not included in this standalone package): a legal die and core, placed macros, a compiled power network, and assigned pins.
• Basic timing vocabulary: slack, setup and hold, and the idea that a "violation" is a number, not a feeling.
• What a buffer and an inverter do in a netlist, at least conceptually — this chapter buffers nets by the million without re-explaining what buffering is.
• Basic Tcl, as used throughout this guide: variables, lists, and running a command with options from icc2_shell.

You do not need prior placement or optimization 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 place_opt's five stages — initial_place, initial_drc, initial_opto, final_place, final_opto — and run any subset of them with -from and -to.
• Run standalone coarse placement and legalization with create_placement and legalize_placement, and say when that control is preferable to the combined command.
• Turn on timing-driven, buffering-aware, and congestion-driven placement, and control the CPU effort spent on each.
• Merge clock-gating cells before placement and explain why sequencing that before place_opt changes what the command does internally.
• Enable IR-drop-aware placement and concurrent clock and data (CCD) optimization, and state what each one actually changes about the placed design.
• Bank single-bit registers into multibit cells with identify_multibit, and split a bank back apart with split_multibit when it hurts more than it helps.
• Use magnet placement to pull a cluster of logic toward a fixed anchor, and refine an existing placement's congestion with refine_placement.
• Prove a placement is actually done with report_placement, report_utilization, and a placement-status query — not a glance at the layout view.

Beginner mental model

Think of it as moving the everyday furniture into a finished floor plan

Analogy. The previous chapter drew the floor plan and installed everything that cannot move — the built-in furniture (hard macros), the wiring (the power network), and the doors and windows (pins). This chapter moves in everything else: the desks, chairs, and shelves — the standard cells — and then walks through the apartment adjusting them room by room. First a fast, rough drop of every piece somewhere reasonable (initial_place). Then a walk-through making sure nothing blocks a doorway or a hallway (initial_drc: fixing up nets with too many branches, buffering long runs). Then a real arrangement pass for comfort and function (initial_opto: timing, area, congestion, leakage). Then small nudges so walking paths are clear (final_place: incremental re-placement plus legalization). Then a last, careful adjustment pass before guests arrive (final_opto).

Engineering translation. All five of those moves are what place_opt does in one command, in order, by default. "A fast rough drop" is coarse placement, also runnable alone with create_placement. "Making sure nothing blocks a doorway" is initial DRC fixing — high-fanout net synthesis and electrical DRC repair. "A real arrangement pass" is timing/area/congestion/leakage optimization. "Small nudges, then legalize" is incremental placement followed by legalize_placement—also runnable alone. "A last adjustment pass" is final optimization, where concurrent clock and data optimization and further legalization happen.

Concepts in dependency order

Filling in the shape, one dependency at a time

1. The place_opt command and its five stages

place_opt performs coarse placement, physical optimization, and legalization in a single command, and by default runs all five of its internal stages in order: initial_place, where the tool merges clock-gating logic and performs coarse placement (and scan chain optimization, if a SCANDEF was read in); initial_drc, where the tool removes existing buffer trees and performs high-fanout-net synthesis and electrical DRC violation fixing; initial_opto, where the tool performs timing, area, congestion, and leakage-power optimization; final_place, where the tool performs incremental placement to improve timing and congestion, and legalizes the design; and final_opto, where the tool performs further optimization and legalization to improve timing and congestion.

The command supports multithreading, using the number of threads set by set_host_options -max_cores. Running it with no options at all executes every stage; that default behavior is the right starting point for a first pass on any new design.

2. Standalone placement and legalization

Everything place_opt does for coarse placement and legalization is also available as two separate commands: create_placement performs coarse placement (and, when a SCANDEF was read in, scan chain optimization), and legalize_placement executes detailed placement — moving cells onto real, legal, non-overlapping site positions without changing the netlist. Running these directly, instead of through place_opt, gives you control that the combined command does not expose as cleanly: legalizing only a named list of cells or a bounded region, for instance, rather than the whole design.

3. Staging place_opt with -from and -to

-from and -to let you run any contiguous subset of the five stages: if you do not specify -from, the tool begins from initial_place; if you do not specify -to, it continues through final_opto. This is how you re-enter the flow after fixing something upstream without re-running stages that already converged — for example, running only place_opt -from initial_drc on a design that already has a good coarse placement, to avoid re-placing it from scratch.

-list_only prints the five stage names without running anything, a quick way to confirm the exact stage names your release expects before scripting around them.

4. Timing-driven, buffering-aware, and congestion-driven placement

create_placement (and, through it, place_opt's coarse-placement behavior) supports several modes that change what coarse placement actually optimizes for. -timing_driven enables timing-driven placement outright. -buffering_aware_timing_driven uses an approximate timing model that estimates the effect of buffers that will be added later on long and high-fanout nets, without changing the netlist itself — intended specifically as a better starting point for later timing optimization, not a substitute for it. -congestion enables congestion-driven placement, with -congestion_effort (low, medium, or high) controlling how much CPU effort is spent avoiding routing hot spots; expect a real runtime cost at high effort.

Figure 4 — Timing-driven and congestion-driven placement, side by side

5. Clock-gating cell optimization during placement

By default, place_opt merges clock-gating cells at the start of initial_place (or, when the Synopsys physical guidance flow is enabled, at the start of initial_opto). If merge_clock_gates has already been run beforehand, place_opt does not merge again. place_opt can go further: if the place_opt.flow.optimize_icgs application option is enabled, the tool performs clock-aware placement of critical clock-gating cells, builds a temporary clock tree specifically to identify timing-critical clock gates, and can split a clock-gating cell if the enable pin of the gate sits on a critical timing path.

6. Trial clock tree and clock-gate latency accuracy

place_opt uses ideal clock information by default. Setting the place_opt.flow.trial_clock_tree application option to true tells the tool to build a temporary clock tree and use propagated clocks during placement and optimization instead; Clock Tree Synthesis later removes this temporary tree and builds the real one. Independently, the tool estimates and updates clock-gate latencies throughout the place_opt flow by default, to make datapath and useful-skew optimization more accurate while clocks are still ideal — specifying real clock tree synthesis settings (buffers, inverters, nondefault routing rules) before running place_opt improves the accuracy of that estimate. A dont_estimate_clock_latency attribute, set with set_attribute on a specific clock-gate's clock pin, opts that one gate out of the estimate.

7. High-fanout synthesis and rebuilding buffer trees

During initial_drc, place_opt performs high-fanout net synthesis, building buffer trees for nets with too many loads for a single driver to handle well. By default this uses virtual routes; setting the place_opt.initial_drc.global_route_based application option to 1 switches it to use global routes instead, which for fragmented floorplans can improve timing and reduce congestion. Combined with place_opt.initial_place.two_pass set to true, the tool runs an integrated two-pass initial placement: wire-length-driven placement, a trial high-fanout synthesis pass whose results are discarded, then timing-driven placement that proceeds into global-route-based high-fanout synthesis for real.

After place_opt has run, if a specific buffer tree needs to be rebuilt to meet a requirement that changed later, create_buffer_trees rebuilds it explicitly — by default for all high-fanout nets, or for one named net with -from.

Figure 5 — High-fanout buffer tree, before and after

8. Path optimization and nondefault routing rules for critical nets

Two further, independently-enabled behaviors improve timing QoR during place_opt. Setting place_opt.flow.do_path_opt to true turns on path optimization — an incremental capability focused specifically on improving individual timing paths' QoR. Setting place_opt.flow.optimize_ndr to true lets the tool apply nondefault routing rules to timing-critical nets during preroute optimization, and guide the router to honor those assignments later as soft constraints.

9. IR-drop-aware placement

During placement, the tool can use the voltage (IR) drop values of cells to identify areas of high power density and spread those cells out, reducing local density. This requires an external voltage-drop analysis source — RedHawk Fusion, set up and run separately — that this guide names but does not cover in depth, since it lives outside the ICC2 User Guide's own scope for this chapter. The ICC2-side procedure is: run place_opt -to final_place to get through final placement; perform static or dynamic voltage-drop analysis with analyze_rail -voltage_drop (after the external setup); enable place.coarse.ir_drop_aware; and rerun with place_opt -from final_place to let the tool use the voltage-drop values on the next pass.

Figure 6 — IR-drop-aware placement, before and after

10. Concurrent clock and data (CCD) optimization

Concurrent clock and data optimization applies useful-skew techniques during the final optimization stage — adjusting clock arrival times at registers to take advantage of positive slack elsewhere in the path. It is enabled by default during final_opto; setting place_opt.flow.enable_ccd to false turns it off. The clock-latency adjustments it derives are stored as offsets (via set_clock_latency -offset and set_clock_balance_point -offset), visible with write_script -format icc2, but not captured in an SDC written with write_sdc. To use CCD meaningfully, the same scenarios active for clock_opt should be active for place_opt, and the tool needs either a trial clock tree (place_opt.flow.trial_clock_tree or place_opt.flow.optimize_icgs set true) or accurate ideal clock latencies on every clock-gating and sequential cell.

Figure 7 — Concurrent clock and data optimization: useful skew

11. Physical guidance from Design Compiler

When starting placement from a Design Compiler Graphical placement instead of from scratch, ICC2 can use that placement as a starting point — reducing placement runtime and improving correlation between the two tools. The DC-side netlist transfers as Verilog with constraints; physical information (die area, site rows, tracks, port locations, macro and cell placement, route guides, prerouted nets, and placement blockages) transfers by reading a DC-generated DEF file with read_def -add_def_only_objects {cells} -convert_sites. Physical constraints DEF does not carry — voltage area definitions, layer constraints, special route guides with utilization, and special blockages with blocked layers — must be applied separately in a Tcl file. Setting place_opt.flow.do_spg to true before running place_opt enables this Synopsys physical guidance (SPG) flow.

Figure 8 — Physical guidance from Design Compiler to ICC2

12. Multibit register optimization

ICC2 can combine (bank) single-bit registers, or smaller multibit register banks, into equivalent larger multibit register cells — merging only registers that share the same timing constraints, and copying those constraints to the resulting bank. Banking reduces area (shared transistors, optimized transistor-level layout), total clock tree net length, and clock tree buffer count and power. The tool can also split (debank) a multibit register into smaller banks or single-bit cells if doing so improves total negative slack, and on libraries with mixed-drive-strength multibit cells, it can rewire a violating path through a higher-drive-strength bit of an existing bank.

Banking can run integrated inside place_opt (enable place_opt.flow.enable_multibit_banking, optionally place_opt.flow.enable_multibit_debanking) or as discrete steps: identify_multibit finds banking opportunities and either applies them directly (-apply) or writes a script of create_multibit commands to review first (-output_file); split_multibit reverses a bank, by name, by slack threshold, or by path group; report_multibit reports what actually exists.

Figure 9 — Multibit register banking

13. Magnet placement and refining placement

magnet_placement pulls the standard cells connected to a fixed anchor object — a fixed macro, a macro pin, or an I/O port — close to it, which can improve congestion around a complex floorplan or improve timing for a specific cluster of logic. Best run before standard-cell placement, it accepts a magnet object plus an optional -cells list restricting exactly which cells get pulled; cells form a contiguous data path from the magnet, or nothing moves. -logical_levels controls how many logic levels from the magnet are considered, and -stop_by_sequential_cells / -stop_on_sequential_cells stop the pull at a register boundary.

After a placement exists, refine_placement performs incremental congestion-optimizing placement on the whole design (or, with -coordinates, one bounded region) without touching the netlist — useful for a targeted congestion cleanup pass after the main place_opt flow has otherwise converged.

Figure 10 — Magnet placement: pulling a contiguous data path

14. Multivoltage-aware placement and optimization

Placement and optimization automatically account for multivoltage constraints. During placement, the tool places cells within their associated voltage area, and places level shifters and isolation cells close to voltage-area boundaries. During optimization, when the tool needs to insert a buffer, it analyzes the power states of the driver and loads' supplies (from the UPF power-state table or power-state groups) and chooses a buffering supply that avoids introducing a new multivoltage violation, preferring single-rail buffers over dual-rail ones to save power, area, and improve routability. check_bufferability answers, for a specific net segment and voltage area, whether a legal buffer actually exists to insert.

Figure 11 — Bufferability across a voltage-area boundary

15. Analyzing the result: utilization, placement QoR, and status

report_utilization reports achieved density from real geometry, exactly as in the previous chapter, optionally scoped to specific objects with -of_objects or to a named configuration created with create_utilization_configuration. report_placement is the placement-specific QoR report: by default it reports total half-perimeter wire length for all nets plus any placement violations, and supports narrower views — physical hierarchy violations, voltage-area violations, hard-macro overlap, and more — through its many options. Every cell instance carries a placement status — unplaced, placed, fixed, legalize_only, or locked — queryable with get_attribute and settable with set_placement_status, which is how you lock a cell's location against further movement by the tool while still allowing manual edits.

16. Diagnosing issues optimization could not fix

Two commands exist specifically to explain a stubborn problem rather than fix it directly. check_bufferability analyzes whether a net segment can be buffered at all — checking for available supply nets in the target voltage area, suitable library cells, and settings (an ideal-network or don't-touch constraint) that block buffering — and reports why, not just whether. analyze_design_violations generates a categorized, descending-severity report of violations that optimization could not fix, by type (max_trans, setup, hold, static_noise, or only_lib for library settings limiting optimization), which is the right first stop when a design comes out of place_opt with violations that a re-run does not seem to improve.

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.

Placing the design Clock-aware placement Congestion and layout refinement Multibit register optimization Diagnostics before handoff Reporting and status

Worked example

Nimbus‑8: placing and optimizing a teaching design end to end

Continuing from the previous chapter's saved checkpoint: a 3.20 mm × 3.20 mm core at 81.9% floorplan-stage utilization, 9.90 million standard cells, 72 SRAM macros, one DDR PHY hard macro, a compiled power network, and assigned pins. This chapter runs the IR-drop-aware placement procedure end to end on Nimbus‑8's own supply, and banks a portion of its register count into multibit cells.

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 a validated floorplan, not a fresh unlinked design.

Step 2 — merge clock-gating cells before placement

icc2_shell> merge_clock_gates
/* run standalone since this worked example uses create_placement directly, not place_opt, for step 4 */

Proof: a clock-gating cell count taken before and after shows a reduction, with no change to the design's logical behavior.

Step 3 — confirm a clean pre-placement start and capture the QoR baseline

icc2_shell> report_utilization -verbose
Utilization: 0.0%
icc2_shell> report_qor -summary

Proof: the 0.0% reading here is measured standard-cell utilization — expected and correct, since Step 4's coarse placement has not run yet, so no standard cell has a location. It is a sanity check that this run starts clean, not the utilization figure Step 9 compares against; the utilization comparison this chapter cares about is against the floorplan-stage planned figure of 81.9% (the previous chapter's macros-plus-budgeted-cells figure over the fixed 3.20 mm × 3.20 mm core), captured before any Placement and Optimization command ran. The report_qor -summary baseline captured here is what Step 9's post-optimization QoR is measured against — a real "before," not an assumption.

Step 4 — coarse placement, timing- and congestion-driven

icc2_shell> create_placement -timing_driven -congestion \
   -congestion_effort medium

Proof: report_placement run at this point shows a legal-ish, if not yet optimized, placement with a reasonable total wire length for a 9.90-million-cell design at this utilization.

Step 5 — bank Nimbus‑8's register file into multibit cells, before optimization

icc2_shell> identify_multibit -register -apply -slack_threshold 0
icc2_shell> report_multibit

Proof: report_multibit lists the banked cells, confirming only registers with slack at or above the threshold were combined — nothing on a genuinely tight path was pulled into a bank without headroom to spare.

Step 6 — run place_opt through final placement

icc2_shell> place_opt -from initial_drc -to final_place

Proof: starting from initial_drc means this run both legalizes and optimizes the banked netlist from Step 5 — it is the required reoptimization pass, not a separate optional step. Stopping deliberately at final_place, rather than letting final_opto run immediately, leaves the design legalized and ready for the IR-drop-aware placement setup in the next step, per the ICC2 User Guide's own procedure for this feature.

Step 7 — enable IR-drop-aware placement and rerun

/* voltage-drop analysis itself requires RedHawk Fusion, set up separately and out of this guide's scope; */
/* the two icc2_shell-side steps below are what the ICC2 User Guide documents for this release */
icc2_shell> set_app_options -name place.coarse.ir_drop_aware -value true
icc2_shell> place_opt -from final_place

Proof: a before-and-after voltage-drop heatmap (from the external analysis source) shows the previous power-density hot spot spread over a wider area, and report_placement confirms no new placement violations were introduced by the rerun.

Step 8 — check tie cells

icc2_shell> report_multibit
icc2_shell> add_tie_cells

Proof: place_opt inserts tie cells automatically where it creates constant-driven pins during optimization; running add_tie_cells afterward catches anything left undriven — a return of no new insertions is itself the pass evidence.

Step 9 — check placement QoR and utilization against the baseline

icc2_shell> report_placement
icc2_shell> report_utilization -verbose
Utilization: 79.4%

Proof: compare this reading against the floorplan-stage planned baseline (81.9%) named at the top of this worked example, not against Step 3's 0.0% (that was a pre-placement sanity check, not a utilization baseline — standard cells had no location yet). Here the illustrative before/after shows utilization moving from the floorplan-stage planned 81.9% down to a measured 79.4% — consistent with Step 5's banking reducing cell count and therefore occupied area inside the same fixed 3.20 mm × 3.20 mm core, not a contradiction of it. report_placement shows no unresolved violations. Never assume utilization is unchanged after a netlist-changing operation like banking; measure it.

Step 10 — lock the DDR PHY's companion logic before CTS

icc2_shell> set_placement_status fixed [get_cells nimbus8_ddrphy_ctrl*]
icc2_shell> get_attribute -objects [get_cells nimbus8_ddrphy_ctrl_top] -name status

Proof: the status query confirms fixed took effect on the queried cell, protecting this cluster's now-converged placement from being disturbed by clock tree synthesis's own optimization passes next chapter.

Step 11 — checkpoint

icc2_shell> save_lib nimbus8_lib
Saving library 'nimbus8_lib'
1

Checkpoint / rollback point: this is the placed, optimized, reoptimized-after-banking design Clock Tree Synthesis will build on. Treat the return value 1 as confirmation, the same discipline carried from every previous chapter.

Figure 12 — Nimbus‑8 placement and optimization exit snapshot

Visual inspection guide

What to look for in the GUI

As in every chapter so far, no screenshots are supplied — the habit of looking with intent outlasts any static picture. ICC2's GUI offers three map modes purpose-built for this chapter's work: the global route congestion map, the cell density map, and the pin density map. After each major step above, open the layout view and check:

• After coarse placement: does the cell density map show any obviously empty or overcrowded region, before optimization has had a chance to smooth it out?
• After initial_opto or a full place_opt pass: does the global route congestion map show any hot spot you did not expect, given the floorplan's macro layout?
• After IR-drop-aware placement: does the same region that showed high power density before now show a visibly wider spread of high-power cells?
• After multibit banking: spot-check a few banked cells in the layout view — do they sit in a sensible location relative to where their original single-bit registers were?
• After locking cells with set_placement_status fixed: confirm in the GUI (or with a status query) that exactly the intended cluster, and nothing wider, was affected.

Reports and how to read them

Reading proof, not just running commands

Figure 13a — Placement analysis map: six categories into one diagnosis

Figure 13b — Placement analysis map: diagnosis to exit decision

Analyzing timing

Reading timing at the placement stage, not skipping it

Timing is automatically updated whenever a command needs it — report_timing included. Use update_timing explicitly when you want a fresh, known-current timing snapshot before comparing two moments in the flow, rather than relying on an implicit update buried inside whatever you run next.

Reading one timing path before running anything

Figure 14 — One report_timing path, top to bottom, with its five fields called out

Before the commands, know what a single reported path is telling you. Every report_timing path names a startpoint (where the signal launches, usually a register's clock pin or an input port) and an endpoint (where it is captured, usually a register's data pin or an output port), grouped into a path group. The report gives an arrival time (when the signal actually gets there, accumulated delay along the path) and a required time (the latest, or earliest, it is allowed to arrive, set by the clock period and any constraint). Slack is required time minus arrival time for a max-delay (setup) path; a positive slack means the path passes with that much margin, a negative slack means it is late by that much.

Analyzing power

Reading a power report without comparing apples to oranges

Power is calculated and reported with report_power. Before running it, know which leakage-power calculation method is active, since it changes the numbers you get back.

icc2_shell> set_app_options -name power.leakage_mode -value average

To include composite current source (CCS) receiver-model capacitance in power analysis and reporting, set power.use_ccs_rcv_cap to true.

Reading a power report

A default power report names the mode, corner, and scenario it was computed in, the voltage and temperature used, the voltage/temperature/power units, cell leakage power, and a breakdown by power group with leakage power, total power, and percentage of total for each group.

Figure 15 — One report_power summary, group by group, with its five fields called out

Power groups

Running report_power without a specific cell list reports the default power groups (io_pad, memory, black_box, clock_network, register, sequential, combinational). Custom power groups — instance-based or library-cell-based — are created with set_power_group, and the report includes both default and user-defined groups. If a cell qualifies for more than one group, its reporting group is decided by precedence: an instance-level set_power_group assignment first, then a library-cell-level assignment, then the cell's default group.

Cell-based vs. pin-based clock-network power

By default, clock-network power in the clock_network group is cell-based: if any output pin of a cell is on the clock network, the entire cell's power — including every input and output — counts as clock-network power. Setting power.clock_network to pin_based limits it to only the pins actually on the clock network.

icc2_shell> set_app_options -list {power.clock_network pin_based}

report_clock_qor -type power always reports pin-based clock-network power, regardless of this setting — a source of apparent disagreement between the two reports if you forget which one you are reading.

Comparing QoR data

Comparing runs, not judging one run alone

A single run's reports tell you whether that run is internally consistent. They do not tell you whether a change helped. For that, ICC2 generates a web-based QORsum report comparing captured QoR data across runs, through a fixed chain of commands.

1. Configure capture (optional) — set_qor_data_options: pick the leakage/dynamic power scenarios and clock/scenario used for summary rows, and optionally a run name.
2. Capture each run — write_qor_data, once per flow stage you want recorded, each run labeled so it stays distinguishable (for example place_opt, post_cts).
3. Generate the comparison — compare_qor_data, pointing at each captured run's location, builds the QORsum report.
4. View — view_qor_data opens the generated report.

Figure 16a — Five steps to a QORsum report

Figure 16b — Regression check, exit or corrective action

Baseline, shading, and delta style

By default, the first row of data is the baseline run; all other runs are compared against it, and the baseline is highlighted to mark it as the golden result. A different baseline can be chosen from the Runs dialog. Non-baseline cells are shaded red for a degradation and green for an improvement relative to the baseline, with lighter shading for a smaller difference and darker shading for a larger one. Right-clicking the table cycles the display between raw values, a percentage delta against the baseline, and an absolute delta against the baseline (shown in italic). Columns can be sorted by clicking their header (ascending, then descending), and both the visible metrics and the visible runs can be filtered from their respective dialogs.

Nimbus‑8: comparing three placement runs

The single-run worked example earlier in this chapter shows one path through placement. In practice you often run more than one experiment and need to know which is actually better — not just which one has the best single number.

Run 2 has the best worst-slack and the fewest failing endpoints — the number a quick glance would call "best." But it also introduced a new congestion hot spot and raised dynamic power, at a real runtime cost. Run 3 solved congestion cleanly but let timing degrade further. None of the three is unambiguously best; the QORsum comparison is what surfaces the tradeoff, instead of a single report_timing from Run 2 in isolation making it look like a clean win.

Tie cells

Adding and removing tie cells

A constant logic-0 or logic-1 pin needs a real drive source, not a direct wire to a supply rail. A tie cell — a small library cell built to drive a fixed constant — provides that source. place_opt and clock_opt insert tie cells automatically wherever their own optimization creates a constant-driven pin; add_tie_cells and remove_tie_cells give you explicit, standalone control over the same operation.

Figure 17 — Tie-cell concept

Advanced placement and legalization controls

Twenty-two settings that shape placement and legalization beyond the default flow

The worked example and command cards above cover the default place_opt/create_placement/legalize_placement path. The ICC2 User Guide documents a further set of application-option-driven controls — mostly under its "Specifying Placement Settings" and "Specifying Legalization Settings" topics — that shape how placement and legalization behave in specific situations: early-stage constraint uncertainty, clock-gating structure, congestion, wide cells and advanced nodes, dynamic power, and several legalization-quality features. Each entry below is scoped to a specific situation — it is not a general recommendation to enable all of them.

Setup risk

Consequences of inaccurate early placement constraints

Purpose

Let coarse placement continue, with a clear warning trail, when early-stage placement constraints (move bounds, blockages) turn out to be too tight for the cells that must go in them.

Problem it solves

Early in a design cycle, floorplan-stage move bounds and blockages are often drawn before final cell counts and cell sizes are known. If a bound ends up overutilized once real cells are placed, the tool can exit during coarse placement instead of finishing with a diagnosable result.

When to use it

Early design cycles where floorplan constraints are known to be provisional — not as a permanent substitute for fixing an undersized region.

Prerequisites

A block that has already failed, or is expected to fail, coarse placement due to a specific overutilized move bound or blockage-covered region.

ICC2 workflow

1. Set place.coarse.handle_early_data to true before running create_placement/place_opt.
2. Let placement continue into the overutilized region instead of exiting.
3. Read the PLACE-089/PLACE-083/PLACE-084 warning messages the tool prints to locate exactly which move bound is overutilized and by how much.
4. Optionally tune place.coarse.utilization_warning_threshold (default triggers above 90% region utilization) to change when the warning fires.

Commands and options

Commands and options for Consequences of inaccurate early placement constraints

Command / option	Behavior
place.coarse.handle_early_data	app option, default false — continues placement through overutilized/blockage-covered regions instead of exiting
place.coarse.utilization_warning_threshold	app option — utilization percentage (default 90%) above which PLACE-027-class warnings are issued

Expected reports or evidence

PLACE-089 (“Utilization of move_bound_0 is 109%”), PLACE-083, and PLACE-084 warning messages in the placement log, naming the specific overutilized region.

Risks and tradeoffs

This is a diagnostic escape hatch, not a fix — an overutilized region it silently plows through still needs its move bound, blockage, or cell budget corrected before the block is real.

Exit-checklist implication

A block that needed handle_early_data to finish coarse placement is not exit-gate clean until the underlying region-sizing problem the PLACE-089 warning named has been corrected and re-run without the warning.

Clock gating

Automatic group bounds for clock-gating structures

Purpose

Automatically keep an integrated clock-gating (ICG) cell and the sequential cells it drives close together during placement, without hand-authoring a group bound for every clock-gating fanout.

Problem it solves

An ICG cell placed far from the registers it gates lengthens the enable and clock paths it drives, working against both timing and the clock tree that CTS will build later.

When to use it

Any block using integrated clock gating where you have not already defined manual group bounds for the ICG/sequential-cell clusters.

Prerequisites

Clock-gating cells already merged (merge_clock_gates, or the equivalent automatic merge during place_opt's initial_place/initial_opt stage).

ICC2 workflow

1. Set place.coarse.icg_auto_bound to true before coarse placement.
2. The tool creates automatic group bounds at the start of placement and removes them at the end — cells already in another group bound are excluded.
3. Optionally cap fanout per automatic bound with place.coarse.icg_auto_bound_fanout_limit (default 40).

Commands and options

Commands and options for Automatic group bounds for clock-gating structures

Command / option	Behavior
place.coarse.icg_auto_bound	app option, default false — enables automatic group-bound generation for ICG cells and their driven sequential cells
place.coarse.icg_auto_bound_fanout_limit	app option, default 40 — caps how many fanout cells an automatic bound can include

Expected reports or evidence

There is no dedicated report for this feature. Check its effect indirectly via placement proximity of ICG cells to their driven registers (for example a cell-density or congestion map) and via the resulting group-bound set from report_bounds, since it is removed again at the end of placement.

Risks and tradeoffs

An automatic bound only exists during placement itself; it is not a persistent design constraint, so it cannot be inspected after placement completes the way a manually defined group bound can.

Exit-checklist implication

Not a standalone gate item; feeds into the general clock-gating-optimization and congestion checks already on the setup/exit gates.

Density

Placement density control

Purpose

Cap how densely the tool packs cells in a region, either uniformly or specifically to relieve congestion around already-congested areas.

Problem it solves

Left uncontrolled, coarse placement can pack cells tightly enough to leave no routing headroom, or can pack the area surrounding a congested hot spot just as tightly as the hot spot itself, leaving nowhere to spread cells out of it.

When to use it

Whenever a block needs an explicit density ceiling instead of the tool's own auto-derived schedule — commonly once a first placement pass shows congestion or over-tight legalization.

Prerequisites

A baseline utilization figure for the block, so the chosen density/utilization value is meaningfully between 1 and that utilization.

ICC2 workflow

1. Choose a value between 1 and the block's overall utilization.
2. Set place.coarse.max_density for an overall density ceiling, and/or place.coarse.congestion_driven_max_util to control density specifically in the region surrounding congestion hot spots.
3. Leave place.coarse.auto_density_control (default -enhanced) enabled unless you have a specific reason to disable it — explicit values you set always take precedence over the tool's derived ones regardless of this setting.
4. Read the PLACE-027 info messages during placement to see which density/utilization values the tool actually used.

Commands and options

Commands and options for Placement density control

Command / option	Behavior
place.coarse.max_density	app option — maximum density ceiling for non-congestion-driven placement; 0 forces uniform spreading
place.coarse.congestion_driven_max_util	app option, default 0.93 — max utilization in areas surrounding congestion hot spots
place.coarse.auto_density_control	app option, default -enhanced — tool-derived density schedule when explicit values are not set

Expected reports or evidence

PLACE-027 info message (“Automatic density control has selected the following settings: max_density 0.60, congestion_driven_max_util 0.77”) printed during placement.

Risks and tradeoffs

Density/utilization limits apply independently per placeable area (voltage area, exclusive move bound) rather than as a block-wide average — a single global number does not describe every region's actual headroom.

Exit-checklist implication

Feeds the setup-gate's density/congestion checks; a block still showing PLACE-027 values far from what was intended should be revisited before sign-off.

Congestion

Congestion-driven restructuring

Purpose

Restructure logic during coarse placement specifically to reduce routing congestion, with tunable effort and a guard against uncontrolled logic-depth growth.

Problem it solves

Congestion is sometimes a structural problem, not just a placement problem — the netlist's fan-in/fan-out shape itself creates local wiring demand that spreading cells alone cannot fix.

When to use it

Congested blocks where create_placement (without -timing_driven) or the place_opt initial_place stage's default restructuring is not aggressive enough, or is adding too much logic depth.

Prerequisites

A congestion signature already visible from a first coarse-placement pass or congestion map.

ICC2 workflow

1. By default this restructuring already runs during create_placement (unless -timing_driven is set) and during place_opt's initial_place stage.
2. Raise or lower effort with place.coarse.cong_restruct_effort (low/medium/high/ultra; default medium).
3. If restructuring is adding too many logic levels to critical paths, cap it with place.coarse.cong_restruct_depth_aware set to true (limits added depth to at most three levels).

Commands and options

Commands and options for Congestion-driven restructuring

Command / option	Behavior
place.coarse.cong_restruct_effort	app option, default medium — low/medium/high/ultra effort for congestion-driven restructuring
place.coarse.cong_restruct_depth_aware	app option, default false — caps added path depth from restructuring to 3 levels of logic

Expected reports or evidence

Before/after congestion maps or report_congestion-class evidence around the restructured region; a path-depth comparison if cong_restruct_depth_aware was enabled specifically to bound depth growth.

Risks and tradeoffs

Restructuring changes logic structure, not just placement — at higher effort it can add path depth that partially offsets its own congestion win with a timing cost, which is exactly what cong_restruct_depth_aware exists to bound.

Exit-checklist implication

Supports the congestion items on the placement-analysis sequence and exit gate; not a separate gate item on its own.

Advanced nodes

Wide-cell density handling

Purpose

Keep wide standard cells placeable and legalizable without large displacement, on advanced nodes where a wide cell may only fit in one position between vertical power straps.

Problem it solves

If a cell cannot straddle the vertical power straps and its width exceeds half the strap pitch, only one such cell fits between a given pair of straps — packing too many wide cells into the same strap-bounded region makes them impossible to legalize without moving them a long way.

When to use it

Advanced technology nodes with meaningful vertical power-strap pitch constraints and a noticeable population of wide cells (wide multiplexers, wide drive-strength buffers, and similar).

Prerequisites

None beyond being on a node where this strap/cell-width interaction applies; the tool does not need extra setup data beyond the technology file's strap geometry.

ICC2 workflow

1. Set place.coarse.wide_cell_use_model to true before coarse placement.
2. The tool then minimizes the density of these wide cells during placement so legalization does not have to displace them far afterward.

Commands and options

Commands and options for Wide-cell density handling

Command / option	Behavior
place.coarse.wide_cell_use_model	app option, default false — enables wide-cell-aware density modeling during coarse placement

Expected reports or evidence

Legalization RMS-displacement figures for wide-cell instances specifically, compared with and without the option enabled.

Risks and tradeoffs

Only relevant where the strap-pitch/cell-width interaction actually applies; enabling it on a design without meaningfully wide cells has nothing to improve.

Exit-checklist implication

Feeds the legalization-displacement checks on the exit gate for designs where wide cells are a known population.

Pin access

Cell-pin effects on placement

Purpose

Make coarse placement aware of pin-access cost or local pin density up front, instead of discovering pin-access DRC problems only after legalization or routing.

Problem it solves

Dense clusters of hard-to-access pins can produce routing and legalization difficulty that generic cell-area-based placement has no way to anticipate.

When to use it

Technology nodes of 7, 7+, 5, s5, or s4 (technology-specific pin-cost model available) or any other node needing generic pin-density awareness.

Prerequisites

set_technology -node already set for the block, since the choice of model depends on it.

ICC2 workflow

1. On 7/7+/5/s5/s4 nodes: set place.coarse.pin_cost_aware to true for the technology-specific pin-cost model (this takes priority over pin-density awareness on these nodes).
2. On any node: set place.coarse.pin_density_aware to true to control maximum local pin density instead.
3. Both default to false; on 7/7+/5/s5/s4 nodes pin_cost_aware=true wins regardless of pin_density_aware; on other nodes only pin_density_aware has effect.

Commands and options

Commands and options for Cell-pin effects on placement

Command / option	Behavior
place.coarse.pin_cost_aware	app option, default false — technology-specific pin-cost-aware placement (7/7+/5/s5/s4 nodes only)
place.coarse.pin_density_aware	app option, default false — generic maximum-local-pin-density-aware placement

Expected reports or evidence

Pin-access DRC counts, or the pin-density map from #visual-inspection, before and after enabling the relevant option.

Risks and tradeoffs

Setting both options without checking Table 7's precedence rule on 7/7+/5/s5/s4 nodes can leave an engineer believing pin-density awareness is active when the pin-cost model has actually taken over.

Exit-checklist implication

Feeds pin-access DRC and legalization-displacement checks on the exit gate.

Clock routing

Effects of nondefault-rule clock nets

Purpose

Account, during placement, for the extra routing space that nondefault routing rules (NDR) on clock nets will need later, instead of discovering the resulting congestion only after clock routing.

Problem it solves

Nondefault routing rules are used extensively on clock nets to improve timing and reduce crosstalk, but they need more space than default-rule routing — congestion from this can appear only after clock routing if placement never accounted for it.

When to use it

Blocks with clock nets known to use nondefault routing rules, especially where post-clock-routing congestion has been a problem before.

Prerequisites

Clock definitions and the intended nondefault routing rule assignments already established (the setup-gate's constraints/clocks row).

ICC2 workflow

1. Set place.coarse.ndr_area_aware to true before coarse placement.
2. The tool factors the anticipated NDR routing-space demand of clock nets into its congestion accounting during placement.

Commands and options

Commands and options for Effects of nondefault-rule clock nets

Command / option	Behavior
place.coarse.ndr_area_aware	app option, default false — accounts for nondefault-routing-rule clock-net congestion during coarse placement

Expected reports or evidence

Post-clock-routing congestion comparison (with vs. without the option) in the regions the NDR clock nets pass through.

Risks and tradeoffs

Only helps congestion that is actually attributable to NDR clock-net routing; does not address unrelated congestion sources.

Exit-checklist implication

Feeds the congestion items on the placement-analysis sequence and exit gate for designs using NDR clock nets.

Clock gating

Clock-gating cells associated with sequential arrays

Purpose

Reduce clock-net congestion specifically around sequential arrays (register files and similar row/column register structures) by making placement aware of the single clock-gating cell that typically drives a whole row.

Problem it solves

A sequential array is a group of registers arranged as a two-dimensional array, usually with the clock pins along one row driven by a single clock-gating cell; naive placement of that structure can create local clock-net congestion.

When to use it

Blocks containing register-file-like sequential arrays with row-shared clock gating.

Prerequisites

None beyond the sequential array existing in the netlist in a form the tool can recognize as such.

ICC2 workflow

1. Set place.coarse.seq_array_icg_aware to true before coarse placement.
2. The tool places the array's clock-gating cell and the row it drives with awareness of this shared-driver structure, reducing the clock-net congestion it would otherwise cause.

Commands and options

Commands and options for Clock-gating cells associated with sequential arrays

Command / option	Behavior
place.coarse.seq_array_icg_aware	app option, default false — reduces clock-net congestion caused by sequential-array clock gating

Expected reports or evidence

Local congestion map around the sequential array before/after enabling the option.

Risks and tradeoffs

Specific to arrays with a single shared clock-gating driver per row; does not apply to arrays clocked with per-register gating.

Exit-checklist implication

Feeds the congestion checks on the exit gate for designs containing register-file-style sequential arrays.

Legalization

Legalization effects during placement

Purpose

Make coarse placement aware, ahead of time, of the legalization limits and restrictions a cell will face — for example a wide cell that cannot legally sit at a specific location because of a power-strap position — so fewer cells need large displacements during legalization itself.

Problem it solves

Coarse placement that ignores legalization restrictions can place a cell somewhere it can never legally be, forcing a large corrective move once legalization runs.

When to use it

Blocks reporting many cells with small-to-medium legalization displacements — that is the use case this feature targets.

Prerequisites

A baseline legalization RMS-displacement measurement to compare against.

ICC2 workflow

1. Set place.coarse.enhanced_legalizer_driven_placement to true before coarse placement.
2. Re-run legalization and compare RMS displacement values against the baseline to confirm the option is actually reducing displacement for this design.

Commands and options

Commands and options for Legalization effects during placement

Command / option	Behavior
place.coarse.enhanced_legalizer_driven_placement	app option, default false — makes coarse placement aware of legalization limits/restrictions

Expected reports or evidence

RMS displacement values reported during legalize_placement, compared before/after enabling the option — that comparison is the check.

Risks and tradeoffs

The benefit is scoped to designs with many small-to-medium displacements; it is not a fix for a design with a few very large, structural placement problems.

Exit-checklist implication

Directly supports the legalization-displacement checks on the exit gate.

Power

Dynamic-power QoR during placement

Purpose

Improve the dynamic-power QoR of a placement without degrading its timing QoR, by making the coarse placer aware of switching-activity-driven power alongside timing.

Problem it solves

Placement decisions made purely for timing or area can leave dynamic power unoptimized, even though placement-stage locality (net length, cell selection proximity) has real influence over switching power.

When to use it

Designs with a defined power budget or dynamic-power target, once switching activity has been annotated.

Prerequisites

• Switching activity annotated on the design (see the Analyzing Power annotation workflow).
• At least one scenario enabled for dynamic-power optimization via set_scenario_status -dynamic_power true.

ICC2 workflow

1. Annotate switching activity on the design.
2. Enable dynamic-power optimization on at least one scenario: set_scenario_status -dynamic_power true.
3. Enable dynamic-power-driven placement for create_placement, refine_placement, place_opt, or clock_opt by setting place.coarse.enhanced_low_power_effort to none/low/medium/high (default low).

Commands and options

Commands and options for Dynamic-power QoR during placement

Command / option	Behavior
set_scenario_status -dynamic_power true	command option — enables a scenario for dynamic-power optimization (prerequisite)
place.coarse.enhanced_low_power_effort	app option, default low — none/low/medium/high effort for dynamic-power-driven placement

Expected reports or evidence

Dynamic/switching power from report_power before/after, alongside a timing check that timing QoR held — this feature targets power without affecting timing QoR.

Risks and tradeoffs

Requires switching activity to already be annotated and a dynamic-power scenario enabled; without both prerequisites the effort-level setting alone has nothing to optimize against.

Exit-checklist implication

Feeds the power-QoR checks in Analyzing Power and the exit gate.

Congestion

Repeater spreading

Purpose

Reduce congestion caused by chains of repeater cells (buffers, inverters, or pipelined registers) clumping along the edges or corners of macros or blockages, by spreading them in an orthogonal direction.

Problem it solves

Repeater chains naturally tend to run along macro/blockage edges and corners; left unspread, that clumping is itself a congestion source.

When to use it

Blocks with macros or large blockages and repeater-chain-heavy paths running along their boundaries, especially where congestion maps show hot spots hugging those edges.

Prerequisites

None beyond the block having macros/blockages with repeater chains routed along them.

ICC2 workflow

1. Set place.coarse.spread_repeater_paths to true before running create_placement, place_opt, or clock_opt.
2. The tool spreads the repeater cells in an orthogonal direction to reduce the edge/corner clumping.

Commands and options

Commands and options for Repeater spreading

Command / option	Behavior
place.coarse.spread_repeater_paths	app option, default false — spreads repeater chains along macro/blockage edges and corners to reduce congestion

Expected reports or evidence

Congestion map comparison specifically along macro/blockage boundaries, before/after enabling the option.

Risks and tradeoffs

Targets a specific congestion pattern (edge/corner repeater clumping); does not address congestion from other causes.

Exit-checklist implication

Feeds the congestion items on the placement-analysis sequence and exit gate.

Legalization

Limiting large cell displacement

Purpose

Reduce how far legalization has to move individual cells, using orientation flexibility and a many-small-moves strategy instead of moving any single cell a long distance.

Problem it solves

Legalization that only knows how to push one violating cell directly to its nearest legal site can end up moving that cell a long way, degrading the placement's original QoR-driven positions.

When to use it

Blocks where legalization is reporting large per-cell displacement, particularly designs where cell orientation is not already fixed by other constraints.

Prerequisites

None beyond having a legalization displacement problem to address.

ICC2 workflow

1. Enable orientation optimization: place.legalize.optimize_orientations to true — lets the tool consider flipping cell orientations to reduce displacement.
2. Enable stream placement: place.legalize.stream_place to true — moves many cells a small distance rather than one cell a large distance.
3. Tune stream placement further with place.legalize.stream_effort and place.legalize.stream_effort_limit if needed.

Commands and options

Commands and options for Limiting large cell displacement

Command / option	Behavior
place.legalize.optimize_orientations	app option, default false — allows orientation flips during legalization to reduce displacement
place.legalize.stream_place	app option, default false — distributes displacement across many small cell moves
place.legalize.stream_effort / stream_effort_limit	app options — further control stream-placement effort

Expected reports or evidence

RMS/maximum displacement values from legalize_placement, before/after enabling these options.

Risks and tradeoffs

Stream placement trades a single large move for many small ones — still real movement, so it should be checked against timing-critical nets it might have nudged, not assumed free.

Exit-checklist implication

Directly supports the legalization-displacement checks on the exit gate.

Pin access

Pin-access-aware legalization

Purpose

Improve routability in high-pin-density areas by redistributing cells during legalization on advanced technology nodes.

Problem it solves

Advanced-node designs can legalize into cell arrangements that are legally valid but leave local pin density too high for the routing stage to access cleanly.

When to use it

Advanced technology nodes, particularly where pin-access DRC or routability problems have shown up after legalization in earlier runs.

Prerequisites

None beyond being on an advanced node where pin-access-driven redistribution is meaningful.

ICC2 workflow

1. Set place.legalize.optimize_pin_access_using_cell_spacing to true before legalization.
2. The tool redistributes cells in high-pin-density areas during legalization to improve routability.

Commands and options

Commands and options for Pin-access-aware legalization

Command / option	Behavior
place.legalize.optimize_pin_access_using_cell_spacing	app option, default false — enables pin-access-driven cell redistribution during legalization

Expected reports or evidence

Pin-access DRC counts, or a pin-density map, before/after enabling the option.

Risks and tradeoffs

Targeted at advanced technology nodes specifically; it is not generally applicable to all node classes.

Exit-checklist implication

Feeds the pin-access DRC checks on the exit gate.

Legalization

Concurrent legalization and detailed routing (CLDR)

Purpose

Improve DRC convergence on pin-access violations after route optimization (RO) or hierarchical route optimization (HRO), by integrating legalization more tightly with detailed routing.

Problem it solves

Pin-access DRC violations found after RO/HRO can be slow to converge when legalization and detailed routing are treated as fully separate passes.

When to use it

Designs seeing persistent pin-access DRC after RO/HRO that ordinary legalize-then-route iteration is not converging quickly.

Prerequisites

A design that has already been through, or is about to go through, RO or HRO.

ICC2 workflow

1. Set place.legalize.enable_cldr to true:

   set_app_options -name place.legalize.enable_cldr -value true

2. Run the normal RO/HRO flow; CLDR integration improves DRC convergence on pin-access issues as part of it.

Commands and options

Commands and options for Concurrent legalization and detailed routing (CLDR)

Command / option	Behavior
place.legalize.enable_cldr	app option, default false — enables Concurrent Legalize and Detail Route integration for pin-access DRC convergence

Expected reports or evidence

Pin-access DRC violation count after RO/HRO, before/after enabling CLDR.

Risks and tradeoffs

Named specifically as a DRC convergence aid after RO or HRO — not a general-purpose legalization mode for earlier flow stages.

Exit-checklist implication

Feeds the DRC-convergence and pin-access items on the exit gate.

Power/ground

Advanced power-ground checks relevant to placement

Purpose

Enable stricter physical DRC checking between cells and prerouted power/ground (PG) net shapes on advanced technology nodes, including checks across multiple neighboring cells at once.

Problem it solves

At 12nm, 7nm, and smaller nodes, cell-to-prerouted-PG-net interactions can create DRC violations that simpler, single-cell-at-a-time checking misses, especially where several cells and PG shapes interact near a boundary.

When to use it

Advanced technology nodes (12nm and below), especially where PG-related DRC has appeared after legalization on prior runs.

Prerequisites

None beyond being on a node where this checking is relevant; multi-cell checks build on the basic advanced PG check being enabled first.

ICC2 workflow

1. Enable the base check: place.legalize.enable_advanced_prerouted_net_check to true.
2. Optionally tune the accessibility checks with place.legalize.advanced_layer_access_check and place.legalize.advanced_libpin_access_check (default behavior suits most designs).
3. For simultaneous multi-cell PG checking, also set place.legalize.enable_multi_cell_pnet_checks to true.
4. For multi-cell pin-access and track-capacity checks specifically at the last route_opt run or after route_auto, additionally enable place.legalize.enable_multi_cell_access_check and, if needed, place.legalize.enable_multi_cell_track_capacity_check (the latter requires the former).

Commands and options

Commands and options for Advanced power-ground checks relevant to placement

Command / option	Behavior
place.legalize.enable_advanced_prerouted_net_check	app option, default false — advanced physical DRC between cells and prerouted PG nets (advanced nodes)
place.legalize.enable_multi_cell_pnet_checks	app option, default false — simultaneous DRC checks across multiple cells and PG net shapes
place.legalize.enable_multi_cell_access_check	app option, default false — pin-access impact from neighboring cells/prerouted PG shapes
place.legalize.enable_multi_cell_track_capacity_check	app option, default false — track-capacity sufficiency check; requires enable_multi_cell_access_check

Expected reports or evidence

PG-related DRC violation counts from legality checking (check_legality) before/after enabling these checks.

Risks and tradeoffs

Layered options with dependencies (track-capacity check requires the access check); enabling one without the other it depends on has no effect.

Exit-checklist implication

Feeds PG-DRC and legalization-cleanliness checks on the exit gate for advanced-node designs.

Legalization

Advanced legalization algorithms

Purpose

Use 2D rule checking and cell-interaction-aware legalization algorithms, which reduce legalization runtime and support pin-access-optimizing strategies not available in the standard legalizer.

Problem it solves

Standard legalization can be slower and less able to account for cell-to-cell pin-access interaction than a 2D-rule-aware algorithm on advanced nodes.

When to use it

Advanced-node blocks where legalization runtime or pin-access-aware legalization quality is a concern; a prerequisite for variant-aware legalization's fullest behavior.

Prerequisites

Awareness that the legalize_placement command's -cells option is not supported once the advanced legalizer is enabled.

ICC2 workflow

1. Enable the algorithm: place.legalize.enable_advanced_legalizer to true.
2. Optionally specify undetected additional rules with place.legalize.enable_advanced_legalizer_rules.
3. Choose pin-access optimization strategy with place.legalize.optimize_pin_access_strategies: horizontal_align, avoid_high_pin_density, or both together.
4. For runtime, optionally enable multithreading: place.legalize.enable_threaded_advanced_legalizer to true, then configure multithreading as described for the tool generally.
5. For multithreaded legality checking specifically, enable the advanced legalizer, configure multithreading, then run check_legality.

Commands and options

Commands and options for Advanced legalization algorithms

Command / option	Behavior
place.legalize.enable_advanced_legalizer	app option, default false — enables 2D-rule-aware advanced legalization algorithms
place.legalize.optimize_pin_access_strategies	app option — horizontal_align and/or avoid_high_pin_density pin-access optimization strategies
place.legalize.enable_threaded_advanced_legalizer	app option, default false — multithreaded advanced legalization
check_legality	command — legality checking, can run multithreaded once the advanced legalizer and multithreading are configured

Expected reports or evidence

Legalization runtime comparison, and check_legality output, before/after enabling the advanced legalizer.

Risks and tradeoffs

The -cells option of legalize_placement stops working once the advanced legalizer is enabled — a targeted, cell-list legalization workflow built on that option needs to be re-checked.

Exit-checklist implication

Feeds the legalization-cleanliness and runtime items on the exit gate for advanced-node designs.

Legalization

Variant-aware legalization

Purpose

Legalize a cell by swapping it for a functionally equivalent variant with different pin placement or pin color, instead of physically moving it, when a library provides such variants.

Problem it solves

A library can offer functionally identical cells whose pins sit in different locations or on different mask colors; ordinary legalization has no way to use that equivalence and can only move the cell.

When to use it

Libraries that are variant-ready (define physical_variant_cells in their Liberty source) or can be made variant-ready via the Library Manager tool.

Prerequisites

• A variant-ready compiled library, or equivalent cell groups defined via create_cell_groups in the Library Manager tool (lm_shell).
• report_cell_groups can confirm equivalent cell groups exist in either the Library Manager or IC Compiler II tool.

ICC2 workflow

1. If the logic library is not already variant-ready, define equivalent cell groups in the Library Manager tool: create_workspace, create_cell_group per group, check_workspace, commit_workspace.
2. Enable variant-aware legalization: place.legalize.enable_variant_aware to true.
3. For pin-track/pin-color alignment specifically, also enable place.legalize.enable_prerouted_net_check and place.legalize.enable_pin_color_alignment_check, and specify the layers to align via place.legalize.pin_color_alignment_layers.

Commands and options

Commands and options for Variant-aware legalization

Command / option	Behavior
place.legalize.enable_variant_aware	app option, default false — enables variant-aware legalization
create_cell_group (lm_shell)	command — defines equivalent cell groups when the library is not already variant-ready
place.legalize.enable_pin_color_alignment_check	app option — pin-color-aware alignment during variant-aware legalization
place.legalize.pin_color_alignment_layers	app option — layers to align for pin-color checking

Expected reports or evidence

report_cell_groups confirming equivalent cell groups are recognized; legalization DRC-violation count before/after, showing violations fixed by variant substitution instead of displacement.

Risks and tradeoffs

If a violating cell has no variant, the tool falls back to moving it — variant-aware legalization reduces displacement, it does not eliminate the need for legalization movement entirely.

Exit-checklist implication

Supports legalization-displacement and DRC-cleanliness checks on the exit gate for libraries that offer variants.

Legalization

Cell legal-placeability analysis

Purpose

Check, after placement and legalization constraints are fully specified, whether specific library cells can actually be legally placed anywhere in the block (or a chosen region) — before relying on them in the design.

Problem it solves

A library cell can be structurally legal in isolation but practically unplaceable in a given block's power-strap/track geometry, something that is easy to discover too late without a dedicated check.

When to use it

After all placement and legalization constraints and settings are specified, particularly for cells you suspect may be hard to legalize (wide cells, cells with unusual pin geometry).

Prerequisites

Placement and legalization constraints/settings already finalized for the block, since the analysis checks against them.

ICC2 workflow

1. Run analyze_lib_cell_placement -lib_cells naming the cells of interest.
2. Optionally scope the search to a region with -region (default: entire core area).
3. Optionally limit the number of sites checked with -trials.

Commands and options

Commands and options for Cell legal-placeability analysis

Command / option	Behavior
analyze_lib_cell_placement -lib_cells	command — checks whether named library cells can be legally placed; -region and -trials scope the search

Expected reports or evidence

The pass/fail-per-cell result of analyze_lib_cell_placement, run against the cells and region of concern.

Risks and tradeoffs

A cell that fails this analysis for the whole core area may still be usable if legally placeable only in a subregion — read the -region-scoped results before excluding a cell outright.

Exit-checklist implication

A useful pre-flight check to run before committing a design to a library cell that later legalization runs might reject outright.

Preroute

Placement-stage parasitic estimation

Purpose

Improve correlation between preroute (placement/optimization-stage) timing and the eventual postroute result, by using more realistic per-net parasitic estimation during place_opt/clock_opt instead of a purely model-based estimate.

Problem it solves

A purely model-based preroute parasitic estimate can diverge meaningfully from what routing eventually produces, especially where per-unit resistance varies across routing layers or on advanced nodes.

When to use it

Designs where preroute-to-postroute timing correlation has historically been poor, or that use advanced technology nodes below 16nm (route-driven estimation is enabled there by default).

Prerequisites

None beyond running place_opt/clock_opt normally; global routing is performed internally as part of these features.

ICC2 workflow

1. Global-route-layer-based (GRLB) estimation: set opt.common.use_route_aware_estimation to auto (enabled only where per-layer resistance varies) or true (always enabled). Remove it with remove_route_aware_estimation before routing.
2. Route-driven estimation (RDE): set opt.common.enable_rde to true (default-on below 16nm already). When enabled, RDE runs during the final_opt stage and overrides/ignores the GRLB setting; honors the -early_cap_scale/-late_cap_scale/-early_res_scale/-late_res_scale options of set_extraction_options.
3. If RDE is enabled, keep it enabled through all subsequent preroute optimization steps in the flow for consistency.

Commands and options

Commands and options for Placement-stage parasitic estimation

Command / option	Behavior
opt.common.use_route_aware_estimation	app option, default false — auto/true enables GRLB per-unit-resistance-aware RC estimation
remove_route_aware_estimation	command — removes global-route-based estimation before routing
opt.common.enable_rde	app option, default true below 16nm — enables route-driven parasitic estimation during final_opt

Expected reports or evidence

Preroute-vs-postroute timing correlation (slack delta on the same paths) before/after enabling GRLB or RDE.

Risks and tradeoffs

RDE silently overrides/ignores the GRLB setting when both are enabled — do not assume both are contributing independently; and RDE should be kept on through the rest of the preroute flow once enabled, not toggled per-stage.

Exit-checklist implication

Supports the timing-correlation confidence behind the exit gate's timing checks, though it is a correlation aid, not a checklist item itself.

Legalization

Area recovery in high-utilization designs

Purpose

Let a design that cannot legalize because of local high-utilization areas recover area in those regions during place_opt/clock_opt, at a documented timing-QoR cost.

Problem it solves

A region with utilization too high to legalize needs area freed up before legalization can succeed there, but ordinary optimization has no built-in mechanism scoped specifically to high-utilization small regions.

When to use it

Designs that are failing to legalize specifically because of small regions of high utilization — not a general-purpose area-reduction switch.

Prerequisites

A confirmed legalization failure attributable to a high-utilization region, so the timing-QoR tradeoff is justified.

ICC2 workflow

1. Set opt.common.small_region_area_recovery to true.
2. Run place_opt or clock_opt; area recovery happens during these commands in the high-utilization regions.
3. Re-check timing QoR afterward — this feature carries a timing-QoR cost.

Commands and options

Commands and options for Area recovery in high-utilization designs

Command / option	Behavior
opt.common.small_region_area_recovery	app option, default false — performs area recovery in high-utilization regions during place_opt/clock_opt

Expected reports or evidence

Legalization success/failure in the previously high-utilization region, plus a timing-QoR comparison (worst slack, TNS) before/after, since a degradation is expected.

Risks and tradeoffs

This slightly degrades timing QoR — use it as a targeted fix for a legalization blocker, not as a routine setting.

Exit-checklist implication

A design that needed this option to legalize should have that fact and its timing-QoR impact recorded before sign-off, not silently left enabled.

QoR

Advanced logic restructuring

Purpose

Restructure logic during the final_opto stage of place_opt/clock_opt, targeted at whichever combination of area, timing, and power QoR the design most needs to improve.

Problem it solves

Standard optimization may leave area, timing, or power QoR short of target even after placement is legal and DRC-clean; targeted restructuring at the final optimization stage can recover some of that gap.

When to use it

Designs where final_opto-stage QoR (area, timing, and/or power) needs a further push, and the specific metric(s) to prioritize are known.

Prerequisites

A clear sense of which QoR metric(s) matter most for this run, since the mode setting is a direct tradeoff choice, not a free win across all three.

ICC2 workflow

1. Set opt.common.advanced_logic_restructuring_mode to the mode matching your priority: none (default, off), area, timing, power, area_timing, timing_power, area_power, or area_timing_power.
2. Run place_opt or clock_opt; restructuring applies during the final_opto stage.

Commands and options

Commands and options for Advanced logic restructuring

Command / option	Behavior
opt.common.advanced_logic_restructuring_mode	app option, default none — area/timing/power/area_timing/timing_power/area_power/area_timing_power restructuring targets for final_opto

Expected reports or evidence

report_qor comparison (area, worst slack/TNS, power) before/after, for the specific metric(s) the chosen mode targets.

Risks and tradeoffs

A mode that combines multiple targets (for example area_timing_power) spreads restructuring effort across all three rather than maximizing any one — choose the narrowest mode that matches the actual priority.

Exit-checklist implication

Feeds the QoR-comparison workflow in Comparing QoR Data; a mode other than the default should be recorded as a deliberate QoR-tradeoff choice.

Multibit / low power

Multibit retention registers

Purpose

Extend multibit register banking to retention registers used in power-gated (multivoltage/UPF) designs, combining single-bit retention registers into a multibit retention register where the library and retention strategy support it.

Problem it solves

Retention registers have retention-specific requirements (a shared retention strategy, matching retention-pin drivers, a matching multibit retention library cell) that ordinary multibit banking does not check for, so a naive banking pass can either miss legitimate retention-register banking opportunities or bank them incorrectly.

When to use it

Multivoltage/UPF designs using single-bit retention registers where the library offers a matching multibit retention cell.

Prerequisites

• The single-bit retention registers share the same retention strategy and the same retention-pin driver.
• The cell library has a matching multibit retention register.
• The multibit retention library cell is registered for the retention strategy via map_retention_cell -lib_cells.

ICC2 workflow

1. Confirm the four banking prerequisites above are met for the candidate registers.
2. Identify multibit retention registers with identify_multibit -register (not -mv_cell, for this specific case).
3. Bank as part of the normal multibit banking flow (see Performing Multibit Register Optimization).
4. To split a previously banked multibit retention register back to single-bit cells, the library must have matching single-bit retention registers also registered via map_retention_cell -lib_cells.

Commands and options

Commands and options for Multibit retention registers

Command / option	Behavior
identify_multibit -register	command option — identifies multibit retention registers specifically (use -register, not -mv_cell, for this case)
map_retention_cell -lib_cells	command — registers a library cell (single-bit or multibit) as usable for a given retention strategy

Expected reports or evidence

Post-banking netlist check confirming retention registers banked into the expected multibit retention cell, and that the retention strategy/UPF checks still pass.

Risks and tradeoffs

Skipping the -register option (using -mv_cell instead) is the wrong option for this case — check the exact option used in any banking script that touches retention registers.

Exit-checklist implication

Extends the multibit-banking sequencing already on the exit gate; a multivoltage design with retention registers should confirm this path explicitly rather than assuming ordinary multibit banking covered them.

Stage completion checklist

The Placement and Optimization exit gate

This is the same checklist a careful placement lead would use before approving a handoff to Clock Tree Synthesis. Every item names its evidence; "looks fine" is not evidence.

• Every standard cell is placed and legalized, with no unresolved placement violations.Evidence: report_placement output reviewed line by line.
• No unexplained placement or physical-hierarchy violations remain.Evidence: report_placement violation counts, each either zero or explained.
• No unresolved hard-macro overlap.Evidence: macro-overlap section of report_placement reviewed.
• Thin channels and swimming-pool area reviewed.Evidence: report_placement's physical-hierarchy detail, or the GUI floorplan view, checked for both.
• Achieved utilization reviewed against the floorplan-stage baseline, with any change explained.Evidence: report_utilization -verbose, compared against the floorplan-stage figure (not the pre-placement 0.0% sanity-check reading), not assumed unchanged.
• Congestion, cell-density, and pin-density maps reviewed in the GUI.Evidence: each map checked as an explicit pass/fail, not skipped.
• Fixed, locked, and legalize_only cells match documented intent.Evidence: a placement-status query matching a written list of intended fixed/locked cells.
• Clock-gating merge behavior verified.Evidence: a clock-gating cell count consistent with expectations for this design.
• High-fanout buffer-tree behavior reviewed.Evidence: create_buffer_trees output or automatic high-fanout handling checked, then legalize_placement confirmed run afterward.
• Multibit decisions verified, with reoptimization and reports run after any banking.Evidence: report_multibit output, plus a place_opt (or equivalent) pass and reports captured after -apply, not before it.
• Tie-cell state checked.Evidence: add_tie_cells run with no unexpected new insertions.
• Multivoltage and bufferability findings resolved or tracked.Evidence: check_bufferability output, each finding resolved or explicitly tracked.
• analyze_design_violations findings resolved, waived with a documented rationale, or assigned to an owner.Evidence: each finding in the categorized list has one of those three dispositions.
• Timing explicitly updated when a fresh reading was needed.Evidence: update_timing run before the readings being reported on.
• Worst timing paths reviewed.Evidence: report_timing output for the worst setup and hold paths.
• report_qor reviewed, not just the single worst path.Evidence: report_qor -summary output.
• report_constraints reviewed for logical DRC violations.Evidence: report_constraints output, each violation reviewed.
• Power report reviewed in the intended scenario and leakage mode.Evidence: report_power output, with mode/scenario/voltage/temperature confirmed intentional.
• Power-group and clock-network power interpretation reviewed.Evidence: power-group breakdown checked, and cell-based vs. pin-based clock-network power setting confirmed before drawing conclusions.
• QoR comparison captured against a named baseline.Evidence: write_qor_data/compare_qor_data output with the pre-placement run set as baseline.
• No option experiment accepted into the checkpoint without before/after evidence.Evidence: a compare_qor_data comparison reviewed before save_lib for any nondefault option tried.
• Final checkpoint, logs, command history, reports, and QoR data are reproducible.Evidence: a second engineer can open_lib your saved checkpoint and reproduce the same reports.
• A CTS handoff note records known limitations or intentional exceptions.Evidence: a short written note naming anything left open on purpose, so CTS does not rediscover it blind.

Mini lab

Lab: pulling Nimbus‑8's DDR PHY controller cluster together with magnet placement

Nimbus‑8's DDR PHY hard macro drives a small cluster of controller and calibration logic — standard cells that, left to ordinary placement, can end up scattered across the core instead of hugging the macro whose timing they are most sensitive to. This lab uses magnet placement to pull that cluster close to the macro, before the main placement pass runs.

Setup

• Nimbus‑8's design library, reopened from this chapter's own checkpoint before Step 3 (that is, after the floorplan is in place but before create_placement has run).
• Confirmation that the DDR PHY macro (nimbus8_ddrphy) is placed and fixed, since a magnet object must itself be fixed for the pull to make sense.

Tasks

1. Preview which cells would move, without moving anything yet, using magnet_placement nimbus8_ddrphy -only_report_magnet_cells.
2. Review the previewed list: does it include cells you did not expect, or exclude ones you did? If a cell you expected is missing, consider whether it is actually on a contiguous data path from the macro.
3. Run the real pull, limited to three logic levels from the macro and stopping at any sequential cell boundary: magnet_placement nimbus8_ddrphy -logical_levels 3 -stop_by_sequential_cells -mark_fixed.
4. Confirm the pulled cells are now marked fixed, using a placement-status query, so the main placement pass in Step 3 does not scatter them again.
5. Proceed with Step 3 (create_placement -timing_driven -congestion) and compare the DDR PHY cluster's final wire length against what a version of this worked example without the magnet-placement step would have produced.

Expected observations

The pulled cluster should show noticeably shorter local wire length in report_placement's per-net detail than an ungoverned placement would produce, but the pull only ever follows a genuinely contiguous data path — a controller cell connected to the macro only through an unrelated shared bus does not move, even if it seems like it should.

Cleanup

If continuing directly into the worked example above, do not repeat Step 3's create_placement call with different options than this lab already used — re-running coarse placement discards the magnet-placement pull. Otherwise, close the library with close_lib once the saved checkpoint reopens cleanly with open_lib in a fresh session.

Interview questions

45 questions worth being able to answer cold

Beginner questions

Intermediate questions

Advanced questions

Expert / senior questions

Glossary

Terms used in this chapter

Baseline run

In a QORsum comparison, the run (by default, the first captured) that all others are shaded and compared against.

Bufferability

Whether a net segment can legally be buffered, given available supply nets, library cells, and blocking constraints.

Coarse placement

A fast first pass giving every standard cell an approximate, legal-ish location.

Concurrent clock and data (CCD) optimization

Adjusting clock arrival times at registers (useful skew) together with datapath optimization.

Congestion-driven placement

Placement that spreads cells to avoid routing hot spots, enabled with -congestion.

Fixed (placement status)

A cell the tool cannot move, but can still resize during optimization.

IR-drop-aware placement

Placement that spreads high-power-density cells using external voltage-drop analysis values.

Leakage mode

The calculation method report_power uses for leakage power: average, unconditional, state (the default), or off.

Legalization

Moving cells onto real, non-overlapping site-grid positions without changing the netlist.

Locked (placement status)

A cell that cannot be moved either manually or by the tool.

Logical DRC violation

A constraint violation — max transition, max capacitance, max/min delay, min pulse width, min period — reported by report_constraints.

Magnet placement

Pulling cells on a contiguous data path toward a fixed anchor object.

Multibit register banking

Combining single-bit registers with identical timing constraints into one equivalent multibit cell.

Path group

The named group (typically per-clock) a timing path is reported and constrained under.

Physical guidance (SPG)

Using a Design Compiler Graphical placement, carried by DEF, as ICC2's placement starting point.

place_opt stage

One of five named phases — initial_place, initial_drc, initial_opto, final_place, final_opto.

Placement status

A per-cell state controlling whether later commands may move it: unplaced, placed, fixed, legalize_only, or locked.

Power group

A named category (default, such as register or combinational, or user-defined via set_power_group) that report_power breaks its results down by.

QORsum report

The web-based report generated by compare_qor_data for comparing captured QoR data across runs.

Refine placement

Incremental, congestion-optimizing placement on an existing design, without touching the netlist.

Slack

Required time minus arrival time on a timing path; positive means the path passes, negative means it fails by that margin.

Tie cell

A library cell providing a real driven source for a constant logic-0 or logic-1 pin, inserted by add_tie_cells or automatically during optimization.

Timing-driven placement

Placement that considers timing criticality when choosing cell locations, enabled with -timing_driven.

Trial clock tree

A temporary clock tree built during placement so the tool can optimize against propagated, not ideal, clocks.

Useful skew

Deliberately shifting a register's clock arrival time to borrow slack from a path that has it, for one that does not.

Voltage-area-aware buffering

Choosing a buffer supply that avoids a new multivoltage violation, preferring single-rail buffers when legal.

Self-check questions

Test yourself before moving on

1. Name place_opt's five stages, in order, and say in one sentence what each one does.
2. Why does running create_placement directly, instead of place_opt, require you to run merge_clock_gates yourself first?
3. Walk through the exact sequence required to enable IR-drop-aware placement, including where final_place fits.
4. What is the difference between placement status fixed and locked, and which one alone does not protect a cell's size?
5. Why can split_multibit not be used on a multibit register cell that was already multibit in the original netlist?
6. Explain why a Design Compiler Graphical DEF file is not, by itself, a complete physical-constraint transfer into ICC2.
7. You just ran identify_multibit -register -apply. What must you do before checkpointing, and why?
8. What is the documented default for power.leakage_mode, and what does it fall back to?
9. Name the four-command chain, in order, for comparing QoR data across runs.
10. Why might report_power and report_clock_qor -type power disagree on clock-network power even on the same design and scenario?

Answers

1. initial_place (merge clock gates, coarse placement); initial_drc (remove/rebuild buffer trees, high-fanout synthesis, electrical DRC fixing); initial_opto (timing/area/congestion/leakage optimization); final_place (incremental placement plus legalization); final_opto (further optimization and legalization).
2. Because place_opt merges clock-gating cells automatically at the start of initial_place, but create_placement called alone does not perform that merge at all.
3. Run place_opt -to final_place; perform voltage-drop analysis externally; set place.coarse.ir_drop_aware to true; rerun with place_opt -from final_place so the next pass uses the voltage-drop values.
4. fixed blocks movement by the tool but still allows resizing during optimization; locked blocks both manual and tool movement entirely. fixed alone does not protect a cell's size — add dont_touch for that.
5. Because split_multibit only splits multibit cells that were themselves created by create_multibit or identify_multibit — a cell that was multibit in the original netlist has no such provenance to reverse.
6. Because DEF carries geometry — die area, site rows, tracks, port and cell locations, route guides, blockages — but not voltage area definitions, layer constraints, special route guides with utilization, or special blockages with blocked layers, which require a separate Tcl file.
7. Reoptimize and revalidate: re-enter place_opt from initial_drc (or earlier), then rerun report_placement/report_utilization/report_qor — because -apply changed the netlist, and checkpointing before reoptimizing would save a stale, unvalidated design.
8. state is the default; it falls back to unconditional if state-dependent leakage characterization data is unavailable.
9. set_qor_data_options (optional configuration) → write_qor_data (capture each run) → compare_qor_data (generate the comparison) → view_qor_data (view it).
10. Because report_power's clock-network power is cell-based by default (a whole cell's power counts if any output is on the clock network), while report_clock_qor -type power is always pin-based — a reporting-basis difference, not necessarily a data error, unless power.clock_network is set to match.

Part summary

What to carry forward

Sign-off checklist

Before you call this stage done

This is a condensed pass over the full 23-item exit gate from earlier in this chapter, repeated here as a final scan before handoff. See Stage completion checklist for the complete list and the evidence required for each item.

• Every standard cell is placed and legalized, with no unresolved placement or physical-hierarchy violations, and no unresolved hard-macro overlap.
• Achieved utilization is reviewed against the pre-placement baseline, with any shift explained — not assumed unchanged.
• Clock-gating cells are merged exactly once, and high-fanout buffer-tree behavior is reviewed.
• Timing-, congestion-, or buffering-aware placement options were deliberately chosen, and any IR-drop-aware placement followed the documented enable-and-rerun sequence.
• Multibit banking decisions are documented, and a reoptimization pass plus fresh reports were run after any -apply.
• Tie-cell state has been checked with add_tie_cells.
• Any manually fixed or locked cell has a documented reason; bufferability and analyze_design_violations findings are triaged, not ignored.
• Timing (update_timing/report_timing/report_qor/report_constraints) and power (report_power, correct scenario and leakage mode) have both been reviewed, not skipped.
• QoR data has been captured and compared against a named baseline, and no option experiment was accepted without a before/after comparison.
• A saved checkpoint, with logs, reports, command history, and QoR data, reproduces cleanly for a second engineer, with a CTS handoff note on any known limitations.

Last word

Last word and bridge to Clock Tree Synthesis

This chapter filled in the shape the previous one defined, and proved — with reports, not impressions — that the fill actually converged: every cell placed and legal, timing and congestion optimized against real constraints, registers banked where it helped, and nothing silently left fixed by accident. What comes next assumes that proof holds. Ideal clocks become real ones. If a clock tree turns out to correlate poorly with this chapter's trial-clock-tree estimates, or a register you banked turns out to sit awkwardly for clock tree balancing, the first productive move is almost always back here: was CCD actually enabled the way you think, is that cell's placement status really what you set it to, does report_placement still show what it showed at handoff.