@User @User sram blocks generate a ton of DRC as expected due to bit cells. If I want to use an SRAM in a design then is it best to have it as a completely separate macro so I can turn off DRC for that macro and enabled for the rest of the design? How would this affect the submission process? Given that there will always be DRC errors, so I assume the precheck would fail.

I just worked through the way to handle SRAM blocks yesterday; you pre-load the SRAM as an abstract view (either from maglef/ in the open_pdks install, or from the LEF file from the OpenRAM repository), then set the option "gds noduplicates true", then read in the GDS. There is no reason that we cannot detect one of the known SRAM cells, although if people use OpenRAM outside of the SRAM macro library, then we may need some kind of way for people to declare that certain cells in the design should be abstracted prior to running DRC checks.

Can you post an example?

What I meant by "There is no reason that we cannot detect ..." is that "we are (as far as I know) not doing this, but we should". If you can tell me the project name/URL, I can guide the people who write and maintain the precheck scripts to properly handle the SRAM block. The exact implementation may require some trial and error.

thanks. I don't actually have a project using sram but I know plenty of people who want to and there is very little documentation and no working examples as far as I kno3w

@Tim Edwards I follow your instruction and load the maglef of the SRAM before running DRC. This can be used to avoid the DRC violation. The SRAM violation with the 8K SRAM can lead to the computer out-of-memory. Our machine only have 64GB of RAM.

@Hieu Bui? "Only"? I'm working here with 16GB. . . I have not had trouble with fitting any designs in memory except for the full caravel + user project + fill shapes, which tends to run close to 20GB, depending on the size of the user project.

Maybe it's the problem of python. I used 8k SRAM in my design. Magic reported so many violations. Openlane tried to convert the drc violation into klayout xml and calibre. At this step, python took a lot of memory and faild after a long running time. I am trying to run the test with 4k and 8k SRAM. The design with 8k SRAM still reports 85 violations.