Hi @Matthew Guthaus I submitted a design with 13 sky130_sram_1kbyte_1rw1r_32x256_8 SRAMs and it passes the tapeout check on the Efabless site. Living on the wild side of life, I replaced 2 SRAMs with sky130_sram_2kbyte_1rw_32x512_8. All from the dev branch labeled DRC and LVS clean. I run into the problem I mentioned a few weeks ago here in this channel. The local precheck generates GB of magic drc error files (, in contrast to the project with only one kind of SRAMs, where the file size is a few kB). This then slows and stalls the python script when converting the DRC error files to KLayout xml files. The precheck on Efabless site gives the error: [09/04/22 094829 PDT] STEP UPDATE Executing Check 7 of 13: Magic DRC [09/04/22 102319 PDT] EXCEPTION Script error code: -9 Again, all I did was replacing two 1kbyte SRAMs with two 2kbyte SRAMs. You can have a look here: https://github.com/cloudxcc/TestRun_macro_2k.git I use this PDK: e8294524e5f67c533c5d0c3afa0bcc5b2a5fa066 Just trying to help. If this project is not relevant, let me know, then I’ll delete it. PS: For reference, this is the project which passes, but it is subject to change due to missing power routing for the macros: https://github.com/cloudxcc/WaveSync_7.git Cheers, Tobias

I'm not an expert in the eFabless precheck, so I can't really say why this is happening... Sorry.

My explaining is probably wrong. It is not about pre-check. The problem is, that replacing one SRAM with another one suddenly generates GB of Magic DRC errors. You are definitely an Magic DRC expert for SRAMs and beyond.

Magic cannot be used to run DRC on the SRAMs unless you replace the bitcells with an abstract view