@User I notice that there are still some "disconnected" ports that are propagated in magic 8.3.274. I'm not sure what these ports are from -- they don't appear to be substrates. When I run LVS, I get a bunch of messages like:

Cell dummy_cell_2rw disconnected node: w_n1073741817_n1073741817#

I'm trying to isolate further as I can only recreate it on a full SRAM right now when I do extract unique all which leads to a bunch of other flattening during LVS.

@User My setup passes LVS for srams up to magic 8.3.270. In versions after that, it appears that the addition of substrate masking layers (DNWELL or SUBCUT) causes the bulk connections to be separated from the rest of the circuit and to be connected at the parent level. There may also be problems in the official netgen version due to port mismatches, but my version flattens those and passes at a higher level.

@User I can't replicate that here. Are you using the OpenRAM configuration for extraction and LVS?

@User I'm not using the OpenRAM extraction/LVS configuration. Working on the openlane device level LVS. I'll try to put something together in the next couple hours. Is your data available? Maybe I could work with your student directly?

@User It really is a bug in substrate extraction that we are trying to fix. You can see our complete test case above in sram.tar.gz if you just run: run_ext.sh and then run_lvs.sh. My student is @User

FWIW, the sram.tar.gz is not compressed so I renamed it sram.tar and extracted.

It was not dealing with it for us...

Sorry, only local changes to netgen so far. I haven't pushed the changes.

And we were using netgen 1.5.159 which worked better with the extra ports

You're aiming for sky130 caravel compatibility, correct?

sky130 yes. I'm not sure what you mean by "caravel" compatibility though.

The device level LVS flow that I'm working on for caravel uses X mosfet devices and micron units while the lvs flow that you're using has M mosfet devices and meter units. The device names are also different.

.SUBCKT pinv_1 A Z vdd gnd
*.PININFO A:I Z:O vdd:B gnd:B
* INPUT : A
* OUTPUT: Z
* POWER : vdd
* GROUND: gnd
Mpinv_pmos Z A vdd vdd p m=1 w=6.4u l=0.4u
Mpinv_nmos Z A gnd gnd n m=1 w=3.2u l=0.4u
.ENDS pinv_1

versus

.SUBCKT pinv_1 A Z vdd gnd
*.PININFO A:I Z:O vdd:B gnd:B
* INPUT : A
* OUTPUT: Z
* POWER : vdd
* GROUND: gnd
Xpinv_pmos Z A vdd vdd sky130_fd_pr__pfet_01v8 m=2 w=1.26 l=0.15
Xpinv_nmos Z A gnd gnd sky130_fd_pr__nfet_01v8 m=2 w=0.74 l=0.15
.ENDS pinv_1

Oh, the one above is scn4m_subm, not sky130.

I'll get sky130 sample data from @User

sram.tar.xz

@User Oops, I think the above is a .zip not a .xz? (similar to my mistake above with .gz but uncompressed)

Here is the new macro

Thanks, @User but...

Extracting wordline_driver_array into wordline_driver_array.ext:
Warning:  Ports "in_15" and "in_14" are electrically shorted.
Warning:  Ports "in_15" and "in_13" are electrically shorted.
Warning:  Ports "in_15" and "in_12" are electrically shorted.
Warning:  Ports "in_15" and "in_11" are electrically shorted.
Warning:  Ports "in_15" and "in_10" are electrically shorted.
Warning:  Ports "in_15" and "in_9" are electrically shorted.
Warning:  Ports "in_15" and "in_8" are electrically shorted.
Warning:  Ports "in_15" and "in_7" are electrically shorted.
Warning:  Ports "in_15" and "in_6" are electrically shorted.
Warning:  Ports "in_15" and "in_5" are electrically shorted.
Warning:  Ports "in_15" and "in_4" are electrically shorted.
Warning:  Ports "in_15" and "in_3" are electrically shorted.
Warning:  Ports "in_15" and "in_2" are electrically shorted.
Warning:  Ports "in_15" and "in_1" are electrically shorted.
Warning:  Ports "in_15" and "in_0" are electrically shorted.
Warning:  Ports "in_15" and "en" are electrically shorted.

Looks like the

in_*

labels are placed at the A terminals of the nand gate. Unfortunately, the

en

taps are also at the A terminal, leaving the B terminals unlabeled at this level. Magic may be able to handle this by creating automatic ports, but can I get this fixed before proceeding?

Thanks, I'll get you a revision asap

Fixing

port_address

and

port_address_0

and then running with the modified

run_ext.sh

gave me a clean LVS result.

But you are on magic 8.3.270, can you reproduce this on the most recent version?

Magic 8.3 revision 274 is what I used.

Oh perfect, I'll try that

This is a bug I was just working on. I don't think it is related to the substrate issue...

I modified the run_ext.sh script to flatten primitive layout cells before extracting. That seemed to eliminate some of the substrate problems for me.

@User That's not a fix, that's a workaround

From my discussions with @User, any layout that has cells with only some of the layers necessary to extract a device will have problems with magic be cause of the way it stores data. https://github.com/RTimothyEdwards/magic/discussions/130#discussioncomment-2146198 I'm just beginning to get a feel for it, but from what I can tell, magic recognizes devices as they are drawn so that putting diffusion and poly in different cells will cause problems. I believe the idea with generated primitive devices in magic was to flatten them after placement. Again, that's just my current understanding. In my quest for full chip device level LVS in the openlane framework using magic as it is, I'm experimenting with adding an openlane variable that will flatten specified cells before extracting. BTW, in order to get the caravel IO cells to pass LVS with magic, I have had to flatten all the subcells when reading gds.

@User These have all the layers to extract the cells...I'm not sure what you mean by that.

My experience led me to believe that the unlabeled mos body connections were causing extraction problems.

Yes, that is the case, but there is enough information there to understand it is a body connection and will be connected later.

I see. Did the work around solve your LVS substrate problem?

No..

Can you send me a sample data set?

In scn4m_subm: https://skywater-pdk.slack.com/archives/C016YSAP6TZ/p1646171568750999?thread_ts=1646162008.885789&cid=C016YSAP6TZ

I'll take a look at it in the morning. Is the tech file included?

I'll send one by morning, hopefully in sky130 when I resolve some other bugs.

May not be exactly what you're after, but by modifying the

setup.tcl

file and

run_ext.sh

files, I got a clean LVS run. magic 8.3.274, netgen 1.5.219

Subcircuit pins:
Circuit 1: sram                            |Circuit 2: sram
-------------------------------------------|-------------------------------------------
addr0[2]                                   |addr0[2]
addr0[0]                                   |addr0[0]
addr0[3]                                   |addr0[3]
addr0[1]                                   |addr0[1]
addr1[2]                                   |addr1[2]
addr1[0]                                   |addr1[0]
addr1[3]                                   |addr1[3]
addr1[1]                                   |addr1[1]
vdd                                        |vdd
gnd                                        |gnd
dout0[0]                                   |dout0[0]
dout0[1]                                   |dout0[1]
dout0[2]                                   |dout0[2]
dout0[3]                                   |dout0[3]
dout1[0]                                   |dout1[0]
dout1[1]                                   |dout1[1]
dout1[2]                                   |dout1[2]
dout1[3]                                   |dout1[3]
csb0                                       |csb0
web0                                       |web0
clk0                                       |clk0
csb1                                       |csb1
clk1                                       |clk1
din0[0]                                    |din0[0]
din0[1]                                    |din0[1]
din0[2]                                    |din0[2]
din0[3]                                    |din0[3]
---------------------------------------------------------------------------------------
Cell pin lists are equivalent.
Device classes sram and sram are equivalent.
Circuits match uniquely.

Hopefully eventually, the additions to the setup file to flatten cells with disconnected nets will not be necessary. This is an ongoing discussion.

Hmm. Some of those will change depending on the design parameters and size. I wasn't able to make a sky130 test... I kept finding other issues.

@User: I was on travel when this thread started, and since I got back I have read through it thoroughly, but I'm confused about which of the

sram.tar.gz

posts is the one I should be looking at. . . FYI, two things: (1)

w_n1073741817_n1073741817#

is not a randomly-assigned name. It follows magic's standard for naming nets that aren't labeled: Find the lower-leftmost geometry on the lowest plane of the net, and create a node name from the plane name and the lower-left coordinate, using "n" for "negative" to keep the name valid for SPICE syntax. The node name above is the coordinate at what magic considers "negative infinity", and is what you get for the substrate. Since the name is unwieldy, I often put something like

set SUB VSUBS

in the .magicrc file so that the substrate net has a recognizable name and doesn't take up so many characters. (2) The substrate extraction used to be pretty straightforward after my first implementation (some years ago). However, after trying to extract a number of deep-nwell structures, it became obvious that the extraction method was incapable of dealing with isolated pwell regions. So I had to rework the whole extraction method. I started off properly by working in a new branch. Then I made the dreadful mistake of believing that the method was working correctly, and I merged that into the master branch. Then I discovered some major flaws in the implementation (I still think the method itself is valid), and have been scrambling to get it corrected since. As of now it seems to work right on a wide variety of examples. But there are still a handful of assumptions in the code that I was unsure about, so there's still room for counterexamples.

@User The original one has the problem (in scn4m_subm). Note the file is not gz but .tar only. I misnamed it. https://skywater-pdk.slack.com/archives/C016YSAP6TZ/p1646171568750999?thread_ts=1646162008.885789&cid=C016YSAP6TZ (1) This is useful, I didn't know that. However, I do set the substrate in my extraction script: set VDD vdd set GND gnd set SUB gnd Is it better to set it to something else than gnd? This is what I've always done... (2) I think the case above is a combination of extraction of substrates and removal of extra ports. It seems that the substrates are actually ok, but there are extra ports disconnected.

@User: I would definitely advise against setting SUB to

gnd

because if GND is also

gnd

then you are forcing them to be the same regardless of the circuit connectivity.

@User I think this was a recommended solution to another problem a long time ago...

@User: At least for the original SCMOS sram layout, the extraction does exactly the thing that I thought I fixed. So apparently my fix does not catch all cases.

@User You may already be aware, but I logged an issue with magic where the substrate connections with later (higher level) SUBCUT are not as expected (with sample data!). If you're changing the algorithm, you might want to include that at the same time.

@User, @User : I know I had punted on this for a while to get other things done, but I didn't realize until I scrolled back to find the thread that it started over a month ago. So I apologize for not getting back to it sooner. I spent the last two days tracking down this issue and another one that I came across recently, related to the extraction (and mostly to do with substrate extraction). For the other error, I found that the global substrate node was not nulled out between searches, leading to the possibility that a substrate could get accidentally connected to another substrate node found on an earlier pass, leading to very unexpected results. For your issue, I found that what I thought was a bottom-up ordering of cells when doing "extract all" was not necessarily always bottom-up, whereas my method for handling substrate extraction assumed that a cell's subcells were always processed first. That caused the substrate of some subcells to get interpreted as isolated substrates, so they got disconnected from everything else. So I just pushed magic version 8.3.287 to opencircuitdesign.com. The first problem only shows up for circuits with multiple isolated substrates (and so is pertinent to the extraction of the caravel chip). The problem affecting the sram circuit only shows up when there are some cells used in multiple levels of a hierarchy. I still need a CI but I cringe at the thought of coming up with the 10,000 corner cases that I need to test to make sure I haven't broken something.

@User I saw the pull yesterday and hoped that was what it was for. I'll try to test it in the next couple days. Sorry I didn't get a test case out.