PDN ring on macro grid: via still not inserted between Metal5 and TopMetal1 despite overlapping geometry (IHP SG13G2)

[RakshithSuresh2001]

Integrating a real SRAM macro (IHP RM_IHPSG13_1P_1024x32_c2_bm_bist, single-port, 1024x32) into a design on IHP SG13G2, via LibreLane (Classic flow). The macro's power pins (VDD!, VSS!, VDDARRAY!) sit on Metal4. The design's main power grid only reaches TopMetal1 (vertical) / TopMetal2 (horizontal). A via layer connecting Metal5 to TopMetal1 exists in the tech LEF (TopVia1), so bridging Metal4 -> Metal5 -> TopMetal1 should be architecturally possible.

What I've tried

A straight add_pdn_stripe on the macro grid at Metal5 never worked, regardless of halo width (tried 10um default, 40um, 90um) or macro X-position. Root cause I believe I found: TopMetal1's vertical stripes get obstruction-avoided across the macro's entire Y-height, and a horizontal Metal5 stripe confined to that same Y-band can never intersect real TopMetal1 geometry no matter how far it extends in X.

Switching to add_pdn_ring on the macro grid (segments on all four sides, so top/bottom edges extend past the obstructed Y-band) got real improvement: unconnected VPWR/VGND nodes dropped from ~2000+ to 343, "no via inserted" warnings dropped from ~700+ to 15. But one specific floating shape remains stuck: a Metal5 segment on VGND, exactly at the bottom edge of one macro instance's ring.

The specific stuck case

Direct .odb inspection (via OpenROAD Tcl scripting) confirms real TopMetal1 geometry does exist overlapping this exact region, so it's not a missing-geometry problem. -fixed_vias {TopVia1} fails immediately with PDN-1021 Unable to find via: TopVia1 (the raw LEF cut-layer name apparently isn't the internal via-rule name OpenROAD expects, and I haven't been able to find what that internal name actually is). -ongrid shifts the attempted via location slightly but the floating shape itself doesn't move or resolve.

Question

Is there a known pattern for closing this last gap on a ring-macro connection when geometry technically overlaps but no via gets legally inserted? Specifically:

Is there a way to list/discover the actual internal via-rule name(s) OpenROAD generates for a given cut layer, so -fixed_vias can be used correctly?
Are there known DRC/enclosure interactions specific to ring segments at exact macro-halo boundaries that could explain a "technically overlapping, still unconnected" result?

Happy to share the full config and a more detailed step-by-step log if useful.

[maliberty]

@gadfort any ideas?

It would be easier to address with a complete test case if you can provide that publicly.

[RakshithSuresh2001]

Update: Found that Metal5↔TopMetal1 vias do successfully form elsewhere in the same design, 22 instances, all using via5_6_2000_440_1_1_840_840 (dimensions 2000×440nm). At my stuck location, both overlapping shapes (the ring's Metal5 segment and the TopMetal1 stripe) are 2000×2000nm, a much larger, fully-square overlap than the successful case's 2000×440.

Question: Could a via generation attempt fail specifically at a large square overlap region (2µm × 2µm) if only a single 1×1 cut is attempted, where a working case with a narrower overlap succeeds because a single cut is naturally sufficient there? Is there a minimum cut-density or array requirement I should be forcing explicitly via -max_rows/-max_columns for wide overlap regions, rather than relying on the default single-cut behavior?

[gadfort]

It's really hard to say why the via generation failed. It there is a min cut rule that couldn't be satisfied, enclosures, via arrays, etc. the test case would help to be able to determine to root cuase

[RakshithSuresh2001]

Built a minimal repro, just the SRAM macro on its own, no CPU or other logic. Reproduces the exact same failure in under 30 seconds instead of 30+ minutes for the full design, so this should be much easier to dig into.

Files attached: min_repro_top.sv (just instantiates the macro directly, no wrapper logic), config.yaml, pdn_cfg_custom.tcl (the custom PDN script with the macro-scoped ring), and a blackbox stub for the macro's Verilog model.

Run with: librelane --pdk ihp-sg13g2 --overwrite config.yaml

Same signature as the full design: PDN-0110 (no via inserted between Metal5 and TopMetal1), PDN-0200 (floating shape removed), and PSM-0069 (grid connectivity check fails) at the end. Let me know if you want anything else from my side.

[RakshithSuresh2001]

clean_pdn_cfg2.py
config.yaml
clean_top_sv.py

[gadfort]

Can you upload the reproducer test case? I don't have librelane

[maliberty]

Librelane has some option to produce a self-contained test case. You can ask on their forums for instructions.

[RakshithSuresh2001]

Will do so. Thanks @maliberty

[RakshithSuresh2001]

reproducible_pdn_bug.tar.gz

Here you go @gadfort. Please look into it.

[RakshithSuresh2001]

// =============================================================================
// RM_IHPSG13_1P_1024x32_c2_bm_bist_stub.v
// -----------------------------------------------------------------------------
// Minimal blackbox port declaration for the real IHP SRAM macro
// RM_IHPSG13_1P_1024x32_c2_bm_bist. Used only to satisfy Verilator's lint
// step and Yosys's port-visibility requirements; contains no behavioral
// logic. The actual timing/behavior for synthesis, PnR, and STA come from
// the macro's real LEF/LIB/GDS views (see MACROS config in config.yaml),
// not from this file.
//
// Port list and widths taken directly from the vendor's own
// RM_IHPSG13_1P_1024x32_c2_bm_bist.v (IHP-Open-PDK, Apache 2.0).
// =============================================================================
module RM_IHPSG13_1P_1024x32_c2_bm_bist (
A_CLK,
A_MEN,
A_WEN,
A_REN,
A_ADDR,
A_DIN,
A_DLY,
A_DOUT,
A_BM,
A_BIST_CLK,
A_BIST_EN,
A_BIST_MEN,
A_BIST_WEN,
A_BIST_REN,
A_BIST_ADDR,
A_BIST_DIN,
A_BIST_BM
);
input A_CLK;
input A_MEN;
input A_WEN;
input A_REN;
input [9:0] A_ADDR;
input [31:0] A_DIN;
input A_DLY;
output [31:0] A_DOUT;
input [31:0] A_BM;
input A_BIST_CLK;
input A_BIST_EN;
input A_BIST_MEN;
input A_BIST_WEN;
input A_BIST_REN;
input [9:0] A_BIST_ADDR;
input [31:0] A_BIST_DIN;
input [31:0] A_BIST_BM;
endmodule

[maliberty]

Opened issue #11087