DRT checkConnectivity break with dense boundary M4 macro pins in ASAP7

[lee3036]

I am attempting to run the OpenROAD-flow-scripts ASAP7 bp_quad design from this repo:

https://github.com/TILOS-AI-Institute/MacroPlacement/tree/main/Flows/ASAP7/bp_quad

During 5_2_route / detailed routing, I see many DRT warnings/errors that appear to be related to one SRAM macro LEF:

https://github.com/TILOS-AI-Institute/MacroPlacement/blob/main/Enablements/ASAP7/lef/sram_asap7_124x64_1rw.lef

This macro has signal pins on M4 placed on every horizontal M4 track at the macro boundary. My current assumption is that this dense M4 pin pattern is causing a DRT pin-access / guide issue, because if I manually modify the macro LEF to split the large buses across opposite macro sides and leave one empty M4 track between pins, detailed routing completes successfully.

I may have set up the flow incorrectly, so I’m opening this mainly to ask whether this macro pin pattern is expected to be routable by DRT.

Example warnings/errors from the original LEF:

Warning: marker bloat 4x width but could not find two grids to add marker cost
  marker -- src: bp_processor/cc/y_0__x_1__tile_node/tile/core/fe/mem/icache/tag_mem/macro_bmem/net128912
    bbox = ( 473.444, 181.272 ) - ( 473.528, 181.287 ) on Layer M4
bp_processor/cc/y_0__x_1__tile_node/tile/core/fe/mem/icache/tag_mem/macro_bmem/net128911
...

Error: bp_processor/cc/y_1__x_1__tile_node/tile/core/be/be_mem/dcache/tag_mem_data_lo[88] 1 pin not visited #guides = 35
...

Error: checkConnectivity break, net bp_processor/cc/y_1__x_1__tile_node/tile/core/be/be_mem/dcache/tag_mem_data_lo[88]
Objs not visited:
...

The failing nets are connected to the SRAM macro data pins. The macro has M4 pins at every track, and the pins appear to be boundary-accessible but very dense. In my experiment, changing the FakeRAM LEF so that rd_out[*] and wd_in[*] are split onto left/right edges with every-other-track M4 pin placement avoids the DRT failure.

Unfortunately, I cannot share the full ODB/DEF from my current run because parts of the design were produced through another flow, but the macro LEF and flow are public. I can provide more logs, OpenROAD version/commit, and the exact LEF patch I used if helpful.

Is DRT expected to handle this kind of every-track M4 boundary pin macro, or should the macro LEF be made less dense / more router-friendly?

Environment information:

I ran the recommended tools/OpenROAD/etc/Env.sh. The output reports:

• OS: Ubuntu 22.04.3 LTS
• Kernel: Linux 6.8.0-117-generic
• GCC/G++: 11.4.0
• CMake: 3.31.9
• OpenROAD version: 26Q2-1745-g5bf1281487

However, Env.sh also prints:

[WARNING] Your current OpenROAD version is outdated.

and later the CMake configure step fails because ortools is not found:

Could not find a package configuration file provided by "ortools"

i put an image of one of the checkconnectivity breaks.

[maliberty]

This would be better submitted as an issue with an attached test case that reproduces the error. How did you even build openroad with a cmake error?