[oharboe]

With -resistance_aware, on an asap7 block that routes without overflow (61,321 nets):

	before	after
FastRoute finalisation	62.1 s	32.4 s
period at global route	992.1 ps	993.3 ps (+0.12 %)
period with the pass skipped entirely		1,004.2 ps

Without -resistance_aware nothing changes.

Why

After a 2D route without overflow, FastRoute reroutes in 3D twice, edges under 40 gcells and then under 12. Resistance-aware routing lifts both thresholds, so both passes rip up every edge of every net with negative slack; the second pass only widens the resistance-aware set from 30 % of the critical nets to all of them. On the block above that was 58.8 of FastRoute's 60.5 s, and 31,030 of the 37,198 nets ripped up in the first pass were not resistance-aware: rerouted with the legacy cost on a route with no overflow to relieve.

Change

One commit: with resistance-aware routing on, the final 3D pass runs once, on the nets resistance-aware routing selected (res_aware_nets_only_ in mazeRouteMSMDOrder3D).

The result is not identical

It reroutes fewer nets on purpose, so routes and timing move. The question for review is whether +0.12 % period on the block above, inside an opt-in mode, is acceptable for half the finalisation time.

Tests

• TestResistanceMode: an unselected net routed on M3 keeps its route through the pass; control: the same net is rerouted onto M1 with resistance-aware routing off.
• res_aware_nets_percentage and resistance_aware_asap7_fr goldens regenerated: wirelength 24,782 -> 24,984 um on the first; TNS -2,619.2 -> -2,626.5 ps, WNS unchanged, on the second.
• repair_design6, repair_setup_reroute1 and repair_setup_reroute2 (rsz) no longer diff a log: they check that the reroute reroutes nets and fixes the slew and capacitance violations, or improves WNS and TNS. Without the reroute, the reroute check fails.
• All grt tests pass.

The integration test, with the measurement, is The-OpenROAD-Project/bazel-orfs#1490.

🤖 Generated with Claude Code

[gemini-code-assist]

Code Review

This pull request introduces the 'finalMazeRoute3D' method to handle final 3D maze routing, optimizing the process when resistance-aware routing is enabled by only rerouting selected nets. It also includes comprehensive unit tests and updates to test golden files. The review feedback suggests minor code improvements: using 'std::move' to avoid copying a local vector, explicitly casting a variable to prevent narrowing conversion warnings in tests, and aligning function definition parameter constness with its declaration for consistency.

[jfgava]

We need to be careful here. I did a similar experiment before. The multiple maze3D calls significantly improve timing QoR on some private designs. Especially when we have many critical nets and not enough resources for everyone on the upper layers. We do a better job when slowly promoting critical nets in multiple steps. I can run some private tests to see the real impact.

[oharboe]

@jfgava Thank you for the direction. I'm closing this PR, it sounds like whatever is done, it will be something different than this.

[oharboe]

@jfgava confirmed on a small asap7 block (Uncache from XiangShan, 74k cells): global route alone from its CTS result, with 3D pass variants behind a switch. Upper-layer capacity has to be short and many nets critical for the second pass to matter. As the block comes, almost no net has negative slack, so I tightened the clock to 850 ps (S1), then also squeezed M8–M9 to 0.9 adjustment (S2), the most that still routes without 2D overflow.

	nets rerouted (pass 1 + 2)	period at grt	TNS	finalisation
S1, master	11,256 + 8,474	960.8 ps	−141,467 ps	24.0 s
S1, this PR (one pass)	2,314	962.7 ps	−144,869 ps	13.5 s
S1, two passes, selected nets only	2,314 + 3,622	960.6 ps	−141,208 ps	22.8 s
S2, master	17,693 + 16,465	1,005.9 ps	−244,868 ps	34.0 s
S2, this PR (one pass)	3,225	1,006.5 ps	−245,056 ps	16.4 s
S2, two passes, selected nets only	3,225 + 6,604	1,006.0 ps	−244,657 ps	30.3 s

Period and TNS are deterministic; finalisation is the best of three runs on a shared machine.

• One pass costs about 2 ps and 2.4 % TNS once many nets are critical, as you said.
• Keeping both passes but skipping the unselected nets matches master's QoR and saves 5–11 % of finalisation: the selected nets do most of the search.
• Each pass also carries a fixed cost of about 4 s on this block, even when it reroutes no net; probably the slack update at its start, not examined.

Closed stays closed.