Hi @Matthew Guthaus I can generate GDS files of my design using multiple SRAMs, generated by Openram master release branch. My understanding is, that we need to generate SRAMs from the dev branch. A minor thing is, that with the dev branch, I get a "AttributeError: 'options' object has no attribute 'experimental_power'" error, but it can be fixed by adding "experimental_power = False" to the configuration file. Q1: I get the "WARNING: file hierarchy_layout.py: line 411: Could not find pin gnd on col_cap_bitcell_2port" warning. Can this be skipped ? Q2: When using ANY of the SRAMs generated with the dev branch, I get different kinds of routing errors (as stated before, it works with the SRAMs generated by Openram master branch). The picture shows an example lef file, which shows some weird ring pffset. The next picture shows 2 dev-branch-SRAMs in the design, the smallest one in the left column and the smallest ones in the right column. Each column is "left-side-aligened" by the given locations in the macro file. Any idea how to overcome the problems ? Thanks a lot in advance, Tobias

@Jesse Cirimelli-Low and I will take a look. We are in the process of regenerating the macros in the library.

Thank you for your reply. I use custom configs, so I'm not sure if the macros in the library will help. It looks as if the dev flow requires the parameter experimental_power, wherever it is defined. No problem. Q1: I get the warning on any sram config. I use the pdk that comes with mp6c and use the dev from last week. Q2: So can I check out a new dev ? Are you planning to do a stable-dev version 😉 Q3: I'm not sire if I submit for 6c, but the master branch cannot be used, right?

Q1: We are using an older one. I haven't tested with any changes... Q2: Running CI now then it will be there. Q3: No, I would not recommend it.

I guess you agree, a tagged openram version, which is tested with 6c and the openram_testchip for instance would be great. #justsaying

Yes, of course

What I was trying to suggest was, that it might be beneficial to have a stable Openram version, which is tested with the latest Openlane flow release (that is 6c) based on a realistic project (for example the openram testchip project), so that problems can be solved already upfront. It does not need to be a chip-tapeout.

I understand. But things change so rapidly that that hasn't been possible.

I checked out the latest dev branch and it seems to work now (Q1 and Q2 are solved). I guess you owe me a beer or two. Probably at WOSET '23. Cheers, Tobias

Wait, why do I owe you a beer and not the other way around? :)