Custom SRAM version (preferred solution): One version uses only custom SRAMs (latest OpenRAM), namely: sky130_sram_2kbyte_1w1r_32x512_8 sky130_sram_4kbyte_1w1r_32x1024_8 sky130_sram_64byte_1w1r_32x16_8 sky130_sram_256byte_1rw1r_32x64_8 Surprisingly, I don’t have any Magic DRC violation in the local precheck and on the Efabless server precheck. Unfortunately, I have 8 FEOL and 131 BEOL errors, which I don’t know how to solve. Is there a chance to solve F\BEOL violations by the user ? In case you care, the precheck results are also uploaded: https://github.com/cloudxcc/TestRun_custom

There were some errors in the klayout DRC deck that I filed. It's in efabless' hands for this... https://github.com/efabless/mpw_precheck/issues/132 https://github.com/efabless/mpw_precheck/issues/131 As I mentioned below, you can't use Magic to verify the SRAMs.

Thank you for your reply. Step 7 (Magic DRC) has 0 DRC violations. This is true for local precheck and efabless server precheck. Steps 8 (KLayout FEOL, 8 violations) and 9 (KLayout BEOL, 131 violations) are problematic: FEOL: nwell.6 [sky130_sram_64byte_1w1r_32x16_8] (4) nwell.6 [sky130_sram_256byte_1rw1r_32x64_8] (4) nwell.6 : min enclosure of nwellHole by dnwell : 1.03um BEOL: m1.7 [mostly SRAMs] (20) m1.7 : min. m1 with holes area : 0.14um² m2.2 [all SRAMs] (9) m2.2 : min. m2 spacing : 0.14um m3.2 [all SRAMs] (108) m3.2 : min. m3 spacing : 0.3um Therefore, as of now, I don’t think that I have nwell.4 or metal4-spacing errors in my design. Any thoughts on how to tackle the violations above ?

I'd have to see what is causing these errors... can you show examples?

Link to the github project at the beginning of the thread. You can download it in the background. The precheck results are also uploaded, so you can check BEOL and FEOL with KLayout. Fair enough ? Thank you for your help.

I'll have to request that you identify these errors.

I thought that the two unix commands (git and klayout -m xml gds) which makes you see the violations within seconds, are way faster to get an understanding of the errors, than config files. But that's okay. I thought that user feedback is valuable for your development. Thanks anyway.

But I need to know what you had for input to replicate any bugs.

Never thought you guys would consider actually debugging it. That’s why I only listed the SRAM names and uploaded the project’s violation xml for quick feedback and advice. These are the 4 SRAM config files which I’m using. The project's xml file might still be helpful to map the individual violations to the individual SRAMs.

The nwell.6 errors are related to the bug I filed above. The m1.7 errors are not in any SRAMs. The m2.2 and m3.2 errors are indeed in the SRAMs and need to be patched. We hand fixed these in the sky130-sram-macros.

Awesome, thank you for your reply. Yes, the m1.7 mentioning is my mistake. Did you also hand fixed nwell.6 violations in the SRAMs of the dev branch ? Do you plan to upstream nwell6, m2.2 and m3.2 patches into OpenRAM soon ?

I just noticed that yours are nwell.6 whereas ours were nwell.4. It still appears to be an invalid error and we did nothing to fix it in the memories. That is why I filed a bug report with the DRC deck. Could you file one for this error as well? I don't have fixes for the m2.2 and m3.2 yet.