Missing poly/poly2 capacitor in cell with substrate tie about magic HOT 8 CLOSED

Maybe not on the right track. This diagram might help visualize the problem:

I believe that the diagram has issues: The poly2 resistor is shown at the same level as the poly -- in reality it will sit above. In the case of the poly/poly2 cap, two significant capacitors are formed: 1) between the poly2 and poly layers, and 2) between the poly layer and substrate.

In the cases shown above the capacitor between poly and substrate is shorted since both are connected to vss. So it makes sense that it be subtracted out. So what's missing is the cap between poly2 (node n2x) and substrate (node vss). In the case with the substrate tie (cap_tc1), vss has this "dual personality" that it seems that extract isn't aware of. ....getting closer?

from magic.

Hello Dan,

I believe that all problems here are potentially resolvable in the technology file. What technology file are you using, and does it use the "substrate" line in the "extract" section?

It is probably better to change the technology file to have poly and poly2 on different planes. In the past, magic could not represent a capacitor device between two different planes, but it can do that now. The right way to treat these is to have the poly-poly2 cap as a device, and the poly-substrate cap as a parasitic.

from magic.

I'm using the SCN3ME_SUBM.30.tech file from the qflow repository with just a couple of modifications. Yes it does have the substrate line:

substrate *psd,space/w,pwell well $SUB

...and I'm setting the SUB variable to "vss" in the .magicrc file.

$ diff SCN3ME_SUBM.30.tech.orig SCN3ME_SUBM.30.tech
6062,6063c6062,6064
<  spacing gc gv1 2 touching_illegal \
<  "GC contact spacing to GV1 via < 2 (Mosis #8.4)"
---
> # AMI / ON Semi 0.50 (C5F/N): Rule 8.4 is waived
> # spacing gc gv1 2 touching_illegal \
> # "GC contact spacing to GV1 via < 2 (Mosis #8.4)"
6149,6150c6150,6152
<  spacing gv1 gv2 2 touching_illegal \
<  "GV1 via spacing to GV2 via < 2 (Mosis #14.4)"
---
> # AMI / ON Semi 0.50 (C5F/N): Rule 14.4 is waived
> # spacing gv1 gv2 2 touching_illegal \
> # "GV1 via spacing to GV2 via < 2 (Mosis #14.4)"
6438c6440
<  overlap (poly,fp,rp,pc,pc)/active (poly2,ecap,phr,p2c)/cap    82.260
---
> # overlap (poly,fp,rp,pc,pc)/active (poly2,ecap,phr,p2c)/cap   82.260
6604a6607,6609
> 
> # device capacitor model top_types bottom_types [perim_cap] area_cap 
> device capacitor poly2Capacitor (poly2,ecap,phr,p2c)/cap (poly,fp,rp,pc,pc)/active 82.26

I've commented out the overlap for the poly/poly2 parasitic cap and added the device cap.

For this layout:

I now get this spice netlist:

* NGSPICE file created from res_tc1.ext - technology: scmos

.subckt res_tc1 n2x vss n1 n2
C0 n2x n2 poly2Capacitor w=6.6u l=6.6u
C1 n1 vss 11.69fF
C2 n2 vss 6.40fF
.ends

C1 is the 10.0 x 12.3 um piece of poly on the right. Yes, there's the cap with the model (C0), dimensions are correct. So that leaves us with the C2 cap between n2 and substrate. It's close to what's left over after carving out the poly2/poly cap (assuming that that is what's going on). I get 7.55 fF. How is that 6.40 fF cap being calculated and what does it represent?

But what troubles me more is the missing 6.6 x 6.6 um poly cap (the poly-to-sub cap underneath the poly2/poly cap). There should be another ~ 4.14 fF from n2 to vss. Unless this is supposed to be accounted for in the cap model?

Nah, that's for "implant" cap. So maybe this should be extracted as a subckt instance instead?

e.g.

XC0 n1 n2 vss poly2Capacitor w=6.6u l=6.6u

.subckt poly2Capacitor a b sub w=2.0u l=2.0u
C0 a b {w*l*0.91e-15}
C1 b sub {w*l*0.12e-15}
.ends

But I don't know how to get extract/ext2spice to do this. I could post-process the spice file, but that doesn't feel quite right.

from magic.

More clues (and funny behavior): label position affects extract

Not sure if this is a new issue or is related to this one.

Four layouts: All a single poly2/poly capacitor, difference is the position of the "b" label on the metal1. The position of the label on the metal 1 affects the extraction file and the derived spice file. The label was created with "label b ne -metal1"

Well, the last one (ppcap_tc4) is slightly different in that the poly2 contact is smaller.

Here are the resulting spice files:

$ cat ppcap_tc{1,2,3,4}.cir
* NGSPICE file created from ppcap_tc1.ext - technology: scmos

.subckt ppcap_tc1 a  b 
C0 b  a  poly2Capacitor w=6.6u l=6.6u
.ends
* NGSPICE file created from ppcap_tc2.ext - technology: scmos

.subckt ppcap_tc2 a  b 
C0 b  a  poly2Capacitor w=6.6u l=6.6u
C1 a  vss 3.90fF
.ends
* NGSPICE file created from ppcap_tc3.ext - technology: scmos

.subckt ppcap_tc3 a  b 
C0 b  a  poly2Capacitor w=6.6u l=6.6u
C1 a  vss 4.85fF
.ends
* NGSPICE file created from ppcap_tc4.ext - technology: scmos

.subckt ppcap_tc4 a  b 
C0 b  a  poly2Capacitor w=6.6u l=6.6u
C1 a  vss 3.52fF
.ends

The position of the label shouldn't affect the electrical characteristics. Same tech file as before (attached).
tech.tar.gz

.mag/.ext/.cir files attached

ppcap.tar.gz

Hmmm, moving label "b" around affects subcap "a":

$ grep -e 'node \"b' -e 'subcap' ppcap_tc{1,2,3,4}.ext
ppcap_tc1.ext:node "b " 42 1243.2 30 18 m1 0 0 0 0 0 0 0 0 0 0 0 0 484 88 0 0 102 56 0 0 0 0
ppcap_tc1.ext:subcap "a " -10683.7

ppcap_tc2.ext:node "b " 42 1243.2 43 24 m1 0 0 0 0 0 0 0 0 0 0 0 0 484 88 0 0 102 56 0 0 0 0
ppcap_tc2.ext:subcap "a " -7789.44

ppcap_tc3.ext:node "b " 42 1243.2 46 26 m1 0 0 0 0 0 0 0 0 0 0 0 0 484 88 0 0 102 56 0 0 0 0
ppcap_tc3.ext:subcap "a " -6843.72

ppcap_tc4.ext:node "b " 42 1243.2 46 18 m1 0 0 0 0 0 0 0 0 0 0 0 0 484 88 0 0 102 56 0 0 0 0
ppcap_tc4.ext:subcap "a " -8174.28

from magic.

The label position affecting the parasitic capacitance calculation is a weird one, I'll admit.

I am deeply buried in the Google/SkyWater project right now and will have practically no time to look at it this month, although I might have a little breather time after my FOSSi presentation next week.

from magic.

I understand. Meanwhile I'm educating myself in the concepts or planes, tiles and regions.

As for putting poly2 on the same plane as poly (named "active" in this case), that would result in a considerable rewrite of the tech file including drc rules, extract section (and not limited to declaring the poly/poly2 as a device), types, etc.... I experimented with doing this and it isn't a "simple" fix.

If you're nearly convinced that this is the correct solution, then I'll continue down this route.

Also, I've looking at the "moving label b changes a's capacitance" issue. ...studying the functions in the extract/ExtCouple.c file...

from magic.

The original issue of the vanishing poly/poly2 cap appears to be resolved by a customized techfile. However I haven't worked through all of the new issues introduced (e.g. DRC, GDS out, ....). I'll follow up shortly with more details and close this issue.

The "moving label changes the extract" issue appears to be separate. I'll open a new issue and provide a self-contained test case for that one.

from magic.

@RTimothyEdwards : thanks for the suggestion that this could be resolved with a modified tech file. I started with the SCN3ME_SUBM.30.tech file from the qflow repository. Putting poly2 on the active plane (removing the cap plane) caused all sorts of mayhem. I have much of it worked out now, but still have a few things to do and plenty of testing to go.

Here are the resulting netlists using magic version 8.3.82 and the modified tech file:

* NGSPICE file created from cap_tc1.ext - technology: scmos

.subckt cap_tc1 n2 n2x vdd vss
C0 n2x vss poly2Capacitor w=6.6u l=6.6u
C1 n2 vdd poly2Capacitor w=14.4u l=4.8u
C2 vss vdd poly2Capacitor w=10.2u l=4.8u
C3 n2 vss 2.29fF
C4 vdd vss 16.03fF
.ends

* NGSPICE file created from cap_tc2.ext - technology: scmos

.subckt cap_tc2 n2 n2x vdd vss
C0 n2x vss poly2Capacitor w=6.6u l=6.6u
C1 n2 vdd poly2Capacitor w=14.4u l=4.8u
C2 vss vdd poly2Capacitor w=10.2u l=4.8u
C3 vss vss 13.90fF
C4 n2 vss 2.29fF
C5 vdd vss 16.03fF
.ends

In the second netlist, cap C3 probably shouldn't be there. Looks like ext2spice isn't detecting the shorted cap. Do you consider this a bug? ....if so, I can look at a fix.

This issue (the original issue) is resolved -- a change to magic source code isn't necessary.

from magic.