Placement, Pre-CTS Optimization, Checks and Handoff: legal cells for CTS

Why this chapter matters in a real project

Placement is the step where the standard cells of the netlist get locations. Everything after it inherits those positions: clock tree synthesis (CTS), routing and timing closure. Legalization and optimization can only repair small things. A poor global placement is nearly always a reason to go back, not to push forward.

Some missing inputs still let the tool produce a result. Without timing constraints, for example, the placer runs on wirelength alone. That result answers a different question from the one you meant to ask. A clean timing summary can then hide real violations, because nothing was checked. Essential physical inputs, such as rows or libraries, can stop the run outright.

The opposite error costs time too. An average can look fine while one window cannot route. A placement handed over without its evidence is only a guess. Done badly, it costs a clock tree built on cells that must move. It also costs a congestion problem found after routing, and a timing number nobody can reproduce.

Prerequisites

• Understanding the Innovus Environment and Session: how to restore a design, use the Tcl prompt and query the database with dbGet.
• Design Data Preparation, Import, Sanity Checks and Export: netlist, libraries, constraints and views loaded and checked.
• Floorplanning: die, core, rows, macros, halos and the saved floorplan checkpoint.
• Power Planning: rings, stripes, rails and the checkpoint that holds the finished grid.
• You do not need to know how the placer's algorithms work inside.
• You do not need to know clock tree synthesis. The next chapter builds the clock tree.

Learning objectives

1. Explain what placement changes in a database, what it leaves alone, and which evidence shows each change.
2. Separate three states that are easy to confuse: the design loads, it is ready for placement, a timing report means something.
3. Describe global placement, legalization and detailed placement, and why a legal placement can still be poor or unroutable.
4. Prepare the placement area: usable rows, fixed objects, blockages, regions, fences, physical cells and cell-use restrictions.
5. Run place_design and optDesign -⁠preCTS with recorded settings, and read the density, congestion and timing reports.
6. Apply one change at a time from a restored baseline, compare runs on several measures, and accept or restore.
7. Answer four separate questions: is it legal, plausibly routable, timing-acceptable for this stage, ready for CTS.
8. Diagnose eight common placement failures from a symptom, and say when the cause is an upstream assumption.
9. Save, restore and hand over the placement with its evidence and its open items.

Figure 1 shows the whole chapter on one page. Come back to it whenever you lose your place.

Placement and pre-CTS on one page

From the power-planned floorplan to a checked handoff for CTS

What to notice: Phase 1 ends with a saved legal placement before Phase 2 changes anything. The result bar names what CTS receives.

The running example and its conventions

Orientation R0 is unrotated; MY is mirrored about the vertical axis. Every quantity this chapter adds, such as a cell area, a utilization or a slack, is invented and says so. Dimensions are in µm, areas in µm² and times in ns unless a figure says ps. Code uses the plain numbers the tool expects.

1  Purpose, boundaries and entry conditions

1.1  Where this chapter starts and stops

Let us fix the position of the chapter in the flow first. Floorplanning decided the geometry: die, core, rows, macros and halos. Power Planning added the supply metal. Preplaced objects, such as macros and physical cells, already have locations. The standard cells have so far been a list in a netlist, with no location.

The sequence we teach is a model, not a list of separate commands. The tool can combine steps or iterate inside them. A single place_design call, for example, runs global and detailed placement together with placement-related optimization. It can also run legalization internally. The worked flow uses two main commands: place_design, then optDesign -⁠preCTS. Section Three commands, three different roles compares them with place_opt_design, the integrated alternative.

Figure 2 places these steps in order. Notice the loop back from the checks: iterating is part of the flow, not a failure of it.

Where this chapter sits in the flow

Two phases between a readiness gate and a handoff gate

What to notice: The first arrow into placement passes a gate, and the last arrow out of the checks passes a gate. Dashed boxes are outside this chapter. The purple box is an alternative, not an extra step.

1.2  Loaded, ready, and meaningful

Thus, a design that loads can still be unready. A design that is ready can still return a timing report that says nothing. The second case is the dangerous one, because a report with no violations looks like good news. Section Clean timing can mislead returns to it.

1.3  Entry conditions

Table 4 lists what placement depends on. Read the consequence column first: it is the reason to check.

1.4  What can be missing, and who decides

Some missing inputs let the tool run in a reduced way. Others stop it. Missing libraries, missing rows or corrupt data can fail the run. Missing constraints allow a wirelength-driven run. Write each gap down, name who decides it, and say what you will do meanwhile. Table 5 gives the usual cases.

1.5  Restore the checkpoint and record the baseline

Everything in the chapter compares against one baseline, so we create it first. Restore the saved floorplan database with power planning completed. Then record a few facts before any placement command runs. The path and top cell name below are examples; take yours from the handoff record. Every command after the restore only reads.

innovus> restoreDesign checkpoints/grid_run1/grid.enc.dat stream_acc ;# load the DB
innovus> puts "top: [dbGet top.name]" ;# print the top cell name
innovus> puts "core box: [dbGet top.fPlan.coreBox]" ;# print the core box
innovus> puts "instances: [dbGet top.numInsts]" ;# print the instance count
innovus> foreach st {unplaced placed fixed} { ;# count instances by placement status
    set l [dbGet -p top.insts.pStatus $st]
    if {$l eq "0x0"} { set c 0 } else { set c [llength $l] }
    puts "$st: $c instances"
}

• restoreDesign loads the saved database. Everything after it only reads.
• dbGet returns a Tcl list. The value 0x0 means "no match", not a count of zero. The guard prints zero only for that case.
• Expected here. The core box is 40 40 1040 1040, the three macros are fixed, and the standard cells are unplaced. So the placed count is zero. These expectations come from the floorplanning stage, not from a tool log.
• pStatus is the attribute that holds placement status. Confirm the field list with dbGet [lindex $some_inst 0].? before you build on it.
• A zero needs a working query. An unplaced count of zero does not mean the design is placed if the list command failed. Test for 0x0 and for an error before you read a number.

2  What placement does: the fundamentals

"Placed" has three meanings in everyday talk. The cells have coordinates; the cells do not overlap; the cells are in good places. A tool can deliver the first without the second, and the second without the third. If you do not keep the three apart, a legal result is read as a good one. A good result is then read as one that is ready for the next step.

2.1  The stages, in plain words

Let us start with an intuition. Imagine a few hundred thousand small parts laid out on a board with a fixed grid of slots. Each part is wired to a few others. A good layout puts parts that talk a lot close together. It keeps long wires for the connections that can afford them. It does not crowd any region so much that the wires cannot get out. A placer works toward that in stages, because one exact solution is out of reach. Table 6 names the stages.

2.2  Instance states

Every instance has a placement status. The status decides who may move it, as Table 7 shows.

So a cell you have fixed is checked but never repaired, and an unplaced cell is neither. Whenever a status word matters to a decision, read it back from your database. The query is in section Query and debug reference; do not rely on Table 7 alone.

2.3  Rows, sites and orientation

A row is a horizontal strip made of identical sites. A site is the smallest width a cell can occupy. In the example, core_site is 0.2 µm wide and 1.4 µm high. So a cell 1.2 µm wide occupies six sites, as Figure 3 draws. A cell is legal when three things hold:

• its lower-left corner is on a site boundary;
• its whole footprint is inside one row, or a stack of rows for multi-height cells;
• its orientation is one the row allows.

Rows, sites and orientation

Two rows sharing one VDD rail; rows drawn shorter

What to notice: Both cells touch the shared VDD rail with their VDD side; A is 1.2 µm wide.

Orientation exists because supply rails alternate. Power Planning laid VDD and VSS rails on alternate row boundaries, so adjacent rows share a rail. A cell in the upper row of a pair is usually flipped about the horizontal axis (MX). That way its VDD pin meets the shared rail below it, the same rail the row underneath uses. A cell in the wrong orientation has its power pins on the wrong rails. checkPlace lists row orientation and site mismatch among the violations it finds. Both rows of Figure 3 show this.

2.4  Overlap, whitespace and density

U   = A_cells / A_usable
d_b = A_cells,b / A_usable,b      (the same ratio for one bin b)

Here A_cells is the total standard-cell area in µm². A_usable is the placeable core area in µm², after macros, halos and hard blockages are removed. Local density d_b is the same ratio for one bin, a small square window. The density map in section Reading the density map shows it.

Which cells and which area a report counts differs between reports. checkPlace includes padding in its utilization and timeDesign does not, so the two numbers can differ. State which one you quote.

The subtotal is a teaching number. It ignores tap and endcap sites, cut or missing rows, further hard blockages and the partial blockage of the example. A report's own capacity figure can therefore differ. The two ratios, 0.61 and 0.41, describe the same design. A reader who sees only one of them cannot tell which was meant.

2.5  Wirelength and routability

HPWL = (x_max - x_min) + (y_max - y_min)

Here x_max, x_min, y_max and y_min are the largest and smallest pin coordinates of the net, in µm. The total is the sum over all nets. Figure 4 shows one net and its box.

HPWL is an estimate. For nets with more than three pins, the shortest route is longer than HPWL even with no obstacle. It also ignores detours, so a net that must go around a macro is longer again. Whether a report states HPWL or an estimated routed length is a property of the report. Use the figure to compare runs of the same tool, not to predict a routed length.

Routability is whether the router can complete the wires with the metal and space available. Wirelength is only part of it. A placement with a short total wirelength can still concentrate many wires in one small region. The router then runs out of tracks there. This is why we read density, congestion and wirelength together.

Half-perimeter wirelength of one net

Four pins, one bounding box, one detour

What to notice: The box is 60 µm wide and 30 µm tall, so HPWL is 90 µm. With four pins, even an unobstructed route would exceed 90 µm; the macro adds a detour on top. Numbers are illustrative.

2.6  Why the three results come apart

Figure 5 follows one small region through the three stages. It is the clearest way to see that "placed", "legal" and "good" are different words.

One region, three stages

Global placement, legalization and refinement of eight cells

What to notice: Only panels B and C are legal. In A the red strips show where cells overlap. Cell h moves furthest in legalization. Refinement swaps g and h, keeps legality and shortens the a-to-h net. No panel shows routing.

Four statements follow from the three stages. Each is a reason not to stop at the first good-looking result.

1. Global placement may be illegal. It optimizes a smooth model in which cells may overlap slightly and sit between sites, because that model is easy to improve. Legalization is a separate step because the model is not the layout.
2. A legal placement may have poor timing. Legalization moves cells to the nearest free site. It does not know which cell sits on a critical path. A cell pushed 8 µm along a critical net adds wire delay that the global stage had avoided.
3. A legal placement may be hard to route. Legality is about cells. Routing needs pins that can be reached and tracks that are free. checkPlace finds some pin-access and power-pin problems. However, cells packed around a macro pin can pass every check and still leave the net hard to route.
4. Low average utilization does not mean low congestion. The average over the usable area hides where the cells are. A design at 61 percent can contain a window at 95 percent, and routing demand follows the window.

3  Preparing for placement

A placer does not know what you intended. It knows the rows, the objects and the restrictions in the database. If a macro is movable when it should be fixed, the placer follows the database faithfully. The same holds for a blockage that is hard when it should be partial, or a missing fence. Preparation is where you make the database say what you mean.

3.1  Usable area and core area

The core is the rectangle that contains the rows. The usable area is the part of the core where a standard cell may actually sit. It is smaller, and the difference is the first thing to understand about a placement. The example is annotated in Figure 6. Table 9 lists what removes usable area.

The usable area of the example

Macros and halos to scale, rows schematic

What to notice: The channel is 70 µm between macro edges and 50 µm after the halos; the left strip is 60 µm, and 50 µm after the halo. The drawing shows the database, not cell positions.

In the example, the geometric subtotal is 671 600 µm²: the core minus the three macros and their non-overlapping 10 µm halos. It leaves out tap and endcap sites, cut or missing rows and any further hard blockage. It does not model the partial blockage either. A partial blockage limits occupancy locally; it is not simply forbidden area.

Use the subtotal for the teaching ratios in this chapter. For a tool comparison, use the placement capacity that a report states, and read which numerator and denominator it used. Do not subtract an exclusion twice. Do not mix cell occupancy with an already reduced denominator.

3.2  Fixed objects

innovus> foreach n {u_buf_a u_buf_b u_coef} { ;# print status, orientation and box
    set i [dbGet -p top.insts.name $n]
    if {$i eq "0x0"} { puts "ERROR: instance $n not found"; continue }
    puts "$n status=[dbGet $i.pStatus] orient=[dbGet $i.orient]\
        box=[dbGet $i.box]"
}

• Expected here. Each macro is fixed. u_buf_a and u_buf_b are R0 and u_coef is MY. Their boxes are 100 90.4 520 390.4, 100 689.6 520 989.6 and 590 800.2 830 960.2.
• A print, not a test. This listing is a diagnostic. The acceptance script in section An acceptance pass in order turns the same comparison into a pass or fail.
• What it leaves out. It does not show the halo, or whether the PG metal is still where the macros are.

innovus> placeInstance u_buf_a 100 90.4 R0 -fixed ;# corner, orientation from record
innovus> placeInstance u_buf_b 100 689.6 R0 -fixed ;# same for the second RAM
innovus> placeInstance u_coef 590 800.2 MY -fixed ;# same for the ROM

3.3  Blockages: hard, soft, partial and macro-only

A placement blockage keeps cells out of an area. How much it keeps out depends on its type.

A blockage is a floorplan object, usually created during floorplanning. In this chapter you read it back. You change it only through the controlled refinement of section Controlled refinement.

innovus> createPlaceBlockage -name pb_example -type partial -density 50 \
    -box {600 100 800 300} ;# at most 50 percent cell density in this box

innovus> deletePlaceBlockage pb_example ;# remove the blockage by its name

• Start from a restored baseline, so that restoring also undoes the object.
• Creating a blockage does not move cells already placed. Placement must run again for it to act.
• There is no report of its effect. Judge it by the density map and the legality check.

3.4  Regions and fences

Figure 7 shows the difference with three members and two nonmembers.

A region and a fence, with members and nonmembers

The same cells under two kinds of constraint

What to notice: Members stay inside in both panels. Nonmember n1 inside the region is allowed; inside the fence it is a violation. A picture is not a membership inventory: read membership back from the database.

innovus> createInstGroup grp_region ;# create an empty instance group
innovus> addInstToInstGroup grp_region {u_dp/u_logic0 u_dp/u_logic1} ;# add leaves
innovus> createRegion grp_region 120 420 480 680 ;# hold the group inside this box

innovus> createInstGroup grp_fence ;# create a second group
innovus> addInstToInstGroup grp_fence {u_ctrl/u_logic0 u_ctrl/u_logic1} ;# add members
innovus> createFence grp_fence 540 420 780 680 ;# members inside, nonmembers out

innovus> createFence u_core/u_mac 120 420 480 680 ;# no user group needed

innovus> setPlaceMode -place_hard_fence true ;# legalizer and checker honor fences
innovus> setOptMode -opt_honor_fences true ;# optimization honors them too

innovus> file mkdir checks ;# directory for the group reports
innovus> checkFPlan -outFile checks/fplan_groups.txt -reportUtil ;# group utilization
innovus> selectGroup grp_region ;# select the members of one group
innovus> reportSelect -file checks/grp_region_select.rpt ;# list what is selected
innovus> deselectGroup grp_region ;# clear the selection
innovus> checkPlace checks/checkplace_groups.rpt ;# members outside their box

• checkFPlan -⁠reportUtil prints the target and effective utilization for the whole design, the fences and the regions. Read the effective figure of each box.
• selectGroup and reportSelect show what the selection holds. The report layout depends on the installation, so read one report before you build a script on it.
• A clean checkPlace shows that the geometry rules hold. It does not show who the members are.

innovus> deleteInstFromInstGroup grp_region u_dp/u_logic1 ;# drop one member
innovus> unplaceGuide grp_region ;# remove the guide, region or fence of the group

3.5  Narrow channels

innovus> report_narrow_channel -width 80 ;# channels under 80 um, so the 70 um one too

innovus> setPlaceMode -place_global_auto_blockage_in_channel none ;# the default

• Choosing the width. Give a width just above the channel you care about, for example 80 for the 70 µm channel. A width equal to the channel may or may not list it.
• The three values are none (the default), soft and partial.
• The soft form acts on channels under 50 µm, and optimization may still place cells in them. Our channel is at that figure, so you cannot assume the rule fires.
• Decide by reading what the tool created, not by the number. The choice is a decision, so record it.

3.6  Tap, endcap and physical-only cells

Well-tap and endcap cells are physical-only: they have no logic function. They are normally preplaced before the standard cells, after the floorplan is fixed and the hard blocks are placed. addWellTap and addEndCap insert them, setEndCapMode chooses the endcap cells, and deleteFiller removes them. The choice of cells depends on the technology and library.

3.7  Cell-use restrictions

innovus> setDontUse DELAYCELL* true ;# forbid these cells; false clears the restriction

3.8  High-fanout nets and scan

3.9  Placement and optimization settings before the run

A mode that is only printed is not applied. Configure the modes first, then read them back. Every run, and every experiment of section Controlled refinement, must source the same baseline script. Printing the modes is not enough.

# Optimization: repair and permissions.
setOptMode -opt_drv true
setOptMode -opt_setup_target_slack 0.0
setOptMode -opt_fix_fanout_load false
setOptMode -opt_honor_fences true
setOptMode -opt_add_insts true
setOptMode -opt_delete_insts true
setOptMode -opt_move_insts true
setOptMode -opt_down_size_insts true
setOptMode -opt_enable_restructure true
setOptMode -opt_pin_swapping true
setOptMode -opt_area_recovery default
setOptMode -opt_max_density 0.95
setOptMode -opt_power_effort none

# Teaching policy of this chapter: no useful skew, no early hold repair.
setOptMode -opt_skew false
setOptMode -opt_skew_pre_cts false
setOptMode -opt_early_hold_fixing none
# Placement.
setPlaceMode -place_design_floorplan_mode false
setPlaceMode -place_global_timing_effort medium
setPlaceMode -place_global_cong_effort auto
setPlaceMode -place_global_uniform_density false
# Controls that the experiments vary, stated explicitly so that a
# restore cannot leave a stale value.
setPlaceMode -place_global_max_density -1
setPlaceMode -place_global_module_padding {}
setPlaceMode -place_global_soft_guide_strength low
setPlaceMode -place_global_clock_gate_aware true
setPlaceMode -place_global_place_io_pins false
setPlaceMode -place_global_ignore_scan true
setPlaceMode -place_global_reorder_scan false
setPlaceMode -place_global_auto_blockage_in_channel none
setPlaceMode -place_hard_fence true
setPlaceMode -place_detail_honor_inst_pad true
setPlaceMode -place_detail_wire_length_opt_effort medium

Three lines make the starting point of every experiment explicit. They set no density cap (-⁠1 is the off value), no module padding, and the lowest soft-guide strength, which is the default. A default is not necessarily the value a restored session holds, so the baseline sets it. The readback below confirms whether an empty module-padding value is accepted as a reset. If your installation rejects it, keep a full readback of a known-good session and compare against that instead.

innovus> source scripts/baseline_policy.tcl ;# apply the baseline policy
innovus> getOptMode ;# the effective optimization modes
innovus> getPlaceMode ;# the effective placement modes
innovus> getOptMode -nonDefault ;# only values that differ from the defaults
innovus> getPlaceMode -nonDefault ;# the same for placement
innovus> getAnalysisMode ;# the analysis settings that timing will use

Each active setting has one effect and one condition:

• Optimization permissions. -⁠opt_add_insts, -⁠opt_delete_insts, -⁠opt_move_insts, -⁠opt_down_size_insts, -⁠opt_enable_restructure and -⁠opt_pin_swapping each allow a kind of change. They do not choose a cell or guarantee a gain. Restructuring and pin swapping need an approved equivalence policy.
• DRV and fanout. Design-rule violations (DRVs) here are max capacitance and max transition violations. -⁠opt_drv true repairs them; false repairs only timing-violating paths. Fanout repair stays a project decision: setOptMode -⁠opt_fix_fanout_load true enables it as a separate experiment.
• Setup target. -⁠opt_setup_target_slack 0.0 is in ns. A positive target asks for margin and grows the netlist.
• Fences. -⁠opt_honor_fences true and -⁠place_hard_fence true are needed when binding fences or regions exist. Verify the effective capacity, because a fence too small for its members may not be honored as written. Confirm the condition for your installation.
• Growth limit. -⁠opt_max_density 0.95 is an area-utilization cap on optimization growth. It is not a recommended placement utilization target. It is also not the global placer's local density cap.
• Area recovery. default reduces area after global optimization and after the second TNS (total negative slack) pass. Recovery gives timing margin back to area, so read the timing summary afterwards.
• Power effort. -⁠opt_power_effort none keeps power-driven transforms off. Low and high add runtime and change the trade-offs.
• Useful skew. Both -⁠opt_skew and -⁠opt_skew_pre_cts must be true for pre-CTS useful skew. The master option can disable the stage option. Any latencies it generates belong in the handoff and must be coordinated with CTS.
• Early hold. -⁠opt_early_hold_fixing belongs to place_opt_design, with ideal or propagated clocks. Reconcile its use in another flow with -⁠help in your installation before running it.
• Placement efforts. -⁠place_global_timing_effort medium and -⁠place_global_cong_effort auto are the middle settings. High timing effort is not advised for congested designs.
• Clock gates. -⁠place_global_clock_gate_aware true moves clock gates toward the center of their fanout. It needs a clock specification file.
• Padding. -⁠place_detail_honor_inst_pad true makes refinePlace and checkPlace honor instance padding.
• Detailed wirelength. -⁠place_detail_wire_length_opt_effort medium allows swaps for a small wirelength gain. high can add run time.
• Prototype mode. -⁠place_design_floorplan_mode false keeps the full placement. True gives a quick prototype that may be illegal.

Some controls stay out of the baseline because they depend on the technology. Examples are spacing and cut-layer modes, color-aware modes, IR-drop-aware (supply voltage drop) modes and preroute-obstruction modes. Add one only when its units, prerequisites and stage relevance are established. Post-route-only congestion controls are not pre-CTS placement techniques.

Two policy choices change the whole chapter if you flip them: scan reordering and useful skew. Keep both consistent with every later clock and scan statement, because CTS inherits them.

3.10  The readiness gate

Run the gate as a list of statements. A blocking item stops the run. A review item is recorded with a decision and an owner. It does not stop the run on its own. Table 11 lists both kinds.

innovus> file mkdir reports/ready ;# a directory for the evidence
innovus> set rows [dbGet top.fPlan.rows] ;# all row objects; names to confirm with .?
innovus> puts "rows: [llength $rows]" ;# how many rows exist
innovus> puts "site of the first row: [dbGet [lindex $rows 0].site.name]" ;# its site
innovus> checkFPlan -reportUtil -outFile reports/ready/fplan.txt ;# objects, util
innovus> report_narrow_channel -width 80 ;# channels under 80 um, so the 70 um one
innovus> puts "active views: [all_analysis_views -type active]" ;# views in use
innovus> report_clocks > reports/ready/clocks.rpt ;# the defined clocks
innovus> report_case_analysis > reports/ready/case.rpt ;# constants that remove paths
innovus> check_timing -verbose > reports/ready/check_timing.rpt ;# completeness

3.11  Three commands, three different roles

• place_design is not "only assigning coordinates".
• optDesign -⁠preCTS is not the initial placement of the full design.
• Placement and optimization commands can invoke internal legalization and other operations.
• refinePlace is a supporting legalization operation, used only when legalization is needed.

4  Global placement

Global placement decides the large-scale shape of the design. It decides which blocks of logic sit near which macros and where the dense areas are. It also decides how far apart the registers of a critical path end up. Legalization and optimization can only repair small things afterwards.

4.1  Intuition: a balance of pulls

4.2  Physical meaning

The placer works on a model. In it, cells have a size and a position, and nets have an estimated length. It does not route wires. It works from an estimated picture of routing resources, fed by the congestion effort and the extraction settings. That picture is coarser than completed detailed routing.

Pull a hundred cells together, and the model says wirelength falls. The physical consequence arrives later. Those hundred cells sit in one window. The wires leaving it must all pass through the edges of that window. Compare the two cases in Figure 8: a tight cluster and a spread one.

Why connected cells cluster, and why unlimited clustering is a problem

The same nine cells beside a macro, pulled together and spread

What to notice: A has the shortest wire, but 14 wires meet 11 tracks. B uses 12 percent more wire, and its 12 wires fit 15 tracks.

Thus, "cells cluster" is not a defect. It is the intended result of the main cost. It becomes a defect in two cases. The cluster may be so dense that there is no room for the repair cells optimization will need. Or the wires may be unable to get out.

4.3  Tool operation: place_design

place_design is the main placement command. It runs global and detailed placement in one call, with placement-related optimization. It is timing-driven by default when constraints are loaded. It is not timing-driven when no constraints are loaded, or in prototyping mode. It honors the optimization, routing, analysis and extraction modes, with the analysis exceptions below.

• Prerequisites. The readiness gate passed, constraints loaded for a timing-driven run, and a restored baseline with the baseline policy applied.
• Options. The baseline runs it bare. -⁠incremental works only on an already placed design and implies -⁠noPrePlaceOpt. -⁠noPrePlaceOpt skips the pre-place step. -⁠sdp makes it structured-datapath aware. -⁠concurrent_macros selects the mixed placer, a separate flow described near the end of the chapter.
• Database change. It gives locations to unplaced standard cells. By default the pre-place step also removes buffers of the specified footprint, in the manner of deleteBufferTree. So the netlist can change before any cell is positioned.
• -⁠noPrePlaceOpt is not a guarantee. It skips that step, but other optimization can still change the netlist. Compare instance counts and the netlist fingerprint before and after, whichever option you chose.
• Analysis overrides. During place_design the tool uses setup analysis even if setAnalysisMode -⁠checkType hold is set. It forces ideal clocks even if -⁠clockPropagation sdcControl is set. It uses -⁠clkSrcPath false even if true is set. setExtractRCMode is honored except -⁠detail. Thus, you cannot make placement see propagated clocks or hold paths with these options.
• Routing model. Placement uses estimated routing models, not final routes. Every congestion and timing number at this stage is an estimate.

innovus> file mkdir checkpoints/place_run1 ;# a directory for this run
innovus> place_design ;# baseline run; timing-driven because constraints are loaded
innovus> saveDesign checkpoints/place_run1/placed.enc ;# save the raw result at once

4.4  Global placement settings: the baseline and the experiments

innovus> setPlaceMode -place_global_timing_effort high ;# experiment 1
innovus> getPlaceMode -place_global_timing_effort ;# read it back
innovus> setPlaceMode -place_global_cong_effort high ;# experiment 2
innovus> getPlaceMode -place_global_cong_effort ;# read it back
innovus> setPlaceMode -place_global_max_density 0.80 ;# experiment 3
innovus> getPlaceMode -place_global_max_density ;# read it back
innovus> setPlaceMode -place_global_uniform_density true ;# experiment 4
innovus> getPlaceMode -place_global_uniform_density ;# read it back
innovus> setPlaceMode -place_global_module_padding {u_dp 1.2} ;# experiment 5
innovus> getPlaceMode -place_global_module_padding ;# read it back
innovus> setPlaceMode -place_global_auto_blockage_in_channel partial ;# experiment 6
innovus> getPlaceMode -place_global_auto_blockage_in_channel ;# read it back
innovus> setPlaceMode -place_global_soft_guide_strength medium ;# experiment 7
innovus> getPlaceMode -place_global_soft_guide_strength ;# read it back

A readback shows what is set; it does not apply anything. Placement reads the settings at run time, so a changed value matters only if it was set before place_design. Whether restoreDesign resets the modes is not established here. That is why every experiment sources the baseline script after the restore. For per-cell or per-instance padding that detailed placement honors, use the recipes in section Recipes: one change each.

4.5  Readback: what to look at right after

innovus> file mkdir reports/place_run1 ;# a directory for this run's reports
innovus> foreach st {unplaced placed fixed} { ;# 1. status counts; nothing unplaced
    set l [dbGet -p top.insts.pStatus $st]
    if {$l eq "0x0"} { puts "$st: 0" } else { puts "$st: [llength $l]" }
}
innovus> checkPlace reports/place_run1/checkplace.rpt ;# 2. legality; lists violations
innovus> reportDensityMap ;# 3. density per window, default grid and threshold

• Status counts. A non-zero unplaced count after a successful run needs an explanation (section Case 1: cells remain unplaced).
• Legality. The positional argument names the violation report file. checkPlace also prints the count of placed cells, the unplaced macros and the placement density.
• Density. reportDensityMap shows a color map and a text report. The defaults are a 50 µm grid and a 0.75 threshold below which bins are not reported.
• Not yet. Congestion needs an early global route first. Section Congestion and routability shows how, and why the map is only an estimate.

Figure 9 shows what changed and what did not.

The same floorplan before and after global placement

Macros and halos stay; only the standard cells move

What to notice: Macros and halos do not move. The channel holds fewer cells because of the halos, not an error. B is not yet legal.

4.6  Failure and repair

4.7  Rerun requirements

Restore the baseline before each run. place_design -⁠incremental works only on an already placed design. It is a different operation from a fresh placement.

You may change a floorplan object, a blockage, a fence, a setting that placement reads, or the constraints. In each case, restore the checkpoint, source the baseline script and run again. After any rerun, regenerate the status counts, the legality report and the density map. Regenerate every other report that depends on cell positions too. A report written before the run describes a design that no longer exists.

5  Legalization and detailed placement

Legalization is the step where a placement becomes something a layout can contain. It is also the step that quietly spoils global placement when it has too much to do. A tool that moves each cell a fraction of a micron is polishing. A tool that moves a few cells 40 µm is rewriting the plan. The timing and routing you were counting on go with it.

5.1  Intuition: sliding cells onto a ruled page

Imagine the global result as a pile of cards laid roughly where you want them. The sheet below them is ruled with rows and columns. Legalization snaps each card to the ruling without letting any two overlap. Where a region holds more cards than it has room for, some must move to a neighboring region. The distance a card moves is its displacement. The art is to keep displacement small, especially for the cards that matter most.

5.2  Physical meaning: what makes a position legal

The rule set depends on your technology and settings. More checks exist than the table lists, for example implant spacing and via spacing. Some are switched on by modes. Whether a check runs is a property of your session, so read the modes you recorded.

5.3  Overlap removal as arithmetic

Cells leave an overfull window by sliding along the row first, then by moving to another row. The capacity of a row segment is the number of sites in it. Let us work an example with invented numbers; Figure 10 then shows three typical violations and their repairs.

1. Take the 50 µm strip between the core edge (x = 40) and the halo of the buffer macros (x = 90).
2. On core_site (0.2 µm wide), one row of that strip has 50 / 0.2 = 250 sites.
3. Suppose global placement left cells with a total width of 270 sites over a 10-row span. The strip holds 10 × 250 = 2 500 sites, so 270 is nothing unusual.
4. Now suppose the same 270 sites sat in a single row. Twenty sites, or 4 µm of cell width, must leave that row.
5. The nearest free sites are in the rows above and below. That is a vertical move of one row, 1.4 µm, plus any horizontal shift needed.

A row-level view: illegal and legal

A window of 19 sites in two rows, before and after legalization

What to notice: Each violation is repaired by a different move. P snaps by half a site, Q slides one site, T slides three sites left out of the halo, and R flips without moving. Legal says nothing about the timing of the moved cells.

Thus, a local overload costs a displacement of about one row height per displaced cell. It costs more if the neighboring rows are full too.

5.4  Tool operation: refinePlace

refinePlace is a supporting legalization operation. Run checkPlace first, and run refinePlace only if the check reports violations. If the placement is already legal, skip it. It fixes overlap, orientation, constraint and blockage violations. It moves only instances whose status is placed, and it does nothing if the design is already legal. It runs automatically at the end of place_opt_design, ccopt_design and optDesign.

• Prerequisite. A placed design, saved so that you can return to it. refinePlace does not place unplaced instances; ecoPlace does.
• Window. -⁠area {llx lly urx ury} limits the work to a window. The braces are required; without them the command is an error.
• Instance list. -⁠inst with a list of instances legalizes only those instances and treats the others as fixed.
• Other modes. -⁠eco, -⁠pre_route_eco and -⁠wire_length_reclaim select other behaviors. setPlaceMode -⁠place_detail_eco_max_distance limits the window of ECO (engineering change order) moves. With -⁠eco and a value of 0, the tool sets it internally to 10 standard-cell heights.
• Database change. Yes, if anything is illegal. If everything is legal, it changes nothing.

innovus> refinePlace ;# legalize every placed instance

innovus> refinePlace -area {40 40 140 140} ;# legalize only inside this window

• Expected result. If the design was already legal after place_design, the command reports that nothing needed to move. Otherwise it prints a move report with the mean and maximum displacement. The report layout depends on the installation, so the excerpt below is a neutral teaching table.
• Reports. The log. Follow it with the full checkPlace below.
• Misinterpretations. A quiet refinePlace shows that nothing was left to repair, not that the placement is good. A small mean displacement can hide a large maximum, which is why you read both.

instances moved by legalization : 31 482 of 196 211
mean displacement               : 0.4 um
maximum displacement            : 38.6 um   (instance u_dp/u_acc_reg[17])

How do we read it? The mean of 0.4 µm is two sites, so the bulk of the design was nearly legal. The 38.6 µm maximum is a different statement: one cell was pushed a long way. Look at that cell and its nets before you accept the placement. A maximum of 38 µm is not a defect by itself. The number says nothing about whether that cell is on a critical path. It tells you where to look.

5.5  The check: checkPlace

innovus> file mkdir reports/legal_run1 ;# a directory for the legality reports
innovus> checkPlace reports/legal_run1/checkplace.rpt ;# check and write the report

innovus> checkPlace -clearMarker ;# remove old violation markers only

• Options that change scope. -⁠noHalo uses the place-and-route (PR) boundary instead of halos. -⁠noHardFence, -⁠noPreplaced, -⁠ignoreOutOfCore, -⁠ignoreFillerInUtil, -⁠inst with an instance list, and -⁠selectedOnly each narrow or widen what the check sees. A result obtained with one of them is not comparable with one without it, so record the options with the result.
• Scope extension. setPlaceMode -⁠place_check_report_fixed_inst_on_blockage true makes it report fixed instances that sit on blockages. Without it, a fixed macro placed over a blockage does not appear.
• What it reads out. Violation counts by type, the count of placed cells, the unplaced macros and the placement density. That density includes padding, so it can differ from the timeDesign density.
• What it does not show. Timing, congestion, a full routing check or a power-grid signoff check. It includes some pin-access and power-pin checks: more than overlaps, but still less than routability.

5.6  Padding and spacing, as the legalizer sees them

innovus> specifyCellPad BUFX4 -left 1 -right 1 ;# one free site each side of every BUFX4

innovus> setPlaceMode -place_detail_honor_inst_pad true ;# honor instance pads
innovus> specifyInstPad u_dp/u_acc_reg* 2 ;# two sites of padding on matching instances

• Cell padding is kept through optimization and CTS, and deleteAllCellPad removes it.
• Instance padding is honored by refinePlace and checkPlace when the mode above is true.
• Both reduce the capacity of rows, so more padding means more displacement elsewhere.
• Section Controlled refinement treats padding as an experiment, not as a default.

5.7  Local refinement

After legalization, detailed placement may swap cells and shift them locally to shorten wires. The baseline setting setPlaceMode -⁠place_detail_wire_length_opt_effort medium controls it; none and high are the other values. It can give up to 2 percent wirelength gain, and high effort may add up to 10 percent run time. These moves keep the placement legal. They do not look at the congestion map, so a gain in wirelength is not a gain in routability.

5.8  Timing and congestion effects of legalization

5.9  Causes of excessive displacement

The causes that push cells far are listed in Table 17. After the table, Figure 11 turns them into a procedure: classify, repair, then check again.

From a legalization problem to a rerun

Classify the cause before choosing the repair

What to notice: Every path restores the baseline first and ends in a rerun of the checks. The red dashed arrow returns to inspection.

5.10  Failure and repair

5.11  Rerun requirements

If legalization or its checks changed anything, regenerate the density map, the congestion estimate, the timing summary and the status counts. A legalization run with -⁠area or -⁠inst changes only that part. So run the full checkPlace afterwards, not only on the window.

The summary gives a mean and a maximum. To list the largest moves yourself, snapshot the lower-left corners before and after the step and compare them. This is a user script, not a tool command, and it has not been run. Confirm the attribute names .box_llx and .box_lly with .? in your installation. The file name is an example.

# Snapshot: instance name and lower-left x y, one line per placed instance.
proc snap_ll {fname} {
    set l [dbGet -p top.insts.pStatus placed]
    if {$l eq "0x0"} { puts "snap_ll: no placed instances"; return 0 }
    set fh [open $fname w]
    foreach i $l {
        puts $fh "[dbGet $i.name] [dbGet $i.box_llx] [dbGet $i.box_lly]"
    }
    close $fh
    return [llength $l]
}

innovus> source scripts/snap_ll.tcl ;# define the procedure
innovus> snap_ll reports/legal_run1/ll_before.txt ;# corners before the step
innovus> refinePlace ;# the step being measured
innovus> snap_ll reports/legal_run1/ll_after.txt ;# corners after the step

The directory reports/legal_run1 was created with the legality check above. Sort the differences outside the tool, for example in a short script of your own, and read the largest few. Equal counts in the two files are a precondition for the comparison.

5.12  Save the inspected legal placement

innovus> file mkdir checkpoints/place_run1 ;# exists already if created before; harmless
innovus> saveDesign checkpoints/place_run1/legal.enc ;# the inspected legal placement

6  Timing-aware placement and pre-CTS optimization

Placement is where timing starts to depend on geometry. Before placement, a net has no real length. The analysis uses whatever wire assumption the earlier stage chose. After it, a net that stretches across 600 µm may cost more than the gate it connects. The pre-CTS timing report is the first number that reflects your layout. It is also the first one that can mislead you. The clock is still ideal and the routing is still an estimate.

6.1  The quantities a setup report uses

s     = t_req - t_arr
t_req = T + t_cap - t_setup - t_unc
t_arr = t_launch + SUM over i of (d_cell,i + d_wire,i)

Here T is the clock period in ns. t_launch and t_cap are the clock arrival times at the launching and capturing registers. t_setup is the setup time of the capturing register, and t_unc is the uncertainty margin from the constraints. d_cell,i and d_wire,i are the delays of the i-th cell and net on the path. Positive slack means the check is met; negative slack is a violation.

• WNS. The worst negative slack is the smallest slack over all checks. Whether a report prints a WNS that is zero or positive, or leaves the line out, is a report convention. Read the report's own header before comparing.
• TNS. The total negative slack is the sum of the negative slacks over the endpoints, so a TNS closer to zero is better. The overall TNS counts each endpoint once, with its worst slack. In a multi-view run it takes the worst slack per endpoint across views. Thus, it need not equal the sum of the path-group TNS values.
• Critical path. A path with the smallest slack, or with slack near the worst. Optimization works on the worst paths first.

6.2  Placement-dependent interconnect delay

d_net ~= R_d * (c * L + C_L)  +  r * L * (c * L / 2 + C_L)

Note the two terms. The first grows linearly with L and mostly loads the driver. The second grows with L squared and is the wire's own delay. Thus, doubling a long wire more than doubles its cost.

The same logic stretched along one wire turns a 13.72 ps net into a 203 ps net. That is the whole mechanism by which placement affects timing.

Thus, a pre-CTS net delay is an estimate of an estimate: a global-route guess on top of a placement. It tracks the placement well enough to rank paths. It does not match the later numbers. Figure 12 puts the delays of one path side by side.

A register-to-register path and its delay contributors

Four cells, four nets, one long net, ideal clock

What to notice: Three of the four nets cost 13.72 ps each. The 600 µm net costs 203 ps and turns the path negative: arrival 604.16 ps against a required 540 ps. The clock is ideal, so there is no clock-tree skew.

Now let the placement bring the long net to 250 µm, which costs 70.0 ps. The arrival falls to 360 + 41.16 + 70.0 = 471.16 ps. The slack becomes +68.84 ps, or +68.8 ps. The path is the same and the netlist is the same. Only the distance changed.

6.3  Ideal and propagated clocks

In an ideal clock, the clock arrives at every register at the same time, apart from any latency the constraints declare. Before CTS no clock tree exists, so the analysis has no choice. Clocks are ideal for timeDesign -⁠prePlace and -⁠preCTS. place_design forces ideal clocks whatever -⁠clockPropagation says. A propagated clock uses the actual tree delays, so launch and capture arrivals differ by skew.

What this means for a pre-CTS slack:

• It carries no clock-tree skew. When CTS builds a tree, skew will make some slacks better and some worse. A pre-CTS slack of +0.05 ns does not promise a positive post-CTS slack.
• It assumes the clock network costs nothing, apart from declared latencies and uncertainty. Constraints should hold a realistic uncertainty, so that pre-CTS numbers are not optimistic. This is a project decision, not a tool default.
• Useful skew is a separate, optional flow. The baseline keeps -⁠opt_skew and -⁠opt_skew_pre_cts false, so the statements above hold as written.
• If you enable useful skew, both options must be true, and the master option can disable the stage option. The result is network latencies on clock pins. They become insertion delays when the clock tree specification is created, and the pre-CTS slack then includes them. Decide this with the CTS owner, because it changes the clock inputs that CTS inherits.

6.4  Pre-CTS is not post-CTS closure

Treat the pre-CTS timing target as a gate for starting CTS, not as evidence that timing will close. The stage has no clock tree and no real routing. Its useful job is to remove the paths that placement and sizing can fix, and to find the ones they cannot. A path that is badly negative after pre-CTS optimization is a signal. Look at the floorplan, the constraints or the logic, since CTS will not repair it.

6.5  Timing optimization before CTS

-⁠opt_max_density and the setup target limit growth. A positive target asks for margin and grows the netlist, and every added cell needs a free site. Useful skew is the optional coordinated flow described above. Incremental optimization (-⁠incr) works on the paths still violated after a full run, with resizing and global buffering.

innovus> restoreDesign checkpoints/place_run1/legal.enc.dat stream_acc ;# Phase 1 result
innovus> source scripts/baseline_policy.tcl ;# apply the baseline policy
innovus> file mkdir reports/opt_run1/opt ;# optimization reports go here
innovus> file mkdir reports/opt_run1/timing ;# the later timing run goes here
innovus> file mkdir checkpoints/opt_run1 ;# the optimized checkpoint goes here

innovus> optDesign -preCTS -outDir reports/opt_run1/opt -prefix opt_run1 ;# optimize
innovus> saveDesign checkpoints/opt_run1/opt.enc ;# save the optimized candidate
innovus> getPlaceMode -nonDefault > reports/opt_run1/place_modes.txt ;# record modes
innovus> getOptMode -nonDefault > reports/opt_run1/opt_modes.txt ;# record opt modes

innovus> restoreDesign checkpoints/place_run1/legal.enc.dat stream_acc ;# Phase 1 result
innovus> source scripts/baseline_policy.tcl ;# apply the baseline policy
innovus> file mkdir reports/opt_drv ;# its own report directory
innovus> optDesign -preCTS -drv -outDir reports/opt_drv -prefix opt_drv ;# DRV only

Incremental setup optimization is different. The tool requires a previous optDesign run on all path groups before -⁠incr. So it starts from the saved candidate of the full run above, checkpoints/opt_run1/opt.enc. It works with resizing and global buffering, without restructuring or DRV repair. It cannot be combined with -⁠drv. Give it its own checkpoint.

innovus> restoreDesign checkpoints/opt_run1/opt.enc.dat stream_acc ;# full-run result
innovus> source scripts/baseline_policy.tcl ;# apply the baseline policy
innovus> file mkdir reports/opt_incr ;# its own report directory
innovus> file mkdir checkpoints/opt_incr ;# its own checkpoint directory
innovus> optDesign -preCTS -incr -outDir reports/opt_incr -prefix opt_incr ;# incr
innovus> saveDesign checkpoints/opt_incr/opt.enc ;# save the incremental candidate

6.6  Reading the result

innovus> timeDesign -preCTS -outDir reports/opt_run1/timing \
    -prefix opt_run1_final ;# setup timing summary

innovus> timeDesign -preCTS -hold -reportOnly -outDir reports/opt_run1/timing \
    -prefix opt_run1_hold ;# provisional hold report, ideal clocks

The files are split by path group: reg2reg, in2reg, reg2out, in2out and reg2cgate. There are also files for max transition, max capacitance, max fanout, density and a summary. The summary table shows WNS, TNS and violating paths per group, a design-rule table, density, and routing overflow in each direction. The excerpt below is a neutral teaching table with invented numbers.

stage: preCTS, clocks ideal, view: setup_view_1
group      WNS(ns)   TNS(ns)   violating/total
all        -0.064    -3.82     118 / 41 902
reg2reg    -0.064    -3.11      96 / 30 540
in2reg     -0.021    -0.71      22 / 8 100
DRV        max_tran 0 viol   max_cap 0 viol   max_fanout 4 viol
density    61.0 %    routing overflow H 0.4 %   V 0.1 %

innovus> report_timing -max_paths 3 > reports/opt_run1/timing/worst3.rpt ;# worst paths
innovus> report_constraint -all_violators > reports/opt_run1/timing/violators.rpt ;# all
innovus> check_timing -verbose > reports/opt_run1/timing/check_timing.rpt ;# constraints

from u_dp/u_acc_reg[17] to u_dp/u_out_reg[3]   clock clk (ideal)
pin / net            cell      fanout  slew   incr     arrival
u_acc_reg[17]/Q      DFFX2     1       40     120      120.00
net 40 um            net       1       45     13.72    133.72
u_mul/U12/Y          NAND2X1   4       80     70       203.72
net 40 um            net       4       50     13.72    217.44
u_mul/U31/Y          XOR2X1    2       60     110      327.44
n_xor31 (600 um)     net       2       95     203      530.44
u_dp/U77/Y           AOI21X1   1       50     60       590.44
net 40 um            net       1       45     13.72    604.16
u_out_reg[3]/D                                         604.16
required time 540.00    slack -64.16 (VIOLATED)

6.7  Placement and optimization, together and apart

Placement and optimization change the same objects. A buffer added by optimization needs a free site, which only legal whitespace provides. A cell moved by optimization alters the density map. Hence the loop of section Controlled refinement: change something, rerun, regenerate every report. The two placements below show what the loop is for.

Two placements of the same path

Let us place the path of Figure 12 twice: spread below the macros, and pulled into the channel between u_buf_b and u_coef. The drawing is in Figure 13 and the comparison in Table 19.

Two placements of the same path

Spread cells with a long net, or pulled-in cells in the channel

What to notice: B gains 133 ps by shortening one net from 600 to 250 µm, but 24 wires must then cross an edge with 19 tracks. Both the gain and the cost are real.

Neither placement is the answer. Thus, a timing gain from placement is not free, and its cost appears in a report you must read. The remedy might be a partial blockage, a smaller pull, a swap of macro orientation or a buffer. Section Controlled refinement teaches how to try one and compare.

6.8  Clean timing can mislead

Two commands read coverage, and neither changes the design. check_timing looks for missing constraints. Its default-on warnings include missing input delay, unconstrained endpoints, loops and clock issues. report_analysis_coverage counts checks that are met, violated and untested, with the reason for each untested check. The directory below exists from the optimization step.

innovus> check_timing -verbose \
    > reports/opt_run1/timing/check_timing_coverage.rpt ;# missing constraints
innovus> report_analysis_coverage -verbose {violated untested} -sort reason \
    > reports/opt_run1/timing/coverage.rpt ;# how many checks ran, and why not

6.9  Rerun requirements

After placement, optimization or any legalization, rerun the timing summary, the coverage check and the density and congestion reports. A timing report that predates the last optimization is stale. If you changed setOptMode, the constraints or the cell-use list, say so alongside the numbers.

6.10  Integrated alternative: place_opt_design

place_opt_design combines placement and pre-CTS optimization in one command. It is another way to organize the flow. This chapter uses the separated flow. It lets you inspect the placement before optimization changes the design. The two routes are drawn side by side in Figure 14, after the list.

• What it combines. Pre-place optimization, standard-cell placement, I/O pin assignment if pins are not preplaced, and pre-CTS optimization.
• Options. They include -⁠incremental, -⁠incremental_timing, -⁠num_paths, -⁠out_dir and -⁠prefix.
• Its result still needs the checks and acceptance evidence of section Checks and acceptance.
• Do not run it afterwards merely because it has also been introduced. It is not an additional step in the main flow.
• Use a separate run identity and the flow assumptions that go with it. In the early clock flow it builds clustering and useful skew. The clock tree specification must then not be deleted between steps.
• The two routes are not guaranteed to produce identical databases or quality of results.

Main teaching flow and integrated alternative

Two routes to a validated pre-CTS candidate

What to notice: The main flow has an inspection and save between placement and optimization. The alternative has none. Both candidates need the same acceptance checks.

7  Congestion and routability

A placement can be legal and meet timing and still be impossible to route. Routing needs tracks, and tracks are a limited supply. When many wires want to pass the same place, some do not fit. Congestion is how that shortage shows up before any wire exists. It is cheaper to read it now than to find it in a failed route.

Phase 2 continues here. This section reads the physical consequences of the optimized candidate. The commands here report; they do not perform the optimization.

7.1  Demand, capacity and overflow

The edge is over capacity by 5 wires. At least 5 wires must take a longer route or a different layer, and they may be unable to.

Subtract an obstruction only from the layer it occupies. Subtract it also from layers it blocks by a stated mechanism, such as a via or a pin-access keep-out. A stripe on one layer does not by itself remove tracks from the next layer.

The estimate comes from an early global route. earlyGlobalRoute is a quick global route for congestion and parasitic estimation, and it is not clean against the design-rule check (DRC). Its log lines carry the tag [NR-eGR]. reportCongestion needs it to have run. timeDesign -⁠preCTS runs it as part of the timing flow. So a timing run at this stage produces the congestion data as a side effect.

Capacity of one GCell edge

Two layers, 25 tracks each, minus what preroutes take

What to notice: Each loss is subtracted only from the layer it sits on. Capacity is 19 + 23 = 42; demand is 47, so the ledger shows an overflow of 5.

7.2  Directional and layer effects

Each layer has a preferred direction, and overflow is counted separately for horizontal and vertical edges. In the example, the stripes from Power Planning run vertically on M6. A stripe pair of two 2 µm wires with a 2 µm gap occupies a 6 µm band every 120 µm. So it covers 6 / 120 = 5 percent of the horizontal span of the vertical layer.

That is a geometric estimate of how much of the span the stripes cover. It is not a track count. It leaves out spacing to neighboring wires and the vias that connect the stripes down. The same reasoning applies to the ring layers and to the rails on M1, each on its own layer.

7.3  Density maps and congestion maps are different

A density map shows how full the placement is: cell area per window. A congestion map shows how short the routing supply is: overflow per window edge. They overlap in practice, but each can be high without the other. Both maps of the upper half of the example are in Figure 16, and Table 20 compares them.

A density map and a congestion map of the same region

Same 50 µm bins, two different questions; schematic, not to scale

What to notice: The densest block, in the upper left, is not the most congested. The overflow sits in the narrow channel between u_buf_b and u_coef, where density is moderate.

7.4  Reading the density map

reportDensityMap shows where cells are concentrated. It needs a placed design and does not modify the database. The defaults give a map in the viewer and a text report. A finer grid and a higher threshold show only the worst windows; the values below are examples.

innovus> reportDensityMap ;# default 50 um grid, 0.75 threshold
innovus> reportDensityMap -gridInMicron 20 -threshold 0.90 ;# worst bins only

innovus> setDensityMapMode -threshold 0.90 ;# store a threshold for later calls
innovus> getDensityMapMode ;# read the stored settings back

• Defaults. A 50 µm grid; bins under a 0.75 threshold are not reported. -⁠gridInMicron has a maximum of 1000. -⁠gridInRow is the alternative, in row heights. Give one of the two, and confirm in your installation which wins if both are given.
• Other options. -⁠ignoreBlock skips block instances in supply and demand. -⁠ignoreFiller shows standard-cell density in post-filler maps. setDensityMapMode -⁠reset restores the defaults.
• Expected result. A colored map and a text report. The report lists the bins above the threshold per power domain, the bin size and a histogram of density ranges.
• Threshold range. The threshold accepts values up to 2.0. That is an input range; it does not show that a bin can exceed 100 percent density. Whether a value above 1.0 appears depends on what the report counts, such as padding or blockage area.
• Grid. A coarse grid averages a small hotspot away. Quote the grid and the threshold with every number.

innovus> queryDensityInBox 530 800.2 580 960.2 ;# cell density in one box
innovus> queryPinDensity -area 530 800.2 580 960.2 ;# pins per area in the same box

queryDensityInBox prints several areas for the box: standard cells over free space, macros, power metal and placement obstructions. It also prints the utilization in that box. It honors placement blockages. queryPinDensity snaps the area to its grid in the output.

7.5  Reading the congestion estimate

innovus> earlyGlobalRoute ;# quick global route for the estimate
innovus> reportCongestion -overflow ;# overflow by direction and edge distribution
innovus> reportCongestion -hotSpot -num_hotspot 5 ;# the five largest hotspots
innovus> reportCongestion -hotSpot -3d ;# per-layer breakdown, a separate call

• Options. -⁠overflow prints horizontal and vertical overflow and a table of edge distribution. -⁠hotSpot prints the top hotspots, and -⁠num_hotspot sets how many. -⁠includeBlockage counts blockage area. -⁠3d gives the per-layer table.
• Hotspot score. The maximum hotspot is the largest contiguous area of overflowing cells; the total is the sum. A maximum score below 100 typically means routable. That is a rule of thumb of the tool's own scoring, not a guarantee. Use the number to compare runs of the same design in the same tool.
• Misinterpretations. An early global route is an estimate. The overflow you read is not the final short count. A clean estimate does not promise a clean route, and a hotspot may disappear or move during real routing.

congRepair is a local experiment, not a free repair, and not part of the main flow. It is incremental placement driven by the early-global-route congestion. It spreads cells at hotspots, and it moves many cells. Run it after place_design or after pre-CTS optimization, never after post-CTS optimization.

innovus> file mkdir checkpoints/cong_run1 ;# directories first
innovus> file mkdir reports/cong_run1/timing ;# its own timing folder
innovus> restoreDesign checkpoints/opt_run1/opt.enc.dat stream_acc ;# optimized DB
innovus> source scripts/baseline_policy.tcl ;# apply the baseline policy
innovus> congRepair -area 530 800.2 580 960.2 ;# spread cells at the channel hotspot

Unlike refinePlace -⁠area, congRepair -⁠area takes the four numbers unbraced; confirm with -⁠help.

innovus> saveDesign checkpoints/cong_run1/cong.enc ;# save the experiment
innovus> checkPlace reports/cong_run1/checkplace.rpt ;# positions changed, so recheck
innovus> timeDesign -preCTS -outDir reports/cong_run1/timing -prefix cong_run1 ;# timing
innovus> check_timing -verbose > reports/cong_run1/check_timing.rpt ;# coverage
innovus> earlyGlobalRoute ;# fresh estimate on the new positions
innovus> reportCongestion -overflow > reports/cong_run1/congestion_overflow.rpt ;# H, V
innovus> reportCongestion -hotSpot -num_hotspot 5 \
    > reports/cong_run1/congestion_hotspot.rpt ;# the worst hotspots
innovus> reportDensityMap > reports/cong_run1/density_map.txt ;# density after the move

The -⁠area window is optional; the default is the whole design. checkPlace follows because the move changes positions. The timing summary and the coverage check rerun in the same block, because the move changes timing. Compare against the baseline as section Controlled refinement describes. If you keep this result, it becomes the selected candidate, with its own run name.

7.6  Local density, macro pins and narrow channels

PG routing restrictions. The supply metal from Power Planning reduces capacity on its own layers, as described above. Over a macro, the stripes also cover layers that the macro's own pins may need. Over a PG-heavy area, a hotspot is often a capacity problem first. Figure 17 draws the channel of placement B. A dashed outline in a cell marks an M5 obstruction (OBS), a shape the router may not cross. The list after the figure counts the supply and demand there, taking each loss once.

A macro channel close-up

Placement B's channel, conceptual and exaggerated, not to scale

What to notice: 50 µm of the 70 µm gap is open to cells. Losses take 8 of 27 M5 tracks, so a supply of 19 meets a demand of 24: overflow 5.

• Supply on M5, the crossing layer, is 27 raw tracks.
• Cell obstructions. Each of the three cells carries an M5 OBS over two tracks, which removes six.
• Stripes. The via-landing and spacing footprint of the two stripes removes two more, one per stripe. So 19 tracks remain.
• Demand is 14 crossing nets plus 10 local connections to pins outside the obstructions, so 24. It holds only wires not already blocked by those shapes.
• Overflow = demand − supply = 24 − 19 = 5.

7.7  Placement adjustment or floorplan revisit?

A congestion problem can have a placement cause, which a placement change can fix. It can also have a floorplan cause, which it cannot. Making the wrong call costs a day. Table 21 reads the usual cases. Figure 18 turns the call into four questions.

Placement adjustment or floorplan revisit?

Four questions about a hotspot that survives the experiments

What to notice: Each question asks for evidence. A floorplan or grid leaf means restoring that stage's checkpoint.

7.8  Rerun requirements

Any change to placement, blockages, padding or the power grid invalidates the density map and the congestion estimate. Rerun earlyGlobalRoute before reportCongestion. Regenerate the timing summary too, because it depends on the same positions. A congestion report from before the last optimization describes cells that are no longer where it says.

8  Controlled refinement

When a result is not good enough, the temptation is to change four settings at once and run again. If the result improves, you do not know which change helped. If it worsens, you do not know which hurt. Controlled refinement is a discipline for keeping that knowledge: one change, from the same starting point, judged on the same measures.

8.1  The loop

Printing the modes after the restore is not enough, because a readback is not configuration. Avoid setPlaceMode -⁠reset as a shortcut. It restores the defaults, which may differ from the baseline you recorded. Figure 19 draws the loop.

The refinement loop

Six steps, three exits, one baseline

What to notice: Every pass returns to the same baseline, never to the previous experiment. The comparison uses several measures. One exit leaves the loop when the cause is upstream.

8.2  The levers, and what each costs

Each lever below is a complete command in the recipes that follow. Table 22 names the trade and the undo. None is a repair by itself; each trades one resource for another. Naming the trade before the run is what makes the result readable.

8.3  Recipes: one change each

innovus> restoreDesign checkpoints/grid_run1/grid.enc.dat stream_acc ;# power-planned DB
innovus> source scripts/baseline_policy.tcl ;# apply the baseline policy

The seven global placement settings are the single-line experiments of Table 14. Each is applied after those two lines. It is followed by place_design, the legality inspection and optDesign -⁠preCTS. The recipes below cover the levers that need more than one line. Cell names, instance names, counts and boxes are example values.

innovus> specifyCellPad BUFX4 -left 1 -right 1 ;# the change
innovus> deleteAllCellPad ;# rollback, run separately when you undo it

innovus> specifyInstPad u_dp/u_acc_reg* 2 ;# the change
innovus> reportInstPad -all ;# list every instance pad
innovus> deleteInstPad {u_dp/u_acc_reg[17]} ;# rollback for one instance, run separately

innovus> createPlaceBlockage -name pb_channel -type partial -density 50 \
    -box {530 800.2 580 960.2} ;# at most 50 percent density in the channel
innovus> deletePlaceBlockage pb_channel ;# rollback, run separately when you undo it

Local spreading. congRepair -⁠area is a local experiment that starts from the saved optimized candidate. Its follow-up checks are in section Reading the congestion estimate. It is a move after timing work, so it is judged by the same comparison as every other recipe.

After any recipe, run the placement and then the evidence block below, and save to a new run directory.

8.4  A single controlled change, as a run

The sequence below is for one experiment. It is a template: replace the run name and the one change. All evidence goes to a run directory named for the experiment, and nothing is written over the baseline.

The one change of each experiment lives in its own small script. That way the same policy can be applied again at acceptance. The script holds mode settings only. A blockage or a padding record travels in the saved checkpoint, so the script does not repeat it. The module and factor (1.0 or more) are example values.

innovus> set fh [open scripts/exp1_modpad_override.tcl w] ;# open the override file
innovus> puts $fh {setPlaceMode -place_global_module_padding {u_dp 1.2}} ;# the change
innovus> close $fh ;# close the file

innovus> file mkdir reports/exp1_modpad ;# 0. directories for this run
innovus> file mkdir reports/exp1_modpad/opt ;# optimization reports
innovus> file mkdir reports/exp1_modpad/final ;# final timing reports
innovus> file mkdir checkpoints/exp1_modpad ;# checkpoints of this run
innovus> restoreDesign checkpoints/grid_run1/grid.enc.dat stream_acc ;# 1. restore
innovus> source scripts/baseline_policy.tcl ;# apply the baseline
innovus> source scripts/exp1_modpad_override.tcl ;# 2. the one change under test
innovus> place_design ;# 3. Phase 1: place
innovus> checkPlace reports/exp1_modpad/checkplace_place.rpt ;# legality for review
# GATE: stop here and read the report. Continue only when legality is accepted.

# Only if the report listed violations: refinePlace, then check again.
# refinePlace
# checkPlace reports/exp1_modpad/checkplace_after_refine.rpt
innovus> saveDesign checkpoints/exp1_modpad/legal.enc ;# the inspected legal placement
innovus> optDesign -preCTS -outDir reports/exp1_modpad/opt \
    -prefix exp1_modpad_opt ;# Phase 2: optimize
innovus> saveDesign checkpoints/exp1_modpad/opt.enc ;# the optimized candidate

innovus> getPlaceMode -nonDefault > reports/exp1_modpad/place_modes.txt ;# modes
innovus> getOptMode -nonDefault > reports/exp1_modpad/opt_modes.txt ;# opt modes
innovus> checkPlace reports/exp1_modpad/checkplace.rpt ;# legality of the final state
innovus> timeDesign -preCTS -outDir reports/exp1_modpad/final \
    -prefix exp1_modpad_final ;# final timing, own folder and prefix
innovus> earlyGlobalRoute ;# fresh congestion estimate
innovus> reportCongestion -overflow \
    > reports/exp1_modpad/congestion_overflow.rpt ;# overflow, H and V
innovus> reportCongestion -hotSpot -num_hotspot 5 \
    > reports/exp1_modpad/congestion_hotspot.rpt ;# the worst hotspots
innovus> reportDensityMap > reports/exp1_modpad/density_map.txt ;# density map

• Option used. -⁠place_global_module_padding {u_dp 1.2} takes a braced module and factor. A factor below 1.0 is ignored, the module name is prefix-matched, and the option acts only in global placement.
• Reports. The same set as for the baseline, under a new directory name. If reportDensityMap does not print to the console in your installation, confirm where it writes before relying on the redirect.
• Scope. This template is a full-placement experiment that starts from the power-planned database. A local experiment starts from a saved placed or optimized candidate instead. Its results are not comparable with a full-placement run unless the baseline is rerun the same way.
• Misinterpretation. A better congestion score with a worse WNS is neither a win nor a loss. It is a trade, judged against the acceptance rule.
• Rerun. Restore the baseline before the next experiment. Do not stack experiments unless you decide to combine two that each helped. Then name the run as a combination.

A run manifest ties the files to one state. A timestamp alone is not evidence. So the manifest names the source checkpoint, the exact policy and the identities of the inputs. Write it as a small script and source it. The script name and the input file names are examples to adapt; copy the tool build from your session banner.

# Run manifest of one experiment. Input names and the build are examples.
set mf [open reports/exp1_modpad/manifest.txt w]
puts $mf "run: exp1_modpad"
puts $mf "baseline checkpoint: checkpoints/grid_run1/grid.enc.dat"
puts $mf "policy: scripts/baseline_policy.tcl"
puts $mf "override: scripts/exp1_modpad_override.tcl"
puts $mf "one change: setPlaceMode -place_global_module_padding {u_dp 1.2}"
puts $mf "legal checkpoint: checkpoints/exp1_modpad/legal.enc"
puts $mf "optimized candidate: checkpoints/exp1_modpad/opt.enc"
puts $mf "inputs: constraints/stream_acc.sdc, view setup_view_1, libs, RC extraction files"
puts $mf "tool build and UI: copied from the session banner, Legacy UI"
puts $mf "checks: checkPlace default scope; timeDesign -preCTS"
puts $mf "estimate: earlyGlobalRoute"
close $mf

innovus> source scripts/manifest_exp1.tcl ;# write reports/exp1_modpad/manifest.txt

Here RC means the resistance-capacitance extraction files. Where the project allows, add a checksum of each file named, for example with md5sum in a shell. The checksum identifies the content; a date does not.

8.5  What to compare

There is no universal threshold. A hotspot score of 100 is a rule of thumb of the tool's own scoring, as noted earlier. What counts as acceptable is a project decision, written before the run.

8.6  An experiment log

Let the acceptance rule be "hotspot score below 100, WNS no worse than the baseline, no legality violations". Then only R3 passes. Thus, the best result here is not the one with the shortest wirelength. It is the one that meets the rule on every measure. It would be wrong to conclude that a partial blockage always works. It worked here because the hotspot was in a channel.

8.7  Select the candidate once

The log picks a run. The choice has to travel, or acceptance will check a different state from the one that won. Record the selected candidate once, in a small script that acceptance and handoff both read. For the worked example, run R3 is chosen. If no experiment is chosen, the record names the optimized run checkpoints/opt_run1/opt.enc.dat and no override.

innovus> set fh [open reports/selected_candidate.tcl w] ;# the one record of the choice
innovus> puts $fh {set cand_run exp3_partial_blockage} ;# the run name
innovus> puts $fh {set cand_dat checkpoints/exp3_partial_blockage/opt.enc.dat} ;# its DB
innovus> set ovr scripts/exp3_partial_blockage_override.tcl ;# the run's override script
innovus> puts $fh "set cand_override $ovr" ;# record it
innovus> close $fh ;# close the record

Section An acceptance pass in order sources this file, and the handoff manifest saves the same identity. A blockage created by the change is already inside the saved checkpoint. So the override script of that run is empty or holds only mode settings.

8.8  When to revisit a macro or the core

Going back means restoring the floorplanning or the power-planning database. You change the floorplan or the grid there, and repeat the stages that depend on it. That is slower than adjusting a setting. It is also the only fix for a cause that sits upstream.

9  Checks and acceptance

After a run, one question is easy to ask and wrong to answer. It is whether the placement is good. That question hides four different questions, each with its own evidence. Answering them separately lets you say afterwards which one failed and what to do about it.

9.1  Four questions, kept apart

"Plausibly" in the second question is deliberate. An estimate can show that a placement is unlikely to route. It cannot show that it will. The phrase "for this stage and scope" in the third is also deliberate. A pre-CTS number is not a closure number.

9.2  The checks

Figure 20 keeps the four verdicts in view.

The four-part acceptance dashboard

Invented values for illustration, not run R3 and not tool output

What to notice: A pass in Q1 does not lift the investigate in Q2. Q4 carries every blocker of Q1 to Q3, so it reads BLOCKING. NOT RUN sits in its own strip, neither a pass nor a zero.

Each row of Table 27 names a check and the question it informs. It also gives the evidence command and what the check leaves out.

9.3  An acceptance pass in order

The pass runs the checks in a fixed order and records each result. It is a template. Run it on a fresh restore of the selected candidate, so that it describes the file and not your session. The candidate is named once, in the file written in section Select the candidate once. With no experiment chosen, it is the optimized candidate opt_run1.

innovus> source reports/selected_candidate.tcl ;# sets cand_run, cand_dat, cand_override
innovus> restoreDesign $cand_dat stream_acc ;# restore the selected candidate
innovus> source scripts/baseline_policy.tcl ;# reapply the baseline policy
innovus> if {[file exists $cand_override]} { source $cand_override } ;# override
innovus> file mkdir reports/final ;# the acceptance evidence goes here
innovus> getPlaceMode -nonDefault > reports/final/place_modes.txt ;# record the policy
innovus> getOptMode -nonDefault > reports/final/opt_modes.txt ;# and the opt modes

Whether restoreDesign resets modes is not established here. So the policy is applied again and then read back. The readback is evidence, not configuration. Compare it with the files written for the selected run, in a Linux shell. The example uses exp3_partial_blockage, the selected run of section Select the candidate once; with no experiment chosen, use reports/opt_run1. A difference is either an approved change or a defect, and you record it either way.

$ diff reports/exp3_partial_blockage/place_modes.txt \
    reports/final/place_modes.txt # placement modes
$ diff reports/exp3_partial_blockage/opt_modes.txt \
    reports/final/opt_modes.txt # optimization modes

Question 1, legality from the database. The script below compares counts and fixed objects with the baseline record. Confirm the attribute names .cell.baseClass, .orient and .box with .? in your installation. A read that fails counts as a failure and never as a match. The expected values are copied from the power-planning handoff record. The file name is an example.

# Q1, database part. Read only. Every failed read counts as a failure.
set nfail 0
proc fail {msg} { global nfail; incr nfail; puts "FAIL: $msg" }
# Counts: macros and other instances are kept apart from the all-instance count.
set n_all [dbGet top.numInsts]
set l_mac [dbGet -p top.insts.cell.baseClass block]
if {$l_mac eq "0x0"} { set n_mac 0 } else { set n_mac [llength $l_mac] }
puts "instances: all=$n_all macros=$n_mac other=[expr {$n_all - $n_mac}]"
set l_unp [dbGet -p top.insts.pStatus unplaced]
if {$l_unp ne "0x0"} { fail "[llength $l_unp] instances are unplaced" }
# Fixed objects: expected boxes and orientations from the baseline record.
array set exp_box {
    u_buf_a {100 90.4 520 390.4}
    u_buf_b {100 689.6 520 989.6}
    u_coef  {590 800.2 830 960.2}
}
array set exp_orient {u_buf_a R0 u_buf_b R0 u_coef MY}

# Fixed objects: status, orientation and box against the baseline record.
foreach n [lsort [array names exp_box]] {
    set i [lindex [dbGet -p top.insts.name $n] 0]
    if {$i eq "" || $i eq "0x0"} { fail "$n not found"; continue }
    set st [dbGet $i.pStatus]
    set or [dbGet $i.orient]
    set b [lindex [dbGet $i.box] 0]
    if {$st ne "fixed"} { fail "$n status $st" }
    if {$or ne $exp_orient($n)} { fail "$n orientation $or" }
    if {[llength $b] != 4} { fail "$n box unreadable: $b"; continue }
    foreach v $b e $exp_box($n) {
        if {abs($v - $e) > 0.005} { fail "$n box $b differs from $exp_box($n)"; break }
    }
}
puts "Q1 database checks: failures=$nfail"
set q1_db [expr {$nfail == 0 ? "PASS" : "BLOCKING"}]
puts "Q1 database part: $q1_db"

innovus> source scripts/accept_q1.tcl ;# prints FAIL lines and sets q1_db

Question 1, tool checks. checkPlace includes pin-access and power-pin checks. The connectivity check is limited to the supply nets. It also verifies all PG port connections, including the soft connections on masterslice layers. -⁠error is a stop: the check ends when that many errors are reported, and the default is 1000. The net names are examples.

innovus> checkPlace reports/final/checkplace.rpt ;# geometry, pin access, power pins
innovus> checkDesign -place -noHtml -outfile reports/final/checkdesign_place.rpt ;# DB
innovus> verifyConnectivity -type special -net {VDD VSS} -allPGPinPort -error 1000 \
    -report reports/final/pg_connectivity.rpt ;# supply nets and PG port connections

innovus> earlyGlobalRoute ;# fresh estimate on the restored candidate
innovus> reportCongestion -overflow > reports/final/congestion_overflow.rpt ;# H and V
innovus> reportCongestion -hotSpot -num_hotspot 5 \
    > reports/final/congestion_hotspot.rpt ;# the worst hotspots
innovus> reportDensityMap > reports/final/density_map.txt ;# density per window
innovus> timeDesign -preCTS -outDir reports/final -prefix final ;# Q3 timing summary
innovus> check_timing -verbose > reports/final/check_timing.rpt ;# missing constraints
innovus> report_analysis_coverage -verbose {violated untested} -sort reason \
    > reports/final/coverage.rpt ;# how much was analyzed

Before any verdict, record what each tool check covered. A check that stopped at its error cap is incomplete, not clean. Compare the number of errors in pg_connectivity.rpt with the cap. If they are equal, run again with a larger -⁠error. A power-pin connection check, geometric special-net connectivity and a power-grid signoff are three different claims. This block supports only the first two, and only for the nets named.

Verdicts. The script judges only the database part of question 1, and keeps it under its own name, q1_db. The overall verdict of question 1 starts as NOTRUN. It becomes PASS only when you have also read the checkPlace, checkDesign and connectivity reports, with their scope and completion state. Questions 2 and 3 start as NOTRUN as well. Question 4 is computed, so it cannot be better than the worst of the first three. It cannot be read before the others are typed. You edit this file after reading the reports; its name is an example.

# Verdict record. Values: PASS, INVESTIGATE, BLOCKING or NOTRUN.
set q(1) NOTRUN
# Edit q(1) after reading all three tool reports. The database part cannot lift it:
if {$q1_db eq "BLOCKING"} { set q(1) BLOCKING }
set q(2) NOTRUN
set q(3) NOTRUN
# Q4 aggregates: BLOCKING or NOTRUN upstream gives BLOCKING.
set q(4) PASS
foreach k {1 2 3} {
    if {$q($k) eq "BLOCKING" || $q($k) eq "NOTRUN"} { set q(4) BLOCKING }
    if {$q($k) eq "INVESTIGATE" && $q(4) eq "PASS"} { set q(4) INVESTIGATE }
}
foreach k {1 2 3 4} { puts "Q$k: $q($k)" }
# Stop gate: handoff only when Q4 is not BLOCKING.
if {$q(4) eq "BLOCKING"} { puts "STOP: do not hand off" }

innovus> source scripts/verdicts.tcl ;# prints Q1 to Q4 and the stop line

• Prerequisites. A saved state to restore, and the baseline record made at the start of the chapter.
• Database change. checkPlace adds markers, and earlyGlobalRoute and timeDesign add session data. No cell moves.
• Two parts of Q1. q1_db covers the database comparison only. The overall Q1 also needs the tool reports, and it stays NOTRUN until a person has read them.
• Fail closed. A missing instance, unreadable box, wrong status or wrong orientation is a failure. The box tolerance, 0.005 µm, is a project decision.
• Q4. The handoff package adds its own items, so a computed PASS here is necessary but not sufficient.
• Misinterpretation. A FAIL does not stop later checks, and the STOP line only prints. The gate is the person who reads the whole output, verdict lines included.

9.4  Pass, investigate, blocking

A check ends in one of three states, and each is defined by what you do next (Table 28).

NOT RUN is neither zero nor pass, and it propagates. A check that was not executed has no value. Write NOT RUN, and treat it as blocking for the claim it would have supported. The exception is a handoff that says in writing that the claim is not made. Question 4 inherits it.

9.5  Waivers and temporary conditions

A waiver allows a stated violation to remain. It is valid only with a scope, an owner, a reason and an approval. A temporary condition is allowed only with the named step that will close it. Neither turns a check into a clean result. Each lets a scoped handoff go ahead and travels with it. A check that reached a cap, or ran in a narrower scope than intended, has incomplete coverage. That is a different state from a check that was not run.

10  Debugging cases

Placement failures rarely announce their cause. They show a symptom, such as a count, a map or a slack. The cause sits somewhere between the symptom and an earlier stage. Each case below follows the same path. It lists what you see, the evidence, the possible causes and the check that separates them. Then come the repair and the reruns. The last row of each case also says whether the cause might lie upstream.

10.1  How to use a case

Read the symptom, then collect the evidence before you form a view. List the possible causes. Pick the discriminating check: the one expected to give a different answer under different causes. Only then change something.

The standard evidence set has six parts. They are the status counts, checkPlace, the density map, the congestion report, the timing summary and coverage. A rerun in the cases below means that set, regenerated, plus any step named.

10.2  Case 1: cells remain unplaced

innovus> array unset cnt ;# clear any old counts
innovus> set u [dbGet -p top.insts.pStatus unplaced] ;# all unplaced instances
innovus> if {$u eq "0x0"} { ;# 0x0 means none
    puts "no unplaced instances"
} else {
    puts "unplaced instances: [llength $u]"
    foreach c [dbGet $u.cell.name] {
        if {[info exists cnt($c)]} { incr cnt($c) } else { set cnt($c) 1 }
    }
    foreach c [lsort [array names cnt]] { puts "  $c: $cnt($c)" }
}

10.3  Case 2: cells move unexpectedly

10.4  Case 3: legalization fails or displaces cells far

10.5  Case 4: congestion persists beside a macro

10.6  Case 5: a narrow channel is overloaded

10.7  Case 6: timing worsens after a change that looked helpful

10.8  Case 7: timing is suspiciously clean

10.9  Case 8: stale reports after a repair

$ ls -l --time-style=full-iso checkpoints/opt_run1/opt.enc.dat reports/final/ # times

10.10  When the cause is an upstream assumption

Several cases ended with "upstream". The rule is simple. Suppose a repair would have to change something that an earlier stage fixed and accepted. Then restore that stage's checkpoint, change it there, and repeat what depends on it. Do not patch the symptom here. Table 37 maps the evidence to the stage.

11  Where mixed placement fits, and why it is not the main flow here

This chapter placed standard cells around macros that were already placed, fixed and surrounded by a power grid. The mixed placer places macros and standard cells together. It answers a different question. It can also undo decisions that the floorplanning and power-planning stages spent their effort on. We describe it so that you can tell when you have left the main flow, and what that costs.

11.1  What it is, and why it is a fork

The example has three macros whose area is 29 percent of the core. The count is small. Their positions were chosen and accepted during floorplanning, with halos, orientations and a channel plan. The power grid was built around them, and the checks of both stages assume them. Thus the main flow keeps the macros fixed.

Mixed placement starts from a different question: where should the macros go? Using it replaces that earlier answer. Figure 21, after the safeguards below, shows where the branch leaves the main flow.

11.2  Safeguards

If you take the alternative flow, these rules apply.

1. Do not replace the accepted checkpoint. Copy it under a new name and work on the copy. The original is the evidence for what the floorplanning and power-planning stages accepted.
2. Do not assume the power grid stays valid. Stripes, rings, macro connections and halos depended on macro positions. Once a macro moves, the grid is no longer the checked grid. Assume it must be rebuilt and rechecked until the checks say otherwise.
3. Expect to revisit more than placement. Macro movement can require revisiting the floorplan decisions, the power plan, the supply connectivity and every check that depended on them.
4. Do not make destructive cleanup routine. One step of the flow, update_floorplan_for_macro_place -⁠remove all, removes blockages, placed instances, wires and more. It is a deliberate reset of a floorplan, not a tidy-up. Run it only on a copy, after you have read what it removes.
5. Verify every command in your installation before you turn it into executable Tcl. The names below are the steps of the flow. The options of the helper commands have not been checked for this chapter. That is why the sequence is a list and not code.
6. Label the result. A design placed this way is the product of a different flow, and its handoff says so.

Where the mixed placer forks from the main flow

The branch works on a copy and re-enters at readiness

What to notice: The branch never changes the original and re-enters at the readiness gate. It is long because everything the macros touched must be re-established.

Alternative flow (separate from the main flow of this chapter):
 0. copy the accepted checkpoint to a new name; work on the copy
 1. create_pg_model_for_macro_place    (prepare a PG model)
 2. update_floorplan_for_macro_place   (-remove all is destructive)
 3. set_macro_place_constraint         (constraints for the macro placer)
 4. addHaloToBlock                     (enlarge halos if needed)
 5. place_design -concurrent_macros    (needs the GigaPlace-GXL license)
 6. saveDesign, then inspect the macro result
 7. refine_macro_place                 (not run by default)
 8. saveDesign
 9. physical cell insertion and power routing again
10. place_design, optDesign -preCTS, then re-enter the checks

12  Query and debug reference

When a run goes wrong you need the next query, not a chapter. The two tables in this section are meant to be kept open beside the terminal. The first lists the questions you ask of a placed design and the commands that answer each. The second lists symptoms with the evidence, the likely cause, the repair and the evidence to regenerate.

Both follow the conventions of the rest of the chapter. Commands are Innovus Tcl unless a row says Linux shell. A report that exists is not a pass: read its header, its scope and its run name. A check that did not run is written NOT RUN.

12.1  Query reference: ask the placed design

innovus> set rd reports/final ;# the report directory used below
innovus> file mkdir $rd ;# create it if needed
innovus> set i [lindex [dbGet -p top.insts.name u_coef] 0] ;# one macro to inspect

12.2  Debug reference: diagnose by symptom

innovus> createPlaceBlockage -name pb_edge -type partial -density 50 \
    -box {530 800.2 580 960.2} ;# L1: keep cells back from the macro edge
innovus> setPlaceMode -place_global_auto_blockage_in_channel partial ;# L2: channel mode
innovus> setOptMode -opt_honor_fences true ;# L3: optimization honors fences

13  Checkpoint, restoration and CTS handoff

A placement that exists only in your session is not a deliverable. The next stage needs to restart from exactly this state. The reviewer needs to know what was checked. A handoff is the checkpoint, the evidence and the list of what is still open. If any of the three is missing, the next person redoes the work or trusts what they should not.

13.1  What to save

Save more than the database. The database is the state. The rest says how the state came about and what was said about it (Table 43).

innovus> set run checkpoints/handoff_run1 ;# the handoff checkpoint directory
innovus> if {[file exists $run]} { error "already exists: $run" } ;# never overwrite
innovus> file mkdir $run ;# create it
innovus> file mkdir reports/handoff_run1 ;# and its report directory

innovus> saveDesign $run/accepted.enc ;# the database checkpoint
innovus> saveNetlist $run/accepted.v ;# the placed netlist
innovus> defOut $run/accepted.def ;# the placement in DEF form

# Handoff manifest. Run it in the session that sourced scripts/verdicts.tcl,
# so that q(1) to q(4) exist, and after $run is set.
source reports/selected_candidate.tcl
set mf [open reports/handoff_run1/manifest.txt w]
puts $mf "run: handoff_run1"
puts $mf "selected candidate run: $cand_run"
puts $mf "selected candidate checkpoint: $cand_dat"
puts $mf "policy: scripts/baseline_policy.tcl"
puts $mf "override: $cand_override (if present)"
puts $mf "handoff checkpoint: $run/accepted.enc"
puts $mf "evidence directory: reports/final"
puts $mf "verdicts: Q1 $q(1) Q2 $q(2) Q3 $q(3) Q4 $q(4)"
puts $mf "inputs: constraints/stream_acc.sdc, view setup_view_1, libs, RC extraction files"
puts $mf "tool build and UI: copied from the session banner, Legacy UI"
puts $mf "timing: timeDesign -preCTS, forced ideal clocks"
close $mf

innovus> source scripts/manifest_handoff.tcl ;# write reports/handoff_run1/manifest.txt

• Needs. The acceptance pass complete, scripts/verdicts.tcl sourced in the same session, and a saved state that you have inspected.
• Changes. Files on disk. The database is not changed.
• Section options. defOut has section options. Add the ones your project needs.
• Timing graph. saveDesign may also take a timing-graph option. Confirm in your installation what it saves before you use it.
• Misinterpretation. A file on disk shows that a save ran. It does not show that the save restores.

13.2  Restore and verify

Restoration is verified with two sessions and two dump calls. Session 1 is the one that saved the design. Session 2 is fresh and restores the saved checkpoint. A comparison that cannot fail proves nothing, so the dump procedure fails closed. An unreadable name, status, orientation or box stops the script with an error. So does a count that disagrees with top.numInsts. Save the procedure once as scripts/dump_place.tcl. Confirm the attribute names and the two value lists in your installation.

proc dump_place {file src} {
    # Remove any old result first, then write to a part file and rename
    # only on success.
    file delete -force $file
    file delete -force $file.part
    set insts [dbGet top.insts]
    if {$insts eq "0x0"} { error "no instances read" }
    set expect [dbGet top.numInsts]
    # Value lists to confirm in your installation.
    set okst {fixed placed softFixed unplaced cover}
    set okor {R0 R90 R180 R270 MX MY MX90 MY90}
    array unset seen
    set n 0
    set fh [open $file.part w]
    puts $fh "# source: $src"
    foreach i $insts {
        set nm [dbGet $i.name]
        set st [dbGet $i.pStatus]
        set or [dbGet $i.orient]
        set bx [lindex [dbGet $i.box] 0]
        if {$nm eq "" || $nm eq "0x0"} { close $fh; error "unreadable name" }
        if {[info exists seen($nm)]} { close $fh; error "duplicate name $nm" }
        set seen($nm) 1
        if {[lsearch -exact $okst $st] < 0} {
            close $fh; error "bad status $st at $nm"
        }
        if {[lsearch -exact $okor $or] < 0} {
            close $fh; error "bad orientation $or at $nm"
        }
        if {[llength $bx] != 4} { close $fh; error "unreadable box of $nm" }
        foreach v $bx {
            if {![string is double -strict $v]} {
                close $fh; error "non-numeric box value at $nm"
            }
        }
        puts $fh "$nm $st $or $bx"
        incr n
    }
    if {$n != $expect} { close $fh; error "read $n of $expect instances" }
    puts $fh "#END $n"
    close $fh
    file rename -force $file.part $file
    puts "wrote $n instances to $file"
}

innovus> source scripts/dump_place.tcl ;# define the procedure
innovus> dump_place reports/handoff_run1/place_before.dump $run/accepted.enc ;# dump
innovus> saveNetlist reports/handoff_run1/before.v ;# netlist identity
innovus> set fh [open reports/handoff_run1/views_before.txt w] ;# view list file
innovus> puts $fh [all_analysis_views -type all] ;# write all views
innovus> close $fh ;# close the view list
innovus> getPlaceMode -nonDefault > reports/handoff_run1/place_modes_before.txt ;# modes
innovus> getOptMode -nonDefault > reports/handoff_run1/opt_modes_before.txt ;# opt modes

innovus> restoreDesign checkpoints/handoff_run1/accepted.enc.dat stream_acc ;# restore
innovus> source scripts/dump_place.tcl ;# define the procedure
innovus> dump_place reports/handoff_run1/place_after.dump \
    checkpoints/handoff_run1/accepted.enc ;# dump the restored state
innovus> saveNetlist reports/handoff_run1/after.v ;# netlist identity
innovus> set fh [open reports/handoff_run1/views_after.txt w] ;# view list file
innovus> puts $fh [all_analysis_views -type all] ;# write all views
innovus> close $fh ;# close the view list
innovus> getPlaceMode -nonDefault > reports/handoff_run1/place_modes_after.txt ;# modes
innovus> getOptMode -nonDefault > reports/handoff_run1/opt_modes_after.txt ;# opt modes

The two sessions also write the netlist, the view list and the effective modes. Equality is then not claimed from the placement dump alone. Compare the identity files first, in a Linux shell. Each diff is read on its own, and none of them changes the placement verdict.

$ d=reports/handoff_run1 # the handoff report directory
$ grep -v '^//' $d/before.v > $d/before.nc.v # netlist without comment header lines
$ grep -v '^//' $d/after.v > $d/after.nc.v # the same for the restored netlist
$ diff $d/before.nc.v $d/after.nc.v > $d/netlist.diff ; echo "netlist: $?" # netlists
$ diff $d/views_before.txt $d/views_after.txt > $d/views.diff # view lists
$ echo "views: $?" # 0 means equal
$ diff $d/place_modes_before.txt $d/place_modes_after.txt \
    > $d/place_modes.diff ; echo "place modes: $?" # placement modes
$ diff $d/opt_modes_before.txt $d/opt_modes_after.txt \
    > $d/opt_modes.diff ; echo "opt modes: $?" # optimization modes

The placement comparison also runs in a Linux shell. It requires the completion marker in both dumps and checks that both sorts succeeded. It keeps the exit code of diff and prints one of three outcomes. Because it uses exit, save it as a script and run it with bash; the name compare_place.sh is an example.

d=reports/handoff_run1
for f in $d/place_before.dump $d/place_after.dump; do
  if [ "$(tail -n 1 $f | cut -c1-4)" != "#END" ]; then
    echo "COMPARISON FAILED: $f has no completion marker" ; exit 2
  fi
done
sort $d/place_before.dump > $d/before.sorted ; rc_b=$?
sort $d/place_after.dump > $d/after.sorted ; rc_a=$?
if [ $rc_b -ne 0 ] || [ $rc_a -ne 0 ]; then
  echo "COMPARISON FAILED: a sort failed" ; exit 2
fi
if [ ! -s $d/before.sorted ] || [ ! -s $d/after.sorted ]; then
  echo "COMPARISON FAILED: a dump is empty" ; exit 2
fi
diff $d/before.sorted $d/after.sorted > $d/place.diff ; rc=$?
if   [ $rc -eq 0 ]; then echo "MATCH"
elif [ $rc -eq 1 ]; then echo "MISMATCH: read $d/place.diff"
else                     echo "COMPARISON FAILED: diff exit status $rc"
fi
exit $rc

$ bash compare_place.sh # prints MATCH, MISMATCH or COMPARISON FAILED

What the comparison does and does not prove:

• What equality proves. The dump covers instance identity, status, orientation and exact position for the same save and restore. Exact equality is a valid same-save test when the serialization is stable. It is not a tolerance check of intended geometry. It does not promise equal timing across tool builds, parallelism or analysis settings.
• Independent identity checks. Compare the two netlists, ignoring comment header lines that may carry a date. Compare the two view lists and the two mode files. The modes belong to the selected candidate: compare them with the baseline plus that run's override, not with the baseline alone. An accepted experiment can differ from the baseline on purpose.
• Then rerun the standard evidence set on the restored state. The timing summary should match the one before the save. A difference needs an explanation before the handoff stands.
• Why a fresh session. A session that has been editing holds state that was never saved.

13.3  The handoff package

Figure 22 gathers the package that CTS receives.

The handoff package for CTS

What travels with the checkpoint, and the questions CTS will ask

What to notice: Every item answers a question CTS will ask: where the cells are, which clocks and constraints apply, what was assumed about the clock, and what is still unsettled.

The clock assumptions deserve a line each, because CTS inherits them.

• Ideal clocks. In the baseline flow, every pre-CTS slack assumed ideal clocks, plus any declared latencies. If useful skew or the early clock flow was used, say so. Name the exact analysis command and clock mode of each report. Even with an early tree, timeDesign -⁠preCTS analyzes with forced ideal clocks.
• Useful skew. The baseline had it off. If you enabled it, both -⁠opt_skew and -⁠opt_skew_pre_cts were true. The result is network latencies on clock pins that CTS turns into insertion delays. Say which applies.
• Early clock flow. Was place_opt_design used in the early clock flow? Then the clock specification must travel with the package. It must not have been deleted between steps, because deleting it loses the useful skew.
• Hold. Any pre-CTS hold number is provisional, because the clocks are ideal. Hold becomes much more representative after CTS. State whether it was reported at all.
• Clock-gate and scan placement. State whether clock-gate-aware placement had a clock specification to use, and whether scan was reordered.

13.4  What placement established, what is provisional, and what CTS will change

Established. Every standard cell has a legal location, and the acceptance evidence says so in a stated scope. Macros and physical cells are where they were fixed. An estimate checked the design for plausible routability. Timing was checked at the pre-CTS stage with ideal clocks and estimated routes, with coverage recorded. The state is saved and restores, and it carries its settings, reports and experiment log.

Provisional. The congestion estimate is not a route. The pre-CTS slacks assume ideal clocks and estimated wires. The hold numbers, if any, are provisional.

What CTS will change. It will build the clock network, which adds buffers and inverters and changes clock-gate positions and fanout. It makes the clock propagated, so skew appears in every slack. Cell padding is kept through optimization and CTS, so padding decisions made here stay in force. The timing picture will change in both directions, and hold becomes much more representative.

14  Common mistakes and how to catch them

Most placement mistakes are mistakes of reading, not of running. Table 44 collects the ones this chapter warned about.

15  Interview preparation

16  Chapter close

Compact glossary

Placement and pre-CTS on one page

Figure 23 condenses the chapter into the order you will use it on a real block.

Placement and pre-CTS on one page

The worked flow, its checks and its key commands

What to notice: Each step names its key commands and one piece of evidence. The four questions sit at the end, and Q4 can never read better than Q1 to Q3.

Where the next chapter goes, and why

The handoff package holds a legal, checked placement and a clear statement of its clock assumptions. Clock Tree Synthesis, Post-CTS Optimization, Checks and Handoff restores that checkpoint and builds the clock network. It adds buffers and inverters, moves clock gates and makes the clock propagated. Every slack then carries real skew, and hold becomes much more representative.

That is why this chapter insisted on recorded clock assumptions, unexplained hotspots closed or owned, and a proven restore. CTS inserts its cells into the whitespace and the routing supply that placement left. The next chapter shows how to build the tree, re-optimize with real clocks and check the result before routing.