Hello! I am trying to harden a module with openlane for sky130A (first time using openlane or openroad) and I'm having some routing issues. My working repo is here: https://github.com/Cal-Poly-RAMP/tapeout-ci-2311/tree/soc-rtl (on branch soc-rtl), and the latest issue-reproducible is attached. I am using a pre-made sky130 sram macro from here (https://github.com/VLSIDA/sky130_sram_macros/tree/main/sky130_sram_2kbyte_1rw1r_32x512_8). I have not been able to get any build with these macros placed to avoid congestion. I've tried: - Increasing and decreasing the target density, many values from 0.01 up to 0.90 - Decreasing the number of SRAM macro instances - Trying different placement and rotations of the SRAMS, using the congestion heat map on the GUI - Increasing and decreasing FP_TAP_HORIZONTAL_HALO and FP_TAP_VERTICAL_HALO - Dramatically increasing GRT_OVERFLOW_ITERS - (Temporarilly) using a much larger DIE_AREA (30x size) There seems to be plenty of room on the die when I inspect with the GUI and the resizer-routing-design-congestion.rpt is completely empty (this normally contains overflow violations, but it seems like I don't have any). I don't really know what to do to keep the flow moving. Without the macros, I've made it to step 23 (detailed placement, diode legalization). Can anyone help out?

Are you manually setting the macro placement? You might try placing it in the middle of the chip.

I’ve tried manual and auto, yeah. Placing them in the center/ spread out didn’t help either. (For context that picture is the 30x DIE_AREA, so the macros appear way in the corner). Starting a run with the huge die and the macros more centered now, though.

I've never successfully placed an openram macro without also creating keep out areas for the router, otherwise I always get stuck on routing

Ideally, that should all be in the lef, right? I was looking at the lef specification the other day and it seems that you could cover the whole macro with routing obstructions and the pin definitions would override any overlapping obstruction.

I don't know tbh. It's so long ago that I figured it out.

@Mitch Bailey that's what we've been seeing with the

lef write -hide

command in Magic - it covers the whole macro with an OBS area but leaves cut-outs for the pins to be reached by the router. It's really handy 🙂

@Ellen Wood reading the lef specs, I’m thinking the cut outs should not be necessary. I think pins are supposed to override obstructions. This works on the pin layer, if the pins are along the border of the obstruction, otherwise the router should drop a via from a non-obstructed layer to the pin. (as far as I could tell from the specs).

Interesting, I'll take a look and see if I can get more SRAMs placed with that. I was able to get them to work without placing keep out areas by mirroring the instances to reduce the routing distance to shared pins and keep busses from needing to flip around: