stt: faster PD nearest neighbors with shared-coordinate handling

[maliberty]

Summary

Builds on #11351 by @gzz2000, which replaces the O(n²) Prim-Dijkstra nearest neighbor search with the double monotone chains algorithm from "Provably Optimal Planar Pareto Nearest Neighbor Search with Double Monotone Chains" (Guo et al, DATE'26). Their commits are kept on this branch.

The paper assumes distinct coordinates. Pins often share x or y (rows, sites, macro edges), and there the chain walk linked every pair of pins on a vertical line: 499,500 edges for 1000 pins instead of 999. This PR fixes that:

• Neighbors are defined by an empty closed bounding box, so a pin on the boundary also excludes the pair. This is safe for PD: routing through such a pin w changes the cost by (α−1)·d(u,w) ≤ 0.
• Coincident pins are merged and linked to the first pin at their location.
• Pins are swept a column of equal x at a time. Column mates are linked to each other and bound the rows that can hold left neighbors.
• Each staircase step is found with a max segment tree over rows instead of chain pointers. Chain pointers can need O(k) updates per inserted pin when a column has k pins.
• Neighbor lists are sorted, so the PD search no longer depends on the order the sweep found them.

The search moves to src/stt/src/pdr/src/neighbors.{h,cpp}. A new gtest, TestNeighbors, compares it against a brute-force search on tie-heavy random inputs and covers collinear, grid, column-plus-staircase and duplicate-pin cases. It is registered in both CMake and Bazel.

Impact

With distinct coordinates the neighbor sets are identical to the old code. With shared coordinates the sets are smaller. On 10k pins:

input	old entries	new entries	old time	new time
random	311,093	310,692	271 ms	22 ms
rows/sites	391,053	159,238	127 ms	9 ms
100×100 grid	1,019,700	39,600	57 ms	1 ms
vertical line	19,998	19,998	53 ms	1 ms

The pd1 and pd_gcd goldens only change which of two coincident pins carries a connection. Wire length and path depth are unchanged for every net. ORFS QoR has not been run yet.

[gemini-code-assist]

Code Review

This pull request introduces a new pdr_neighbors library implementing an efficient double monotone chains algorithm for nearest neighbor search, replacing the previous O(N^2) implementation in pd.cpp. It also adds comprehensive unit tests and updates build configurations and test expectations. The review feedback focuses on performance optimizations in neighbors.cpp, including adding fast-path checks in the segment tree queries, replacing std::make_tuple with direct coordinate comparisons in the sorting comparator to avoid overhead, and pre-reserving capacity for the column rows vector to prevent redundant reallocations.

[maliberty]

@gzz2000 I would be interested in your feedback on Claude's solution to the aligned points issue from your PR.

[oharboe]

This is a really neat optimization. Prim-Dijkstra brings back memories from university, and seeing it get a provably optimal neighbor search with proper handling of shared coordinates is very cool.

I was curious what the impact would be on XiangShan, so I looked at per-step perf profiles I had lying around from master on XSTile (asap7, about 4 M nets, 48 threads). This is how much of each step is in the Steiner tree code:

step	samples in pdr::	in any Steiner code (stt, Flute, pdr)
3_4_place_resized	0.3 %	0.3 %
3_5_place_dp	1.0 %	1.2 %
4_1_cts	0.4 %	1.0 %
5_1_grt	0.1 %	0.1 %
estimate_parasitics -placement	0.2 %	0.3 %

[maliberty]

You need a very high fanout net to see a big benefit but some designs have those (eg global reset).

[oharboe]

We tried this on XiangShan (KunMingHu, asap7, hardened per block) and saw little effect. Here's why, in case it helps anyone else measuring it.

XiangShan's reset is asserted asynchronously and released synchronously. In the generated Verilog, 994 always blocks are @(posedge clock or posedge reset) and none uses a synchronous if (reset). The release is pipelined by ResetGen (3 flops) and the AsyncResetSynchronizers, but those sit in XSTop and at the clock-crossing queues, outside the tile. Inside each hardened block, reset is therefore one very-high-fanout net with a pin on every flop: the case you describe.

It only stays that way until the first repair_design, though. We cap fanout at 32 with set_max_fanout, so the resizer breaks reset into a buffer tree of small nets. After that, CTS, global route and detailed route never see a high-fanout net. The faster search only gets used on the few Steiner trees built for the whole unbuffered net, during timing-driven global placement and that first repair_design. Going by the table above, that's seconds, against stages that take hours.

We also false-path reset (set_false_path -from [get_ports reset]). For now we treat reset as a solved problem that isn't interesting to study, so we keep its recovery/removal checks out of the timing picture. We may come back to it later. It isn't why we see little effect, though: the net is still estimated and buffered with its full fanout.

We'd expect a large benefit where a high-fanout net stays unbuffered: an ideal network, dont-touch, or a flow with no fanout limit.

[gzz2000]

I re-run part of the flow regression locally on the latest pdr-dbl-monotone commit (I had to ln -s ~/install/OpenROAD/bin/openroad ./build/bin/ before I run, which looks a bit hacky. Also I could not run it without the flow while it is documented to run all tests. Maybe I missed some configurations or the README documentation is stale).

There are cases that do not pass. Looks like one of them is a numerical difference:

zizhengg@5900ea8871e9:~/OpenROAD$ ./test/regression flow
------------------------------------------------------
Flow
gcd_nangate45 (tcl) pass
gcd_sky130hd (tcl) pass
gcd_sky130hd_fast_slow (tcl) pass
gcd_sky130hs (tcl) pass
gcd_asap7 (tcl) pass
ibex_sky130hd (tcl) *FAIL* DRT::max_slew_slack  -6% <  -6%
ibex_sky130hs (tcl) pass
aes_nangate45 (tcl) pass
aes_sky130hd (tcl) *FAIL* DRT::ANT::errors   1 >   0
aes_sky130hs (tcl) pass
aes_asap7 (tcl) pass
tinyRocket_nangate45 (tcl) pass
...

I think a segment tree to handle shared-coordinates handling (as done by Claude) is a bit overkill for this problem.

If our goal is a deterministic result and to avoid time complexity degradation on ties, an easier solution exists: we can run the algorithm on tie-breaker-embedded coordinates, such as letting x' := (x coordinate, y coordinate, pin id), y' := (y coordinate, x coordinate, pin id).

If we want to match the original brute force exactly: the original algorithm also has its quirks. Notably, its neighbor relations might be asymmetric (A->B does not imply B->A). Maybe we don't need to replicate that completely?

[maliberty]

Identical replication of the brute force result is not essential.

[maliberty]

From Claude on your suggestion:

Thanks for the suggestion. I tried it: your chain walk on rank coordinates x' = (x, y, id), y' = (y, x, id). It's correct (it's a superset of the closed-box neighbor set) and it fixes the vertical line. But the tie-break acts like a diagonal shear: x + εy, y + εx. Pins on the box edge move inside for lower-left/upper-right pairs and outside for upper-left/lower-right pairs. So the anti-diagonal pairs blow up. At 10k pins: a 100×100 grid gives 1.98M entries (this PR 39.6k, old O(n²) 1.02M) and rows/sites gives 1.20M (this PR 83k). Using one shear per direction would make each direction exact. But the upper-left and lower-left walks share chain pointers, so each pass would still step through the other direction's bad links, about O(n^1.5) on grids. The segment tree keeps both directions output-sensitive. I agree we don't need to match the brute force exactly; the closed-box relation here is two-way. I'll look into the ibex/aes flow differences.

[maliberty]

The ibex delta is just noise in detailed routing.

[maliberty]

I've looked at the secure CI results and there are some variations but nothing noteworthy.