repair-timing-grt

Goal

Get a trustworthy answer about repair_timing at global route: whether it grinds, why, and whether a proposed change moves it. Three traps below have each wasted hours-long runs; avoid all three before drawing any conclusion.

Trap 1 — a skip-repair / fast grt measures nothing about repair

When the question is about repair_timing (the grt grind/timeout, hold- or setup-buffer insertion), do NOT use a fast/skip-repair grt flow (SKIP_INCREMENTAL_REPAIR=1, SKIP_CTS_REPAIR_TIMING=1, or a grt_skiprepair-style extract). It skips repair_design / repair_timing entirely — it only global-routes and estimates parasitics — so a clean, fast exit tells you nothing about whether repair grinds. Using it to "test the grind" is structurally meaningless.

The fast-grt flow is built for clock skew / parasitic re-measurement, where skipping repair is exactly what you want. For anything about repair, run the FULL grt with repair enabled (SKIP_INCREMENTAL_REPAIR=0).

Trap 2 — repair_timing needs the live global-route structures

repair_timing must run inside global_route.tcl, on the pre-GR ODB. It needs the live global-route structures (GR grid, congestion, routing guides) that are not persisted in the saved post-GR ODB. So you cannot bolt repair_timing onto a saved post-GR ODB in a fresh session — it must happen in the same openroad session as global_route, which is exactly what global_route.tcl does:

# (shape of the flow script)
global_route
if { !$SKIP_INCREMENTAL_REPAIR } {
  repair_design_helper
  repair_timing_helper
}

To test repair on a modified netlist, stage the PRE-GR ODB (the CTS-stage output) into the grt extract and run the grt stage with SKIP_INCREMENTAL_REPAIR=0, so global_route rebuilds the structures and repair runs live. Do NOT reuse a saved post-GR ODB.

Trap 3 — split the grind into setup vs hold before blaming either

The grind can be setup-dominated (a large count of setup-violated endpoints at negative clock slack — a design far from setup closure) or hold-dominated (many hold endpoints → many hold buffers), and the two want completely different fixes. A hold-side fix does not touch a setup-dominated grind, and vice versa.

Before trusting any grt result about repair, always:

1. Confirm repair_timing actually ran — grep the log for repair_timing, RSZ- messages, and Took N seconds: repair_timing. If absent, a SKIP_* flag routed around it (Trap 1).
2. Split setup vs hold — read the setup-violated vs hold-violated endpoint counts and the setup- vs hold-buffer counts from the RSZ messages. Attribute the runtime to whichever dominates.
3. Reconcile your hypothesis against the split. If you framed the problem as a "hold pathology" but the measured grind is setup, the framing is wrong — fix the attribution before proposing a hold fix.

Note on the effort dial

repair_timing -effort low|medium|high instruments the setup phase's marginal-progress stop (it bails out of a non-convergent setup grind early). It does not currently have an equivalent knob for the hold phase, and hold repair is generally harder to bound than setup — so do not expect -effort low to shorten a hold-dominated grind. See the deps-preflight skill for confirming which effort actually reaches the tool.

Pairs with byo-openroad (iterate on a repair change) and orfs-deps-preflight (validate the code path before the hours-long run).