Routing, Post-Route Optimization, Checks and Handoff: from estimates to routed wires

Why this chapter matters in a real project

Until now, the data wires in every timing report were estimates. Routing draws the real ones: metal shapes on specific layers, joined by vias, on tracks, around obstacles. Those shapes have length, resistance, capacitance and neighbors that the estimate never saw. So the slacks move.

In our example, one setup path loses 0.125 ns between estimate and route. A hold path that looked safe turns negative. Routing also creates new things to check: spacing, shorts, opens and antenna violations.

The cost of getting this stage wrong is high in both directions. If you read stale or partial reports, you hand off a design with real violations that finishing then has to unpick. If you chase every number without a diagnosis, you waste runs. Worse, you break one check while fixing another.

Prerequisites

• Clock Tree Synthesis, Post-CTS Optimization, Checks and Handoff: the starting point is its accepted checkpoint. Clock trees are built, clocks are propagated, post-CTS setup and hold were read, and a handoff note exists.
• Placement, Pre-CTS Optimization, Checks and Handoff: you know what a legal placement and a macro halo are.
• Power Planning: you know that the power grid takes routing tracks on some layers.
• You do not need to know how the router's internal algorithms work.
• You do not need signoff extraction or signoff timing. Those come in later stages.

The worked example is the invented design stream_acc. It has a 1000 x 1000 um core, two RAM macros u_buf_a and u_buf_b, and one ROM macro u_coef. The main clock clk_core has a 2.5 ns period. Time is in ns, distances in um and capacitance in pF.

Learning objectives

1. Describe what routing changes in a database, what it leaves alone, and which evidence shows each change.
2. Tell a route guide from detailed wiring, and a global-route result from a routable design.
3. Set layers, rules, clock-net protection, and timing-driven and crosstalk-driven routing with native commands, then read the settings back.
4. Read a congestion count as demand against capacity, find its cause, and change the cause rather than the symptom.
5. Inspect a detailed route for completion, design-rule violations, antenna violations, clock-route integrity, detours and vias.
6. Explain why routed wires change setup and hold slack, and measure the change against a baseline.
7. Apply setup, hold and electrical repairs in an order that protects each from the others, and state what each repair costs.
8. Read the timing, electrical, violation and connectivity reports, say what each one does not prove, and recognize a stale report.
9. Debug from a symptom to a confirmed cause, then classify the candidate as clean, accepted with documented exceptions, or not ready.

The whole stage fits on one page, in Figure 1. Come back to it whenever you lose your place.

Routing and post-route on one page

Two phases: route and inspect, then measure, repair and decide

What to notice: Phase A ends with a saved checkpoint, and every Phase B candidate is measured against the R0 baseline.

1  Where routing fits

Until now, the data wires in the timing report were estimates. The clock wires were whatever clock tree synthesis had routed. Routing now draws the real signal wires. That changes three things: timing, the set of checks, and how hard the database is to change.

1.1  The handoff from the previous stage

This chapter uses that note as input, but not blindly. You restore the checkpoint and check what came back, as "Confirm the starting checkpoint" shows.

The flow in Figure 2 runs from that checkpoint to finishing.

The two phases of this chapter

Phase A routes and inspects; Phase B extracts, optimizes, reports and decides

What to notice: The routed checkpoint is saved at the end of Phase A, so every Phase B experiment can start from it.

1.2  What routing adds

Routing adds signal wires and vias. For clock nets, it adds the clock wires that were reserved earlier. By itself, routing does not move cells, change the clock tree or alter the power grid. Repairs such as antenna diodes can add cells, though.

Each of those has a different consequence, and the evidence for each is different.

1.3  Why routed parasitics change timing

These effects are not small. In our example, one path loses 0.125 ns between estimate and route. A hold path that looked safe turns negative (see "Extract and assess").

1.4  Two phases

Finishing comes after both phases: fillers, decoupling cells, metal fill and signoff checks. Finishing can reopen timing. Thus this handoff is a stage decision, not a signoff.

Phase A: Routing

2  Confirm the starting checkpoint

Routing makes the physical database much harder to change. Some defects are cheap to fix before routing: an illegal cell, a missing clock rule, a broken power connection. After routing, each becomes an ECO (engineering change order). Spend ten minutes here to avoid a day later.

2.1  Restore, replay and read back

Restore the checkpoint and look at what came back. Do not rely on your memory of what was saved.

Start a new Innovus session for every restore. The tool does not support loading another database while a design is already in memory. This chapter does not use an unload command. So when a later step says "restore", close the session and start a fresh one.

innovus> restoreDesign handoff_cts.enc.dat stream_acc ;# load the post-CTS checkpoint

innovus> source site_setup.tcl ;# replay the approved site setup
innovus> getAnalysisMode ;# print the analysis mode
innovus> getExtractRCMode ;# print the extraction mode
innovus> getDelayCalMode -SIAware ;# is delay calculation crosstalk-aware?
innovus> all_analysis_views -type setup ;# list the active setup views
innovus> all_analysis_views -type hold ;# list the active hold views
innovus> check_timing -verbose > start_check_timing.rpt ;# look for missing constraints

innovus> checkPlace ;# are all cells still legally placed?
innovus> check_design -type route ;# the routing readiness check
innovus> report_clocks -generated ;# list clocks, including generated clocks
innovus> timeDesign -postCTS -outDir timing_start -prefix start ;# starting setup
innovus> timeDesign -postCTS -hold -outDir timing_start -prefix start ;# starting hold

• check_design -⁠type route is the routing readiness check. Run it before routeDesign, and read its messages.
• checkPlace confirms that the cells still have legal locations.
• report_clocks -⁠generated lists the clocks, including generated clocks, with their definitions and waveforms. That is constraint-level evidence. It shows what the clocks are meant to be. It does not show that they are propagated, or that the routed clock wires are intact. Those come from the timing and clock-wire reports later.
• The two timeDesign calls run early global route and extraction on this checkpoint. They give you the starting numbers, on estimated wires, that Phase B is compared with.
• They also generate the default electrical reports for maximum transition and capacitance. Read those reports now: they are the starting electrical record.

2.2  What blocks routing, and what proceeds with tracking

Not every finding stops the flow. Table 1 separates the findings that block routing from the ones you track and carry forward.

3  Routing essentials

Every routing decision in this chapter rests on six ideas: tracks, layers, vias, guides, capacity and rules. Learn them once on small drawings. The congestion and violation cases later then read as simple counts.

3.1  Tracks and layers

A routing layer has a preferred direction. For example, odd layers might run horizontally and even layers vertically, or the reverse, depending on the technology. Wires normally sit on tracks: evenly spaced lines in that direction, one wire wide.

Most regular routing follows the preferred tracks. Off-track geometry can exist. However, it must still satisfy the manufacturing grid, the technology rules and the routing policy. A wire in the wrong direction is legal in some technologies, but it uses resources fast, so the router avoids it.

Low layers are thin and narrow, so they are resistive and good for short local wires. High layers are wide and thick, so they are fast and good for long wires. That is a tendency, not a law. It is why timing repair often promotes long nets upward, and the benefit depends on the technology.

3.2  Vias

A via joins two adjacent layers. It is a cut with metal enclosure on both layers. Its footprint takes routing space through both the enclosure and the cut spacing. A via also has resistance of its own.

Route topology balances wire RC, via RC, pin access, design rules and reliability. So a layer change is sometimes the better choice and sometimes the cost.

Figure 3 shows a net that changes layer twice, and a second net that only crosses it.

A layer change, from above and from the side

Net X climbs M3 to M4 to M5; net Y crosses on M4 with no via

What to notice: A crossing is not a connection. Only a cut with enclosure on both layers joins two layers.

3.3  Guides, then wires

A guide does not give legal tracks or physical wire and via geometry. Global routing can still account for layers, as the 3D congestion report shows.

Figure 4 is a simplified 2D projection of the same net at both stages.

A guide and its detailed route

Same net, same coordinates, two stages

What to notice: The guide is not metal. The same five gcells become three wires and four vias.

3.4  Capacity and demand

overflow = max(0, demand - capacity)

With several layers, add up the positive overflows. Spare tracks on another layer do not cancel a blocked layer. Overflow means some wire must detour, change layer, or become a violation.

Figure 5 shows the arithmetic on one gcell edge.

Demand and capacity on one gcell edge

Eight wires want to cross; a second layer adds two tracks

What to notice: The arithmetic is the whole mechanism: 8 - 6 = 2, then 8 - 8 = 0.

3.5  Rules and blockages

The router obeys design rules from the technology: minimum width, minimum spacing, minimum area and via enclosure. Non-default rules (NDRs) give selected nets wider wires or more spacing, such as the clock rule from clock tree synthesis.

Blockages remove tracks from a region. A blockage helps when it protects something. It hurts when it is stale and nobody remembers why it was placed.

4  Prepare the routing configuration

Left alone, the router uses defaults. Those defaults do not know your clock rules, your timing priorities or your antenna fix. Each setting below answers one question. Set it before routing, read it back, and write down what you changed. A setting you did not read back is only a setting you intended.

4.1  Which layers may signal nets use?

innovus> setDesignMode -bottomRoutingLayer M2 -topRoutingLayer M7 ;# signals on M2-M7

The layer names are examples. In this invented design the approved top layer is M7. The residual M7 tracks are approved for signals after the power-ground reservations. The congestion case in the next section depends on that. A blockage removal cannot make a layer usable above a hard top bound. So the bound and the capacity table have to agree.

innovus> setAttribute -net clk_core_trunk1 -bottom_preferred_routing_layer 5 \
    -top_preferred_routing_layer 6 -preferred_routing_layer_effort high ;# layers 5-6

• Meaning. Wires of this net prefer layers 5 to 6. The effort says how hard the router tries: low, medium, high or hard.
• Net names. Use the actual physical net names from the clock tree, such as clk_core_trunk1. The token @CLOCK names the clock-net class. This chapter does not rely on a @CLOCK|name form. It does not apply one setting to every clock net without saying so. Repeat the command for each net you mean to protect.
• Cost. A strong preference pulls wires onto a limited number of layers, which concentrates demand there.
• -⁠avoid_detour true asks global routing to keep the net from wandering. It is a request, not a guarantee, and it can add congestion elsewhere.

4.2  How do the clock nets stay as they were built?

innovus> setNanoRouteMode -route_strict_honor_route_rule true ;# harden NDR spacing
innovus> setNanoRouteMode -route_route_clock_nets_first true ;# clock nets first
innovus> setNanoRouteMode -route_fix_clock_nets true ;# keep clock net status

• -⁠route_strict_honor_route_rule true hardens NDR spacing only. The router can still taper a wire or use default vias. So read the clock wire and via reports after detailed route, rather than assume the rule held everywhere. The default false lets the router use extra NDR space when congested.
• -⁠route_route_clock_nets_first true is a routeDesign context option. It needs clock routing that NanoRoute, the Innovus router, already made. It does nothing for clock wires that came from elsewhere.
• -⁠route_fix_clock_nets true applies to routeDesign only. It preserves the status that clock nets already have. It does not make them FIXED (a route status that tells the router not to change the net).

This chapter's main flow runs globalRoute and detailRoute separately. The two routeDesign options above control the alternative flow. Setting them is context, not proof that the clock was preserved in the split flow. Validate the clock with the physical clock reports after detailed route and on the final candidate.

Clock wires that do not move during routing can still move later. Post-route optimization can repair clock design-rule violations through ccopt_pro. That is a clock-tree optimization step it can call. "The clock did not move" is a measurement, not an assumption.

4.3  Should routing watch timing and crosstalk?

innovus> setNanoRouteMode -route_with_timing_driven true ;# slack as a priority
innovus> setNanoRouteMode -route_with_si_driven true ;# reduce crosstalk

• -⁠route_with_timing_driven true tells the router to treat slack as a priority. It routes critical sinks first, with less resistance and coupling, and tunes detours. It writes a timing file in the working directory.
• -⁠route_with_si_driven true reduces crosstalk (SI, signal integrity) by spacing and layer choice. Together with the timing option, this is the combined routing mode, sometimes called SMART routing.
• Cost. Both options add runtime. They do not replace post-route optimization. They lower the work that the setup and hold repairs must do later.

4.4  How should antenna violations be fixed?

An antenna violation is charge collected on a long wire during manufacturing that can damage a connected gate. By default the router fixes it by layer hopping. It moves the long run up a layer, so less metal is attached at each manufacturing step. It can also insert a diode near the gate.

innovus> setNanoRouteMode -route_detail_fix_antenna true ;# repair antennas
innovus> setNanoRouteMode -route_antenna_diode_insertion true ;# allow diode insertion
innovus> setNanoRouteMode -route_antenna_cell_name ANTENNA_X1 ;# example diode cell name

• The antenna-fix default is auto, which acts like true only on data nets in routeDesign. Confirm with -⁠help in your installation which option carries that default. Set true explicitly for full effect.
• Antenna repair needs three things. The first is LEF (library exchange format) antenna data for the layers. The others are a real diode cell with a placeable site, and free space near the gate. If the technology data is missing, an antenna check that finds nothing is a coverage failure, not a clean result.
• Clock nets are separate. Diode insertion on clock nets needs -⁠route_diode_insertion_for_clock_nets, which is false by default. This chapter leaves it off and reports clock antennas as their own item.
• Cost. A diode costs one cell and one pin on the net. Layer hopping costs vias and a little congestion. Choose by what your block can afford.

4.5  How many vias, and how many cuts?

innovus> setNanoRouteMode -route_detail_use_multi_cut_via_effort medium ;# more cuts

The values are low (the default), medium and high. Higher effort means more double cuts. Double cuts help yield and resistance, but they cost runtime and congestion.

4.6  Blockages

createRouteBlk places a routing blockage, and deleteRouteBlk removes one by name and layer. Both belong to the partition-floorplanning command set. No command in this flow prints all existing route blockages.

To find out which blockages exist, read the floorplan record or open the layout view. A blockage that you did not create and cannot explain is a finding for global route.

4.7  Read the settings back

innovus> getDesignMode -bottomRoutingLayer ;# read the lowest routing layer
innovus> getDesignMode -topRoutingLayer ;# read the highest routing layer
innovus> getAttribute -net clk_core_trunk1 ;# read the per-net attributes
innovus> getNanoRouteMode ;# read the router modes

getDesignMode reads the global layer bounds, getAttribute the per-net attributes, and getNanoRouteMode the router modes. Keep the output with the candidate. When two candidates differ, the first question is whether their settings were the same.

5  Global route and congestion

Global route is cheap and fast. It shows where the design will struggle before any metal is drawn. Congestion that you find here costs one rerun. The same congestion found as hundreds of violations after detailed route costs a day.

5.1  Run global route and read the congestion

innovus> globalRoute ;# build a guide for every signal net
innovus> reportCongestion -overflow ;# report gcell overflow
innovus> reportCongestion -hotSpot -3d ;# report hotspots, layer by layer

• reportCongestion -⁠overflow reports overflow.
• reportCongestion -⁠hotSpot -⁠3d is meant for global-route hotspots, so it suits the state after globalRoute. The -⁠3d option asks for layer-based congestion.
• You can also read the congestion from the layout view or the log.

gcell (412 380)        V: 0/6/20         H: -3/0/23

The "capacity 23, demand 26" used below is hypothetical bookkeeping from the layer table in the congestion case. Keep it separate from anything a tool prints.

5.2  A congestion case: the channel between the two RAMs

In stream_acc, the horizontal count above sits in the narrow channel between u_buf_a and u_buf_b. Every wire that crosses from the left half of the design to the right passes there. Let us follow it from symptom to intervention.

Evidence. Overflow of 3 on the horizontal tracks of the channel. Total capacity 23, demand 26.

The M7 row is the finding. The blockage covers 8 tracks that nobody uses for power. Its name suggests an old floorplan keep-out. Nobody on the team can say why it is still there.

innovus> deleteRouteBlk -name blk_m7_chan -layer 7 ;# remove the stale M7 blockage

The blockage name and layer are examples. Resulting evidence. Capacity becomes 14 + 9 + 8 = 31. Demand is still 26, so overflow is 0 and the utilization is 26 / 31 = 84%. Rerun globalRoute and reportCongestion -⁠overflow to confirm that the gcell no longer appears.

Figure 6 draws the channel before and after the fix.

The channel between the two RAMs

Each square is one track slot across a cut line in the channel; demand is 26 wires

What to notice: Removing one blockage adds 8 slots and ends the overflow: 26 / 31 = 84% used.

6  Detailed route and inspect

6.1  Run detailed route

innovus> detailRoute ;# draw wires and vias on tracks
innovus> saveDesign routed_raw.enc ;# save before any repair

Save before you repair. If the repair makes things worse, you can come back here.

6.2  Inspect the routed result

innovus> set_verify_drc_mode -limit 1000 ;# stop listing after 1000 violations

innovus> verifyConnectivity -type all -error 50 -warning 50 ;# opens, unrouted, loops
innovus> verify_drc -report A_drc_first.rpt ;# design rules on routed geometry
innovus> verify_antenna -report A_antenna_first.rpt ;# antenna ratios on routed nets

These habits keep the reports honest.

• Cap. -⁠error 50 stops the listing at 50 messages. If a run prints exactly 50, read it as "at least 50", not "50". -⁠type all is the connectivity check family. It is not LVS (layout versus schematic), and it is not every power-ground port check.
• Mode. set_verify_drc_mode settings persist. A later bare verify_drc uses them and would overwrite a report name set there. So this chapter names each report on the verify_drc call itself, with a name that carries the stage or candidate. Write the options you set into the record.
• Scope. The default check scope check_only is not all checks. The NDR spacing mode auto is not the same as asking for NDR spacing explicitly with verify_drc -⁠check_ndr_spacing. If NDR spacing is part of the question, ask for it.
• Prerequisites. verify_antenna needs antenna data in the LEF. With no data it has nothing to compare. An empty list then means "not checked", not "clean".

Is every net connected?

Begin Summary
  Open      : 0
  Unrouted : 0
  Loop      : 0
End Summary

Decision. Any open or unrouted net blocks the handoff. Does not prove: that the wires are legal, only that each net joins its pins.

Are the design rules met?

Violation Type         Count
Short                      3
Metal Spacing              6
Min Area                   2
Total                     11

The first pass in this example shows 11 violations. Your count will differ. What matters is whether the violations are local or clustered. Figure 7 shows three of the findings you meet most often.

Spacing, short and open

Three findings on the same kind of M3 wires

What to notice: In a short, both nets are wrong. Each finding has its own repair.

Repair design-rule violations with ecoRoute -⁠fix_drc. It fixes the existing markers only. It reports an error if open nets exist, so settle connectivity first. Also make sure the markers are current: the verify_drc above just made them. Clear nothing by hand, run the check again, and compare the counts.

innovus> ecoRoute -fix_drc ;# repair the current DRC markers
innovus> verifyConnectivity -type all -error 50 -warning 50 ;# recheck connectivity
innovus> verify_drc -report A_drc_second.rpt ;# recheck design rules, new report name

In the example, the count goes from 11 to 0. Any physical repair can disturb the other checks. So connectivity, DRC (design rule check) and antenna checks all rerun after the last repair. Do not rerun only the check that prompted it.

If the count does not reach 0, go to "Debug common failures". Do not run ecoRoute -⁠fix_drc repeatedly and hope. A violation that survives two passes has a cause, and the cause is rarely in the router's effort.

Is the antenna clean?

Net n_7781   layer M3   ratio 512.0   limit 400.0   VIOLATION
Net n_9020   layer M4   ratio 431.0   limit 400.0   VIOLATION
Total antenna violations: 2

The limit is a property of the technology, not a number to adopt. The mechanism is simple. A long wire built on a low layer collects charge before the layer above it exists. The fix attaches less metal at that step (layer hopping) or gives the charge a path (a diode).

Figure 8 compares the two antenna fixes side by side.

An antenna violation and its two fixes

Before, layer hop and diode, on the same driver and gate

What to notice: Layer hopping costs vias and a little congestion. A diode costs one cell and a pin on the net.

innovus> deselectAll ;# start with an empty selection
innovus> selectNet {n_7781 n_9020} ;# select the two antenna nets
innovus> detailRoute -select ;# reroute only the selected nets
innovus> deselectAll ;# clear the selection again
innovus> verifyConnectivity -type all -error 50 -warning 50 ;# recheck connectivity
innovus> verify_drc -report A_drc_third.rpt ;# recheck design rules
innovus> verify_antenna -report A_antenna_second.rpt ;# recheck antenna

The net names are the example's. In the example both violations clear, 2 to 0, and the rerun connectivity and DRC stay clean. If they did not, the reroute would have traded one problem for another.

Are the clock routes intact?

innovus> report_net_wires -net clk_core_trunk1 -file wires_trunk1.rpt ;# trunk 1
innovus> report_net_wires -net clk_core_trunk2 -file wires_trunk2.rpt ;# trunk 2
innovus> report_via -on_clock_nets -detail ;# via details on clock nets

• Look for: the width rule and layer on each wire piece, the shield status, and the via cut counts.
• Repeat the first command for every net on the intended clock-net list from the post-CTS handoff. The two names here are examples, not the whole population.
• Decision. Compare with the clock rule and layer policy from clock tree synthesis. A documented, approved change is acceptable. An unexplained difference means you reroute the clock nets before going on.
• This is the Phase A record. Post-route optimization can change clock wires, so the same checks are repeated on the final candidate.

Did anything take the long way around?

innovus> report_route -multi_cut ;# routing statistics with multi-cut via share

For a specific net, open the layout view of the path studied in "Extract and assess". Note a route much longer than the straight pin-to-pin distance, or one that jumps through many layers. Such a route is a finding, not necessarily a fault. A detour around a macro is correct if the straight way is blocked.

6.3  Checkpoint summary for Phase A

innovus> saveDesign routed.enc ;# save the inspected routed checkpoint

Phase B: Post-route optimization

7  Extract and assess

You cannot repair what you have not measured. You cannot call a repair good without a baseline either. Extraction turns the drawn wires into resistance and capacitance. Timing analysis on those numbers is the first honest timing result of the flow. Save it as candidate R0 before you change anything.

7.1  Configure extraction and the analysis

The multi-mode multi-corner (MMMC) setup comes from the project: views, libraries, RC technology and derates. It was validated when you confirmed the starting checkpoint. This block does not define it. Set the analysis type first, because SI needs it. Then set extraction and SI, then read everything back.

innovus> setAnalysisMode -analysisType onChipVariation -cppr both ;# OCV, remove CPPR
innovus> setExtractRCMode -engine postRoute -effortLevel low -coupled true ;# routed RC
innovus> setDelayCalMode -SIAware true ;# include crosstalk in delay calculation

innovus> getAnalysisMode ;# read the analysis mode back
innovus> getExtractRCMode ;# read the extraction mode back
innovus> getDelayCalMode -SIAware ;# read the SI setting back

• -⁠engine postRoute extracts from the real wires. -⁠coupled true includes coupling capacitance between neighbors, the third effect from "Where routing fits". Coupled extraction is the default for the post-route engine.
• -⁠effortLevel low selects the native extractor. Higher levels select other extractors, and some need their own license or a signoff setup. Check what your site uses. Implementation extraction is not signoff extraction.
• -⁠analysisType onChipVariation -⁠cppr both analyzes with on-chip variation (OCV). It removes the common-path pessimism (CPPR) that the launch and capture clock paths share. The best-case/worst-case analysis type can be optimistic with crosstalk, so do not use it here.
• -⁠SIAware true makes delay calculation include crosstalk. It needs the MMMC setup with on-chip-variation analysis.
• timeDesign -⁠postRoute and optDesign -⁠postRoute enable SI by default, unless it was explicitly set to false. Thus an SI-off diagnostic left in a session silently stays off. Restore the exact setting afterwards, and never accept an SI-off run as evidence.
• Each getter reads one interface. getExtractRCMode does not report the analysis views. The required and active views come from all_analysis_views and the report headers.

innovus> timeDesign -postRoute -expandedViews -numPaths 200 \
    -outDir timing_route -prefix R0 ;# setup on routed wires
innovus> timeDesign -postRoute -hold -expandedViews -numPaths 200 \
    -outDir timing_route -prefix R0 ;# hold on routed wires
innovus> saveDesign routed_R0.enc ;# save the baseline candidate

timeDesign -⁠postRoute runs the native detailed extraction itself. It does not run early global route. The expanded views give you one report per analysis view.

7.2  The baseline

Everything in Phase B is measured against the R0 column. Setup and hold both went from passing to failing. The electrical counts were not recorded at the start of Phase A in this table. The post-CTS electrical reports still had to be reviewed, though. R0 is where this chapter begins counting them.

7.3  Why one path lost 0.125 ns

required time = 0.650 + 2.500 - 0.080 - 0.050 = 3.020 ns

Path 1: VIOLATED Setup Check with Pin u_out/res_reg_3/D
  Launch clock latency      0.640
  Clock-to-Q                0.210
  Logic cells               1.835
  Wire (base RC delay)      0.395
  Crosstalk delta (SI)      0.025
  Arrival time              3.105
  Required time             3.020
  Slack                    -0.085

Check the arithmetic: 0.640 + 0.210 + 1.835 + 0.395 + 0.025 = 3.105. The layout of a real report differs, and the values here are invented. What matters is that you can find the same four groups in your report: cells, wire, crosstalk and the clock terms. The split of the wire term into base RC and a separate crosstalk delta is a simplified bookkeeping view.

A longer wire is slower for two reasons at once. Resistance grows with length, and so does capacitance. So for an isolated uniform wire, its own RC term grows faster than linearly. Buffering, loading, layer changes and coupling change the path total, so treat this as a tendency. It is one reason a detour can hurt more than its extra length suggests.

Figure 9 shows the wire part: the same net, estimated and routed.

One net, estimated and routed

A simplified straight estimate of 320 um against a routed detour of 455 um

What to notice: Wire delay 0.330 became 0.395, plus 0.025 of coupling: +0.090 ns from the wire. With +0.035 from the cells, slack +0.040 becomes -0.085. Real early-route estimates can see obstacles, but still differ from final geometry.

Coupling needs its own picture, because it works in both directions. Setup analysis assumes the neighbor makes the victim slower. Hold analysis assumes it makes the victim faster. Each check must hold in its own worst case. On P1 the slow case adds 0.025 ns. On the hold pair, a same-way neighbor speeds the edge by 0.022 ns. Figure 10 shows the geometry and both effects.

Coupled neighbors

Three parallel M3 wires: a victim between two aggressors

What to notice: The victim tends to be slower when the neighbor switches the other way, and faster when it switches the same way. Setup takes the slow case and hold the fast case, when the switching windows can overlap.

Subtract the launch latency and the clock-to-Q from the required time. The rest is the data path's budget: 3.020 - 0.640 - 0.210 = 2.170 ns. Any data delay above that is negative slack.

Figure 11 puts the three versions of P1's data delay side by side against the budget.

The data delay of path P1, three times

Pre-route, routed and repaired, against a budget of 2.170 ns

What to notice: The routed bar crosses the budget by 0.085. The repaired bar, from "Optimize setup", is back under it.

7.4  The limits of this evidence

8  Optimize setup

Setup repair that starts with the command instead of the diagnosis wastes runs. Four different causes can produce the same negative slack, and each has a different cheap fix. Find the cause on the worst path, then let the tool repair the rest.

8.1  Diagnose before repairing

Two of the four are repairable at this stage: the driver and the layers. The detour stays. Moving a macro or its halo reopens two earlier stages: Placement, Pre-CTS Optimization, Checks and Handoff and Clock Tree Synthesis, Post-CTS Optimization, Checks and Handoff. Name the detour in the acceptance record instead of fighting it.

8.2  Repair

innovus> setOptMode -opt_setup_target_slack 0.0 ;# setup target slack of 0.0 ns
innovus> optDesign -postRoute -outDir timing_route -prefix S1opt ;# post-route repair

• By default, optDesign -⁠postRoute runs with setup priority, so no extra option is needed.
• It is not setup-only. The default run also repairs design-rule violations and glitch (crosstalk noise) violations. That is why the electrical counts can move here too.
• It optimizes in the analysis views together, and it routes the changes it makes.
• The -⁠prefix only names the report files. It neither restores nor creates a checkpoint.

innovus> setAttribute -net n_p1 -bottom_preferred_routing_layer 5 \
    -top_preferred_routing_layer 6 -preferred_routing_layer_effort high ;# prefer 5-6
innovus> deselectAll ;# start with an empty selection
innovus> selectNet n_p1 ;# select the stubborn net
innovus> detailRoute -select ;# reroute only that net
innovus> deselectAll ;# clear the selection again

innovus> extractRC ;# extract parasitics from the current wires
innovus> timeDesign -postRoute -expandedViews -numPaths 200 \
    -outDir timing_route -prefix S1 ;# fresh setup numbers
innovus> timeDesign -postRoute -hold -expandedViews -numPaths 200 \
    -outDir timing_route -prefix S1 ;# fresh hold numbers
innovus> verifyConnectivity -type all -error 50 -warning 50 ;# recheck connectivity
innovus> verify_drc -report S1_drc.rpt ;# recheck design rules
innovus> verify_antenna -report S1_antenna.rpt ;# recheck antenna
innovus> report_constraint -all_violators > S1_constraints.rpt ;# list all violators

Check: 1.775 + 0.365 = 2.140. Arrival is 0.640 + 0.210 + 2.140 = 2.990. Required is 3.020, so slack is +0.030. The difference 2.255 - 0.115 = 2.140 confirms the saving.

8.3  What this repair costs

• Area and power. A larger driver is a larger cell with more input capacitance, which loads the previous stage.
• Routing resources. A net that moves to M5 and M6 uses tracks that other nets wanted. In a congested region, this can create overflow that was not there before.
• Hold. A faster data path has a shorter minimum delay. On a net with a hold-critical short path, speeding up the data path can make hold worse. Read hold again after setup repair. Here it is unchanged at -0.022.

Figure 12 shows the same routed path before and after the two repairs.

The same routed path, before and after

Left: weak driver, low layers. Right: stronger driver, wires on M5 and M6

What to notice: The detour around the macro is unchanged, because in this example the macro also blocks M5 and M6. Delay was recovered by driving the wire harder and moving it to faster layers.

innovus> saveDesign routed_S1.enc ;# save candidate S1

9  Hold and electrical repair

Hold repair and electrical repair both add cells. Each can take slack from setup. This section shows how, with one worked pair of paths. Then it separates electrical repair from timing repair, because they answer different questions.

9.1  Why routed wires expose hold

A hold check asks whether new data arrives too early, while the capture flop still needs the old value. The data must not arrive before the capture clock edge plus the hold time. Hold uses the minimum delay of the data path. So it is sensitive to everything that makes a path faster: shorter wires, a neighbor switching the same way, a sharper slew.

Let us consider the worst hold pair, from flop FF1 to flop FF2. It runs through a two-input AND gate, where the short FF1 path meets the long FF3 path. When the FF1 arc is timed, the FF3-side input is assumed to be 1 (non-controlling), and the other way around. So both arcs through the AND gate are timed. The gate delay is inside the path delays below. In the example, FF1 is u_acc/acc_reg_4 and FF2 is u_io/io_reg_9.

The launch clock arrives at 0.640 and the capture clock at 0.890. So the capture clock is 0.250 later than the launch clock. That skew is the reason hold is tight: data has to survive 0.250 ns of extra waiting. Hold time is 0.040 and uncertainty is 0.020, so:

required time = 0.890 + 0.040 + 0.020 = 0.950 ns

Estimates are often pessimistic about wires on short paths. Routing can remove that pessimism, which tends to help setup and hurt hold.

The 0.020 is a delay inside the path. It is not a change to the hold time of FF2. Slew at the capture pin can change the library hold requirement. That is a different term, on the required-time side, and a sharper slew does not always improve it.

Figure 13 draws the same numbers on one time axis.

The hold pair on one time axis

Launch at 0.640, capture at 0.890, required time 0.950 ns

What to notice: The routed arrival lands before the required time of 0.950, so hold slack is 0.928 - 0.950 = -0.022.

9.2  The repair and what it takes from setup

The usual hold repair is a delay cell: a cell that adds delay and does nothing else. Put one in the fast corner and the pair is fixed. A delay cell of 0.050 in the fast corner gives -0.022 + 0.050 = +0.028.

However, the same cell sits where other paths share it. In this example it sits at position H1, on the net between the AND gate and FF2. The long path from FF3 also passes there. The cell is slower in the slow corner, where setup is checked: it costs 0.080 there. The long path had slack +0.075, so now it has 0.075 - 0.080 = -0.005.

Hold repair with the default settings in the tool is allowed to do this. The option that controls it is -⁠opt_hold_allow_setup_tns_degradation. Its default is true, meaning setup TNS may get worse while hold is fixed. Setting it to false protects setup TNS only. It is not a promise about setup WNS or about every path, so read the setup numbers again afterwards.

Figure 14 shows both positions of the delay cell.

A hold fix that costs setup

FF1 drives the short path and FF3 the long path; both meet at an AND gate before FF2

What to notice: One cell helps one check and costs margin in the other. A cell on a shared net is paid for by every path through it.

C2 restarts from S1, not from H1. H1 is an experiment that did not protect setup, so it is not a parent. Start a new session and restore the saved S1 checkpoint (the reason is in "Confirm the starting checkpoint"). Replay the site setup and read the analysis modes back. Database identity alone does not prove identical analysis settings.

innovus> restoreDesign routed_S1.enc.dat stream_acc ;# restore S1 in a fresh session
innovus> source site_setup.tcl ;# replay the approved site setup
innovus> getAnalysisMode ;# read the analysis mode back
innovus> getDelayCalMode -SIAware ;# confirm SI is on
innovus> setOptMode -opt_hold_allow_setup_tns_degradation false ;# protect setup TNS
innovus> setOptMode -opt_hold_target_slack 0.0 ;# hold target slack of 0.0 ns
innovus> optDesign -postRoute -hold -outDir timing_route -prefix C2hold ;# repair hold

site_setup.tcl is the example name for the site-owned procedure. -⁠opt_hold_target_slack sets the hold target. Zero is only a starting value: write down the target your project uses, and why.

In the example, the hold repair with the default produces candidate H1. H1 has hold WNS +0.028 and TNS 0, but setup WNS -0.005, TNS -0.005 and one endpoint. Running it from S1 with the protection on leads to C2. There the cell goes at position C2, on the FF1 branch before the gate. Only the short path pays for it. C2 is a candidate only after its final state is saved and measured.

9.3  Electrical repair is a separate question

Maximum transition and maximum capacitance are not timing checks. They are limits that a pin must not exceed, no matter what the slack is. A cell driving a long wire can produce a slow edge. That edge can make the next cell misbehave, even if the path meets setup. These limits are often called DRV (design rule violation) limits in optimization commands.

innovus> report_constraint -drv_violation_type {max_transition max_capacitance} \
    -all_violators > C2hold_electrical.rpt ;# transition and capacitance violators

max_transition   n_4412  limit 0.300 actual 0.342 slack -0.042 VIOLATED
max_capacitance  n_6035  limit 0.080 actual 0.091 slack -0.011 VIOLATED

R0 has 7 transition and 3 capacitance violators. The excerpt above stands for R0, not for C2hold. Setup repair fixes most of them as a side effect. The cause is often the same: a weak driver on a long wire.

S1 has 2 transition and 0 capacitance violators. The two remaining transition violators need a different repair, because their cause is not delay. In this example the hold cells add no new capacitance violation. The default optDesign -⁠postRoute also repairs design-rule violations, so your own counts can differ.

innovus> optDesign -postRoute -drv -outDir timing_route -prefix C2drv ;# tran and cap

The two prefixes, C2hold and C2drv, keep the two stages' reports apart. Why a separate stage? It targets exactly two limits, and it is not a setup or hold repair. So after it, you read setup, hold and the electrical counts again from the same state. Do not assume that fixing one set leaves the other alone.

10  Reroute, re-extract and repeat

Every repair changes the database, and every change needs a fresh measurement. The way to stay in control is to treat each repair as a candidate. A candidate is a saved database with its own reports, compared with the one before. A repair that makes the next number worse is discarded, not patched on top.

10.1  What a repair leaves behind

10.2  One compact comparison

That is a trade, and it is visible because the candidates were kept. Figure 15 draws the same history as a tree.

Before you save C2, produce its fresh evidence. Run the C2 reports of "Reporting: timing, electrical, rules and connectivity", then save.

One candidate per step

R0 to S1, then a fork: H1 (discarded) and C2, both from S1

What to notice: C2 is not a child of H1. It is a separate branch of S1.

innovus> saveDesign routed_C2.enc ;# save candidate C2

10.3  Which saved state does each experiment start from?

10.4  When to stop

The last case is common. If every remaining setup violator crosses the same macro channel, the repair is in floorplan or placement. It is not necessarily in a fourth optDesign run.

11  Reporting: timing, electrical, rules and connectivity

Each decision in this chapter rests on a report, and each report answers one question. Reports come before debugging for two reasons. You cannot debug a symptom you have not read correctly. And most debugging starts with the question "which report is that number from?".

11.1  Views and constraint completeness

innovus> all_analysis_views -type setup ;# list the active setup views
innovus> all_analysis_views -type hold ;# list the active hold views
innovus> check_timing -verbose > C2_check_timing.rpt ;# constraint completeness

• Plain English. The first two commands list the active setup and hold views. You compare them with the project's required list. check_timing reports missing or unpropagated clocks, unconstrained endpoints and incomplete I/O delays. It accepts -⁠view for a per-view report.
• Decision. A required view that is not active blocks acceptance. Every warning is fixed or recorded as intentional.
• Does not prove: that the constraints are correct, only that they are present. A default call does not enable every warning class. The coverage report below complements this check; it does not replace it.

11.2  Timing

innovus> timeDesign -postRoute -expandedViews -numPaths 200 \
    -outDir timing_final -prefix C2 ;# final setup summary
innovus> timeDesign -postRoute -hold -expandedViews -numPaths 200 \
    -outDir timing_final -prefix C2 ;# final hold summary
innovus> report_timing -late -max_paths 5 -nworst 1 > C2_setup_paths.rpt ;# setup paths
innovus> report_timing -early -max_paths 5 -nworst 1 > C2_hold_paths.rpt ;# hold paths

Setup      WNS +0.012         TNS 0.000       Violating endpoints 0
Hold       WNS +0.025         TNS 0.000       Violating endpoints 0

• Plain English. WNS is the worst slack of any path. TNS adds up the worst negative slack of each endpoint across the applicable views, without counting an endpoint twice. So the overall TNS is not the sum of per-view TNS. The endpoint count says how many endpoints fail. State the view scope of every summary you quote.
• Decision. Compare against the project targets, in each analyzed view. A positive WNS in the views that ran passes those views.
• Does not prove: that the views that did not run pass, that signoff agrees, or that the margin survives fill and ECOs.
• Options. -⁠late reports the setup side and -⁠early the hold side.
• Coverage limits. -⁠numPaths 200 limits how many paths are listed, not how many endpoints were analyzed. -⁠expandedViews reports only the views that are active. Five paths from report_timing are a spot check, not a full review. Reports go to the log unless you redirect them, so the files above carry the candidate name.

11.3  Coverage

innovus> report_analysis_coverage -verbose {violated untested} -sort reason \
    > C2_coverage.rpt ;# met, violated and untested checks

Check type       Total     Met     Violated   Untested
Setup            4020      4002         0         18
Hold             4020      4008         0         12

• Plain English. Every check is either met, violated or untested. Check: 4002 + 0 + 18 = 4020, and 4008 + 0 + 12 = 4020.
• The same report on R0 would have shown 3971 + 31 + 18 for setup and 3996 + 12 + 12 for hold. Take the coverage from the candidate you are deciding on, not from an earlier one.
• Counts are checks. They are not endpoints, so a violated count need not equal an endpoint count. Dynamic checks are left out unless you ask for them with -⁠include_dyn_checks.
• Decision. Every untested check needs a reason. A tied-off clock, a constant or a disabled arc is a reason. "I do not know" is not.
• Does not prove: that untested means passing. Untested means no result exists.

11.4  Electrical limits

innovus> report_constraint -drv_violation_type {max_transition max_capacitance} \
    -all_violators > C2_electrical.rpt ;# final transition and capacitance violators

11.5  Rules and connectivity

innovus> verifyConnectivity -type all -error 50 -warning 50 ;# opens and unrouted nets
innovus> verify_drc -report C2_drc.rpt ;# design rules of candidate C2
innovus> verify_antenna -report C2_antenna.rpt ;# antenna of candidate C2

verifyConnectivity         Open 0      Unrouted 0
verify_drc                 Total 0
verify_antenna             Total 0

• Plain English. The wires join the right pins, obey the spacing and width rules, and carry no antenna excess.
• Decision. Any open, unrouted net or short blocks the handoff. Design-rule and antenna violations are repaired or documented.
• Scope. Record the set_verify_drc_mode options in force. The default check scope is not all checks, and a -⁠error 50 cap can hide a longer list. A clean verify_antenna also needs antenna data in the LEF.
• Does not prove: that the rules are the ones your foundry signs off. The technology file in the session defines them, and signoff verification is a later stage.

11.6  Clock

innovus> report_clock_timing -type skew -early -view hold_view \
    > C2_clock_skew.rpt ;# clock skew for the hold check

launch clock arrival   u_acc/acc_reg_4     0.640
capture clock arrival  u_io/io_reg_9       0.890
s = capture - launch = +0.250

• Plain English. These are the clock arrivals at FF1 (u_acc/acc_reg_4) and FF2 (u_io/io_reg_9), the hold pair of Figure 13.
• This chapter writes skew as s = capture - launch. So s = +0.250 makes hold harder and setup easier. A report may print its skew with the opposite sign, so convert to this convention before you compare.
• Decision. Compare with the post-CTS record. Whether this skew is intended is in that record.
• Does not prove: anything about data paths. It says nothing about clock topology, wire status, layers, widths, shielding or vias either. A skew number can look the same while the clock wires differ. Check the clock physically, on the final candidate, as below.

innovus> report_net_wires -net clk_core_trunk1 -file C2_wires_trunk1.rpt ;# trunk 1
innovus> report_net_wires -net clk_core_trunk2 -file C2_wires_trunk2.rpt ;# trunk 2
innovus> report_via -on_clock_nets -detail ;# via details on clock nets

Repeat report_net_wires for every net on the intended clock-net list, not for one sample. Compare the rule and layer policy with the post-CTS record. Approved changes are acceptable if they are documented. Literal geometric identity is not required.

11.7  Recognizing a stale report

A stale report describes a database that no longer exists. It looks like any other report. Check these signs before you trust a number. They are triggers for investigation, not proof. Tie freshness to the last change that matters (geometry, netlist, constraints or analysis settings), and to the candidate and configuration identity.

• Time. The report file is older than the last repair or reroute. A saveDesign alone does not change the design, so an older file is only a clue.
• Name. The prefix or folder is not the candidate's. This is why every run in this chapter carries a prefix: R0, S1, C2.
• Extraction. Parasitics were extracted before the last wire change. timeDesign -⁠postRoute extracts fresh. A report from another command might not.
• Views. The report covers different views, or a different analysis mode, from the one you compare against. getAnalysisMode, all_analysis_views and the report header show them. getExtractRCMode shows the extraction mode only.
• A repair with no visible effect. The headline numbers equal the previous candidate's to the last digit. An unrelated local repair can leave the worst slack unchanged, so this is a reason to look, not a verdict.

12  Debug common failures

The debug order

Six steps in a fixed order, with one return path

What to notice: The repair comes fifth. A repair before the distinguishing check is a guess.

12.1  Case 1: persistent congestion or incomplete routing

• Symptom. Overflow remains after global route, or detailed route ends with unrouted nets.
• Evidence. reportCongestion -⁠overflow output with overflow. Where your release supports it after routeDesign, dumpNanoCongestArea lines with negative overflow. verifyConnectivity reporting unrouted nets.
• Competing causes. Capacity lower than it should be (a stale blockage, a wide clock rule). Or demand higher than the region can hold (placement, a macro channel).
• Distinguishing check. Count capacity by layer in the worst gcell, as in the channel case. If capacity matches the layer count, the cause is demand.
• Repair. Capacity: remove a confirmed blockage, or relax a rule only where the owner agrees. Demand: change placement or macro spacing, which reopens Placement, Pre-CTS Optimization, Checks and Handoff.
• Remeasure. globalRoute and reportCongestion -⁠overflow again.

12.2  Case 2: recurring design-rule violations

• Symptom. ecoRoute -⁠fix_drc clears the markers, and the same ones return.
• Evidence. The violation type and layer, repeated at one location or on one net type.
• Competing causes. A rule the router cannot satisfy in this space (a clock NDR in a congested channel). A cell or pin the router cannot access. Or a setting that fights the rule.
• Distinguishing check. Do the violations cluster on the NDR nets? Run the check below and compare. Do they cluster at one macro or cell edge?
• Repair. NDR: give the net its space, or change the rule with the owner. Pin access: change the placement or halo.
• Remeasure. verify_drc with a new report name, and compare counts and locations.

innovus> verify_drc -check_ndr_spacing -report case2_ndr.rpt ;# include NDR spacing

12.3  Case 3: opens and shorts

• Symptom. verifyConnectivity reports opens, or verify_drc reports shorts.
• Evidence. The net names and the marker positions.
• Competing causes. For opens: congestion left the net unfinished, or the net already had FIXED route status. A skip-routing or preservation restriction may also apply. -⁠route_fix_clock_nets is a routeDesign setting. It does not control the split globalRoute and detailRoute flow of this chapter. For shorts: a repair or a guide squeezed two nets together.
• Distinguishing check. report_preserves -⁠obj_type net -⁠dont_touch lists nets with explicit preservation. Add -⁠computed to see preservation that the net inherits. Fixed-route and skip-routing status are separate causes, so inspect them separately. Check whether the open net shows up in any of the three: preserved, FIXED, or skip-routing.
• Repair. Open: route the nets again (deselectAll, selectNet, detailRoute -⁠select, deselectAll), or remove the restriction with its owner. Short: ecoRoute -⁠fix_drc, after connectivity is settled.
• Remeasure. verifyConnectivity, then verify_drc, then verify_antenna.

innovus> report_preserves -obj_type net -dont_touch ;# explicit net preservation
innovus> report_preserves -obj_type net -dont_touch -computed ;# include inherited ones

12.4  Case 4: antenna violations that stay

• Symptom. verify_antenna still lists violations after routing.
• Evidence. Net, layer, ratio and limit.
• Competing causes. The antenna settings were not active (the default acts on data nets only). Or the diode cell name or its site is wrong. Or the LEF has no antenna data, and the check has nothing to compare.
• Distinguishing check. getNanoRouteMode shows the settings. The one-net report below shows that net's layers in detail. Without -⁠nets, -⁠detailed covers all nets and all layers.
• Repair. Set the options, and route those nets again, with the selection cleared before and after.
• Remeasure. verifyConnectivity, verify_drc and verify_antenna, each with a new report name.

innovus> verify_antenna -nets n_7781 -detailed -report antenna_n_7781.rpt ;# one net

12.5  Case 5: setup degrades after route

• Symptom. Slack that passed on estimates fails after routing.
• Evidence. The stage breakdown from "Extract and assess": cell, wire, crosstalk.
• Competing causes. Detour, low layers, weak driver, crosstalk.
• Distinguishing check. Compare the routed length with the straight distance. Read the layers from report_net_wires and the driver transition. Time the path with crosstalk off, as a diagnostic run only.
• SI-off diagnostic, safely. Read getDelayCalMode -⁠SIAware first. Switch SI off for the diagnostic. Then restore the exact prior setting, read it back, and regenerate the baseline report with SI on. An SI-off run is never final evidence.
• Repair. As in "Optimize setup", one cause at a time.
• Remeasure. timeDesign -⁠postRoute, same views.

12.6  Case 6: hold exposed by routed parasitics

• Symptom. Hold passed before routing and fails after.
• Evidence. The minimum delay of the failing path, before and after.
• Competing causes. A shorter wire than the estimate, a neighbor switching the same way, a sharper slew, a changed clock skew.
• Distinguishing check. Break the minimum-delay change into those parts, as in "Hold and electrical repair". Check the clock latencies at both flops, so you know skew did not move.
• Repair. A delay cell on the short branch, or skew if the clock allows it.
• Remeasure. timeDesign -⁠postRoute -⁠hold, and setup.

12.7  Case 7: setup regression after hold repair

• Symptom. Hold is fixed, and a setup path that had margin now fails.
• Evidence. The failing setup path passes through a cell inserted by the hold repair.
• Competing causes. The cell sits on a shared net, protection was off, or the hold target was higher than needed.
• Distinguishing check. List the inserted cells and the other paths that go through each. Check -⁠opt_hold_allow_setup_tns_degradation and -⁠opt_hold_target_slack.
• Repair. Restart from the setup-repaired candidate in a fresh session. Set -⁠opt_hold_allow_setup_tns_degradation to false, which turns the protection on. Lower the target to what the project needs.
• Remeasure. Setup and hold together.

12.8  Case 8: transition or capacitance violations

• Symptom. report_constraint lists maximum transition or capacitance violators.
• Evidence. Net, limit, actual, slack.
• Competing causes. A weak driver on a long wire, or a fanout too high. A wide NDR wire with more capacitance. Or a limit tighter than the library supports.
• Distinguishing check. Net length, fanout and driver cell, and the limit's source.
• Repair. optDesign -⁠postRoute -⁠drv, with its own prefix. A tight limit is a constraint question for its owner.
• Remeasure. report_constraint to a named file, and setup and hold afterwards.

12.9  Case 9: timing stops improving

• Symptom. Successive candidates change a number by less than the noise.
• Evidence. The remaining violators.
• Competing causes. The router and optimizer have exhausted what they can do. Or the violators share a cause upstream: a macro detour, a clock skew, a constraint.
• Distinguishing check. Group the violators by shared structure: the same macro, the same clock, the same path group. report_timing -⁠from and -⁠to narrow it.
• Repair. Go upstream. Another optDesign run with nothing changed upstream is not a diagnosis.
• Remeasure. After the upstream change, start again from R0 of the new database.

12.10  Case 10: reports that do not match the candidate

• Symptom. A number in a report cannot be reproduced.
• Evidence. The file time, header and prefix.
• Competing causes. Stale extraction, wrong restore, wrong prefix, different views.
• Distinguishing check. Restore the saved candidate from a fresh session, replay the site setup, and run the report again.
• Repair. Regenerate every report you rely on.
• Remeasure. The two reports agree.

13  Accept the candidate and hand it to finishing

A candidate that was repaired is not necessarily one that can go forward. No command knows your project's margins, its waivers, or what finishing will do next. The decision uses evidence, and it ends in one of three states.

13.1  Five assessments, kept independent

13.2  Three states

Three acceptance states

Clean, accepted with documented exceptions, and not ready

What to notice: Each state carries text as well as color. "Accepted" is not "clean".

The thresholds that turn a number into a pass belong to your project. This chapter does not set any.

13.3  Worked example: candidate C2

Open nets, shorts and a missing required analysis are not waivable under this chapter's gate. An inherited waiver counts only if it is current, approved and still applicable.

13.4  Save and export what finishing needs

The native checkpoint is the authoritative restart artifact. The netlist and the DEF (design exchange format) file are exchange forms for tools that cannot read it. Use your own names. Say what each file does and does not carry, because the receiving flow depends on it.

innovus> saveDesign handoff_route.enc ;# native checkpoint for restart
innovus> saveNetlist handoff_route.v ;# logical Verilog netlist
innovus> defOut -routing handoff_route.def ;# DEF with routing

• Native checkpoint. It references the libraries, LEF and SDC (timing constraint) files it was built with. It does not copy them, so keep those files, in the same form, with the checkpoint. Extracted RC and timing-graph data are optional, not automatic. Plan to extract and time again after a restore, not to find them waiting.
• Netlist. saveNetlist writes a logical Verilog netlist by default. Add -⁠includePhysicalInst, -⁠includePowerGround or -⁠phys only when the receiving flow asks for them.
• DEF. defOut needs matching technology, cell, via and rule definitions on the receiving side. Net attributes are not saved in DEF. -⁠withShield is a selected-net export option that needs -⁠routing and -⁠selected. It is not a switch that makes a full-block DEF complete, so do not add it to the command above.
• Packaging. Consider saveDesign -⁠libs only if the site's packaging and licensing policy allows it. Do not add export options blindly.

innovus> restoreDesign handoff_route.enc.dat stream_acc ;# restore the handoff candidate
innovus> source site_setup.tcl ;# replay the approved site setup
innovus> getAnalysisMode ;# read the analysis mode back
innovus> getExtractRCMode ;# read the extraction mode back
innovus> getDelayCalMode -SIAware ;# confirm SI is on
innovus> all_analysis_views -type setup ;# active setup views
innovus> all_analysis_views -type hold ;# active hold views
innovus> check_timing -verbose > handoff_check_timing.rpt ;# constraint completeness

innovus> timeDesign -postRoute -expandedViews -numPaths 200 \
    -outDir timing_handoff -prefix handoff ;# setup on the handoff candidate
innovus> timeDesign -postRoute -hold -expandedViews -numPaths 200 \
    -outDir timing_handoff -prefix handoff ;# hold on the handoff candidate
innovus> report_constraint -all_violators > handoff_constraints.rpt ;# all violators
innovus> report_analysis_coverage -verbose {violated untested} -sort reason \
    > handoff_coverage.rpt ;# coverage with reasons
innovus> verifyConnectivity -type all -error 50 -warning 50 ;# connectivity
innovus> verify_drc -report handoff_drc.rpt ;# design rules
innovus> verify_antenna -report handoff_antenna.rpt ;# antenna
innovus> report_net_wires -net clk_core_trunk1 -file handoff_wires_trunk1.rpt ;# clock
innovus> report_net_wires -net clk_core_trunk2 -file handoff_wires_trunk2.rpt ;# clock
innovus> report_via -on_clock_nets -detail ;# clock vias
innovus> report_clock_timing -type skew -early -view hold_view \
    > handoff_clock_skew.rpt ;# hold-side clock skew

The broad report_constraint -⁠all_violators also lists special checks, and its file is named for what it holds. Repeat report_net_wires for the whole intended clock-net list, because post-route optimization can change clock wires. Read the handoff files, not the intermediate ones.

13.5  The handoff note

13.6  The package manifest

14  Before you copy any recipe

This chapter says which commands it uses, and it also says that none of them was run. A reader on a different release needs to know what each claim is, and what to try before trusting a recipe.

14.1  Commands by recipe

14.2  Three kinds of statement

14.3  The smoke test

Do these in a licensed, approved environment, and record what happens.

1. Check each command and option you will use with -⁠help in your installation, and record the build.
2. Restore a disposable copy of an accepted checkpoint in a fresh session. Confirm that every example name (net, layer, cell, view, file name) maps to a real object, and that all dependencies resolve.
3. Try the split globalRoute and detailRoute path, and the routeDesign-only clock settings, separately. Do not infer one command's behavior from another's name.
4. Reproduce the congestion intervention under your real layer bounds. Look at the physical result, not the invented numbers.
5. Try an isolated selected-net reroute, a marker-driven repair and a one-net antenna report. Look for collateral changes.
6. Run one candidate through the site configuration before and after a save and restore, and reconcile the results.
7. Check the final report, database, netlist and DEF package from the receiving side.
8. Keep the logs, report files, configuration and approvals.

You do not need to reproduce the chapter's invented numbers. Report what actually happened.

15  Common mistakes and how to catch them

Most failures at this stage are reading failures, not tool failures. The list in Table 21 collects the ones this chapter warns about, and how to catch each.

16  Interview preparation

Compact glossary

Routing and post-route on one page

Where the next chapter goes, and why

You now hand finishing a routed, extracted and optimized candidate with named evidence. Finishing then adds what this stage left out: fillers, decoupling cells and metal fill, and the signoff checks.

Each of those changes the layout. Fill adds coupling capacitance, and fillers and decoupling cells change the rows. So the next chapter, Chip Finishing and Signoff Handoff, reruns the same evidence discipline on a new candidate. The habits you built here carry straight over. Save a named candidate and measure it fresh. Read each report for what it does not prove, and decide with a record.