rsz: repair_timing -effort policy (tapeout|explore)

[oharboe]

repair_timing has one built-in policy: work toward tape-out closure. During design space exploration that is the wrong policy — on WNS-dominated designs setup repair grinds for hours toward targets it cannot reach, and hold repair spends hours inserting buffers that carry no exploration information (hold closes at any clock period). Users end up hand-rolling workarounds out of slack margins and skip flags, per stage, per design.

This PR adds repair_timing -effort <directives>: a policy interface analogous to the compiler driver -O flags (POLA). The caller states intent; the tool owns the mapping to its internal heuristics. Directives compose left to right and a later directive overrides an earlier one, like -O0 -O2. Two directives are defined:

• tapeout (default) — the exact historical behavior.
• explore — setup repair may stop when its marginal progress plateaus; hold repair is not run. An explicit -hold to the right of -effort explore re-enables it.

The plateau heuristic behind explore is a strawman. The ask of this PR is not the heuristic: it is that we agree OpenROAD accepts the policy interface and the responsibility for the mapping behind it. Graded levels between the two (-O1/-O2/-Os analogues) are intentionally not introduced; that is left for people who understand those use cases.

Resolution is implemented in rsz::EffortPolicy with a gtest unit test; tapeout reproduces the previous hardcoded values bit-for-bit, so behavior without -effort is unchanged.

Measured on the nightly CI of an industrial RISC-V design at three sizes of the same microarchitecture (S/M/L), route stage (global route + repair_timing). Before = the hand-rolled bounding workarounds that design carried (per-stage slack margins, skip flags); after = those replaced by the explore semantics of this PR. Detailed routing downstream is unchanged between the two runs (~100 min at S in both), the delta is repair:

design	global route + repair, before	after	WNS before	after
S	140 min	52 min	−284 ps	−358 ps
M	226 min	104 min	−470 ps	−560 ps
L	317 min	not measured	−479 ps	not measured

The two runs are one night apart on actively developed RTL, so the WNS deltas include design churn (S's TNS improved while its WNS regressed); the runtime deltas are the policy.

[gemini-code-assist]

Code Review

This pull request introduces a new -effort option to the repair_timing command, providing a coarse optimization policy with directives like tapeout and explore to control setup and hold repair heuristics. Feedback on these changes highlights a few critical issues: the use of a C++20 defaulted comparison operator in EffortPolicy.hh which is incompatible with the project's C++17 standard, a potential glob-matching vulnerability in the Tcl argument parsing, and an uninitialized repaired_hold variable in Resizer.tcl that could trigger Tcl runtime errors when the explore directive is used.

[maliberty]

For the UI I would prefer low/medium/high to tapeout/explore. Its more descriptive of what the tool is doing rather than prescriptive of the user (a user could explore with high effort if they want).

[oharboe]

For the UI I would prefer low/medium/high to tapeout/explore. Its more descriptive of what the tool is doing rather than prescriptive of the user (a user could explore with high effort if they want).

This does not capture that hold should not be fixed in explore.

[oharboe]

The reasoning of tapeout and explore flags is to communicate intent and that OpenROAD uses this to shape policy. low/mid/high are orthogonal

[gadfort]

I think low/medium/high would be more in line with how I would think about it

[oharboe]

I think low/medium/high would be more in line with how I would think about it

For, tapeout, yes.

For exploration, hold should not be repaired. For tapeout low hold repair effort makes sense to me

[oharboe]

@gadfort @maliberty I actually tried implementing low/mid/high first, but ran into a wall: designing a working effort policy (especially for hold) without first defining the goal is extremely hard, and adding those keywords today would just create misleading no-op flags. The hold repair_timing algorithm is especially sensitive to the accuracy that grt provides, so it is an O(n^2) algorithm, best as I could understand with the help of Claude.

That led me to realize that explore vs tapeout communicates intent, which is orthogonal to effort (low/mid/high) — much like -Os (size intent) is orthogonal to -O2/-O3 (speed effort) in GCC/Clang. Communicating intent orthogonally is the right long-term architecture, and we should eventually support both.

By letting the user state their intent (explore vs tapeout), OpenROAD can pick the right policy:

• For explore: The hold policy becomes simple: don't run it (per discussions with Matt, hold cells shouldn't be part of exploration).
• For tapeout: Hold repair runs toward full timing closure.

Once we build an actual policy mechanism for effort levels, we can layer low/mid/high on top as orthogonal options.

[maliberty]

I think you are trying to force one use model that may not be as universal as you think. Not all estimators will agree on how much effort to expend.

[oharboe]

I think you are trying to force one use model that may not be as universal as you think. Not all estimators will agree on how much effort to expend.

So any thoughts on how to capture the intent?

Without intimate knowledge of every niggling little step and algorithm, such as that there exists no termination policy for hold in exploration.

In recent news, exploration with AI is an important use-case...

[gadfort]

can you just use repair_timing -setup to avoid the hold fixing?

[oharboe]

can you just use repair_timing -setup to avoid the hold fixing?

The ask here is for a tapeout/explore policy, not a list of a bizillion options and long turnaround times to discover by reading the source code, trying and failibg what those options should be tweaked to for my design.

[oharboe]

Or as Andrew Kahng said: NHIL. No human in the loop.