FYI, I just pushed (to the opencircuitdesign.com git repo) an update to magic that fixes the main issues that it had with doing full R-C parasitic extraction. I would be happy to have people try it out. There is a tutorial that is getting increasingly out of date, so the steps are as follows:

extract all
ext2sim labels on
ext2sim
extresist tolerance 10
extresist
ext2spice lvs
ext2spice cthresh 0.01
ext2spice extresist on
ext2spice

This probably works better on a flat netlist, although I have run it on a shallow hierarchy (standard cell layout) without issues. I am still working on a better solution that does not depend on the .sim file format (which is a flat format).

@Tim Edwards: There still seem to be a few problems: The W/L scaling seems too large by a factor of 10^6, and I am missing some connectivity to the IO.

If you see a scalefactor where W=1 meaning 1um, then that's correct (for obscure reasons magic has "10000000u" instead of "1" but it's the same thing). This matches the ".option scale" statement that's embedded in the SkyWater model libraries.

Trying to extract some PNPs and I get the following output after extresist:

Cannot open file sky130_fd_pr__pnp_05v5_W3p40L3p40.sim

Did you do

ext2sim

first?

these are my steps

extract all
ext2sim labels on
ext2sim
extresist tolerance 10
extresist
ext2spice lvs
ext2spice cthresh 0.01
ext2spice extresist on
set filename "$cellname"
set spicefilename [lindex [split $filename .] 0]
ext2spice -F -o "../pex/$spicefilename.spice"

Was there an error message when doing

ext2sim

?

The .ext was written to the PDK directory

Try using "extract do local" before "extract". Does that make a difference?

I tried

extract do local
extract all

but still get

Cannot open file sky130_fd_pr__pnp_05v5_W3p40L3p40.sim

I see this though:

Extracting

sky130_fd_pr__pnp_05v5_W3p40L3p40 into sky130_fd_pr__pnp_05v5_W3p40L3p40.ext:

Or. . . I think I recall this problem, which has to do with hierarchy. It might not even make a difference to the output. If it does, then you might want to flatten the circuit before you extract. "extresist" was originally only designed for a completely flat circuit layout, and my attempts to get it working hierarchically are something of a kludge; I have a development plan for it, but right now it is in a state that works, but may very well fail in a hierarchical circuit.

When I simulate I get unknown subckt errors:

Error: unknown subckt: x0.xpnps_0.xsky130_fd_pr__pnp_05v5_w3p40l3p40_0[0|0].x0 x0.amplifier_0/gnd x0.amplifier_0/gnd x0.pnps_0/sky130_fd_pr__pnp_05v5_w3p40l3p40_0[7|4]/emitter x0.xpnps_0.xsky130_fd_pr__pnp_05v5_w3p40l3p40_0[0|0].sky130_fd_pr__pnp_05v5 area=1.19887e+13p
    Simulation interrupted due to error!

Is this what you mean by doesn't simulate?

No; that's a known issue that was pointed out yesterday and I am working on today. Magic extracts a "generic" PNP model that doesn't actually exist---there are only models for the two specific layouts with fixed width and length. You'll need to do a string substitution on the output netlist and change device name

sky130_fd_pr__pnp_05v5

to

sky130_fd_pr__pnp_05v5_W3p40L3p40

.

Thanks. I've noticed something else w/ the PNP extraction. Netgen reports 2 separate PNPs, but it seems like 1 PNP has absorbed all of the area:

Subcircuit pins:
Circuit 1: sky130_fd_pr__pnp_05v5          |Circuit 2: sky130_fd_pr__pnp_05v5          
-------------------------------------------|-------------------------------------------
1                                          |1                                          
2                                          |2                                          
3                                          |3                                          
---------------------------------------------------------------------------------------
Cell pin lists are equivalent.
Device classes sky130_fd_pr__pnp_05v5 and sky130_fd_pr__pnp_05v5 are equivalent.
Class bandgapcorev3_flat:  Merged 38 devices.

Subcircuit summary:
Circuit 1: bandgapCore                     |Circuit 2: bandgapcorev3_flat              
-------------------------------------------|-------------------------------------------
sky130_fd_pr__res_xhigh_po_2p85 (4)        |sky130_fd_pr__res_xhigh_po_2p85 (4)        
sky130_fd_pr__pnp_05v5 (2)                 |sky130_fd_pr__pnp_05v5 (2)                 
Number of devices: 6                       |Number of devices: 6                       
Number of nets: 5                          |Number of nets: 5                          
---------------------------------------------------------------------------------------

But when I look at the extracted netlist, only 1 PNP has nonzero area:

* NGSPICE file created from bandgapcorev3_flat.ext - technology: sky130A

.subckt bandgapcorev3_flat Vb Vbg Va GND
X0 GND GND Vbneg sky130_fd_pr__pnp_05v5 area=4.79548e+14p
X1 GND GND Vbneg sky130_fd_pr__pnp_05v5 area=0p
X2 GND GND Vbneg sky130_fd_pr__pnp_05v5 area=0p
X3 a_6870_n27666# a_13606_n30120# GND sky130_fd_pr__res_xhigh_po_2p85 l=3.152e+07u
X4 VbEnd GND GND sky130_fd_pr__res_xhigh_po_2p85 l=2.15e+07u
X5 GND GND Vbneg sky130_fd_pr__pnp_05v5 area=0p
X6 a_6870_n22758# a_13606_n26848# GND sky130_fd_pr__res_xhigh_po_2p85 l=3.152e+07u
X7 GND GND Vbneg sky130_fd_pr__pnp_05v5 area=0p
X8 a_6870_n28484# VbgEnd GND sky130_fd_pr__res_xhigh_po_2p85 l=3.152e+07u
X9 GND GND Vbneg sky130_fd_pr__pnp_05v5 area=0p
X10 a_6870_n26030# a_13606_n23576# GND sky130_fd_pr__res_xhigh_po_2p85 l=3.152e+07u
X11 GND GND GND sky130_fd_pr__res_xhigh_po_2p85 l=3.152e+07u
X12 GND GND Vbneg sky130_fd_pr__pnp_05v5 area=0p
X13 GND GND GND sky130_fd_pr__res_xhigh_po_2p85 l=1.662e+07u
X14 GND GND Vbneg sky130_fd_pr__pnp_05v5 area=0p
X15 GND GND Vbneg sky130_fd_pr__pnp_05v5 area=0p
X16 GND GND Vbneg sky130_fd_pr__pnp_05v5 area=0p
X17 Vb Vbneg GND sky130_fd_pr__res_xhigh_po_2p85 l=3.152e+07u
X18 GND GND Vbneg sky130_fd_pr__pnp_05v5 area=0p
X19 GND GND Vbneg sky130_fd_pr__pnp_05v5 area=0p
X20 GND GND Vbneg sky130_fd_pr__pnp_05v5 area=0p
X21 GND GND GND sky130_fd_pr__res_xhigh_po_2p85 l=2.15e+07u
X22 GND GND Vbneg sky130_fd_pr__pnp_05v5 area=0p
X23 GND GND Vbneg sky130_fd_pr__pnp_05v5 area=0p
X24 GND GND Vbneg sky130_fd_pr__pnp_05v5 area=0p
X25 GND GND Va sky130_fd_pr__pnp_05v5 area=0p
X26 GND GND Vbneg sky130_fd_pr__pnp_05v5 area=0p
X27 GND GND Vbneg sky130_fd_pr__pnp_05v5 area=0p
X28 GND GND Vbneg sky130_fd_pr__pnp_05v5 area=0p
X29 GND GND Vbneg sky130_fd_pr__pnp_05v5 area=0p
X30 GND GND Vbneg sky130_fd_pr__pnp_05v5 area=0p
X31 GND GND Vbneg sky130_fd_pr__pnp_05v5 area=0p
X32 GND GND Vbneg sky130_fd_pr__pnp_05v5 area=0p
X33 GND VbgEnd GND sky130_fd_pr__res_xhigh_po_2p85 l=1.662e+07u
X34 GND GND GND sky130_fd_pr__res_xhigh_po_2p85 l=2.15e+07u
X35 GND GND Vbneg sky130_fd_pr__pnp_05v5 area=0p
X36 a_6870_n26030# a_13606_n29302# GND sky130_fd_pr__res_xhigh_po_2p85 l=3.152e+07u
X37 GND GND Vbneg sky130_fd_pr__pnp_05v5 area=0p
X38 GND GND Vbneg sky130_fd_pr__pnp_05v5 area=0p
X39 GND GND Vbneg sky130_fd_pr__pnp_05v5 area=0p
X40 GND GND GND sky130_fd_pr__res_xhigh_po_2p85 l=3.152e+07u
X41 VbEnd a_13606_n29302# GND sky130_fd_pr__res_xhigh_po_2p85 l=3.152e+07u
X42 GND GND Vbneg sky130_fd_pr__pnp_05v5 area=0p
X43 GND GND Vbneg sky130_fd_pr__pnp_05v5 area=0p
X44 GND GND Vbneg sky130_fd_pr__pnp_05v5 area=0p
X45 GND GND GND sky130_fd_pr__res_xhigh_po_2p85 l=1.662e+07u
X46 a_6870_n21122# Vb GND sky130_fd_pr__res_xhigh_po_2p85 l=3.152e+07u
X47 GND GND Vbneg sky130_fd_pr__pnp_05v5 area=0p
X48 GND GND Vbneg sky130_fd_pr__pnp_05v5 area=0p
X49 GND GND Vbneg sky130_fd_pr__pnp_05v5 area=0p
X50 GND GND Vbneg sky130_fd_pr__pnp_05v5 area=0p
X51 GND GND Vbneg sky130_fd_pr__pnp_05v5 area=0p
X52 a_6870_n27666# a_13606_n25212# GND sky130_fd_pr__res_xhigh_po_2p85 l=3.152e+07u
X53 a_6870_n21940# Va GND sky130_fd_pr__res_xhigh_po_2p85 l=3.152e+07u
X54 a_6870_n22758# Vbg GND sky130_fd_pr__res_xhigh_po_2p85 l=3.152e+07u
X55 VaEnd a_13606_n30120# GND sky130_fd_pr__res_xhigh_po_2p85 l=3.152e+07u
X56 GND GND Vbneg sky130_fd_pr__pnp_05v5 area=0p
X57 GND GND Vbneg sky130_fd_pr__pnp_05v5 area=0p
X58 GND GND Vbneg sky130_fd_pr__pnp_05v5 area=0p
X59 a_6870_n28484# a_13606_n26848# GND sky130_fd_pr__res_xhigh_po_2p85 l=3.152e+07u
X60 VaEnd GND GND sky130_fd_pr__res_xhigh_po_2p85 l=2.15e+07u
X61 a_6870_n21940# a_13606_n25212# GND sky130_fd_pr__res_xhigh_po_2p85 l=3.152e+07u
X62 GND GND Vbneg sky130_fd_pr__pnp_05v5 area=0p
X63 a_6870_n21122# a_13606_n23576# GND sky130_fd_pr__res_xhigh_po_2p85 l=3.152e+07u
.ends

There should be 1 single PNP connected to net Va, and the other parallel PNPs connected to Vbneg. How can it be that 2 distinct PNPs were found, yet only one has any area?

It's not critical here, because the W3p40L3p40 model has a fixed area. Magic is totalling all area on a single net, so you should run

ext2spice

with the

-d

option (distributed area/perimeter).

Oh right. As long as the number of extracted devices and their connected nets are correct the behavior will be right

I hadn't really considered what the lumped area method would do to devices like bipolars. My fix (if I get around to it today) would add the device size suffix to the model and also remove the "area=" from the line, because the area is hard-coded into the subcircuit and should not be passed as a parameter. I'm honestly not sure if the behavior will be right or not. It depends on whether the area parameter actually gets seen and parsed and overrides the default or not, and if so, whether the gummel-poon model will just basically cause a zero-area device to not exist. So, lots of unanswered questions. . .

Makes sense. I think I raised the same question on area here https://skywater-pdk.slack.com/archives/C016HUV935L/p1621315865013500

No idea. If you can bundle up a reproducible case, I'll look into it.