@Tim Edwards @Mitch Bailey while reading openram memory macro gds files , i am encountered with these errors. Any idea on how to fix these?

@Abhishek Anand I believe these are non fatal errors that you can ignore.

@Abhishek Anand: What Mitch said. The magic tech file for sky130 doesn't implement the optical correction layers. Also, there are several layer:purpose types that describe boundaries. The documentation on these is scarce, and magic and OpenRAM are disagreeing on how they should be used. However, they are just boundary markers, so it's not a critical issue of any kind.

@Tim Edwards Should/are the optical correction layers being included in the final caravel gds?

@Mitch Bailey yes they are

@Mitch Bailey: Yes. Since the bit cells are part of the PDK, magic will always use the vendor GDS. I don't like to include the optical correction layers in magic because they aren't really user design layers. It takes special software to predict the diffraction effects, and I don't know of any open source software that does that. But it's worse than that, since SkyWater runs the optical correction software on all the mask layout, so the optical correction design layers are marking exceptions to the standard optical correction.

@Mitch Bailey @Tim Edwards Thanks for the clarification. I am running the following commands in sequence. gds read filename select top cell flatten filename_flat load filename_flat cellname delete filename cellname rename filename_flat filename select top cell extract do local extract all ext2sim labels on ext2sim (Here I encountered with "cannot read filename.ext)? What could be the reason for this?

Are you trying to run parasitic extraction on the entire SRAM macro?

@Mitch Bailey Yes . Trying to do for entire SRAM macro

@Tim Edwards Can magic handle a flattened SRAM parasitic extraction?

@Mitch Bailey: Yes, it can. Takes something like 12 hours for the 1kB SRAM, but it can do it. What I have not been able to do is get ngspice to run the resulting netlist, but my computer's oom manager killed the process when I tried to install open_pdks at the same time, so maybe it would have finished given enough time.

@Tim Edwards after executing "extract all" magic didn't show any output indicating that it doesn't produced a file. I will run it once again and see

@Tim Edwards Can you share that with us? @Bugra Onal was extracting but only getting capacitances even though the resistance threshold was set to 0.

@Matthew Guthaus: You can't just set

rthresh

to get parasitic resistances. Magic's extraction has a very unusual "lumped resistance" model which calculates a single "effective resistance" for an entire net. This outputs as a single-pin resistor---a value R associated with a net such that R*C will yield the effective point-to-point delay through the net (which of course is wildly inaccurate for anything other than a net with two endpoints). Plus, there aren't any tools that I know of that know how to deal with a single-pin resistor. So the full R-C extraction has to be done with the following recipe (which is floating around several places in the slack workspace):

load <cellname>
flatten <cellname>_flat -dotoplabels
load <cellname>_flat
cellname delete <cellname>
cellname rename <cellname>_flat <cellname>
select top cell
extract do local
extract all
ext2sim labels on
ext2sim
extresist tolerance 10
extresist
ext2spice lvs
ext2spice cthresh 1
ext2spice extresist on
ext2spice

This recipe also reflects the fact that the full R-C extraction isn't clearly meaningful when run on a hiearchical layout, and so it is necessary to flatten the entire layout first. For the 1kB SRAM, though, the cellnames were so long and the hierarchy was so deep that I had to use

flatten ... -dotoplabels

to prevent issues with net names becoming rediculously long (and crashing magic, although I fixed that specific issue). That makes it harder to find nodes in simulation, but I can do

getnode

in the (flattened) layout to find the name of any specific net I want to look at in the simulation. Over the course of a week or so, I managed to track down (almost) all of the issues that were causing negative capacitances (there were a surprising number of them that were all completely independent from each other). I think that on the "tiny" SRAM there were no negative capacitances the last time I ran. I also think that the 1kB SRAM still had a handful of small negative capacitances which I just removed from the netlist. I still need to do another round of debugging to track down the remaining source of negative caps. The capacitances come out negative because magic uses a method where it first computes the total parasitic capacitance of a wire to substrate, then subtracts off the portion that is shielded. If it doesn't do that accounting correctly and double-counts some area or counts some area it isn't supposed to, then it can end up subtracting off more than the original total amount. You will at least want to make sure you do the full R-C extraction using the most recent version of magic. I can share the netlists but they are very large, so I'd prefer to avoid posting them if you can duplicate the way they were generated.

@Tim Edwards @Mitch Bailey .ext file was not generated it seems. Any idea on how to resolve this?

@Abhishek Anand: That is unexpected. The extraction seems to have taken no time (did not report percentage progress, which I would expect for something the size of an SRAM. Did you look at the layout when it was doing extraction? The output is possibly consistent with a failure to start up with the correct tech file, but I can't tell that from a screenshot.

I am doing on a 16*2 SRAM macro. Just making sure whether it works on small macros. Any other information needed ? So that we can able to debug this?

@Abhishek Anand: Yes. As I said above, did you look at the layout when it was doing extraction? How long did the extraction take? I do recall seeing something weird recently, in which the .ext file output ended up in another directory. I have never seen that happen before or since, so I've been treating it as a one-off issue, but just in case, does the .ext file show up somewhere else?

@Tim Edwards I am unable to debug that issue. I installed it entire setup in another system. Everything is working fine and i followed the same steps that you have mentioned above . After using the command cellname delete<cellname> A window pops up saying " some n number of magic cells have been modified do you want to delete these modified cells" what does it mean??I selected no and proceeded and finally got a spice netlist file with R and C values.

@Abhishek Anand: The last time I did a full R-C extraction on something that size I also got a handful of negative capacitances, so there's still something wrong in magic's accounting of shielding. But I didn't see very many of them and they weren't very large, so for the moment I'm punting on investigating that error, and I suggest that you just delete the negative capacitances from the netlist.

@Tim Edwards Yeah Sure .Thank you

@Abhishek Anand the 2206q version of the single port sram has a short in the word decoder. But that’s not the problem you’re seeing. I think the problem you have is that there is no simulation model for the special device

sky130_fd_pr__special_nfet_pass

extracted in the single port memory cells. In the dual port version, this model is not extracted. @Tim Edwards will this require a rule modification?

@Mitch Bailey: There is a model for

nfet_pass

, and it exists in all memory cells. @Abhishek Anand: What statements are you using in your simulation to include the model files?

Ok, sorry for any confusion. Maybe I’m using the wrong pdk

$ volare ls
$PDK_ROOT/volare/sky130/versions
└── e6f9c8876da77220403014b116761b0b2d79aab4 (2023.02.10) (enabled)

$ ls $PDK_ROOT/$PDK/libs.ref/sky130_sram_macros/spice/*
$PDK_ROOT/sky130A/libs.ref/sky130_sram_macros/spice/sky130_sram_1kbyte_1rw1r_32x256_8.spice
$PDK_ROOT/sky130A/libs.ref/sky130_sram_macros/spice/sky130_sram_1kbyte_1rw1r_8x1024_8.spice
$PDK_ROOT/sky130A/libs.ref/sky130_sram_macros/spice/sky130_sram_2kbyte_1rw1r_32x512_8.spice
$PDK_ROOT/sky130A/libs.ref/sky130_sram_macros/spice/sram_1rw1r_32_256_8_sky130.spice

$ grep nfet_pass $PDK_ROOT/$PDK/libs.ref/sky130_sram_macros/spice/*

$

@Mitch Bailey: Devices won't be found in the SRAM library. You'll find them in

$PDK_ROOT/$PDK/libs.ref/sky130_fd_pr/spice/sky130_fd_pr__special_nfet_pass.pm3.spice

.

I used .lib to include files

@Abhishek Anand: I think you're seeing an error that's due to an issue in magic when extracting one of the weirder geometries in the single-port SRAM layout. This problem was fixed in magic version 8.3.378 (March 13, so about 2 months ago).

I am using version 8.3.397 of magic

@Abhishek Anand: In the screenshot above, the SRAM and its components are being read from

sky130_sram_0kbytes_1rw_2x16_None_flat.cir

. The incorrect size of

special_nfet_pass

devices is in the low-level single-port SRAM cell, so it must be defined in that file. When and how was that netlist created?

That netlist is created from magic . That netlist consists of extracted values of R and C as well.

It's the "tiny" SRAM, so the files aren't all that big. I have the same layout (unless it's been changed in the past month or so) with the same flattened R-C extraction, so I can do a direct comparison. Can you please post the GDS and the netlist (feel free to post me in a private message if you don't want to broadcast the GDS to everyone in the Slack workspace)?

Can this be confirmed in the GDS version of the colenda cell?

Oh, great, another patch for open_pdks. . . : )

We use our own sram cell repo at this point.

@Tim Edwards. "Coming Back to me" ?are you referring to the same error that was posted in this thread (unable to find nfet_pass)?

@Abhishek Anand: No, I mean I looked at a slightly larger version of this SRAM layout (2x16) about a month ago. I noted the issue in my notebook and corrected it manually because my end goal was just to get a working simulatable netlist.

@Tim Edwards does that mean the error that i got (unable to find nmos_pass) can be rectified?so that i can able to simulate the netlist?

Yes. If I patch up the cell and send it back to you, can you replace it in your library and the SRAM layout GDS?

Thanks, I'll get this into OpenRAM too.

I would wager that that cell has never been taped out by Cypress or SkyWater. . .

Yeah sure . I would try

There was a time when netgen and magic were having issues handling substrate extraction a couple years ago and I probably added something like those labels/pwell layer to debug. Maybe they never made it out.

@Jesse Cirimelli-Low: These are the cells from the Google skywater-pdk sky130_fd_bd_sram repository on github.

@Tim Edwards i replaced your cell with the highligthed cell present in the following folder.and then generated SRAM layout using OpenRAM . The generated SRAM layout is extracted with the same procedure used earlier. Still I am encountering the same error.

@Abhishek Anand: Yes, that's the correct procedure, but you should not get the same error unless there's another cell with the same problem. For the layout I extracted, the problem went away after I fixed the column end cell's GDS.

@Tim Edwards is there a way to compare my SRAM macro gds file with yours ? So that we can able to find out the problem.

@Abhishek Anand: Please repost your corrected GDS to me in the private message channel like you did with the last one

@Tim Edwards after extracting the fixed gds SRAM layout file that you shared with me , I didn't get any errors and working fine. Thank you