Has anyone encountered extracting w=0 l=0 sky130_fd_pr__res_xhigh_po resistors when extracting parasitic resistances? is this the proper case to use rthresh=

something small

? For context, I have a design which when extracted with this script:

extract all
ext2spice lvs
set filename [cellname list window]
set spicefilename [lindex [split $filename .] 0]
ext2spice -B -d -o "../lvs/$spicefilename.spice"

extracts the resistors I expect (no w=0,l=0 resistors). When the same circuit is extracted with this script:

extract do local
extract all
ext2sim labels on
ext2sim
extresist tolerance 10
extresist
ext2spice lvs
ext2spice cthresh 0.01
ext2spice rthresh 0.001
ext2spice extresist on
set filename [cellname list window]
set spicefilename [lindex [split $filename .] 0]
ext2spice -d -B -F -o "../pex/$spicefilename.spice"

extracts the resistors I expect, parasitic resistances, and w=0,l=0 resistors; I get 3 of these 0 size resistors. Each of them are connected to nodes that seem to have been made for the parasitic extraction (e.g. Vb.t10, Vb.t11)

Yes. This is a known issue as of a few days ago. To avoid it---and possibly other related or unrelated errors---flatten your circuit before running extresist.

it's flattened

BTW: "rthresh" is not what you want. That extracts "lumped resistance" which is a 1-terminal device that can be used by tools like IRSIM to compute time delays on a wire. But that is not equivalent to R-C extraction.

Oh okay thank you!

But I'm concerned that you may have found a case where the layout is flattened but the device length and width are coming out zero anyway? If so, I'll want to debug it.

So I had what I thought was an already flattened design, which gave me the issue, but I flattened it again and now the 0 size resistors disappear

Now I'm not sure if flattening fixes the problem, or if the problem just comes and goes randomly.

if i send you the two extracted netlists (one from the 1x flatten, other from 2x flatten) would that help? i could bundle up all my .mag files too and send them

As long as I can just reproduce the zero width/length output, that's all I need.

I'll private message it

Yes, it segfaults for me, and I just tracked down and fixed that segfault (along with a couple of other errors). The result now gets through "extresist" but extresist complains about not finding two of the nodes, so I still need to track down what's going on there. The fix (or partial fix) has been committed to the master branch on opencircuitdesign.com.

That was fast!

Doesn't count if it's only a partial fix. . .

That would explain why the model that showed up was what it was

I pushed another fix to the magic master branch on opencircuitdesign.com. This fixes the device name and incorrect parameters (e.g., zero length and width). The root cause of both was the incorrect device name. The parameters were supposed to be taken from the original device in the .ext file, and the terminal names from the updated device in the .res.ext file. With mismatched names, it could not find the matching device.

Thank you for these fixes. I ran the extraction script on the same design and got two errors from extresist:

Couldn't find device at 16435 11073
Error in extracting node bandgapcorev3_0/Vbneg
... adding nodes here ...
Couldn't find device at 15147 7209
Error in extracting node amplifier_0/Va

I looked through the generated .nodes, .ext, .ext.res, and .sim files and could only find these coordinates referenced in the .sim file. at these coordinates I found

x GND bandgapcorev3_0/Vbneg GND l=0 w=0 x=16435 y=7209 t=16 sky130_fd_pr__pnp_05v5
x GND amplifier_0/Va GND l=0 w=0 x=15147 y=7209 t=16 sky130_fd_pr__pnp_05v5

I'm guessing the l=0 w=0 is what's causing the extraction of these nodes to fail? Can I do anything about this?

The l=0, w=0 is not affecting anything (at least not anymore, since yesterday's fixes). The PNP is characterized by area, not length and width, but the values are left in the .sim file just for simplicity of parsing it. I have seen this error before, but not recently, so it's apparently intermittant and probably a memory issue I need to track down. If the original node names exist---and I know they do if they are pins, but if not I'm not sure---then failing to find and replace the device would mean the original device and its connections are kept, so the net resistances to that device would not be accurate, but otherwise it should be a valid netlist for simulation. If the original node names are deleted, then the simulation would halt immediately due to dangling nodes, which ngspice does not like.

By pins do you mean labels or ports? or something else entirely?

Ports, defintely. Labels, not sure. I don't think so.