Detailed-route qualification

11.1 Stage purpose

Routing happens in two phases. Global routing divides the die into rectangles called global routing cells, or gcells, and assigns each net to a path through them. It does not yet decide which track a wire uses. Detailed routing then lays real wires on routing tracks, following the global plan, and adds vias where a wire changes layer. During detailed routing the router runs search and repair: it finds shorts and spacing violations and reroutes the area around them inside a window that grows with each pass.

Two words recur in this chapter. Regular wires are the signal and clock wires that the router creates. Special wires are the power and ground routes made earlier by power planning. The checks treat them differently, so a report must say which of the two it covers.

The key fact for qualification is that detailed routing ends with the best result it could reach, not with a guarantee. It stops on its own when it cannot make further progress. Thus, a finished run can still hold shorts, spacing violations, open nets and antenna violations. This chapter keeps four ideas apart. Tool completion means routeDesign returned. Analysis coverage means the verification commands covered the whole die, every net type and every rule category. Stage qualification means the results meet your project budget. Signoff is a separate, later activity with its own tools and rules, and nothing in this chapter replaces it.

11.2 Entry prerequisites

11.3 Relevant files and analysis context

The checks read the database in memory, and routing settings live in the session. The route log is the second source of evidence, because it records what the router saw while it ran. Keep the log of the routing run with the other results, and note its file name from getLogFileName (Chapter 1).

Four properties of the verification commands shape how you run them. First, verify_drc reports at most 1000 violations unless you raise the limit, and a limit of 0 removes it. A count that equals the limit is therefore a truncated count. Second, set_verify_drc_mode settings are saved in the design and used by every later verify_drc run, so a report is only meaningful together with get_verify_drc_mode. Third, verify_drc checks only placed instances. Fourth, verifyConnectivity and the antenna check overwrite their markers on every run, whereas verify_drc updates its markers incrementally.

Timing after routing depends on the extraction mode. setExtractRCMode -engine postRoute selects detailed extraction, and -effortLevel selects the variant: low is the native engine, medium is TQuantus, high is IQuantus and signoff is standalone Quantus. Defaults depend on the process node and on whether a Quantus technology file is defined. Record the engine and the effort level with every timing report. A timeDesign -postRoute run uses native detailed extraction by default, so set the effort level explicitly before the baseline and keep it for every later run.

11.4 Checks and command cards

11.4.1 Pre-stage checks

check_design -type route -out_file <f>
check_tracks
getDesignMode -bottomRoutingLayer -topRoutingLayer
getNanoRouteMode -nonDefault
getNanoRouteMode -route_with_timing_driven -route_with_si_driven

11.4.2 Post-stage checks

setNanoRouteMode -route_detail_end_iteration <n>
routeDesign

report_route -summary
reportRoute

verify_drc -limit 0 -report <f>
get_verify_drc_mode

ecoRoute -fix_drc
verify_drc -limit 0 -report <f>

verifyConnectivity -type regular -report <f>

verify_antenna -report <f>
verify_antenna -detailed -report <f>

report_via -regular
report_route -multi_cut

verifyConnectivity -net {VDD VSS} -type special -report <f>
verify_drc -check_only special -report <f>
verifyPowerVia -net {VDD VSS} -report <f>

getExtractRCMode -engine -effortLevel
timeDesign -postRoute -expandedViews -outDir <dir>
timeDesign -postRoute -hold -expandedViews -outDir <dir>

11.5 Required reports, artefacts and how to read them

The route log comes first because it shows how the run ended. The excerpt below is built from the style of a NanoRoute log. Its numbers are illustrative, and the exact layout and field names in your log can differ.

#Start Detail Routing.
#start initial detail routing ...
#number of violations = 412
#start 1st optimization iteration ...
#number of violations = 38
#start 2nd optimization iteration ...
#number of violations = 3
#Complete Detail Routing.
#WARNING (NR) There are 2 open nets.
#List of open nets :
# u_core/net_a
# u_core/net_b
#
#Total wire length = 340827 um.
#Total half perimeter of net bounding box = 298122 um.
# number of DRC violations = 3
# By Layer and Type:
#            MetSpc  Short  EolOpp  Totals
#   Metal2        0      1       0       1
#   Metal3        1      1       0       2
#   Totals        1      2       0       3

Read the excerpt from the bottom up. Two nets are open, which is a hard stop on its own: those nets have no complete route, whatever the violation count says. The three remaining violations are two shorts and one parallel-run spacing violation, all on Metal2 and Metal3. Shorts are the more serious kind, because they join two nets.

The trend is healthy. The count fell from 412 to 38 to 3, so each pass made progress, which is the pattern the router is designed to show. A count that stalls instead points to congestion or a data problem. Finally, the wire length is 340827 divided by 298122, or about 1.14 times the half perimeter. That ratio is a sanity number, not a limit. Compare it with the previous route of the same design, and look at the nets with the largest individual ratios if it jumps.

11.6 Healthy, suspicious and hard-stop examples

11.7 Debugging, corrective action and reruns

Group the violations before you fix any of them. The location and type usually point to the cause, and one cause can account for hundreds of markers.

11.7.1 Worked example: a short between two nets

Suppose D-04 reports one short. Figure 14 is a small model of the cause and of what the router does about it. It removes the offending shape, which is called ripping up, and routes the net again around the obstacle. Every wire in the new route sits on a track centre, and each via has a dark cut with metal enclosing it on both layers. The enclosure is what makes a via use routing space beyond its cut.

The ledger shows why a repair is not free. Net B is now two pitches longer and carries two extra vias. Each extra via adds resistance, and a longer wire adds capacitance, so the timing of net B has changed. The repair also moved net B onto M2 track t2, one pitch from net C and, between c5 and c6, one pitch from net A. In this example that spacing is legal. In a real design, the rules decide.

The command sequence is short. Report before the repair so that you can compare, then repair and recheck on the whole die.

verify_drc -limit 0 -report drc_before.rpt
ecoRoute -fix_drc
verify_drc -limit 0 -report drc_after.rpt
verifyConnectivity -type regular -report conn_after.rpt

Notice what the sequence does not do. It does not clear the markers first, because ecoRoute -fix_drc works from them. It does not trust the repair either. The reference says the command returns to its starting snapshot if the count would increase, so a repair that returned silently looks the same as one that did nothing. Compare the counts in the two reports. The decision after the recheck: if both reports show zero, D-04 and D-06 pass. Then rerun D-03 and D-07 to D-10, because the new vias and wire change antenna, via and timing results. If the count stays above zero, stop and look at congestion near the marker before you try again.