Placement Optimisation in Cadence Innovus

01Chapter Overview #

Placement is the first step in the implementation flow where the tool knows real distances. Up to this point, timing was computed with ideal clocks and estimated wires, so a path that looked fine after synthesis could still be far too long once its cells land on opposite sides of the die. After placement, most wire lengths are fixed, the congestion picture is set and the majority of the timing problems the design will ever have are already visible. Clock tree synthesis (CTS) and routing can correct only a part of what placement leaves behind.

This handbook covers three things in that order. First, the sanity checks that should pass before a single placement command is run. Second, the techniques that move timing, congestion and power during placement, each explained with a small example before the command that expresses it. Third, the interview questions that come with the topic, grouped by experience level.

Why it matters in interviews: almost every physical design interview spends time on placement, because it is where cause and effect is easiest to test. "I ran place_opt_design" is not an answer. "The hotspot came from a narrow macro channel, so I added a partial blockage there and the timing held" is the kind of answer the panel is listening for.

Where it is used in real projects: every block goes through placement many times. Each floorplan change, netlist drop or constraint update means another placement run, and the quality of that run decides how many iterations CTS, routing and signoff will need.

What is new at the placement stage

It helps to be clear about which inputs change when the design moves from synthesis to placement, because that is what makes the timing numbers move. Table 1.1 lists them.

Table 1.1 · What placement adds to the timing picture

Thus, a timing report after placement is the first one in the flow that can be trusted to point at real problems, and the first one that can mislead the designer if the inputs behind it are wrong.

02Concept Primer #

2.1 Global placement, detail placement and legalisation

Placement is done in two steps. Global placement finds rough locations for every standard cell so that connected cells are close together and the cells are spread evenly over the core. At this step the cells are allowed to overlap and do not yet sit exactly on rows. Detail placement then snaps every cell to a legal site in a row, removes overlaps, honours blockages and halos, and improves the result locally for timing, wire length and congestion. The part of detail placement that only makes the placement legal is called legalisation; in Innovus this is done by refinePlace, which place_opt_design calls by itself at the end.

Thus, a good global placement is the precondition for a good final placement. If global placement crowds a region, legalisation has to push cells far from where timing wanted them.

2.2 Utilisation and density

Utilisation is the area of standard cells divided by the area available to them. Density is the same ratio measured in a small window (a bin) instead of the whole core. A block can have a moderate utilisation and still contain bins near 100%, which is why the density map matters more than the single number.

## Assuming, a core of 500 x 400 um and two macros of 30,000 um2 each
Core area             = 500 x 400            = 200,000 um2
Macro area            = 2 x 30,000           =  60,000 um2
Area for std cells    = 200,000 - 60,000     = 140,000 um2
Std cell area         =                         98,000 um2
Utilisation           = 98,000 / 140,000     = 70 %
## Assuming, CTS and hold buffers will add about 4 % of cell area later
After growth          = 98,000 x 1.04 / 140,000 = about 73 %

2.3 What place_opt_design does inside

In Innovus, place_opt_design is the command most flows use for this stage. It is a single command, but it runs several steps in order, and knowing them makes the log readable. Figure 2.3 shows the sequence.

Step 4 itself uses several techniques: inserting buffers, resizing gates, restructuring logic, swapping pins, moving cells and, unless disabled, useful skew. Section 5.7 explains each one with an example.

2.4 Why wire length matters so much

A wire has resistance and capacitance per unit length, and both grow with length. The delay of an unbuffered wire therefore grows roughly with the square of its length: double the length and the delay becomes about four times larger. This is the reason a placement that spreads one path across the die can lose far more time than the extra distance suggests, and why optimisation splits long wires with repeaters.

Thus, keeping critical cells close is the cheapest way to save delay, and repeaters are the fix when they cannot be close. We will see both in Section 5.

03Sanity Before Placement #

So far we saw what placement does. Now we turn to what must be true before it starts. A common belief is that a bad placement is a placer problem. In most cases it is an input problem: a missing timing view, an incomplete constraint, a macro that is not fixed. The placer does not stop for these. It produces a legal placement anyway, and the designer finds the real issue two days later. Thus, the checks in this section are cheap insurance.

3.1 Library and netlist

Let us start with the data. Every cell used in the netlist needs a physical view (LEF) so it can be placed and a timing view (Liberty) so it can be timed. The netlist itself should have no floating inputs, no outputs tied to power and no unexpected multi-driven nets. The tool can report all of this in a few commands.

## Library, netlist, P/G and floorplan integrity, written to a text report
checkDesign -all -noHtml -outfile rpt/checkDesign.rpt
## Netlist summary: floating ports, multi-driven nets, pad issues
checkNetlist -outfile rpt/checkNetlist.rpt
## Every non-leaf module must be instantiated once (returns 1 if unique)
checkUnique -verbose
## Preconditions for placement: PG rail alignment, pin access, followpins, taps, termination cells
check_design -type place -out_file rpt/check_place.tcl

checkDesign looks for missing or inconsistent library and design data at any stage. check_design -type place is narrower: it checks the conditions placement depends on, such as power rail alignment, pin access, missing follow-pins and misaligned tap cells. In a report, an error is a stop. A warning is acceptable only when the designer can explain it.

3.2 Timing constraints

Placement is timing-driven by default when constraints are loaded. That is useful only if the constraints are complete. If a clock is missing, every path it drives is unconstrained: the tool does not see it as a timing path and will not pull its cells together. The report will look clean for those paths simply because nothing was checked.

## Missing clocks, unconstrained endpoints, missing input delay, loops
check_timing -verbose > rpt/check_timing.rpt
## Zero wire-load baseline: if this already fails badly, fix synthesis or the SDC first
timeDesign -prePlace -outDir rpt/prePlace

The pre-place run deserves a word. It times the netlist with zero wire load and ideal clocks. If a path fails badly even here, no placement setting can fix it, because placement can only add wire delay, never remove gate delay. In such a case the problem belongs to synthesis or to the constraints.

3.3 Floorplan readiness

Before standard cells go in, the floorplan must be final and legal: macros at their positions with a fixed status, halos around them, blockages where cells should not go, and a power grid in place.

## Floorplan quality check with target and effective utilisation
checkFPlan -reportUtil -outFile rpt/checkFPlan.rpt
## Keep-out ring around every macro: left bottom right top, in microns (values illustrative)
addHaloToBlock 5 5 5 5 -allMacro
## Preplaced cells and macros must already be legal (report file name is positional)
checkPlace rpt/checkPlace_preplace.rpt

A macro left with a placed status instead of fixed can be moved by the placer. That might sound harmless, but a macro moved by a few microns can block a channel the designer planned for routing, or break the power hookup. Fixing macros is one line of effort and it removes a whole class of surprises.

3.4 Physical cells and their order

Some cells have no logical function but must be in the rows before placement. End caps terminate each row and well taps tie the wells to the supplies at a regular interval. Both are preplaced, so the placer fills the space around them. Other physical cells come later. Figure 3.2 shows the order.

## Choose the end cap cells (names are examples from a typical library)
setEndCapMode -leftEdge ENDCAP_L -rightEdge ENDCAP_R
## End caps first, on every row end
addEndCap -prefix ENDCAP
## Then well taps at the maximum spacing the technology allows (50 um is illustrative)
addWellTap -cell TAPCELL -cellInterval 50 -prefix WELLTAP

Fillers go last because adding them earlier hides placement problems and costs runtime on every later step. Thus, the order is not a matter of taste: each kind of cell is added when the step that depends on it is next.

3.5 Things people forget

• Scan information. Scan chain reordering needs the scan DEF, loaded with defIn. Without it the tool warns and skips reordering.
• Don't-use list. Cells the methodology bans (very weak drivers, delay cells in data paths, special cells) should be marked with setDontUse before the first optimisation, not after.
• RC scale factors. Pre-route estimates should track post-route numbers. If they do not, placement optimises against the wrong delays.
• Utilisation target. Worked Example 2.1 showed why: leave room for CTS, hold and ECO cells.
• Fanout fixing. Optimisation does not fix max fanout violations by default. If the methodology needs it, turn it on before the first pre-CTS run (Section 4.2).

3.6 The pre-placement gate

04Setting Up the Placer #

Once the inputs are sane, the designer tells the tool what to care about. It is recommended to set every mode before the step it controls and to print the full set into the log, because a reviewer reading the log should be able to see exactly what ran.

4.1 Path groups

Optimisation spends its effort per path group. If every path sits in one group, a few badly constrained input paths might take most of the effort while the real register-to-register paths stay negative. Splitting the paths into groups lets the designer decide where effort goes. Figure 4.1 shows the standard groups.

## Create reg2reg, reg2cgate, in2reg, reg2out and in2out groups
createBasicPathGroups -expanded
## High effort groups are optimised separately for the best WNS
setPathGroupOptions reg2reg -effortLevel high
setPathGroupOptions reg2cgate -effortLevel high
## Print the groups and their options into the log
reportPathGroupOptions

A negative -slackAdjustment on a group tightens it and, unless low effort is set explicitly, raises it to high effort automatically. It is useful for a group the designer knows will degrade later, such as paths that will pick up clock skew. Used on every group, it simply over-constrains the whole design, so it is better kept for the few groups that need it.

4.2 The modes that matter most

Innovus has many placement and optimisation options. Table 4.1 lists the ones that change results most often at this stage. The detail of each appears in the technique it belongs to in Section 5.

Table 4.1 · Placement and optimisation modes worth knowing

## Print every placement and optimisation mode into the log for review
getPlaceMode
getOptMode
## Use local CPUs for placement; do not ask for more threads than physical cores
setMultiCpuUsage -localCpu 8

Thus, by the end of this step the designer has decided which paths matter, how hard the tool should work on timing and congestion, and how much room optimisation may use. The next section is about what to do when the result is still not good enough.

05Placement Optimisation Techniques #

This section covers twelve techniques. Each one follows the same order: the problem it solves, a small example, the Innovus command that expresses it, and the cost or caveat. It is better to apply them in response to evidence (a timing report, a congestion map, a density map) than to switch them all on at once, because several of them pull in opposite directions.

At the end of each technique a small trade-off table shows its typical effect on setup, hold, congestion, area, power and runtime, the kind of violation it suits best, and the setPlaceMode or setOptMode options that control it. Section 5.13 then maps each violation to a technique, Section 5.14 collects all trade-offs in one matrix, and Sections 5.15 and 5.16 list the key setPlaceMode and setOptMode options with their defaults.

5.1 Timing-driven placement

Let us consider a simple path: a launching flip-flop, two gates and a capturing flip-flop. If the placer puts the two flip-flops on opposite sides of the block because each connects more strongly to other logic, the path picks up two long wires. From Section 2.4, a long wire costs far more than its length suggests.

The tool handles this by running timing analysis between placement passes and giving extra weight to nets on critical paths, so their cells move closer. place_design and place_opt_design are timing-driven by default when constraints are loaded. The designer can also raise the weight of a known critical net directly.

## Raise timing effort only when congestion is under control
setPlaceMode -place_global_timing_effort high
## Raise the weight of a known critical net; weights above 10 are treated as 10 by the placer
specifyNetWeight core/alu_result_bus* 8
## Placement plus pre-CTS optimisation in one step, reports into rpt/place_opt
place_opt_design -out_dir rpt/place_opt

The cost: pulling cells together raises local density. Timing improves now and routing pays later. Thus, timing effort is usually raised only after the congestion map shows headroom.

5.2 Congestion-driven placement

The router divides the die into small tiles called global routing cells (gcells). Each gcell has a fixed number of routing tracks, its supply, and the nets passing through it need some of them, the demand. When demand is larger than supply, the difference is called overflow. A group of neighbouring gcells with overflow is a hotspot.

## Assuming, 20 horizontal tracks pass through the gcell
Supply      = 20 tracks
Demand      = 24 nets want to cross it horizontally
Overflow    = 24 - 20 = 4 tracks  (20 % over)
## The router must detour 4 nets around the gcell, or leave shorts

A congestion-driven placer uses early global route to find overflow and spreads cells in those areas so more tracks are free between them. Typical sources are macro corners, narrow channels and logic with many pins in a small area such as multiplexers and crossbars.

## Higher congestion effort for global placement
setPlaceMode -place_global_cong_effort high
## Hotspot scores and per-layer congestion from early global route
reportCongestion -hotSpot -3d
## Spread cells at hotspots incrementally; use after placement or pre-CTS opt, not after post-CTS opt
congRepair

The cost: spreading lengthens wires. It is better to find the cause of the hotspot first (Sections 5.3 to 5.5 give local fixes) and raise effort globally only when the problem is spread over the whole block. After every congestion fix, check timing again.

5.3 Density control and padding

Sometimes the placer packs a region tightly even though the block as a whole has room. Figure 2.2 showed such a bin. There are two kinds of fix: limit the density of a region, or reserve space around particular cells. Reserving space is called padding.

Table 5.1 · Density and padding controls

Three details are worth remembering. Cell padding stays honoured by CTS and optimisation until the designer removes it with deleteCellPad. Instance padding is honoured by detail placement only when the honour option above is set. Module padding factors below 1.0 are ignored, and the option affects global placement only. Thus, the three kinds of padding are not interchangeable, and choosing the wrong one gives the impression that "padding does not work".

5.4 Placement blockages

A placement blockage is an area where the designer limits what the placer may put. Innovus offers several types, and they solve different problems. Figure 5.4 shows the three used most often.

## Hard: nothing may be placed here (coordinates illustrative)
createPlaceBlockage -type hard -box {100 200 160 260} -name keep_out_A
## Soft: placement keeps out, optimisation may still add buffers, inverters and similar cells
createPlaceBlockage -type soft -box {300 120 315 380} -name chan_B
## Partial: limit density to 40 percent in a crowded area
createPlaceBlockage -type partial -density 40 -box {420 50 520 150} -name dens_C

So when is each one used? A hard blockage is for areas that must stay empty, for example under a sensitive analogue macro edge. A soft blockage suits macro channels, because long nets crossing the channel still need repeaters. A partial blockage is the gentle tool for a region that is too dense but still useful.

5.5 Macro channels and halos

The narrow gap between two macros is called a channel. It has few routing tracks because the macros above and below use or block them, yet the placer sees free sites in it and might fill them. Those cells then sit in the hardest place on the die to route to.

## Automatic soft blockages in narrow macro channels before global placement
setPlaceMode -place_global_auto_blockage_in_channel soft
## Or protect one channel the designer has identified (coordinates illustrative)
createPlaceBlockage -type soft -box {120 400 135 620} -name chan_A
## Halo: keep-out ring around each macro (left bottom right top, microns)
addHaloToBlock 5 5 5 5 -allMacro

Before blaming the channel, it is prudent to check the macro pins. A macro whose pins face a wall or another macro forces every connection to detour. Thus, many "placement" hotspots near macros are really floorplan problems, and the fix belongs in macro orientation or position.

5.6 Guides, regions, fences and attractors

Sometimes logic that should sit together ends up spread, or logic that talks to a macro or an I/O sits far from it. Innovus offers four ways to steer it, from gentle to strict.

The cost: over-constraining is a classic cause of bad timing. A fence that is too small forces high density inside and long wires to everything outside. It is recommended to start with a guide and move to a region or fence only with a reason, such as a power domain or a block that must be hardened separately.

## Fix fanout limits too (off by default); keep this on through post-route
setOptMode -opt_fix_fanout_load true
## Keep area recovery away from near-critical paths (value illustrative, in ns)
setOptMode -opt_area_recovery_setup_target_slack 0.05
## Ban cells the methodology does not allow (library and cell names are examples)
setDontUse slow_lib/DLY4X1 true

## Assuming, three flops in a pipeline: FF1 -> FF2 -> FF3, same clock
Path A (FF1 -> FF2): setup slack = -40 ps
Path B (FF2 -> FF3): setup slack = +60 ps
## Delay the clock at FF2 by 50 ps
Path A: capture is 50 ps later   -> setup slack = -40 + 50 = +10 ps
Path B: launch is 50 ps later    -> setup slack = +60 - 50 = +10 ps
## The catch: hold on path A loses the same 50 ps
Path A: hold slack = (old hold slack) - 50 ps

## Load scan chain information so reordering can run (file name is an example)
defIn design_scan.def
## After placement, report chain lengths and scan wire length
report_scan_chain -out_file rpt/scan.rpt

## Power effort with a balanced leakage/dynamic target (0.5); dynamic needs switching activity loaded
setOptMode -opt_power_effort low -opt_leakage_to_dynamic_ratio 0.5
## Allow multi-bit merging and splitting during pre-CTS optimisation (default only splits)
setOptMode -opt_multi_bit_flop_opt true
## Check how instances are spread across Vt classes after placement
reportVtInstCount -outFile rpt/vt.rpt

## 1. Restore the floorplan database that passed the gate in Section 3.6
restoreDesign db/floorplan.enc.dat top
## 2. Path groups so reg2reg and reg2cgate get their own effort
createBasicPathGroups -expanded
setPathGroupOptions reg2reg -effortLevel high
setPathGroupOptions reg2cgate -effortLevel high
## 3. Optimisation settings kept for the whole flow
setOptMode -opt_fix_fanout_load true
setOptMode -opt_drv_margin 0.1
## 4. Protect macro channels before global placement
setPlaceMode -place_global_auto_blockage_in_channel soft
## 5. Print every mode into the log for review
getPlaceMode
getOptMode
## 6. Placement plus pre-CTS optimisation
place_opt_design -out_dir rpt/place_opt
## 7. Tie cells after standard cells are placed
addTieHiLo
## 8. Exit checks (Section 6)
checkPlace rpt/checkPlace.rpt
timeDesign -preCTS -outDir rpt/preCTS
reportDensityMap -threshold 0.75
reportCongestion -hotSpot -3d
## 9. Save before CTS so the flow can come back here
saveDesign db/place_opt.enc

5.13 Choosing a technique for each type of violation

So far each technique was described on its own. In practice the designer starts from a report, not from a technique. Table 5.3 turns the question around: given the violation, which technique is tried first, which one comes next, and what should be avoided. The first column is what the timing, DRV, congestion or power report shows.

Table 5.3 · Violation to technique selection guide

5.14 Trade-off matrix

Every technique buys one thing with another. Table 5.4 collects the trade-off rows from Sections 5.1 to 5.11 into one view, so the designer can see what a change is likely to cost before making it. The entries describe the typical direction of the effect, not a guarantee; the real result depends on the design, and it should be confirmed with the reports in Section 6.

Table 5.4 · Typical effect of each technique (▲ better, ▼ worse, ● little change, ◆ depends on how it is used)

Three trade-offs come up so often that they deserve a sentence each. Timing against congestion: pulling cells together shortens wires and raises density; spreading them does the opposite, so the two efforts are tuned together, never one alone. Setup against hold: useful skew and scan reordering both help one check by taking margin from hold, so the hold picture after CTS has to be planned for. Timing against area and power: every buffer, upsized gate and low-Vt swap that fixes setup costs area and power, which is why area recovery and power optimisation are kept away from near-critical paths with a slack target rather than switched off.

5.15 setPlaceMode at a glance

setPlaceMode holds the persistent settings of the placement engine. They apply to place_design, place_opt_design and refinePlace until changed, and the current values are printed with getPlaceMode. Table 5.5 lists the options most often used at this stage. Defaults are given as documented; confirm them in the release you use.

Table 5.5 · Key setPlaceMode options

5.16 setOptMode at a glance

setOptMode holds the settings of the optimisation engine used by place_opt_design and optDesign. Several options here decide how much of the netlist the tool may change and at what cost. Table 5.6 lists the ones that matter most before CTS, grouped by purpose.

Table 5.6 · Key setOptMode options

## A balanced starting point for a congested, timing-critical block (values illustrative)
setPlaceMode -place_global_cong_effort high -place_global_timing_effort medium
setPlaceMode -place_global_auto_blockage_in_channel soft
setOptMode -opt_fix_fanout_load true -opt_drv_margin 0.1
setOptMode -opt_area_recovery_setup_target_slack 0.05
## Print both into the log so the run can be reproduced
getPlaceMode
getOptMode

Thus, the two tables are not a list of switches to flip. Most defaults are sensible, and each change in these tables should answer a specific line in a report. Table 5.3 says which report line leads to which option.

06After Placement: Check Before CTS #

A placement is finished when the evidence says so, not when the command returns. This section lists the reports to read and what each one should show before the design moves to CTS.

## Legality: overlaps, off-grid cells, blockage and fence violations
checkPlace rpt/checkPlace.rpt
## Pre-CTS timing: runs early global route and extraction, then writes setup and DRV reports
timeDesign -preCTS -outDir rpt/preCTS
## Density map; bins above 75 percent are listed
reportDensityMap -threshold 0.75
## Hotspots and per-layer congestion
reportCongestion -hotSpot -3d

6.1 Reading the pre-CTS timing summary

The summary that timeDesign -preCTS writes has one row per path group with the worst negative slack (WNS), the total negative slack (TNS) and the number of violating paths, followed by a table of design rule violations (max transition, max capacitance, max fanout) and the density. Two details are easy to misread.

• The overall TNS and the overall count of violating paths are counted per endpoint, so they need not equal the sum of the path group values. An endpoint failing from two groups counts once overall.
• The density in this report ignores padding, while checkPlace includes it (Section 5.3).

## Assuming, one register has two failing paths into its D pin
From an input port   : slack -0.6 ns   (in2reg group)
From another register: slack -0.3 ns   (reg2reg group)
in2reg TNS  = -0.6 ns,  reg2reg TNS = -0.3 ns
Overall TNS = -0.6 ns  (one endpoint, its worst slack only)
Violating endpoints overall = 1, not 2

6.2 The exit gate

07Debug Playbook #

Table 7.1 maps the symptoms seen most often after placement to their usual causes. The first column is what the report shows; the last column is where to look first, not a guaranteed fix.

Table 7.1 · Symptom to cause to first action

Thus, most debugging at this stage is a question of asking what the tool believed: which constraints it saw, which areas it thought were free, which nets it thought were critical. Once that is clear, the fix is usually small.

08Interview Questions #

The questions are grouped by the experience level at which they are typically asked. Each one has four parts: why the interviewer asks it, the expected answer, and a pair of follow-up questions with short answers. The answers are written in the first person because that is how they will be spoken.

Level 1: Basic (0 to 2 years)

Level 2: Intermediate (2 to 5 years)

Level 3: Advanced (5 to 8 years)

Level 4: Expert (8+ years: Senior, Lead, Staff)

09Chapter Summary #

Placement turns a netlist into positions, and with positions come real wire lengths, a congestion picture and the first timing report that can be trusted. We saw that most bad placements come from bad inputs, so a gate of library, netlist, constraint, floorplan and physical cell checks comes first. We then looked at what place_opt_design does inside, why wire length costs more than distance suggests, and twelve techniques for timing, congestion, density, guidance, netlist changes, clock and scan awareness, power and incremental runs. Each technique has a cost, and several of them pull against each other, which is why they are applied in response to a report rather than all at once.

Getting placement wrong is expensive in a chain: congestion that survives becomes detours, detours become timing failures after routing, and those become late ECOs and a moving tapeout date. A clean exit gate before CTS is what breaks that chain. In the next stage, clock tree synthesis, the ideal clock assumption ends; the reg2cgate paths, the useful skew offsets and the room left for buffers all come back into play.

10Top 15 Quick Revision Questions #

1. Placement in one line? Mapping cells to legal row sites so timing, congestion and density all agree.
2. Global vs detail? Rough, overlapping, spread positions vs legal sites with local improvement.
3. Legalisation command? refinePlace, called by place_opt_design at the end.
4. First step inside place_opt_design? Removing synthesis buffer trees.
5. Utilisation vs density? Whole-block ratio vs ratio inside one bin.
6. Why zero wire-load timing first? If it fails there, placement cannot fix it.
7. Why break loops in SDC? So every run analyses the same timing graph.
8. Hard, soft, partial blockage? Nothing; no placement but buffers in opt; density limit.
9. Fix for a crowded macro channel? Soft blockage plus halos, and a look at macro pins.
10. Guide, region, fence? Preference; module inside, others allowed; module only, all inside.
11. Overflow? Routing demand minus supply in a gcell.
12. Why clock-gate-aware placement? Real ICG clock arrives early, so its enable path has less time.
13. Useful skew catch? Moves slack, worsens hold on the borrowing path, needs CTS to implement it.
14. Scan reorder risk? Short scan paths become hold violations after CTS.
15. Incremental vs full rerun? Local change vs new floorplan, macros or netlist.

11Important Definitions #

12Important Commands #

13Quick Revision Notes #