Re: OpenRAM SRAM DRCs - Does the plan for the upcoming MPW remain that errors in the posted macros at https://github.com/efabless/sky130_sram_macros are to be waived? Or should we be fixing these? Thanks in advance

The SRAMs are (mostly) DRC clean with core memory rules which are not implemented in the magic deck. So, yes, there will need to be a way to waive these. I'll let the shuttle people figure out a way how... I've pinged them.

Terrific thanks. Re: LVS on the same cells - Can we confirm they pass LVS with the blessed (netgen) setup? We’ve been running a commercial LVS tool, and it’s reporting power-ground shorts in the 4kB cell.

@Dan Fritchman I think that there is still an LVS error in the published ones. I fixed it but need to regenerate. So your tool is correct.

Glad I asked! Thanks!

@Matthew Guthaus, you mention that the 4K and 8K have less verification. How risky would it be to include these for testing purposes (ie count on the 2k working, and plan to see how the 4k/8k worked)? I see power/ground shorts mentioned above. Could including one of these less-verified devices actually kill the chip?

It's my top priority now, but I need Xyce working to do it

I also want to use the 8K SRAM for my design. For the DRC, I patched Openlane as following:

diff --git a/scripts/magic/drc.tcl b/scripts/magic/drc.tcl
index 5019f2c..90b4bfb 100755
--- a/scripts/magic/drc.tcl
+++ b/scripts/magic/drc.tcl
@@ -13,6 +13,10 @@
 # limitations under the License.
 
 if { [info exist ::env(MAGIC_DRC_USE_GDS)] && $::env(MAGIC_DRC_USE_GDS) } {
+    if { [info exist ::env(USE_SRAM_ABSTRACT)] && $::env(USE_SRAM_ABSTRACT) } {
+       load $::env(PDKPATH)/libs.ref/sky130_sram_macros/maglef/$::env(SRAM_ABSTRACT_MODEL)
+       gds noduplicates true
+    }
        gds read $::env(CURRENT_GDS)
 } else {
        lef read $::env(TECH_LEF)

Then, in the config file you need to add two configs:

# This needs a patch to openlane
set ::env(USE_SRAM_ABSTRACT) 1
## this needs a pdk build with the sram macros
set ::env(SRAM_ABSTRACT_MODEL) ${SRAM_MODEL_NAME}.mag

The DRC for the SRAM will pass. My observation is that if the DOUTs are not connected (no metal wire connect to the pins), they will cause DRC violations. Therefore, you should connect it to somewhere.

Yes, you will get min area metal in this case, but it isn't true because the HDS actually has more wire connected to they pin.

@Matthew Guthaus Hi, Sorry if this question was asked somewhere else. I'm quite new to this Slack channel. Can I generate Sram macros by OpenRAM for the Sky130 process, at the very moment? I cloned OpenRAM and had sucessfully generated macros for the SCN4. However, I'm not seeing OpenRAM is included with the sky130 under /technology directory.

We are working with Google to release this. It needs some fix ups first

Thank you for your prompt reply. I tried a ngspice simulation with one generated model for the SCN4. I got error at first run and I managed to change +VERSION in pmos/nmos models from 3.1 to +VERSION=3.3.0. I'm using latest ngspice compiled from source. FYI