Missing poly/poly2 capacitor in cell with substrate tie

[mooredan]

This is a continuation of the issue first posted on the magic listserv in June 2020 : http://opencircuitdesign.com/pipermail/magic-dev/2020/000751.html

Some issues observed have been resolved, however one remains:

Please consider these two cells which contain three poly/poly2 capacitors. These layouts are identical except for the for substrate tie to vss. Cell cap_tc1 has the tie, and cell cap_tc2 does not.

After extraction and translation to a SPICE subcircuit, I would expect to see the three capacitors in the SPICE subcircuit (along with any stray caps):

• a large cap connected between vdd and node n2
• a small cap connected between n2x and vss
• an in-between cap connected between vdd and vss

Here are the resulting .cir files:

$ cat cap_tc{2,1}.cir
* NGSPICE file created from cap_tc2.ext - technology: scmos

.subckt cap_tc2 n2 n2x vdd vss
C0 vdd n2 63.27fF
C1 vdd vss 60.69fF
C2 n2x vss 41.06fF
C3 n2 vss 2.29fF
.ends
* NGSPICE file created from cap_tc1.ext - technology: scmos

.subckt cap_tc1 n2 n2x vdd vss
C0 n2 vdd 63.27fF
C1 vdd vss 60.69fF
C2 n2 vss 2.29fF
.ends

I believe that the first subckt (cap_tc2.cir) is correct. It has the expected capacitors at about the expected values. However, note that the second subckt (cap_tc1.cir) is missing the capacitor between port/node n2x and substrate (vss). This is the poly/poly2 cap in the lower left of the layout.

The extract file of cell cap_tc1:

$ cat cap_tc1.ext 
timestamp 1593139151
version 8.3
tech scmos
style AMI0.5um(amic5)from:T11Z
scale 1000 1 30
resistclasses 82400 102700 816000 816000 1 22300 41300 41300 90 90 60
port "vdd" 3 25 78 25 78 m1
port "n2x" 2 45 24 45 24 m1
port "n2" 1 72 57 72 57 m1
port "vss" 4 85 2 85 2 m1
node "vdd" 151 60693.5 25 78 m1 0 0 0 0 0 0 0 0 0 0 2781 314 0 0 0 0 696 244 0 0 0 0
node "n2x" 42 41057 45 24 m1 0 0 0 0 0 0 0 0 0 0 0 0 484 88 0 0 102 56 0 0 0 0
node "n2" 125 2286.6 72 57 m1 0 0 0 0 0 0 0 0 0 0 0 0 768 128 0 0 206 108 0 0 0 0
substrate "vss" 0 0 85 2 m1 0 0 120 44 0 0 0 0 0 0 1056 130 544 100 0 0 1045 406 0 0 0 0
cap "n2" "vdd" 63265.7
subcap "n2x" -39813.8

The capacitance value for node "n2x" (41057) matches the value seen in cell cap_tc2's subcircuit. It appears that it evaporated. Well, it didn't. When the ext2spice command is run, the negative subcap value for "n2x" is added to the node value ( 41057 - 39813.8 = 1243.2 aF). This is less than the LocCapThreshold (eff. 2000 aF) in ext2spice.c so it doesn't get output to the SPICE file.

It appears that the "subcap "n2x" -39813.8" line in the .ext file is suspect. This gets added by the extSubtreeInteraction() function in extract/ExtSubtree.c file. Maybe this line shouldn't be added since the presumably correct value is already on the node line.

If I comment out the subcap line in the cap_tc1.ext file, then the expected SPICE subcircuit is output:

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

.subckt cap_tc1 n2 n2x vdd vss
C0 n2 vdd 63.27fF
C1 vdd vss 60.69fF
C2 n2x vss 41.06fF
C3 n2 vss 2.29fF
.ends

TCL commands used to extract:

set SUB vss
load cap_tc1
extract warn all
extract

Note: the "set SUB vss" is a don't care and extract produces the same .ext file with and without the SUB variable being defined.

If desired, I can assemble a self-contained test case for anyone who is interested in investigating this further.

Am I on the right track for finding a solution to this? It seems that one would want to know if the substrate cap was already included in the node value and decide if an adjustment is needed. Sorry, it's not clear to me when (or even if) the subcap line is necessary.

Thanks, Dan

[mooredan]

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?

[RTimothyEdwards]

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.

[mooredan]

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.

[mooredan]

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

[RTimothyEdwards]

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.

[mooredan]

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...

[mooredan]

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.

[mooredan]

@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.