PDN/TAP: rows kept at the edge of a macro halo get followpins PDN can't connect (PDN-0179 on asap7/swerv_wrapper)

Subject

Describe the bug

asap7/swerv_wrapper fails PDN with [ERROR PDN-0179] Unable to repair all channels. The cause is a mismatch between TAP's row cutting and PDN's macro halo, and both tools contribute:

• TAP (cut_rows, halo 2 µm) keeps row 73.980–74.250 under macro u38955. The macro's bottom edge is at y = 76.256, so its 2 µm halo starts at 74.256, and the row is kept because Rect::overlaps is strict (74.250 < 74.256).
• PDN creates the VDD followpin (row rail) on that row edge, centred on y = 74.250, 6 nm from its own macro halo (define_pdn_grid -macro -halo 2.0). The M2→M5 via stack extends 14–23 nm on each side of the rail, so it would sit 8–17 nm inside the halo, and PDN doesn't place it.

Here the rail is the top row of a narrow slot between two fakeram7_256x34 (about 10 µm apart) capped by a fakeram7_2048x39 32 nm above them. No other strap crosses it, so it stays unconnected. The repair strap needs the same via, so channel repair fails as well. All three remaining channels follow this pattern, one under each big RAM.

Expected Behavior

Every row that TAP keeps should end up with followpins PDN can connect, so PDN completes without leaving channels. Either TAP shouldn't keep a row whose boundary rail can't be connected next to a macro halo, or PDN should handle that case. Without that, PDN should at least report the macro and rail involved, instead of a generic channel-repair failure.

Environment

Git commit: d921a700771dfa70a3ae567fe420bdbc2ade2b15
OpenSTA commit: 84c4d7e133d3b1a54352c97c6a5df3140c71c78c

To Reproduce

Attached: pdn0179_swerv_wrapper_repro.tar.gz (the macro-placed floorplan from the failing run, asap7's grid_strategy-M1-M2-M5-M6.tcl, and run.tcl, which runs tapcell with the 2 µm halos and then pdngen).

tar xzf pdn0179_swerv_wrapper_repro.tar.gz && cd repro_pdn0179
openroad -exit run.tcl                      # fails: PDN-0178 x3, PDN-0179
ROWS_HALO_Y=2.03 openroad -exit run.tcl     # row halo 30 nm above the PDN halo: passes

Full flow: ORFS 0b56643596 with OpenROAD d921a70077, then make DESIGN_CONFIG=designs/asap7/swerv_wrapper/config.mk floorplan. It has failed in every nightly since https://jenkins.openroad.tools/job/OpenROAD-flow-scripts-Nightly-Public/7659

pdn0179_swerv_wrapper_repro.tar.gz

Relevant log output

[INFO ODB-0303] The initial 1093 rows (5977617 sites) were cut with 28 shapes for a total of 7401 rows (3087383 sites).
[INFO PDN-0001] Inserting grid: top
[WARNING PDN-0178] Remaining channel (208.8180, 72.0330) - (214.8120, 77.7210) on M2 for nets: VDD
[WARNING PDN-0178] Remaining channel (227.7720, 72.0330) - (237.4920, 77.7210) on M2 for nets: VDD
[WARNING PDN-0178] Remaining channel (269.4060, 72.0330) - (275.4000, 77.7210) on M2 for nets: VDD
[ERROR PDN-0179] Unable to repair all channels.

Screenshots

No response

Additional Context

• Trigger: #11830 slightly changed floorplan repair_timing (+0.06 µm² std-cell area), which moved the macros into this layout. #11830 isn't at fault; any small change can do the same.

To discuss:

• TAP: should cut_rows make sure every kept row's boundary rails can be connected, instead of only checking row/blockage overlap?
• PDN: PDN creates a followpin its own halo makes impossible to connect. Should it handle this case, or at least report it precisely?
• We'd prefer an automatic fix over a new user-facing option.