Holy cow, folks, how can I ship around that one: 25-tritonRoute.log: ..... [INFO DRT-0028] Complete via4. [INFO DRT-0028] Complete met5. complete 10000 nets. [WARNING DRT-0215] Pin dut.cubevi.rv32i.RF1it.memi/din0[17] not covered by guide. [WARNING DRT-0215] Pin dut.cubevi.rv32i.RF1it.memi/din0[17] not covered by guide. [WARNING DRT-0225] dut.cubevi.rv32i.RF1it.dina\[17\] 1 pin not visited, fall back to feedthrough mode. [WARNING DRT-0224] dut.cubevi.rv32i.RF1it.dina\[17\] 1 pin not visited, number of guides = 19. [ERROR DRT-0218] Guide is not connected to design. Error: or_droute.tcl, 34 DRT-0218 Any idea ? Would be great. Thanks a lot. Is it because the SRAM is embedded in the hierarchy ? But din0[17] is just like any other din0 pin.

SRAM has to be at top level or it won't get powered. Don't know if that's related to your report tho

Thanks Matt, I was hoping that this constraint has become outdated, but if you say it is still mandatory, I know what to do on the weekend. There are plenty of them. Cheers, Tobi

@User This is a limitation of pdngen and how it does power connections using straps, unfortunately.

Because it reached step 25, detailed routing, I thought this issue is not relevant anymore. But it is not a big deal. So I guess it is also the reason why I have problems with placing SRAMs next to each other west-east. There is a "reasonable" w-e-gap required and it is not worse investigating this, right ? North-south adjacent placements seems to be no problem, but you should leave some space for routing. Do W or E orientation work for SRAMs. Btw., thanks for giving us so much joy, it is soooo much fun working with this step by step and to see the layout evolve. Thanks again, cheers.

@User Changing the orientation will cause problems with the power straps because the ring layers are the wrong directions...

Sadly this problem still exists even with SRAMs on top. Guess I have to understand what a guide is, next.

?

The openram pins are generally not on the routing grid, but they are like 3x bigger than the grid.

worth taking a look surely

lol

Thanks you for your awesome support. When I shake around the layout a little bit, the problem still remains. But when I change the SRAM from sky130_sram_1kbyte_1rw1r_32x256_8 to sky130_sram_2kbyte_1rw1r_32x512_8 (with the MSB address bit tied to 0) the flow continues and I'm reaching the holy land of optimization iterations. In my pathetic understanding I would guess it is the sram cell.

@User I also faced similar issue in SRAM integration. Interestingly I have integrated same SRAM in two project. One project does not had any issue, but other project has this error. Only difference between the both project was interface IP to SRAM block were different I have raised this issue in OpenRoad with example. They has suggest to use the latest version of Openlane Tool Set. With latest efabless/openlane:latest docker version this fixed Here is Issue Tracking one: https://github.com/The-OpenROAD-Project/OpenROAD/issues/1197

@User Thank you for your support. Sadly the issue remains even with the latest Openlane version (after cleaning some resizer issues in the current release).

@User Did you used efabless/openlane:latest docker ? As issue more related to OpenRoad tools

@User Sorry for the late response. With the new Openlane\Docker combo the flow continued. Thank you for your support.