RSZ: new resistance-aware move for repairSetup

[openroad-ci]

Summary

ResAwareMove is a new timing repair move type in the rsz module that improves setup timing by selectively rerouting critical nets onto lower-resistance layers via the Global Router (GRT). It integrates with repair_timing -setup as a first-class optimization move rather than a whole-flow routing mode, and adds a dedicated RESAWARE phase to the multi-phase repair framework.

Changes

OpenROAD

New: rsz/src/ResAwareMove.cc / ResAwareMove.hh

Implements the ResAwareMove class derived from BaseMove. The doMove method:

1. Guards: Rejects the move if the driver pin or net is missing, the instance is marked don't-touch, the net is a special net, or the net is already resistance-aware routed.
2. Fast pre-filter: Calls GlobalRouter::getFRNetResistance() (current routing resistance from the FastRoute Steiner tree) and GlobalRouter::getFRNetResistanceOnMinClockLayer() (estimated resistance if all wire segments were placed on the minimum clock layer). Rejects the move if the estimated resistance reduction is below a 40% threshold, avoiding unnecessary incremental reroutes.
3. Accept: Marks the net as resistance-aware (setNetIsResAware), adds it to GRT's dirty-net list, and invalidates its parasitic cache. The physical reroute is deferred to the next estimate_parasitics_->updateParasitics() call.

Modified: rsz/src/RepairSetup.cc

• repairPathResAware: New function that expands a timing path, ranks all driver nodes by descending wire delay, and tries ResAwareMove on each in order, returning after the first accepted move.
• repairSetup_ResAware: New phase implementation. Iterates over violating endpoints and calls repairPathResAware for each, using the shared repairEndpoints loop. Tracks iteration counts and progress identically to the existing LEGACY and LAST_GASP phases.
• setupMoveSequence: When the explicit sequence contains RES_AWARE, ResAwareMove is added to the move list only if global routing is present (haveRoutes). In the default (empty) sequence, it is prepended before UnbufferMove when resistance-aware mode is enabled.
• Phase dispatch: RESAWARE is registered as a valid phase name in the phase-iteration loop, alongside LEGACY, WNS, TNS, ENDPOINT_FANIN, STARTPOINT_FANOUT, and LAST_GASP.
• Progress table: The iteration progress table includes a "ResAware Nets" column reporting the count of nets rerouted by ResAwareMove.

Modified: grt/src/GlobalRouter.cpp / FastRoute

• getFRNetResistance(db_net): Returns the current routing resistance of a net computed from the existing FastRoute Steiner tree.
• getFRNetResistanceOnMinClockLayer(db_net): Estimates resistance assuming all horizontal/vertical wire segments are placed on the minimum clock layer (or minimum routing layer if no clock layer is set), preserving via resistances from actual layer transitions. Uses the existing Steiner topology without triggering a reroute.
• getNetResistanceOnLayer(db_net, layer) (FastRouteCore): Walks the existing Steiner tree edges and accumulates wire resistance using the specified layer's R/sq values.
• setNetIsResAware / isNetResAware: Per-net flag in the GRT Net object controlling whether the net is force-rerouted via the resistance-aware scoring path on the next incremental route.

New: Regression Tests (rsz/test/)

• repair_setup_res_aware1.tcl: Tests ResAwareMove as the sole move in the sequence (-sequence "res_aware") on ASAP7 GCD.
• repair_setup_res_aware2.tcl: Tests the dedicated RESAWARE phase.
• repair_setup_res_aware3.tcl: Tests ResAwareMove included automatically in the default sequence via the -resistance_aware flag.
• Corresponding .ok golden output files for CMake/Bazel regression.

ORFS (flow/scripts/global_route.tcl)

The post-GRT repair_timing call can be used in different ways:

1 - Including the ResAwareMove at the start of the default move sequence with the default phases.

repair_timing_helper -resistance_aware

2 - The RESAWARE phase runs first to flag high-resistance critical nets for rerouting before conventional sizing and buffering moves.

repair_timing_helper \
  -phases "RESAWARE LEGACY LAST_GASP" 

3 - The RESAWARE phase runs first. Then the convetional phases run with res_aware included in the sequence.

repair_timing_helper \
  -phases "RESAWARE LEGACY LAST_GASP" \
  -sequence "res_aware,unbuffer,vt_swap,sizeup,swap,buffer,clone,split"

Type of Change

• New feature

Impact

ResAwareMove introduces a targeted per-net decision made inside the timing repair loop: only nets where routing on a better layer is estimated to reduce resistance by at least 40% are marked for resistance-aware rerouting.

Verification

• I have verified that the local build succeeds (./etc/Build.sh).
• I have run the relevant tests and they pass.
• My code follows the repository's formatting guidelines.
• I have included tests to prevent regressions.
• I have signed my commits (DCO).

[github-actions]

clang-tidy review says "All clean, LGTM! 👍"

[gemini-code-assist]

Code Review

This pull request introduces a resistance-aware rerouting capability to the resizer, allowing for improved timing closure by rerouting nets that exhibit high resistance. The implementation includes a new ResAwareMove class, updates to the GlobalRouter to support resistance-aware routing, and integration into the repair_timing command. My feedback is that the magic number 0.40f used as a threshold for resistance reduction should be replaced with a named constant to improve code maintainability.

[gemini-code-assist]

The constant 0.40f (kMinResistanceReduction) is a magic number. It would improve maintainability and clarity to define this as a named constant, perhaps in a configuration file or a dedicated constants header, to make its purpose explicit and easily modifiable.

References

1. Define tunable parameters as named constants instead of using hardcoded magic numbers.

[jfgava]

I think this could be set with a TCL parameter in the future. The 0.4 value is ok for Rapidus and Asap7, but may not be ideal for other PDKs

[povik]

I propose renaming to RerouteMove as a user-friendly name

[jfgava]

I propose renaming to RerouteMove as a user-friendly name

Agree, we should rename it.
RerouteMove, LayerPromoteMove,...

[github-actions]

clang-tidy review says "All clean, LGTM! 👍"

[github-actions]

clang-tidy review says "All clean, LGTM! 👍"

[jfgava]

@povik Eder and Cho also approved your suggestion. So it is now called RerouteMove. I've already made the necessary changes in the code

[github-actions]

clang-tidy review says "All clean, LGTM! 👍"

[eder-matheus]

Looks good on the GRT side. I'll let @precisionmoon and @povik do the review on the resizer part.