CHAPTER 5

Power-planning qualification

Power planning builds the supply network that every later stage depends on and that every later stage must route around. A grid that is connected can still be too thin, too dense, or short-circuited, and the cost shows up as lost routing tracks. This chapter qualifies the connection of supply pins, the physical-only cells, the rings, stripes and followpins, and the vias between them.

5.1 Stage purpose

The chapter assumes a flat block with one power net and one ground net, called VDD and VSS here. Your net names will differ. Power planning has two halves. The logical half tells the database which instance pins belong to which supply net, with globalNetConnect. The physical half draws the metal: a ring around the core, stripes across it, and followpins, which are the supply rails that run along the standard-cell rows. A via is a cut that joins metal on two adjacent layers, and the metal around the cut is its enclosure. Figure 7 shows these objects on one small core.

Figure 7. Power grid plan view with its cost ledger

Read it. The ring is M5 on top and bottom and M6 on the sides. M6 stripes run vertically in VDD and VSS pairs, an M5 stripe pair runs horizontally, and M1 followpins run along the rows, so the directions alternate. A small square with a dark dot is a via. The macro takes its supply on M5 pins under a stripe. Marker 1 is a stripe crossing of the same net with no via. Marker 2 is a macro VSS pin with no V5 via to the stripe above it. The ledger counts the tracks inside the core box: the M6 stripe sets take 14 of 48 tracks and the M5 stripe set takes 7 of 36, all values illustrative. Each set blocks its four stripe tracks, the one-track gap and one spacing track on each side, which is 7 tracks per set. The grid is drawn for the ledger and is not a healthy grid, because the M6 sets leave the right-hand columns without a stripe.

Metal that is drawn is metal that routing cannot use. Each stripe takes tracks on its layer, and each via stack takes landing pads on the layers below it. Thus, a power grid is qualified on two questions at once: is everything connected, and what routing resource is left?

5.2 Entry prerequisites

Must already be true	Why
Chapter 4 passed, with the special-net snapshot stored	It is the baseline that the connectivity check in this chapter is compared with.
The floorplan is final, macros are fixed and halos are set	A macro move after power planning invalidates stripes, followpins and macro hookups.
A power specification lists nets, layers, widths, spacing and set-to-set distances	The cards check the grid against it. This book sets none of those numbers.
The technology data defines the metal stack, the cut layers and the PG pin names of every cell and macro	Connection rules and via generation read them.
The routing track budget for PG exists	The ledger needs a project budget to be judged against.

5.3 Relevant files and analysis context

The checks read the design database and the technology data, and no timing view is involved. Three kinds of stored setting steer the result, so each card asks you to record them with the report: the global net connection rules, the ring and stripe mode settings read with getAddRingMode and getAddStripeMode, and the special-route mode read with getSrouteMode. Two runs of the same command with different stored modes can build different metal, so the mode listing is part of the evidence.

The power commands are usually kept in a script of their own. The reference notes that a single-instance connection rule is stored in the PG file and not in the floorplan file, which matters if the floorplan is saved and reloaded on its own. Keep that script under version control and note its revision with the reports.

5.4 Checks and command cards

5.4.1 Pre-stage checks

Before any metal is drawn, three things are cheap to confirm. The special-net snapshot from Chapter 4 exists. The metal stack, with direction and pitch per layer, is recorded. And the connection rules are in place, because a ring that cannot see its pins is drawn into nothing. P-01 covers the connection rules, and P-08 holds the metal-stack and track commands, which you run both now and after the grid is built.

P-01PG and tie-pin connection

Question it answers	Is every supply pin on the right net through an explicit rule, and does any terminal float or sit on the wrong net?
Stage	After global net connection
Product	Innovus Implementation. The reference entry names no separate licence requirement for this command.
Required state	Netlist loaded. The PG pin names of standard cells and macros are known.
Legacy UI	checkDesign -powerGround -noHtml -outfile <f> checkDesign -tieHiLo -noHtml -outfile <f> globalNetConnect <pg_net> -type pgpin -pin <pg_pin> -all -verbose globalNetConnect <pg_net> -type pgpin -pin <pg_pin> -singleInstance <inst> -override globalNetConnect <power_net> -type tiehi globalNetConnect <ground_net> -type tielo getTieHiLoMode -nonDefault

Common UI	Not yet verified No Common UI form is printed. The provided files do not document one.
Mapping	Not established in the provided documentation
Options used	`-powerGround` reports power terminals on ground nets, ground terminals on power nets, floating PG terminals and PG terminals on other nets. `-tieHiLo` reports unconnected tie-high and tie-low terminals, and tie pins and PG pins connected to different nets. `-type pgpin -pin -all` connects the named PG pin of every instance to the global net. `-singleInstance` applies a rule to one instance, for macro pins whose names differ from the net. `-type tiehi, -type tielo` connect tie-high and tie-low pins directly to the power or ground net.
Scope and view	Whole design, or one instance for a single-instance rule.
Why it comes first	The reference recommends the PG check before routing, extraction, and geometry and connectivity verification. addTieHiLo works on placed designs, so only the direct connection and the stored tie mode (getTieHiLoMode -nonDefault) are qualified here. Whether a direct tie connection is allowed is a project rule that this book does not state. Tap and end-cap PG pins are reached only if their pin names match a rule.
Effect on session	updates the design database; writes files. Some commands in this card only read or report.
Output	Connection statistics on the console, and a text report with one section per check.
Fields that matter	Pins connected per rule; floating, wrong-net and unconnected tie terminals.
Healthy	Every rule connects the count you expect, and the check reports no PG findings and no unconnected tie terminals.
Warning	A rule that connects zero pins, which usually means a misspelled pin name, or a tie terminal on a net that differs from its PG pin net.
Hard stop	Any terminal on the wrong supply net, or floating PG terminals on standard cells or macros.
Common misuse	Mixing direct tie connections with addTieHiLo. The reference states that addTieHiLo overrides the direct connection, so choose one on purpose.
Root cause and fix	Add the missing rule, using a single-instance rule where the macro pin name differs, then reapply the rules.
Rerun after a fix	Rerun P-01 and P-06.
Verification	Legacy syntax checked against the Innovus Legacy text reference.

5.4.2 Post-stage checks

P-02Physical-only cells

Question it answers	Are end caps and well taps present where the technology requires them, and does the verification tool agree?
Stage	After the floorplan, before rings
Product	Innovus Implementation. The reference entry names no separate licence requirement for this command.
Required state	Floorplan done. End-cap and well-tap modes and cells are set and recorded with getEndCapMode and get_well_tap_mode.
Legacy UI	addEndCap -prefix <prefix> addWellTap -cell <tap_cell> -cellInterval <um> -prefix <prefix> getEndCapMode get_well_tap_mode verifyEndCap -report <f> verifyWellTap -report <f> verifyWellTap -cell <tap_cell> -rule <um> -report <f>

Common UI	Not yet verified No Common UI form is printed. The provided files do not document one.
Mapping	Not established in the provided documentation
Options used	`-prefix` sets the instance name prefix so these cells can be recognised later. `-cell, -cellInterval` name the tap cell and the distance between taps. `-report` writes the verification report to a file. `verifyWellTap -cell, -rule` take the tap cell and the distance from the project rule, not from the add step.
Scope and view	All rows.
Order	The reference calls addEndCap after the floorplan and before addWellTap. Tap cells are added with preplaced status, so they are not moved by placement. check_design -type place also reports misaligned well-tap cells and missing termination cells. Whether stored connection rules reach cells added later is not verified, so repeat P-01 after adding them.
Effect on session	adds GUI violation markers; updates the design database; writes files. Some commands in this card only read or report.
Output	Physical cells in the database, and verification markers and a report.
Fields that matter	Missing and wrong-type end caps; well-tap coverage by the recorded rule.
Healthy	End caps at every row end and taps at the intervals the rule requires.
Warning	Rows that the well-tap check does not cover. The reference states it does not check row areas covered by blocks and their halos or by placement blockages.
Hard stop	Missing end caps or missing taps where the rule applies.
Common misuse	Reading a clean well-tap report as complete latch-up coverage. It honours the recorded cell and rule only, and a wrong rule passes cleanly.
Root cause and fix	Correct the cell or interval, remove with deleteFiller and the recorded prefix, and add the cells again.
Rerun after a fix	Rerun P-01, P-02 and the check_design placement check from Chapter 4.
Verification	Legacy syntax checked against the Innovus Legacy text reference.

P-03Rings and stripes

Question it answers	Do rings and stripes have the layers, width, spacing, offset and set-to-set distance of the power specification, and do they cover the core?
Stage	After connection rules
Product	Innovus Implementation. The reference entry names no separate licence requirement for this command.
Required state	P-01 clean. The ring and stripe mode settings are read back and recorded.
Legacy UI	getAddRingMode setAddRingMode -stacked_via_bottom_layer <layer> -stacked_via_top_layer <layer> addRing -nets {<pwr_net> <gnd_net>} -type core_rings -follow core \ -layer {top <h_layer> bottom <h_layer> left <v_layer> right <v_layer>} \ -width <w> -spacing <s> -offset <o> getAddStripeMode setAddStripeMode -stacked_via_bottom_layer <layer> -stacked_via_top_layer <layer> addStripe -nets {<pwr_net> <gnd_net>} -layer <layer> -direction vertical \ -width <w> -spacing <s> -set_to_set_distance <d> -start_offset <o>

Common UI	Not yet verified No Common UI form is printed. The provided files do not document one.
Mapping	Not established in the provided documentation
Options used	`-type core_rings -follow core` draw a ring that follows the core boundary. -layer takes one layer per side, horizontal for top and bottom, vertical for left and right. `-width, -spacing, -offset` give the wire width, the gap between the two ring wires, and the distance of a ring from the core edge. `-nets` names the nets. For stripes the number of names sets the number of stripes per set, and the first is the left or bottom stripe. `-layer, -direction` select one stripe layer and its direction. Each call draws one layer. `-set_to_set_distance, -start_offset` set the pitch of the stripe sets and where the first set starts. `-stacked_via_bottom_layer, -stacked_via_top_layer` limit the layers in which vias are stacked.
Scope and view	Core boundary and core area.
Effect on session	changes analysis configuration; updates the design database. Some commands in this card only read or report.
Output	Special wires on the ring and stripe layers, and vias where they cross other PG layers.
Fields that matter	Layers, widths, spacing, stripe count per set, pitch and start position, against the specification.
Healthy	Geometry equals the specification, the ring is closed with vias at its corners, and stripe sets cover the whole core.
Warning	Default stacked-via limits that cut through unwanted layers, or a set-to-set distance that leaves a wide strip of core with no stripe, often beside macros.
Hard stop	A ring side missing, a stripe pair with the nets reversed, a layer the specification does not allow, or a short between the two nets.
Common misuse	Drawing each layer in a separate session without recording the modes, so the stacked-via limits differ between layers.
Root cause and fix	Delete the offending wires, correct the layer list, net order, mode or distance, and draw again.
Rerun after a fix	Rerun P-04 to P-08.
Verification	Legacy syntax checked against the Innovus Legacy text reference.

P-04Followpins and macro pin connection

Question it answers	Does every row have followpins connected to the grid, and does every macro supply pin have a connection?
Stage	After stripes
Product	Innovus Implementation. The reference entry names no separate licence requirement for this command.
Required state	Stripes drawn. The special-route mode is recorded with getSrouteMode.
Legacy UI	getSrouteMode sroute -connect corePin -nets {<pwr_net> <gnd_net>} -corePinTarget firstAfterRowEnd \ -allowLayerChange 1 -layerChangeRange {<bottom_layer> <top_layer>} sroute -connect blockPin -nets {<pwr_net> <gnd_net>} -blockPin useLef \ -blockPinTarget nearestTarget -inst {<macro_inst>} check_design -type place -out_file <f>

Common UI	Not yet verified No Common UI form is printed. The provided files do not document one.
Mapping	Not established in the provided documentation
Options used	`-connect corePin` creates followpin wires from the standard-cell PG pins. `-corePinTarget` selects where the followpin ends. firstAfterRowEnd is the default. `-allowLayerChange, -layerChangeRange` allow the route to change layer, within the stated range. `-connect blockPin, -blockPin useLef` connect macro PG pins, using the pin shapes in the LEF. `-blockPinTarget, -inst` choose the target and limit the command to named macros.
Scope and view	Standard-cell rows and the named macros.
Why macro pins need a separate look	Macros often have several PG ports per pin, and their pins sit on a layer different from the rows. Card P-06 checks them with a port-level option. A successful sroute call does not prove row coverage, so read the placement check as well.
Effect on session	updates the design database; writes files. Some commands in this card only read or report.
Output	Followpin wires along the rows and macro pin routes, with vias to the stripes.
Fields that matter	Rows with followpins, where the placement check lists missing followpins in the rails; macro pins with and without connection.
Healthy	Every row and every macro PG pin has a connection to the grid, and the placement check lists no missing followpin or rail-alignment entry.
Warning	Connections that exist but land on a different layer from the plan.
Hard stop	A row with no followpin, or a macro PG pin with no connection.
Common misuse	Running sroute for core pins and macro pins in one call without checking each, so a failure on the macro side hides behind a good row count.
Root cause and fix	Correct the target or layer range and run again. Existing connections are kept unless -deleteExistingRoutes is given, so use it or editDelete the FOLLOWPIN, COREWIRE and BLOCKWIRE shapes first. A defOutBySection checkpoint before sroute allows an undo.
Rerun after a fix	Rerun P-05 to P-08.
Verification	Legacy syntax checked against the Innovus Legacy text reference.

P-05Power vias

Question it answers	Does every crossing of two same-net wires on adjacent layers have a via, and are the stacks complete?
Stage	After followpins
Product	Innovus Implementation. The reference entry names no separate licence requirement for this command.
Required state	Rings, stripes and followpins drawn.
Legacy UI	verifyPowerVia -net {<pwr_net> <gnd_net>} -report <f> verifyPowerVia -net {<pwr_net> <gnd_net>} -stackedVia -layerRange {<bottom_layer> <top_layer>} \ -report <f> editPowerVia -add_vias 1 -nets {<pwr_net> <gnd_net>} -bottom_layer <layer> -top_layer <layer> editPowerVia -add_vias 1 -nets {<pwr_net> <gnd_net>} -cell_pins {<macro_cell>:<pg_pin>} report_via -special reportPowerRoute -followpin_cut_ratio {<cutclass1> <w1> <cutclass2> <w2>} -net <net>

Common UI	Not yet verified No Common UI form is printed. The provided files do not document one.
Mapping	Not established in the provided documentation
Options used	`-net` names the nets to check. `-stackedVia` checks missing vias between all non-adjacent as well as adjacent layers. `-layerRange` checks the stack between the bottom and top layers and the adjacent vias between them, not the stacks between intermediate layers. The effect of using both options together is not stated. `-add_vias 1 -nets` adds vias between the layers named by -bottom_layer and -top_layer. `-cell_pins` names macro PG terminals on which vias are dropped. `-special` with report_via, summarises special vias by single-cut and multi-cut. `-followpin_cut_ratio` reports the ratio of two cut classes on followpins. It is meaningful only if the LEF defines both classes and via stapling was used.
Scope and view	The named PG nets.
Side effect	By default, editPowerVia generates no vias on standard-cell pins. verifyPowerVia only reports. editPowerVia changes the database, so store the marker report before and after it.
Effect on session	adds GUI violation markers; updates the design database; writes files. Some commands in this card only read or report.
Output	Markers and a report file. The default report file is named after the design with a powervia suffix.
Fields that matter	Missing vias by net and layer pair; single-cut and multi-cut counts.
Healthy	No missing vias, and the multi-cut share matches the plan.
Warning	A high single-cut share on a layer pair that the plan expected to be multi-cut.
Hard stop	A missing via at a crossing of same-net wires, or a stacked via that is incomplete.
Common misuse	Adding vias by hand to silence a marker without checking the nets. A via between VDD and VSS wires is a short.
Root cause and fix	Add the missing vias with editPowerVia, or correct the stripe layers so crossings are generated.
Rerun after a fix	Rerun P-05 to P-08.
Verification	Legacy syntax checked against the Innovus Legacy text reference.

P-06Special-net connectivity against the baseline

Question it answers	Are all PG nets connected, and what has changed since the baseline taken in Chapter 4?
Stage	After vias
Product	Innovus Implementation. The reference entry names no separate licence requirement for this command.
Required state	P-05 reviewed. The Chapter 4 snapshot is available.
Legacy UI	verifyConnectivity -net {<pwr_net> <gnd_net>} -type special -noAntenna -report <f> verifyConnectivity -net {<pwr_net> <gnd_net>} -type special -noAntenna -allPGPinPort \ -report <f>

Common UI	Not yet verified No Common UI form is printed. The provided files do not document one.
Mapping	Not established in the provided documentation
Options used	`-net` limits the check to the named PG nets. `-type special` checks special wires and vias only. `-noAntenna` ignores dangling wires, which are geometrical antennas and not process antenna violations. It keeps this run in the form of the baseline. `-allPGPinPort` verifies all PG ports, which matters for macros with several ports per pin. `-report` writes the report file.
Scope and view	The named PG nets.
Side effect	The reference states the command does not change the database unless the design is saved, in which case the markers are saved too. Connected is not the same as strong: a clean report says nothing about grid width. Connectivity markers are overwritten when the check runs again in a session, so the baseline is the stored report file. Run once without -noAntenna to see dangling stubs on the grid.
Effect on session	adds GUI violation markers; writes files
Output	Markers and a report.
Fields that matter	Opens and unconnected PG pins per net, compared with the baseline.
Healthy	Opens fall from the baseline to none, with the same command form in both runs.
Warning	Unconnected pins on cells that are intentionally not powered, which must be listed and explained.
Hard stop	Any open on a supply net, or any unconnected macro PG port.
Common misuse	Comparing runs made with different options. Without the same -net and -noAntenna, the counts are not comparable.
Root cause and fix	Fix the cause, which is nearly always a missing rule in P-01 or a missing connection in P-04.
Rerun after a fix	Rerun P-06 and P-07.
Verification	Legacy syntax checked against the Innovus Legacy text reference.

P-07PG shorts and grid design rules

Question it answers	Is any supply wire shorted to another net, and does the grid obey the design rules between special routes and other shapes?
Stage	After connectivity is clean
Product	Innovus Implementation. The reference entry names no separate licence requirement for this command.
Required state	P-06 clean.
Legacy UI	verify_drc -check_only special -limit 0 -report <f> verify_drc -check_only special -check_short_only -report <f> get_verify_drc_mode

Common UI	Not yet verified No Common UI form is printed. The provided files do not document one.
Mapping	Not established in the provided documentation
Options used	`-check_only special` checks special routes against other shapes, for example a power wire against a cell blockage. `-limit` sets the number of violations reported; the default is 1000. `-check_short_only` excludes every check except shorts. `-report` writes the violation report.
Scope and view	Special routes, and the instances that are placed.
Report limit	The default limit is 1000 violations, so use -limit 0 when counts are compared between runs, and record the settings with get_verify_drc_mode.
Effect on session	adds GUI violation markers; writes files. Some commands in this card only read or report.
Output	Violation markers and a report.
Fields that matter	Shorts, spacing and cut violations on special routes, by layer.
Healthy	No violations, and the report was produced by the same stored settings you record.
Warning	An empty report from a run that completed, which proves only that the checker ran.
Hard stop	Any short between VDD and VSS, or between a supply wire and a signal net.
Common misuse	Reading a clean special check as proof that stripes clear standard cells. Only placed instances are checked, so spacing to movable standard cells is not tested until they are placed. Preplaced end caps and taps are placed instances.
Root cause and fix	Move or delete the offending wire, then rebuild the affected stripes or vias.
Rerun after a fix	Rerun P-05 to P-07.
Verification	Legacy syntax checked against the Innovus Legacy text reference.

P-08Track budget and routing resource left

Question it answers	How much of each routing layer does the power grid use, and is what remains inside the project budget?
Stage	After the grid is final
Product	Innovus Implementation. The reference entry names no separate licence requirement for this command.
Required state	The grid is built and P-06 and P-07 are clean.
Legacy UI	report_metal_stack report_tracks -prefer_only report_route -track_utilization -layer <bottom_layer>:<top_layer>

Common UI	Not yet verified No Common UI form is printed. The provided files do not document one.
Mapping	Not established in the provided documentation
Options used	`report_metal_stack` lists direction, offset, pitch, spacing and width for each routing layer. `-prefer_only` limits report_tracks to the preferred direction of each layer. `-track_utilization -layer` reports the track shares by layer range, with PG mesh as its own column.
Scope and view	A layer range of the routing stack.
Regular wiring	Regular routes are excluded from this table unless -include_regular_routes is given. report_metal_stack supports only uniform track patterns with a single pitch and lists the preferred direction by default.
Effect on session	reads or reports only
Output	Tables on the console.
Fields that matter	PG mesh share, blockage share, available tracks per layer.
Healthy	The routing resource left on each layer meets the project budget.
Warning	One layer carrying far more PG than its neighbours, which pushes routing to other layers.
Hard stop	Free tracks on a layer below the project budget, because the router has nothing to work with.
Common misuse	Judging by PG share alone. Blockages and macros also take tracks, so look at the available tracks.
Root cause and fix	Increase the set-to-set distance or reduce the width in the power specification, justify it again against the IR and EM budget, then redraw and recheck.
Rerun after a fix	Rerun P-03 to P-08.
Verification	Legacy syntax checked against the Innovus Legacy text reference.

Only if the block uses UPF: reportPowerDomain -file <f> lists the power domains and verifyPowerDomain -gconn checks that the global connections agree with them. Neither applies to a flat single-supply block. Their rows in the status table below are marked not applicable.

5.5 Required reports, artefacts and how to read them

Report	Fields that support qualification	Evidence class
PG and tie check (P-01)	floating, wrong-net and unconnected tie terminals	implementation
Mode listings (P-03 and P-04)	ring, stripe and special-route settings used	implementation
Power via report (P-05)	missing vias per net and layer pair; single and multi-cut counts	implementation
Connectivity report (P-06)	opens and unconnected pins against the baseline	implementation
Special check report (P-07)	shorts and special-route rule violations	implementation
Track utilisation table (P-08)	PG share and available tracks per layer	preliminary

A track table is preliminary evidence, because routing blockages and congestion from placement are not in it yet. Figure 8 shows what a single crossing costs, and the ledger there is the source of the via counts in the plan figure.

Figure 8. A via stack from a followpin to a stripe, and the macro hookup

Read it. The top view shows an M6 stripe crossing an M1 followpin with nested landing pads on M2 to M5 and a 2 by 2 array of cuts. The cross-section shows the same stack from M1 to M6, with each pad wider than its cuts by an enclosure that differs per layer. The macro hookup shows an M5 pin joined to a same-net M6 stripe with two V5 cuts. The ledger gives 4 cuts per cut layer, 20 per followpin stack, and 200 cuts and 40 pads for the 10 stacks of the plan figure.

Reading a track utilisation tableSynthetic report, not tool output

report_route -track_utilization -layer M5:M6          ## illustrative excerpt, TrackLength column omitted
Layer #Tracks PG Mesh % Blkg & IO % BlockCell % StdCell % Nets % Avail Tracks %
M5       36     19.4 %     0.0 %       4.2 %      0.0 %    0.0 %     76.4 %
M6       48     29.2 %     0.0 %       0.0 %      0.0 %    0.0 %     70.8 %

The numbers are illustrative and are not taken from a run. Read the table from the right. The available share is the number the router sees, and it is lower on M6 than on M5 because the PG mesh takes 29.2 per cent there against 19.4 per cent. Those two shares match the ledger of the plan figure, so the table agrees with the drawing. The Nets column is zero because regular routes are excluded by default. If your project budget asks for more available tracks on M6 than this, the fix is in the power specification: a wider set-to-set distance or a narrower stripe.

5.6 Healthy, suspicious and hard-stop examples

Finding	Status	Why
PG and tie check clean, every rule connects its expected count	PASS	Metal is drawn on pins that are on the right nets.
Macro PG pin without a connection	HARD STOP	The macro has no supply and cannot work.
Special check clean but placement has not run	WARN / REVIEW	Spacing to movable standard cells is not tested until they are placed.
Single-cut vias where the plan expects multi-cut	WARN / REVIEW	Resistance and failure tolerance are weaker than planned.
Open on a supply net after vias	HARD STOP	Part of the block has no supply.
Available tracks below the project budget	HARD STOP	The router lacks resource and the cost appears as congestion.
Power-domain checks in a single-supply block	NOT APPLICABLE	No power domains exist.

5.7 Debugging, corrective action and reruns

Power faults are local, but their checks are not. A missing via is found by P-05, which finds it by net and layer pair, and the same fault can pass P-06 because other crossings keep the stripe connected. Thus, a clean connectivity report does not replace the via check, and the order matters: connect, draw, via check, connectivity, shorts, then track budget.

5.7.1 Worked example: a macro supply pin without a via

Two findings from one gridSynthetic report, not tool output

verifyPowerVia -net {VDD VSS} -report pv.rpt            ## illustrative excerpt
 net VDD  M5 to M6  checked 14  missing 0
 net VSS  M5 to M6  checked 14  missing 2  at (x1 y1) and (x2 y2)
verifyConnectivity -net {VDD VSS} -type special -noAntenna -allPGPinPort -report vc.rpt
 VSS  unconnected PG pin  RAM0/VSS   (macro pin)

This matches the markers in the plan figure. Marker 1 is a VSS stripe crossing with no via between M5 and M6. Connectivity does not report it, because the same VSS stripe has other crossings with the ring and with the other stripe, so the net still reaches every pin. The grid is weaker there and the via check is the only one that sees it.

Marker 2 is a different case. The VSS pin of the macro has no V5 via to the stripe above it, so connectivity reports the pin as unconnected, and the all-ports form is used because a macro pin can have several ports. The macro has no ground. The decision is HARD STOP on marker 2 and a fix-then-continue on marker 1. Add the vias with the macro-pin form of editPowerVia or rerun the macro hookup in P-04 with the correct target, then rerun P-05 to P-08. The counts in this example are illustrative: the VSS line counts 12 grid crossings and 2 macro pin crossings.

5.8 Exit criteria and stage checklist

Connections. PG and tie check clean, with the connection rules stored in the power script.
Physical cells. End caps and taps verified against the recorded rule, with their gaps explained.
Modes. Ring, stripe and special-route mode listings stored with the reports.
Geometry. Rings, stripes and followpins match the power specification.
Vias. Power via report has no missing vias, and the multi-cut share is within the plan.
Connectivity. Special-net report has no opens, compared with the Chapter 4 baseline using the same options.
Shorts. No shorts and no special-route violations, with the caveat about unplaced standard cells noted.
Budget. Available tracks per layer within the project budget.
Strength. IR and EM evidence for the grid is recorded under the project budget, or deferred in writing to the stage that owns it.

Thus, power planning is qualified when the grid is connected, free of shorts, and leaves the routing resource the design needs, with strength evidence recorded or deferred by name. A grid that is only connected passes quietly and costs the router later. In the next chapter, the gate before placement reads the database that this chapter completed.

CHAPTER 5 SANITY CHECKS

5.9 Sanity check cheat sheet: Power planning

One row per command card. Read left to right: the check, the command that answers it, then what a healthy result, a result to review and a hard stop look like. Judge every row against your project budgets, because this book sets no universal limits.

Card	Check and when	Command	Healthy	Review	Hard stop
P-01	PG and tie-pin connection After global net connection	`checkDesign -powerGround -noHtml -outfile <f>` `checkDesign -tieHiLo -noHtml -outfile <f>` `globalNetConnect <pg_net> -type pgpin -pin <pg_pin> -all -verbose`	Every rule connects the count you expect, and the check reports no PG findings and no unconnected tie terminals.	A rule that connects zero pins, which usually means a misspelled pin name, or a tie terminal on a net that differs from its PG pin net.	Any terminal on the wrong supply net, or floating PG terminals on standard cells or macros.
P-02	Physical-only cells After the floorplan, before rings	`addEndCap -prefix <prefix>` `addWellTap -cell <tap_cell> -cellInterval <um> -prefix <prefix>` `getEndCapMode`	End caps at every row end and taps at the intervals the rule requires.	Rows that the well-tap check does not cover. The reference states it does not check row areas covered by blocks and their halos or by placement blockages.	Missing end caps or missing taps where the rule applies.
P-03	Rings and stripes After connection rules	`getAddRingMode` `setAddRingMode -stacked_via_bottom_layer <layer> -stacked_via_top_layer <layer>` `addRing -nets {<pwr_net> <gnd_net>} -type core_rings -follow core \ -layer {top <h_layer> bottom <h_layer> left <v_layer> right <v_layer>} \ -width <w> -spacing <s> -offset <o>`	Geometry equals the specification, the ring is closed with vias at its corners, and stripe sets cover the whole core.	Default stacked-via limits that cut through unwanted layers, or a set-to-set distance that leaves a wide strip of core with no stripe, often beside macros.	A ring side missing, a stripe pair with the nets reversed, a layer the specification does not allow, or a short between the two nets.
P-04	Followpins and macro pin connection After stripes	`getSrouteMode` `sroute -connect corePin -nets {<pwr_net> <gnd_net>} -corePinTarget firstAfterRowEnd \ -allowLayerChange 1 -layerChangeRange {<bottom_layer> <top_layer>}` `sroute -connect blockPin -nets {<pwr_net> <gnd_net>} -blockPin useLef \ -blockPinTarget nearestTarget -inst {<macro_inst>}`	Every row and every macro PG pin has a connection to the grid, and the placement check lists no missing followpin or rail-alignment entry.	Connections that exist but land on a different layer from the plan.	A row with no followpin, or a macro PG pin with no connection.
P-05	Power vias After followpins	`verifyPowerVia -net {<pwr_net> <gnd_net>} -report <f>` `verifyPowerVia -net {<pwr_net> <gnd_net>} -stackedVia -layerRange {<bottom_layer> <top_layer>} \ -report <f>` `editPowerVia -add_vias 1 -nets {<pwr_net> <gnd_net>} -bottom_layer <layer> -top_layer <layer>`	No missing vias, and the multi-cut share matches the plan.	A high single-cut share on a layer pair that the plan expected to be multi-cut.	A missing via at a crossing of same-net wires, or a stacked via that is incomplete.
P-06	Special-net connectivity against the baseline After vias	`verifyConnectivity -net {<pwr_net> <gnd_net>} -type special -noAntenna -report <f>` `verifyConnectivity -net {<pwr_net> <gnd_net>} -type special -noAntenna -allPGPinPort \ -report <f>`	Opens fall from the baseline to none, with the same command form in both runs.	Unconnected pins on cells that are intentionally not powered, which must be listed and explained.	Any open on a supply net, or any unconnected macro PG port.
P-07	PG shorts and grid design rules After connectivity is clean	`verify_drc -check_only special -limit 0 -report <f>` `verify_drc -check_only special -check_short_only -report <f>` `get_verify_drc_mode`	No violations, and the report was produced by the same stored settings you record.	An empty report from a run that completed, which proves only that the checker ran.	Any short between VDD and VSS, or between a supply wire and a signal net.
P-08	Track budget and routing resource left After the grid is final	`report_metal_stack` `report_tracks -prefer_only` `report_route -track_utilization -layer <bottom_layer>:<top_layer>`	The routing resource left on each layer meets the project budget.	One layer carrying far more PG than its neighbours, which pushes routing to other layers.	Free tracks on a layer below the project budget, because the router has nothing to work with.

CHAPTER 5 CHEAT SHEET

5.10 Command cheat sheet: Power planning

Legacy UI commands. Angle brackets are placeholders, and values shown are examples, not project limits.

Command	What it produces

Global net connection and tie pins
`checkDesign -powerGround -noHtml -outfile <f>`	Text report of power terminals on ground nets, ground terminals on power nets, floating PG terminals and PG terminals on other nets. Writes a file.
`checkDesign -tieHiLo -noHtml -outfile <f>`	Text report of unconnected tie-high and tie-low terminals, and of tie pins and PG pins connected to different nets. Writes a file.
`getTieHiLoMode -nonDefault`	The setTieHiLoMode settings that are not at their default value.
`writeFPlanScript -fileName <f> -sections {globalNetConnect}`	The global net connections written as Tcl commands you can review and source later. Writes a file.
`globalNetConnect <pg_net> -type pgpin -pin <pg_pin> -all -verbose`	Connects the named PG pin of every instance to the global net and prints statistics. Changes the database.
`globalNetConnect <pg_net> -type pgpin -pin <pg_pin> -singleInstance <inst> -override`	Connects one instance, typically a macro with its own pin names, and replaces earlier connections. Changes the database.
`globalNetConnect <pg_net> -type net -hierInst <hinst> -net <net_basename>`	Moves the connections of a named net under a hierarchical instance onto the global net. Changes the database.
`globalNetConnect <power_net> -type tiehi`	Connects tie-high pins directly to the power net. addTieHiLo overrides this later. Changes the database.
`globalNetConnect <ground_net> -type tielo`	Connects tie-low pins directly to the ground net. Changes the database.
`clearGlobalNets`	Removes every logical PG and tie connection. Changes the database; use it only before rebuilding the rules.

Physical-only cells
`verifyEndCap -report <f>`	Markers and a report for missing end-cap cells and end caps of the wrong type.
`verifyEndCap -wrongLocation -report <f>`	Adds a check that end caps sit in the right location.
`verifyWellTap -report <f>`	Markers and a report for missing well taps and taps that break the distance rule, with the actual and rule distance. It does not check row areas covered by blocks and their halos or by placement blockages.
`verifyWellTap -cell <tap_cell> -rule <um> -report <f>`	The same check with the tap cell and distance taken from the project rule.
`getEndCapMode`	The stored setEndCapMode settings.
`get_well_tap_mode`	The stored set_well_tap_mode settings.
`addEndCap -prefix <prefix>`	End-cap cells at the row ends, with preplaced status. Changes the database.
`addWellTap -cell <tap_cell> -cellInterval <um> -prefix <prefix>`	Well-tap cells at the given maximum interval, with preplaced status. Changes the database.
`deleteFiller -prefix <prefix>`	Removes physical cells that carry the prefix. The default prefix is FILLER, so pass the end-cap or tap prefix you used. Changes the database.

Mode settings to record
`getAddRingMode`	The stored values of every setAddRingMode option.
`getAddStripeMode`	The stored values of every setAddStripeMode option.
`getSrouteMode`	The stored values of every setSrouteMode option.
`getViaGenMode`	The stored values of every setViaGenMode option, which also steer the power vias.

Rings, stripes and followpins
`setAddRingMode -stacked_via_bottom_layer <layer> -stacked_via_top_layer <layer>`	Limits the layers that ring vias can stack through. Changes the session settings.
`addRing -nets {<pwr_net> <gnd_net>} -type core_rings -follow core -layer {top <h_layer> bottom <h_layer> left <v_layer> right <v_layer>} -width <w> -spacing <s> -offset <o>`	Core rings around the core boundary. Changes the database.
`setAddStripeMode -stacked_via_bottom_layer <layer> -stacked_via_top_layer <layer>`	Limits the layers that stripe vias can stack through. Changes the session settings.
`addStripe -nets {<pwr_net> <gnd_net>} -layer <layer> -direction vertical -width <w> -spacing <s> -set_to_set_distance <d> -start_offset <o>`	A set of stripes on one layer. Changes the database.
`addStripe -report_cut_stripe <f>`	Writes a DRC marker file for stripes that were cut to avoid a violation. Run it as part of an addStripe call.
`sroute -connect corePin -nets {<pwr_net> <gnd_net>} -corePinTarget firstAfterRowEnd -allowLayerChange 1 -layerChangeRange {<bottom_layer> <top_layer>}`	Followpin wires from the standard-cell PG pins to the grid. Changes the database.
`sroute -connect blockPin -nets {<pwr_net> <gnd_net>} -blockPin useLef -blockPinTarget nearestTarget -inst {<macro_inst>}`	Wires from macro PG pins to the nearest legal target. Changes the database.
`setViaGenMode -viarule_preference {<rule1> <rule2>} -optimize_cross_via 1`	Sets the preferred via rules and minimum-enclosure crossover vias before the power commands. Changes the session settings.

Power vias
`verifyPowerVia -net {<pwr_net> <gnd_net>} -report <f>`	Markers and a report of missing vias where orthogonal power wires on adjacent layers cross.
`verifyPowerVia -net {<pwr_net> <gnd_net>} -stackedVia -layerRange {<bottom_layer> <top_layer>} -report <f>`	Adds the check for missing stacked vias between the bottom and top layers, plus the adjacent vias between them. The reference does not state the combined effect with -stackedVia.
`report_via -special`	Single-cut and multi-cut summary of the special vias.
`reportPowerRoute -followpin_cut_ratio {<cutclass1> <w1> <cutclass2> <w2>} -net <net>`	Cut ratio of followpin via stapling. Needs two cut classes defined in the LEF.
`editPowerVia -add_vias 1 -nets {<pwr_net> <gnd_net>} -bottom_layer <layer> -top_layer <layer>`	Adds power vias between the layers. Changes the database.
`editPowerVia -add_vias 1 -nets {<pwr_net> <gnd_net>} -cell_pins {<macro_cell>:<pg_pin>}`	Drops vias on the named macro PG pins. Changes the database.

Connectivity and geometry
`verifyConnectivity -net {<pwr_net> <gnd_net>} -type special -noAntenna -report <f>`	Opens and unconnected PG pins on the named nets, with markers. The same form as the Chapter 4 baseline.
`verifyConnectivity -net {<pwr_net> <gnd_net>} -type special -noAntenna -allPGPinPort -report <f>`	Adds a check of all PG ports, for macros with several ports per pin.
`verify_drc -check_only special -limit 0 -report <f>`	Markers and a report of violations between special routes and other shapes, without the default cap of 1000.
`verify_drc -check_only special -check_short_only -report <f>`	Only the shorts involving special routes.
`get_verify_drc_mode`	The current verify_drc settings.
`violationBrowser -connectivity`	Opens the browser on connectivity markers only.
`saveDrc <f>`	Writes DRC markers to a file without saving the whole design. The reference documents it for verify_drc and verifyMetalDensity markers, so connectivity markers are not verified. Writes a file.

Track budget
`report_metal_stack`	Direction, offset, pitch, minimum spacing, minimum width and default width of every routing layer. Uniform track patterns only, and the preferred direction by default.
`report_tracks -prefer_only`	The track definitions of each layer in its preferred direction.
`report_route -track_utilization -layer <bottom_layer>:<top_layer>`	Per layer: tracks, share blocked by the PG mesh, blockages, cells and nets, and the share still available.
`report_pg_keepout`	Every PG keepout box in the design.

Rework and checkpoint
`defOutBySection <f> -specialNets -specialNetRouting`	The special nets with their routing written to a DEF file, which is the way to keep the grid outside the database. It also writes the die area, components and nets unless suppressed. Writes a file.
`saveFPlan <f>`	The floorplan file and a power route data file next to it. Writes files.
`saveDesign <name>.enc`	The whole database, as the checkpoint to return to. Writes files.
`editDelete -nets {<pwr_net> <gnd_net>} -shape RING`	Deletes the ring wires of the nets so they can be rebuilt. Changes the database.
`editDelete -nets {<pwr_net> <gnd_net>} -shape STRIPE`	Deletes the stripes of the nets. Changes the database.
`editDelete -nets {<pwr_net> <gnd_net>} -shape FOLLOWPIN`	Deletes the followpin wires of the nets. Changes the database.
`editDelete -nets {<pwr_net> <gnd_net>} -shape COREWIRE`	Deletes the core wires that sroute leaves outside the row area. Changes the database.
`editDelete -nets {<pwr_net> <gnd_net>} -shape BLOCKWIRE`	Deletes the macro pin routes of the nets. Changes the database.
`deleteAllPowerPreroutes`	Removes every power preroute from the floorplan. Changes the database.
`trim_pg -net {<pwr_net> <gnd_net>} -layer <layer> -pattern {<keep_trim_string>} -type stripe`	Removes redundant stripes by a 0 and 1 pattern, based on IR drop evidence. Changes the database.
`reinforce_pg -auto_ir_fix preroute`	Adds stripes between existing ones where Voltus reports IR drop violations. Changes the database; needs rail analysis.
`check_design -type place -out_file <f>`	The placement prerequisite list, to be rerun in Chapter 6 once the grid is final. Writes a file.

Only if the block uses UPF
`reportPowerDomain -file <f>`	Power domain names, boxes, libraries and always-on status. Writes a file.
`reportPowerDomain -pgNet -file <f>`	The power and ground nets of each domain. Writes a file.
`verifyPowerDomain -gconn`	Checks that PG pins and tie connections inside each domain connect to that domain nets.
`verifyPowerSwitch -checkPlace -checkRowCoverage`	Checks that power switches are placed and that every row is covered.
`reportPowerSwitch -outFile <f>`	Every power switch instance with its location and pin connections. Writes a file.