Capacitance calculations

[d-m-bailey]

@RTimothyEdwards I was wondering if the new substrate processing would effect capacitance calculations. You said that extraction erases pwell before redrawing. Is capacitance calculated after that?

Also, what about capacitance over isosub regions?

[RTimothyEdwards]

Doesn't affect it at all, if you write the techfile correctly. The parasitic capacitances to substrate have to include both pwell and isosub. Each layer should have a pair like this in the technology file:

 defaultoverlap     allli locali dnwell,isosub       dwell 36.99
 defaultareacap     allli locali nwell,obswell,pwell well  36.99

The first line calculates the overlap capacitance of any material to (pwell in) deep nwell or isosub (both on the dnwell plane, which is below the well plane, and so anything on the well plane such as nwell or pwell shields this capacitance), and the second calculates overlap capacitance to nwell, obswell, and pwell (in addition to space) on the well plane.

All that having been said, (1) the defaultareacap documentation is missing any explanation of the 3rd argument, and (2) the first of the two statements is missing in the sky130 tech file for the poly layer. I will have to go fix all of those now.

The "new substrate processing" is only doing one thing, really, which is enforcing that the "pwell" layer should only be drawn over isolated substrate regions, and not over the default substrate. Since the "pwell" layer was declared optional in the techfile by specifying both it and "space/w" as substrate types, then the (existing) calculations should be correct whether or not "pwell" is drawn, since it's optional. The "new substrate processing" is merely applying a more rigorous standard for where the "pwell" layer should and shouldn't be drawn, so that the extraction method doesn't get confused by it.

(I need to make some corrections in open_pdks today, so I will also push the correction to the missing statement for poly to dnwell and isosub.)

[RTimothyEdwards]

After reading over the code comments, the PDK tech file, and the documentation several times, I have become thoroughly confused and realize that the documentation for the simplified parasitic extraction methods needs a pretty substantial overhaul. But also, I'm not sure whether the optional arguments for "defaultareacap" and "defaultperimeter" are needed. The "substrate" statement should contain all the relevant information about what layers contribute to, and shield from, the substrate. I will review this shortly.

[RTimothyEdwards]

This layout demonstrates the parasitics from metal1 to substrate or wells in a number of different situations including deep nwell, nwell, overlapping local interconnect, isolated substrate, nwell over deep nwell, etc. It already revealed one error in the sky130.tech file where a parasitic definition used the wrong arguments because they had been accidentally copied from a different parasitic statement. But after fixing that, there is clearly a problem where the shielding types are being determined differently for area capacitance than they are for perimeter capacitance, because there are a lot of problems surrounding the capacitance extraction over deep nwell, and that's showing up as perimeter capacitance being doubled in some cases, or not counted at all in other cases. So I'm debugging the parsing in ExtTech.c now. See the README in the zip file below for details of the ongoing analysis.

parasitics.zip

[RTimothyEdwards]

@d-m-bailey : After a lot of work between yesterday and today, I resolved the main issues around the way that the isolated substrate regions are handled by the parasitic capacitance calculations. My torture test in the zip file posted above now correctly computes the parasitic capacitances except in two cases. One of those involves the "obswell" layer, which being an abstract view's obstruction layer, doesn't really have a properly defined solution, and can be ignored. The other one is very concerning to me. I put a stack of metal1 over local interconnect over deep nwell, and the capacitance from metal1 to substrate comes out. . . negative. What I found is that for any stack involving more than one type shielding another type from the substrate (in this case, local interconnect and deep nwell, but it also works with a stack of, say, metal1-metal2-metal3), the shielding effect gets calculated independently for each of the shields, resulting in too much substrate capacitance being subtracted off to account for the shielding.

Well, there is something going on because the area capacitance is correctly accounted for, but the perimeter capacitance is not. Both use a variable called "areaAccountedFor" to prevent double-counting any part of the area or perimeter. But it's not working in the case of perimeter. I think it's most likely that something just got broken.

[d-m-bailey]

@RTimothyEdwards Could this be serendipitously related to https://github.com/RTimothyEdwards/magic/pull/135/files? @antonblanchard

[RTimothyEdwards]

No, and good thing. When related things get worked on at the same time, doing a git merge can become a mess.

[antonblanchard]

The issues that caused me to create RTimothyEdwards/magic#135:

Missing prototype for function that returns float:

lef/lefTech.c:          float oscale = CIFGetOutputScale(1000);

The others are int vs long issues which are likely not as fatal as int vs float, but could still be problematic:

+extern PlaneMask CoincidentPlanes(TileTypeBitMask *typeMask, PlaneMask pmask);

PlaneMask might be a long.

+long extSubtreeTotalArea;      /* Total area of cell */
+long extSubtreeInteractionArea;        /* Total area of all interactions, counting the
+long extSubtreeClippedArea;    /* Total area of all interactions, counting only

These were all defined as int, but prototypes said they were long.

[RTimothyEdwards]

@d-m-bailey : I have finished (for now, anyway) my fixes for the capacitance extraction. I was not aware of how broken the capacitance extraction had become, mostly due to the changes in the way substrate was handled. A simple "towers of Hanoi" stack of metal completely failed to get any of the shielding correct. I have restored sanity. The only thing that still does not extract correctly in the example layout I posted above is the "obswell" layer, which as I noted in a previous post is probably not worth pursuing.