CHAPTER 10

Global and early routing qualification

Placement and clock tree synthesis decide where cells and clock wires go. Global routing asks the next question: is there room for every other wire? This chapter checks the routing set-up, runs early global route, and reads congestion, layer usage and pin access before detailed routing starts.

10.1 Stage purpose

Early global route is a quick global router. It estimates routing congestion and the resistance and capacitance of the wires, and it does so without producing a finished, design-rule-clean route. The Innovus tools run it inside several other steps, not only when you call it. The reference states that its settings affect the results of place_opt_design, ccopt_design and post-CTS timing, so a change made here moves numbers in earlier chapters as well.

Global routing works on gcells, which are the rectangles into which the routing area is divided. Each gcell has a supply or capacity, and a demand. The reference defines a gcell as overflowing when its demand exceeds its supply, and describes typical supply as the number of unobstructed tracks crossing the gcell and demand as the number of wires assigned to it. The idea is drawn in Figure 13. A track is one legal wire position on a layer, so a gcell with twelve free tracks can carry twelve wires and no more.

Overflow is the amount by which demand exceeds supply. In the figure, 15 nets want to cross a gcell that has 12 free tracks, so the overflow is 3. A net with no track must go somewhere else, usually around the gcell, and that costs wire length, bends and delay. The figure keeps the three kinds of statement apart: the capacity is a count of tracks, the demand is a count of nets, and the overflow is their difference. The overflow percentage printed in the log is a different, normalised number, not a count of tracks, and the tool documentation gives two different formulas for it. Set the budget in the unit the tool prints, and use the hotspot reports for track counts.

One more distinction matters in this chapter. A route guide says where wires may go, and geometry is the metal itself. Early global route produces estimates, and the reference warns that its wires can overlap where a gcell is only partly covered by a blockage or by pre-routed wires. It also states that the result is not guaranteed DRC clean and must not be used for signal integrity analysis. Thus, treat its wires as a forecast of the detailed route, not as the route.

Four ideas are kept apart. Tool completion means earlyGlobalRoute returned. Analysis coverage means every net you expect was routed, on the layers you expect. Stage qualification means the overflow, hotspots, layer usage and pin access meet your project budgets. Signoff comes after detailed routing and signoff extraction, and this chapter never claims it. A run can complete with a clean-looking summary and still be unqualified, because an average hides one blocked channel.

Figure 13. Gcell capacity against demand, and what overflow costs a net

Read it. Panel A gives demand over capacity for each gcell of a small grid. Two touching gcells are red because their demand is above their capacity, and the gcell marked B is enlarged in panel B. There, capacity is drawn as track lines: eight on M3 and eight on M5, of which four on M5 sit under a blockage. Both are horizontal layers in the technology of the log excerpt in Section 10.5. Demand is drawn as 15 individual nets. Twelve nets each take a track, and the three dashed magenta nets numbered 1 to 3 have none. The amber strip states the arithmetic: capacity 12 tracks, demand 15 nets, overflow 3. Panel C shows one net that cannot take the straight route through the red gcells and detours around them, and the ledger counts the cost. All counts are illustrative.

10.2 Entry prerequisites

Must already be true	Why
Chapters 1 to 9 passed, with a legal placement and a qualified clock tree	Early global route reads the cells, the pre-routed power and the clock nets as they stand. The reference says to rerun it after placement, CTS and any optimisation that changes connections.
The routing layer range is decided and set	The layer range sets the capacity. The default lowest routing layer is Metal2, and early global route does not use Metal1 by default.
Clock route types, NDRs and shields were defined before CTS	The router can only reserve resource for clock rules that exist.
Routing blockages and partial blockages are known and recorded	They remove supply, so an unrecorded blockage looks like unexplained overflow.
Project budgets for overflow, hotspot score and per-layer track use exist	This book sets no limits. The reports show values, and your budget decides.

10.3 Relevant files and analysis context

Early global route works on the database in memory, so there is no input file to check. What it reads is the placement, the tracks, the blockages, the pre-routed wires and a set of settings. The settings come from setRouteMode, which the reference says is used automatically whenever early global route runs, explicitly or inside another step, and from setDesignMode for the routing layers. Because both change the result, they are recorded with every report.

Record	How	Why
Routing layer range	`getDesignMode -bottomRoutingLayer` and `getDesignMode -topRoutingLayer`	The layers set the capacity.
Early global route settings	`getRouteMode`	Effort level, clock track reservation and partition options all change congestion values.
Track definitions	`report_tracks -prefer_only`	Tracks are the capacity of a gcell.
Partial blockages	the commands that created them	They scale the supply on a layer in an area.
Run log name	`getLogFileName`	The overflow and wire length lines are printed to the log.

Early global route also honors net attributes set with setAttribute: the non-default rule, preferred extra spacing, preferred top and bottom routing layers, skip routing, and the shield net. The layer attributes are soft limits, so the router may go outside them when it must. The attributes are the reason clock rules must be committed before this stage, as Section 10.4 shows.

Early-route parasitics deserve one more sentence. The timing commands that run early global route, such as timeDesign, extract from its wires, and the default extraction engine is preRoute. Numbers built on those wires are preliminary. Judge them as a trend against the same flow at the previous stage, and expect them to move once detailed routing replaces the estimate.

10.4 Checks and command cards

10.4.1 Pre-stage checks

G-01Routing set-up record

Question it answers	Which layers, tracks, effort level and extraction engine will early global route use, and are they the ones the project intends?
Stage	Before earlyGlobalRoute
Product	Innovus Implementation. The reference entry names no separate licence requirement for this command.
Required state	Placement and CTS complete.
Legacy UI	getRouteMode getRouteMode -earlyGlobalEffortLevel getDesignMode -bottomRoutingLayer getDesignMode -topRoutingLayer getDesignMode -congEffort getExtractRCMode -engine report_tracks -prefer_only check_tracks -layer <layer> -direction H

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	`-earlyGlobalEffortLevel` on getRouteMode, reads the congestion effort level. The default is standard. `-bottomRoutingLayer` on getDesignMode, reads the lowest LEF layer for global and detail routing. `-topRoutingLayer` on getDesignMode, reads the highest LEF layer for global and detail routing. `-prefer_only` on report_tracks, lists only the preferred-direction tracks of each layer. `-layer -direction` on check_tracks, select the layer and direction to check. Results go to the log.
Scope and view	Whole design.
Why capacity starts here	The supply of a gcell is the count of unobstructed tracks that cross it, so the layer range and track definitions fix the capacity before any net is placed. The reference notes that setDesignMode -congEffort and the early global route effort level are separate settings, and recommends the standard level when the congestion effort is high.
Effect on session	reads or reports only
Output	Tcl values and messages, track definitions in DEF TRACKS format, and a log summary of the track check.
Fields that matter	Effort level; bottom and top routing layer; congestion effort; extraction engine; the STEP of each layer; on-track pins and non-accessible pins from check_tracks.
Healthy	Layer range, effort level and tracks match the technology plan, and every setting is recorded.
Warning	Effort level low or medium for a decision run, which the reference says gives a less accurate congestion report.
Hard stop	A routing layer range or track definition that differs from the technology plan, so capacity is wrong before any net is routed.
Common misuse	Comparing a log from a lower effort run with one from a standard effort run.
Root cause and fix	Correct the layer range or the track definitions, then rerun early global route and every card after this one.
Rerun after a fix	Rerun G-01, then G-04 to G-08.
Verification	Legacy syntax checked against the Innovus Legacy text reference.

G-02Clock routing attributes

Question it answers	Will early global route reserve the routing resource that the clock route types ask for?
Stage	Before earlyGlobalRoute
Product	Innovus Implementation. The reference entry names no separate licence requirement for this command.
Required state	CTS complete; route types defined before CTS.
Legacy UI	reportRouteTypeConstraints -summary report_route -clock report_route -ndr getRouteMode -earlyGlobalNumTracksPerClockWire commit_ccopt_clock_tree_route_attributes

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	`-summary` on reportRouteTypeConstraints, prints the constraint usage per layer, per NDR and per constraint type. `-clock` on report_route, reports statistics of clock nets. `-ndr` on report_route, reports NDR statistics of nets. `-earlyGlobalNumTracksPerClockWire` on getRouteMode, reads the number of tracks reserved for each clock wire. The default is 0.
Scope and view	All nets with route type constraints.
Side effect	commit_ccopt_clock_tree_route_attributes sets isClock and isCTSClock on the clock tree nets and applies the route type layers, NDR and shield. The reference does not say whether ccopt_design runs it for you, so confirm with the summary and run it only if the constraints are missing. After ccopt_design the clock nets are already detail routed and the early global route log counts pre-routed nets, so the summary matters most for clock nets that early global route routes itself. The tool documentation says the feature that converts CCOpt routing constraints into the database needs flow support from Cadence, so this is not verified for your flow.
Effect on session	updates the design database. Some commands in this card only read or report.
Output	A constraint table on the console, and Tcl values.
Fields that matter	Constraint counts by category, including INNOVUS_CLK_NDR; adherence of the router; the preferred bottom layer used; the NDR type; the clock track reservation.
Healthy	Clock nets show their NDR and shield constraints, so the router reserves the width and spacing.
Warning	No clock constraints appear, so early global route would treat the clock nets it routes as ordinary wires.
Hard stop	Clock nets that early global route routes have NDR or shield requirements that the summary does not list.
Common misuse	Assuming the track reservation setting is in force. The reference says it is ignored when clock specifications are committed.
Root cause and fix	Run commit_ccopt_clock_tree_route_attributes, or correct the route types, and recheck the summary.
Rerun after a fix	Rerun G-02, then G-04 and G-05.
Verification	Legacy syntax checked against the Innovus Legacy text reference.

G-03Route readiness and pin access

Question it answers	Does the database have anything that stops routing, such as unplaced items, overlaps, a blockage at a pin, or a pin the router cannot reach?
Stage	Before earlyGlobalRoute
Product	Innovus Implementation. The reference entry names no separate licence requirement for this command.
Required state	Placement complete; the database is not a pre-placed one.
Legacy UI	check_design -type route -out_file <report_file> checkPlace <report_file> check_library -place -cell <lib_cell> -file <report_file>

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 route` on check_design, runs the checks that precede routing, such as congestion, placement and pin access. `-out_file` on check_design, writes the findings as a Tcl dictionary file. `-place -cell` on check_library, checks one library cell against the existing preroutes. `-file` on check_library, names the output file.
Scope and view	Whole design for check_design and checkPlace; the named cell for check_library.
Default stop level	By default check_design stops the flow if the worst over-congested gcell is above 0.75 percent. That is a tool default, not your project gate. The reference says such congestion can be ignored but must be understood and waived deliberately.
Effect on session	adds GUI violation markers; writes files
Output	A message list, a violation table, a Tcl dictionary file, markers in the violation browser, and a library cell report.
Fields that matter	Unplaced instances and top-level pins; track rule adherence; overlapping cells; pin spacing; blockages at pin locations; congestion; pin access for NDR nets; pin access violations from checkPlace; cell DRC, pin access, symmetry and pin alignment.
Healthy	No errors, and no pin access violations on cells you cannot move.
Warning	A congestion finding below the tool stop level but above your budget, or a library cell with a pin access note.
Hard stop	Unplaced instances or pins, overlapping cells, a blockage at a pin, or pin access violations on many instances.
Common misuse	Running check_design -type route on a pre-placed database. The reference states it cannot be run that way.
Root cause and fix	Fix each finding at its source: placement, pin plan, blockage or library setup.
Rerun after a fix	Rerun G-03, then G-04 to G-08.
Verification	Legacy syntax checked against the Innovus Legacy text reference.

10.4.2 Post-stage checks

G-04Early global route run and log

Question it answers	Did early global route run on the intended nets and layers, and what did it report for overflow and wire length?
Stage	After the routing set-up record
Product	Innovus Implementation. The reference entry names no separate licence requirement for this command.
Required state	G-01 to G-03 reviewed.
Legacy UI	earlyGlobalRoute report_message -errors -count report_message -warnings -count getLogFileName

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	`-errors -count` on report_message, lists {ID count} pairs for the error IDs issued. `-warnings -count` on report_message, lists {ID count} pairs for the warning IDs issued.
Scope and view	Whole design, unless setRouteMode -earlyGlobalRouteSelectedNetsOnly is true, which routes only selected nets.
Estimates only	The reference states that early global route does not guarantee DRC-clean routing and must not be used for signal integrity analysis. If you run optimisation commands after it, rerun it so the interconnect matches the netlist. The gcell size is a tool setting, so compare congestion between runs of the same design and set-up, not between designs.
Effect on session	updates the design database; runs an expensive analysis. Some commands in this card only read or report.
Output	Estimated routes in the database and [NR-eGR] lines in the log: nets read and ignored, the layer group and layer range, overflow, estimated wire length, and a table of length and vias per layer.
Fields that matter	Number of nets read and ignored; layer range of each group; overflow in H and V; estimated wire length; length and vias per layer; total half perimeter of the net bounding boxes; clock net wire length.
Healthy	The net count matches the design, the layer range is the planned one, and overflow is within your budget in both directions.
Warning	Overflow in one direction only, or ignored nets that you have not explained.
Hard stop	Any error message, a layer range that differs from the set-up record, or a run that routed only a selected set of nets.
Common misuse	Reading the log of a run with selected nets only, or with a lower effort level, as a full run.
Root cause and fix	Fix the cause of the first error, correct the set-up, and rerun.
Rerun after a fix	Rerun G-04, then G-05 to G-08 and the timing cards of Chapter 9.
Verification	Legacy syntax checked against the Innovus Legacy text reference.

G-05Overflow and congestion distribution

Question it answers	How much overflow is there, in which direction, and how are the remaining tracks spread over the gcells?
Stage	After earlyGlobalRoute
Product	Innovus Implementation. The reference entry names no separate licence requirement for this command.
Required state	G-04 reviewed; a route exists.
Legacy UI	reportCongestion -overflow reportCongestion -hotSpot -num_hotspot 5 reportCongestion -3d

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	`-overflow` reports horizontal and vertical overflow. `-hotSpot` reports the local hotspot score, the maximum and total hotspot area. `-num_hotspot` sets how many hotspots to list. `-3d` honors the 3D congestion map and reports congestion by layer.
Scope and view	Whole design.
Tool guidance	The reference describes a maximum hotspot score below 100 as typically routable. Use it as a pointer to what the tool considers comfortable, and use your project budget as the gate.
Effect on session	reads or reports only
Output	A usage line, an overflow line, a congestion distribution table, and with -hotSpot a table of hotspot boxes and scores.
Fields that matter	Horizontal and vertical overflow; the count and percentage of gcells at each remaining-capacity level; the maximum hotspot score; the total hotspot score; the box of each top hotspot.
Healthy	Overflow in both directions and the maximum hotspot score are within your project budget.
Warning	Small average overflow with one large hotspot, or horizontal and vertical results that disagree.
Hard stop	Maximum or total hotspot score beyond budget, or the top hotspot sits over a macro channel or a pin cluster.
Common misuse	Judging the average and ignoring the hotspot, or running the command before a route exists. The reference says a route must be called first.
Root cause and fix	Locate the hotspot with G-06, find its cause, relieve it with G-09, and rerun.
Rerun after a fix	Rerun G-05 after every relief step.
Verification	Legacy syntax checked against the Innovus Legacy text reference.

G-06Hotspot areas and the nets inside them

Question it answers	Where exactly are the hotspots, how large are they, and which nets pass through them?
Stage	After G-05
Product	Innovus Implementation. The reference entry names no separate licence requirement for this command.
Required state	G-05 shows overflow or a hotspot.
Legacy UI	reportCongestArea -num 10 -mode average -outfile <report_file> dumpCongestArea -all <file> dumpNetsInCongestedArea <file> setLayerPreference gcellOvflow -isVisible 1 dbQuery -areas {{<llx> <lly> <urx> <ury>}} -objType gcell

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	`-num` on reportCongestArea, sets how many hot spots to report. The default is 10 and the reference states a maximum of 100, although it also allows all. `-mode` on reportCongestArea, selects average or max. The reference does not say what the two modes mean (not verified). `-outfile` on reportCongestArea, writes the report to a file. `-all` on dumpCongestArea, writes every gcell, whatever its congestion level. Without it only the most congested gcells are written. `-areas -objType` on dbQuery, select the search area and the object type gcell.
Scope and view	Whole design; dbQuery works on the areas you give.
How a hot spot is found	The reference describes the method. It starts at the most over-congested gcell, checks a number of gcells in each direction (the -step value, default 3), stops at a side when the overflow falls below the cut-off, and then looks for the next worst gcell outside the area already found.
Effect on session	adds GUI violation markers; writes files. Some commands in this card only read or report.
Output	A vertical and a horizontal hot spot table, an ASCII gcell file, a list of net names, and a congestion display in the GUI after setLayerPreference.
Fields that matter	Peak overflow; location of the peak; boundary box; hot spot area in gcells; per-gcell overflow and track counts; names of the nets in the congested area.
Healthy	Few hot spots, each small, and none over a macro channel, a pin cluster or a clock net area.
Warning	Hot spots confined to one region that a placement or blockage change could relieve.
Hard stop	A large hot spot over a macro channel or pin group, where no routing change inside the gcells can help.
Common misuse	Treating the default top 10 as the full list. A hot spot also needs a gcell above the cut-off, which defaults to an overflow value of -2, and a ratio cut-off of 0.01 of the peak also applies.
Root cause and fix	Find the cause in the hot spot area: channel width, pin density, placement density, clock rules or blockage. Then use G-09.
Rerun after a fix	Rerun G-05 and G-06 after any change.
Verification	Legacy syntax checked against the Innovus Legacy text reference.

G-07Layer usage and track utilisation

Question it answers	Which layers carry the wire, how many vias are there, and how much of the track resource is already used?
Stage	After G-05
Product	Innovus Implementation. The reference entry names no separate licence requirement for this command.
Required state	G-04 reviewed.
Legacy UI	report_route -summary report_route -track_utilization -layer <bottom>:<top> report_route -track_utilization -layer <bottom>:<top> -include_regular_routes report_route -clock report_route -ndr

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	`-summary` on report_route, shows only the summary table. `-track_utilization` reports the track utilisation. `-layer` selects a layer or a layer range such as M1:M4. `-include_regular_routes` also counts tracks blocked by regular wiring. By default regular wiring is not counted. `-clock` reports statistics of clock nets. `-ndr` reports NDR statistics of nets.
Scope and view	Whole design, or the area given with -area or -view_window.
Layer note	The reference example log shows Metal1 with zero length and many vias. That is the expected shape when the lowest routing layer is Metal2: The reference does not give the reason (not verified), but the tool documentation states that early global route does not use Metal1 by default.
Effect on session	reads or reports only
Output	Tables on the console: design metrics, net pin statistics, wire length per layer, and a track table.
Fields that matter	Wire length and vias per layer; for each layer the number of tracks and the percentages blocked by PG mesh, blockage and IO, cells, standard cells and nets; the percentage of tracks still available.
Healthy	Wire and vias sit on the planned layers, and available tracks stay above your project level on every layer.
Warning	One layer carries most of the wire while the layers above it are lightly used.
Hard stop	Wire on layers outside the planned range, or available tracks near zero on a layer in a congested area.
Common misuse	Reading the available-tracks column without noting whether regular wiring was counted. The two versions of the report give different answers.
Root cause and fix	Correct the layer range, the layer attributes or the blockages, then rerun early global route.
Rerun after a fix	Rerun G-04, G-05 and G-07.
Verification	Legacy syntax checked against the Innovus Legacy text reference.

G-08Route guides and the clock guide diagnostic

Question it answers	Is the early global route result saved as a guide where you need one, and is the CCOpt clock guide diagnostic set for the clock routing?
Stage	After G-04
Product	Innovus Implementation. The reference entry names no separate licence requirement for this command.
Required state	G-04 reviewed; no optimisation since the run.
Legacy UI	saveRouteGuide -rguide <guide_file> get_ccopt_property check_route_follows_guide report_route -clock get_ccopt_property check_route_follows_guide_min_length

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	`-rguide` on saveRouteGuide, names the route guide file. `-clock` on report_route, reports statistics of clock nets, which are the nets the diagnostic compares. `check_route_follows_guide` CCOpt property that runs a diagnostic comparing the lengths of estimated clock routes with the final detailed wiring. The default is true. `check_route_follows_guide_min_length` CCOpt property that sets the minimum net length for that diagnostic.
Scope and view	Whole design for the guide file; clock nets for the diagnostic.
Guides versus geometry	The reference describes route guide files as regions in which early global route can create wires. The CCOpt reference adds that CCOpt generates route guides that are passed to NanoRoute for the final clock tree routing. A guide is a region, and geometry is the metal that the detailed router builds inside it. The guide file from saveRouteGuide and the CCOpt guides are separate. The reference describes the diagnostic as comparing estimated clock routes with the final detailed wiring of clock nets routed by NanoRoute, so it belongs to the CCOpt clock routing of Chapter 9. Changing the property here probably has an effect only after ccopt_design is rerun (not verified).
Effect on session	writes files. Some commands in this card only read or report.
Output	A route guide file, and Tcl values for the two properties.
Fields that matter	The guide file exists and covers the intended nets; the diagnostic is on; the minimum length is a value you chose.
Healthy	The guide file is current for the nets you need, and the diagnostic was on with a minimum length that includes your clock nets.
Warning	The diagnostic was off, or the minimum length is so large that the long clock nets are skipped.
Hard stop	The guide you need was saved before the last optimisation or CTS change, so it describes routes that no longer exist.
Common misuse	Treating the guide as proof that the final wires will follow it. A guide limits where wires may go, and only the detailed route and its checks show what was built.
Root cause and fix	Rerun early global route after the last change and save the guide again. Set the diagnostic properties before ccopt_design.
Rerun after a fix	Rerun G-04 and G-08.
Verification	Legacy syntax checked against the Innovus Legacy text reference.

G-09Congestion relief and rerun

Question it answers	Does a partial routing blockage reduce the overflow in a hotspot, and does the rerun confirm it?
Stage	After G-06
Product	Innovus Implementation. The reference entry names no separate licence requirement for this command.
Required state	A hotspot location from G-06, and its cause understood.
Legacy UI	createRouteBlk -box {<x1> <y1> <x2> <y2>} -partial <percent> -layers {<layer>} deleteRouteBlk -name <blockage_name> setRouteMode -reset

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	`-box` on createRouteBlk, gives the blockage area. `-partial` on createRouteBlk, sets the density: only that percent of the routing resource in a gcell is available to global routing. `-layers` on createRouteBlk, names the layers it applies to. `-name` on deleteRouteBlk, removes a blockage by name. `-reset` on setRouteMode, restores every setRouteMode parameter to its default, including the settings recorded in G-01 and G-02. The reference also allows resetting only the parameters named after it.
Scope and view	The blockage box and layers you give.
Overlap rule	The reference states that where partial blockages overlap, the lowest density percentage applies. A partial blockage changes the routing resource that the global router sees in the box. The reference does not say what happens to wires that already exist there, so check the route after the rerun.
Effect on session	changes analysis configuration; updates the design database
Output	A routing blockage in the database, and after a rerun new overflow and hotspot numbers.
Fields that matter	Overflow and hotspot score before and after; the location of the new top hotspot; the list of partial blockages you added.
Healthy	Overflow and hotspot score fall after the change, and no new hotspot appears next to the old one.
Warning	The hotspot moves to a neighbouring area instead of disappearing.
Hard stop	Overflow stays above budget after relief, or a partial blockage is left in the database with no record of why.
Common misuse	Using a partial blockage as the first fix. Reading -partial 75 as 75 percent blocked: it means 75 percent of the resource is available.
Root cause and fix	Treat the cause: widen the channel, change the placement density, or correct the clock rules. Use a partial blockage to steer, not to hide.
Rerun after a fix	Rerun earlyGlobalRoute, then G-04 to G-08 and the timing cards of Chapter 9.
Verification	Legacy syntax checked against the Innovus Legacy text reference.

10.5 Required reports, artefacts and how to read them

Report	Fields that support qualification	Evidence class
Routing set-up record (G-01, G-02)	layer range, effort level, tracks, constraint table	implementation
Route readiness findings (G-03)	unplaced items, overlaps, pin access, congestion finding	implementation
Early global route log (G-04)	nets read, overflow H and V, estimated wire length, length and vias per layer	preliminary
Congestion and hotspot reports (G-05, G-06)	overflow, distribution, hotspot score and boxes, nets inside	preliminary
Layer and track reports (G-07)	wire and vias per layer, available tracks per layer	preliminary
Route guide file and diagnostic setting (G-08)	guide written, diagnostic on, minimum length	preliminary

Everything this chapter produces is built on estimated routes, so none of it is signoff evidence. It is preliminary: good enough to decide whether detailed routing is worth starting, and not good enough to sign off timing, signal integrity or design rules.

Reading an early global route log and a hotspot tableSynthetic report, not tool output

earlyGlobalRoute                                         ## illustrative excerpt
[NR-eGR] Read 7482 nets ( ignored 0 )
[NR-eGR] Layer group 1: route 7425 net(s) in layer range [2, 6]
[NR-eGR] Overflow after Early Global Route 0.31% H + 0.84% V
[NR-eGR]              Length (um)   Vias
[NR-eGR] Metal1 (1H)            0  25155
[NR-eGR] Metal2 (2V)       134127  35802
[NR-eGR] Metal3 (3H)       189844   5296
[NR-eGR] ...  (Metal4 to Metal6 omitted)
[NR-eGR] Total             526492  68315

reportCongestion -hotSpot
[hotspot] | Top | hotspot bbox              | hotspot score |
[hotspot] |  1  | 32.2 262.6 216.5 400.8    |    142.0      |
[hotspot] |  2  | 554.4 170.4 638.9 277.9   |     30.9      |

The layout follows the reference examples, and the numbers are illustrative. Read the log from the top. All 7482 nets were read, none were ignored, and 7425 were routed in the layer range 2 to 6. The excerpt does not say why 57 nets are not in the layer group (not verified), so find out what they are before you accept the run. That matches a design routed from Metal2 up, with Metal1 showing zero length and many vias, as in the note on G-07. The overflow is small in both directions. It is higher in the vertical direction, so the pressure is on the vertical layers. In this log Metal2 is marked 2V and Metal3 is marked 3H, so the even-numbered layers are vertical, and Figure 13 draws its two horizontal layers as M3 and M5 to match.

The hotspot table changes the verdict. The top hotspot scores 142, well above the second at 31, so the congestion is one region, not a general shortage. Its box is a region on the left of the block, about 184 by 138 units, which holds many gcells. The score is a normalised area, not a gcell count. Thus, the average overflow looked acceptable, and the decision follows the hotspot. This is the same lesson as the channel in Chapter 4, now seen with routed wires instead of an estimate. The next step is G-06, to find which gcells and which nets make the strip.

One caution about the congestion distribution table that reportCongestion also prints. Its Remain column lists tracks left in a gcell, with negative rows for overflow, as the reference example suggests, but the reference does not define the column. Confirm the meaning once against a gcell you can inspect in the GUI before you rely on it.

10.6 Healthy, suspicious and hard-stop examples

Finding	Status	Why
earlyGlobalRoute returned and nothing else was read	NOT EVALUATED	Completion is not qualification.
Overflow and maximum hotspot score within budget	PASS	Detailed routing can start from a routable picture.
Low average overflow with one large hotspot	WARN / REVIEW	The average hides a blocked region.
Hotspot over a macro channel or pin cluster beyond budget	HARD STOP	The region cannot be routed. Fix the floorplan or placement.
Clock NDRs missing for clock nets that early global route routes	HARD STOP	Clock resource is not reserved, so congestion is understated.
Routed layer range differs from the set-up record	HARD STOP	Capacity and wire length are not those of the plan.
Pin access violations on many instances	HARD STOP	The detailed router may leave violations at those pins.
Partial blockages left in the database without a record	WARN / REVIEW	Overflow numbers hide where supply was reduced.
Power-domain route constraint in a single-supply block	NOT APPLICABLE	No power domains exist.

10.7 Debugging, corrective action and reruns

Start with the run, then the numbers, then the place, then the cause. First confirm in G-04 that early global route covered the intended nets and layers, because a run on a selected set of nets or the wrong layer range makes every later number wrong. Then read G-05 for the size of the problem, G-06 for where it is, and G-07 for which layers are full. Only then look for the cause.

The cause is usually one of five things: a narrow channel next to a macro, a dense pin cluster, high placement density, clock rules that take more tracks than the plan allowed, or a blockage you forgot. The reference gives a related rule of thumb for detailed routing: if most violations sit at congestion hot spots, reduce placement density there or change the floorplan, and if most are on Metal1 and Metal2, suspect pin access on standard cell pins. The same split helps here.

After any change, rerun from the earliest affected card. A floorplan or placement change needs Chapter 4 or Chapter 7 again. A change to routing layers, track definitions or clock rules needs G-01 onward. A partial blockage needs G-04 to G-08. Every rerun of early global route changes the parasitics, so rerun the post-CTS timing cards of Chapter 9 as well.

10.7.1 Worked example: moderate overflow with a hotspot beside a macro

Suppose G-01 to G-04 are clean. G-05 gives overflow below budget, but the maximum hotspot score is 142 against a project budget of 100, and G-06 places the hotspot beside the macro RAM0. Its worst two touching gcells are the red pair in Figure 13. In the enlarged gcell, capacity is 12 tracks, demand is 15 nets and overflow is 3.

G-07, run with -area on that gcell, shows why the supply is small. Four of the eight M5 tracks in that gcell are blocked by the macro, so only 12 of 16 tracks are free. The three nets with no track detour around the hotspot. In the figure ledger, a detour from 4 steps to 6 adds 50 percent to the wire length, so both the resistance and the capacitance rise by that factor and the wire delay by about 2.25. The numbers are illustrative, but the mechanism is general.

The decision for G-05 is HARD STOP, because a hotspot beyond budget beside a macro is likely to leave violations or open nets for detailed routing. The fix is to give the channel more room, for example by moving the macro or the cells that crowd it, or to reduce the placement density in the neighbouring gcells. A partial blockage in the gcells next to the hotspot can then steer nets away, and it is recorded. Rerun early global route and G-04 to G-08. Accept the change only when the maximum hotspot score is within budget and no new hotspot has appeared next to the old one.

10.8 Exit criteria and stage checklist

Set-up. Routing layers, effort level, tracks and extraction engine are recorded and match the plan.
Clock rules. Clock NDR and shield constraints appear in the route type summary.
Readiness. check_design -type route and checkPlace show no errors and no pin access violations.
Run. earlyGlobalRoute finished without errors, on every intended net and layer.
Overflow. Horizontal and vertical overflow are within the project budget.
Hotspots. The maximum and total hotspot scores are within budget, with no hotspot over a macro channel or pin cluster.
Layers. Wire and vias sit on the planned layers, and available tracks stay above the project level.
Guides. The route guide is saved after the last change, and the clock guide diagnostic is on.
Records. Every partial blockage added is listed, with the reason for it.

Thus, global routing is qualified when the set-up is recorded, the run covered every net, overflow and hotspots meet the budget, and pin access is clean. A design that passes on average overflow alone can still hold a blocked channel that detailed routing cannot cross. Chapter 11 starts detailed routing from this picture, and judges what the router actually built.

CHAPTER 10 SANITY CHECKS

10.9 Sanity check cheat sheet: Global and early routing

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
G-01	Routing set-up record Before earlyGlobalRoute	`getRouteMode` `getRouteMode -earlyGlobalEffortLevel` `getDesignMode -bottomRoutingLayer`	Layer range, effort level and tracks match the technology plan, and every setting is recorded.	Effort level low or medium for a decision run, which the reference says gives a less accurate congestion report.	A routing layer range or track definition that differs from the technology plan, so capacity is wrong before any net is routed.
G-02	Clock routing attributes Before earlyGlobalRoute	`reportRouteTypeConstraints -summary` `report_route -clock` `report_route -ndr`	Clock nets show their NDR and shield constraints, so the router reserves the width and spacing.	No clock constraints appear, so early global route would treat the clock nets it routes as ordinary wires.	Clock nets that early global route routes have NDR or shield requirements that the summary does not list.
G-03	Route readiness and pin access Before earlyGlobalRoute	`check_design -type route -out_file <report_file>` `checkPlace <report_file>` `check_library -place -cell <lib_cell> -file <report_file>`	No errors, and no pin access violations on cells you cannot move.	A congestion finding below the tool stop level but above your budget, or a library cell with a pin access note.	Unplaced instances or pins, overlapping cells, a blockage at a pin, or pin access violations on many instances.
G-04	Early global route run and log After the routing set-up record	`earlyGlobalRoute` `report_message -errors -count` `report_message -warnings -count`	The net count matches the design, the layer range is the planned one, and overflow is within your budget in both directions.	Overflow in one direction only, or ignored nets that you have not explained.	Any error message, a layer range that differs from the set-up record, or a run that routed only a selected set of nets.
G-05	Overflow and congestion distribution After earlyGlobalRoute	`reportCongestion -overflow` `reportCongestion -hotSpot -num_hotspot 5` `reportCongestion -3d`	Overflow in both directions and the maximum hotspot score are within your project budget.	Small average overflow with one large hotspot, or horizontal and vertical results that disagree.	Maximum or total hotspot score beyond budget, or the top hotspot sits over a macro channel or a pin cluster.
G-06	Hotspot areas and the nets inside them After G-05	`reportCongestArea -num 10 -mode average -outfile <report_file>` `dumpCongestArea -all <file>` `dumpNetsInCongestedArea <file>`	Few hot spots, each small, and none over a macro channel, a pin cluster or a clock net area.	Hot spots confined to one region that a placement or blockage change could relieve.	A large hot spot over a macro channel or pin group, where no routing change inside the gcells can help.
G-07	Layer usage and track utilisation After G-05	`report_route -summary` `report_route -track_utilization -layer <bottom>:<top>` `report_route -track_utilization -layer <bottom>:<top> -include_regular_routes`	Wire and vias sit on the planned layers, and available tracks stay above your project level on every layer.	One layer carries most of the wire while the layers above it are lightly used.	Wire on layers outside the planned range, or available tracks near zero on a layer in a congested area.
G-08	Route guides and the clock guide diagnostic After G-04	`saveRouteGuide -rguide <guide_file>` `get_ccopt_property check_route_follows_guide` `report_route -clock`	The guide file is current for the nets you need, and the diagnostic was on with a minimum length that includes your clock nets.	The diagnostic was off, or the minimum length is so large that the long clock nets are skipped.	The guide you need was saved before the last optimisation or CTS change, so it describes routes that no longer exist.
G-09	Congestion relief and rerun After G-06	`createRouteBlk -box {<x1> <y1> <x2> <y2>} -partial <percent> -layers {<layer>}` `deleteRouteBlk -name <blockage_name>` `setRouteMode -reset`	Overflow and hotspot score fall after the change, and no new hotspot appears next to the old one.	The hotspot moves to a neighbouring area instead of disappearing.	Overflow stays above budget after relief, or a partial blockage is left in the database with no record of why.

CHAPTER 10 CHEAT SHEET

10.10 Command cheat sheet: Global and early routing

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

Command	What it produces

Record the routing set-up
`getRouteMode`	The current setRouteMode settings, which control early global route. Record them with every congestion report.
`getRouteMode -earlyGlobalEffortLevel`	The congestion effort level of early global route. The default is standard, the most accurate and slowest.
`getDesignMode -bottomRoutingLayer`	The lowest LEF layer used by global and detail routing.
`getDesignMode -topRoutingLayer`	The highest LEF layer used by global and detail routing.
`getDesignMode -congEffort`	The congestion effort level that controls placement and place_opt_design. The default is auto.
`getExtractRCMode -engine`	The extraction engine. The default is preRoute, which early global route parasitics use.
`report_tracks -prefer_only`	The track definitions of each layer in DEF TRACKS format, preferred direction only. Tracks set the capacity of a gcell.
`check_tracks -layer <layer> -direction H`	A check of offset, direction and spacing of the tracks on one layer, written to the log. Needs LEF loaded and the design placed.

Clock routing attributes
`reportRouteTypeConstraints -summary`	Route type constraints per layer, per NDR and per constraint type, so you can see what clock routing the router was asked for.
`getRouteMode -earlyGlobalNumTracksPerClockWire`	The number of tracks early global route reserves per clock wire. The default is 0.
`commit_ccopt_clock_tree_route_attributes`	Sets isClock and isCTSClock on the clock tree nets and applies route type layers, NDR and shield. Changes the database.
`setRouteMode -earlyGlobalNumTracksPerClockWire <n>`	Reserves n tracks per clock wire, from 0 to 8. Ignored once clock specifications are committed. Changes the session.
`setAttribute -net <net> -non_default_rule <rule>`	Assigns a non-default rule to a net, which early global route honors. Changes the database.

Route readiness and pin access
`check_design -type route -out_file <report_file>`	Checks routing prerequisites such as congestion, placement and pin access, and writes a Tcl dictionary of findings. Needs a placed database.
`check_design -type place -out_file <report_file>`	Placement prerequisites such as PG rail alignment and pin access issues. Writes a file.
`checkPlace <report_file>`	Placement violations, including pin access violations caused by pre-wires, with markers. Writes a file.
`check_library -place -cell <lib_cell> -file <report_file>`	Cell DRC, pin access, symmetry and pin alignment of one library cell against the existing preroutes. Writes a file.
`check_library -place -all_lib_cell -file <report_file>`	The same checks for every library cell. Writes a file.

Run early global route
`earlyGlobalRoute`	A quick global route that estimates congestion and parasitics, with a log of overflow and wire length per layer. Changes the database.
`setRouteMode -earlyGlobalEffortLevel low`	Faster and less accurate congestion estimates. Changes the session; record it.
`setRouteMode -reset`	Restores every setRouteMode parameter to its default and reports those that changed, so redo the set-up record afterwards. Changes the session.
`report_message -errors -count`	A list of {ID count} pairs for every error ID issued.
`report_message -warnings -count`	A list of {ID count} pairs for every warning ID issued.
`getLogFileName`	The name of the current log file, where the [NR-eGR] lines are.

Congestion reports
`reportCongestion -overflow`	Average congestion, horizontal and vertical overflow, and a congestion distribution table.
`reportCongestion -hotSpot`	The local hotspot score with the maximum and total hotspot, and a table of hotspot boxes and scores.
`reportCongestion -hotSpot -num_hotspot 5`	The same, limited to the number of hotspots you ask for.
`reportCongestion -hotSpot -includeBlockage`	The hotspot report with blockage area included.
`reportCongestion -3d`	Layer-based congestion reporting from the 3D congestion map.
`reportCongestArea -num 10 -mode average`	Up to 10 hot spots, vertical and horizontal, each with peak overflow, location, boundary box and size in gcells.
`reportCongestArea -num all -outfile <report_file>`	All hot spots, written to a file. The reference also states a maximum of 100 areas.

Congestion locations and nets
`dumpCongestArea <file>`	The most congested gcells, with coordinates and track counts, in an ASCII file.
`dumpCongestArea -all <file>`	Congestion information for every gcell, whatever its level. Writes a file.
`dumpNetsInCongestedArea <file>`	The names of the nets in the congested area, from the early global route result. Writes a file.
`dumpNanoCongestArea -all <file>`	The NanoRoute equivalent after routeDesign, with remaining and total tracks per gcell. Writes a file.
`dbQuery -areas {{<llx> <lly> <urx> <ury>}} -objType gcell`	The gcell objects that overlap the area, in microns.
`setLayerPreference gcellOvflow -isVisible 1`	Shows routing congestion in the GUI. Changes a display preference only.

Layer usage and wire length
`report_route -summary`	Design metrics, net pin statistics, wire length per layer and via counts per layer.
`report_route -track_utilization -layer <bottom>:<top>`	Per layer, the tracks blocked by PG mesh, blockages, cells and nets, and the percentage of tracks still available.
`report_route -track_utilization -layer <bottom>:<top> -include_regular_routes`	The same table with tracks blocked by regular wiring counted as well.
`report_route -clock`	Routing statistics of the clock nets.
`report_route -ndr`	NDR statistics of nets.
`report_route -net <net>`	The routing report for one net.
`reportRoute`	Routing statistics for signal nets, including actual wire length and vias on each layer.

Route guides and geometry
`saveRouteGuide -rguide <guide_file>`	The early global route result in route guide format. Writes a file.
`saveRouteGuide -rguide <guide_file> -selNetFile <net_file>`	The same, for the nets listed in the file only. Writes a file.
`get_ccopt_property check_route_follows_guide`	Whether CCOpt checks that detail-routed clock nets follow their CCOpt route guides. The default is true. Set it before ccopt_design.
`get_ccopt_property check_route_follows_guide_min_length`	The minimum net length for that guide diagnostic.
`route_ccopt_clock_tree_nets`	Routes the CCOpt clock tree nets from the CCOpt route guides, when final clock routing was disabled. Changes the database.

Relieving congestion
`createRouteBlk -box {<x1> <y1> <x2> <y2>} -partial <percent> -layers {<layer>}`	A partial routing blockage that limits the router to the stated percent of the resource on the layer. Changes the database.
`deleteRouteBlk -name <blockage_name>`	Deletes a routing blockage by name. Changes the database.
`setRouteMode -earlyGlobalReverseDirection "(<x1> <y1> <x2> <y2>) <layer>:<layer>"`	Models routing in the non-preferred direction on one layer in an area. It affects the congestion value only, so it changes the estimate, not the design. Changes the session.

Only if the block is a partition or uses UPF
`setRouteMode -earlyGlobalRoutePartitionHonorFence {<partition>}`	Routes the named partitions without crossing their fences. Changes the session.
`setRouteMode -earlyGlobalHonorMsvRouteConstraint true`	Routes inside the preferred power domains as far as possible. Changes the session.