Deep well and substrate extraction for caravel chip_io

[d-m-bailey]

@RTimothyEdwards Moving the slack conversation here.

By flattening the subcells and making a few minor changes to the layout recognition layers and netlists, I'm able to get most of the io cells in caravel's chip_io block to pass netgen LVS with only property errors.

I'm having a problem with pwell connections of sky130_ef_io__gpiov2_pad_wrapped. Using the current tech file, I get disjointed pwells which are probably connected via substrate. black=nwel, yellow=dnwell, orange=pwel

I would expect pwell to be everything except nwell, but the rule file definition is

 layer pwell TAP,DIFF
 and-not NWELL,nwelcheck
 grow 130
 or SUBTXT,SUBPIN
 grow 420
 shrink 420

I've tried to modify the rule file without success. These didn't work.

layer pwell bbox
and-not NWELL,nwelcheck

layer pwell ~(NWELL,nwelcheck)/well

Also, NWEL has a copyup statement. Does that mean that the layer is copied to higher levels of the hierarchy? Should DNWEL and SUBCUT also have a copyup statement.

[RTimothyEdwards]

The rule for pwell was meant to deal with the known issue that magic tends not to extract substrate regions correctly if they are drawn in disjoint pwell areas (which is a known issue, currently being worked on).

My extraction method of the moment is to first draw pwell over the entire cell at the beginning of extraction, and erase everything that would constitute a blocking area (deep nwell, nwell, isosub). If there are no isolated regions formed by that, the step is ignored.

I found out from the last failing example posted two problems with the above method: (1) By ignoring the step if no isolated regions are formed, I am causing the problem mentioned at the top, where separated pwell regions drawn in the layout aren't implicitly connected together by extraction. This would be easy enough to fix, except then I realized that (2) Isolated substrate regions with isosub that are surrounded by pwell, there's no way to separate them. The above-mentioned step would paint pwell over the cell, erase the area under isosub, then after noting that there is an isolated region, it would draw pwell back into that area which then just merges again with the other pwell. So I will have to have special layer types for isolated pwell regions. That will take a bit of work to implement.

Anyway, the main points are that (1) anything you do to manipulate pwell when reading GDS is likely not going to have any effect because magic will redraw the pwell itself before extraction, and (2) there are probably situations in the GPIO cells that fail for the two reasons just mentioned.

As for "copyup"---The point of "copyup" is that magic's layer types are typically derived from combinations of input GDS layers; e.g., other tools draw a contact cut, but magic has "poly contact" (poly + cut + metal) and "ndiff contact" (diff + n-implant + cut + metal), and if a cell in the GDS input contains some but not all of the constituent layers, then it can't build the correct derived type. So "copyup" only makes sense for layers which are part of derived layers. Deep nwell and isolated substrate don't interact with other types, so use of "copyup" wouldn't do anything useful.

[d-m-bailey]

@RTimothyEdwards If I understand correctly, pwell extraction is partially hard coded in magic? There's no way to change this via the techfile?

The changes I'm trying to make are

1. move the substrate layer to the dwell plane
2. add a dpwell layer on the dwell plane
3. use SUBCUT to split pwell, dpwell, and substrate rather than use it as a separate connection layer
   Here are my current rules (that don't work)

types
# Deep nwell
  dwell dnwell,dnw
  dwell dpwell,dpw
  #dwell isosubstrate,isosub
  dwell photodiode,photo
...
 -comment isosub
 -comment isoring

connect
...
  pwell,*psd,*mvpsd,npn,dpwell  pwell,*psd,*mvpsd,npn,dpwell

cifinput
...
 templayer largeiso SUBCUT
 grow 10

 layer isoring largeiso
 and-not SUBCUT
...
 layer pwell bbox
 and-not NWELL,nwelcheck
 or SUBTXT,SUBPIN
 and-not isoring
 variants (vendor)
 labels SUBTXT port
 variants ()
 labels SUBTXT text
 variants *
 labels SUBPIN port

 layer dnwell DNWELL
 labels DNWELL

 layer dpwell bbox
 and-not DNWELL,isoring

 layer isosub SUBCUT
 #labels SUBCUT

extract
...
 substrate dpwell dwell $SUB

I also change the isosub capacitance extraction rules, but I don't think that's relevant to the extraction, so I didn't list the changes here.
The isoring layer is only created on gdsin, so it's not a valid tech file for gdsout or layout changes within magic, as is.

Also, in regards to copyup, your explanation matches what I read in the manuals, but the rule file has this

 templayer nwellarea NWELL
 copyup nwelcheck

 # Copy nwell areas up for diffusion checks
 templayer xnwelcheck nwelcheck
 copyup nwelcheck

nwelcheck is not defined anywhere; does that mean it's a copy of nwellarea? When nwelcheck is used to calculate xnwelcheck, do we need to copyup again to keep it from being deleted?
And then with the diodes

 templayer ndiodearea DIODE
 and NSDM
 and-not HVI,hvcheck
 and-not NWELL,nwelcheck
 copyup DIODE,NSDM
...
 templayer mvndiodearea DIODE
 and NSDM
 and HVI,hvcheck
 and-not NWELL,nwelcheck
 copyup DIODE,NSDM

Does this copy only the DIODE and NSDM related to the respective templayer?

[RTimothyEdwards]

No, it's not hard-coded at all. It depends on the substrate line in the tech file. But it does make certain assumptions, such as that there is a type defined (e.g., pwell) that represents the substrate.

Be very careful reassigning the substrate because I have slowly worked out this method with substrate being on the plane above deep well, such that pwell (substrate) and pwell-in-deep-nwell are both represented by the same type, on the same plane. Deep nwell is then defined as a "shield" type that shields pwell-in-deep-nwell from the substrate.

If you define "substrate" as not including space, then dpwell must be drawn everywhere that is not an nwell, or else nFETs not in dpwell will get their bulk terminal disconnected from everything.

"copyup nwelcheck" creates a new templayer called "nwelcheck" on the fly. In the expression "templayer nwellarea NWELL ; copyup nwelcheck", this separates the copied layer "nwelcheck" from all other NWELL, so that it doesn't end up creating actual layer geometry in every hierarchical cell above where it's actually drawn. The idea is to keep track of where layers exist in subcells for the purpose of figuring out how to deal with derived layers that have been split between cells, but not to actually copy those layers themselves up the hierarchy.

When the "copyup" is at the end of a recipe like "copyup DIODE,NSDM", it is taking whatever geometry is remaining at that point in the recipe and copying it up into the parent cell as layers DIODE and NSDM; it's actually making two copies of the same geometry. Unlike the previous case, here I'm not trying to avoid copying an actual layer up. In this recipe, I have determined that there exists a DIODE layer in this cell that needs additional information to cast it into a specific derived type (e.g., ndiode, pdiode, mvndiode, etc.), but that there are insufficient other layers in the cell to be able to make a derived type. Without those layers, there would be no recipe for any derived layer, and the DIODE layer will get ignored, and the diode that is presumably there will get eliminated from the layout. So the solution is to rip the diode out of the cell and move it up one level of the hierarchy, on the assumption that the extra layers needed to determine what kind of diode it is will be found there, and the diode derived type can be created. This of course rearranges the whole layout from what was in the GDS file. But it works. The recipes around "copyup" tend to get complicated and hard to follow---as you have probably noticed---so I tend to add in only what I need to cover some case I find in a vendor file. Most of the "copyup" statements in the sky130 tech file have been put there to cope with the I/O library layouts.

[RTimothyEdwards]

Honestly, you can't extract a device unless you know what kind of a device it is. Which is why I can't understand why it isn't a rigorous standard in layout to include all layers that define a unique device in the same cell. Apparently software like Calibre has gotten so clever that it will figure out how to extract anything no matter how convoluted the layout is. Accordingly, having no pressure to design things well, layout engineers just create ridiculously convoluted layouts. But if you do something like putting poly and diffusion in cell X, and then instantiating cell X inside parent cell Y, once over nwell and once not, then cell X contains a transistor which is either a pFET or an nFET, depending on context. A clever extractor will then split cell X into two context-dependent cells X[1] and X[2], one with an nFET and one with a pFET, or else just flatten X into parent Y such that X no longer exists. Because of the way magic's database works, magic can't do this during extraction but is forced to figure it out when GDS is read in. Magic's database inherently does not allow devices to be split across cells.

[d-m-bailey]

@RTimothyEdwards Thought I had something working for chip_io, but had problems in mgmt_protect.

Now I'm trying to make a large pwell/dpwell area and subtract nwell/dnwell from that. Seems pretty straightforward but I'm not getting the expected results. pwell should not overlap nwell or isoring, but does. Any idea why?

black:nwell, yellow:dnwell, orange:pwell, green:isoring (barely visible)

I'm using the following rules, but it doesn't look like the subtraction is working. Does the resulting pwell polygon have too many vertices? Does magic have problems with and-not when subtracting a shape that completely internal? Does the large grow size cause problems?

 layer pwell TAP,DIFF,NWEL,DNWEL,SUBTXT,SUBPIN
 grow 10000
 and-not NWELL,nwelcheck,isoring

[d-m-bailey]

@RTimothyEdwards You can ignore the previous question. I wasn't flattening the io subcells and incomplete layouts caused the problem. When I flattened the cells before loading, the dpwell and pwell areas displayed as expected.

[d-m-bailey]

@RTimothyEdwards I think the problem I was having with the current magic extraction rules dealt with pwel over dnwel inside SUBCUT. I was surrounding all the individual io cells with SUBCUT, but maybe that's overkill.
I'm currently investigating rule changes that move the substrate layer to the dwell plane. I'm also using copyup on the SUBCUT layer so hopefully it won't be necessary to add SUBCUT to higher level hierarchies.
I may be running into problems with the sram module in the mgmt_core. dnwel is added at the top level and I'm wondering how magic handles hierarchical substrate connections.

[RTimothyEdwards]

@d-m-bailey : You can't put isosub and dnwell in the same place because they exist on the same plane---or at least that was the original intent. I guess if you moved "isosub" to the comment plane then it is no longer a problem. I would not expect that isosub + dnwell would be an issue, though, because they are both classified as layers which shield the substrate.

[d-m-bailey]

@RTimothyEdwards I thought I was getting closer to a solution, but it appears that the rule changes I was trying don't work correctly when dnwel is added at a higher level of the hierarchy as with the sram modules. I get a vssd1-vccd1 merge short. LVS passes with the original magic rules. How does that work? In the lower hierarchy, there are connections to substrate via pwel (because dnwel doesn't exist) but at the higher levels, the pwel connection to substrate is blocked.

Is there an easier way to narrow the search for a short by looking at what nets are merged in the ext file? For example,

merge "EP_CZ_sky130_sram_1kbyte_1rw1r_32x256_8_data_dff_0/gnd_uq30" "EP_CZ_sky130_sram_1kbyte_1rw1r_32x256_8_contact_39_1/m1_0_6#"
merge "EP_CZ_sky130_sram_1kbyte_1rw1r_32x256_8_contact_39_1/m1_0_6#" "vccd1"
merge "vccd1" "EP_CZ_sky130_sram_1kbyte_1rw1r_32x256_8_wmask_dff_0/EP_CZ_sky130_fd_bd_sram__openram_dff_0/gnd"

Does this mean that EP_CZ_sky130_sram_1kbyte_1rw1r_32x256_8_wmask_dff_0/EP_CZ_sky130_fd_bd_sram__openram_dff_0/gnd is closely connected to vccd1?

Other questions and observations:
The manual states that the copyup operation can only be used with templayer. It appears that this is correct and that adding copyup to a normal layer operation will be silently ignored.
Are templayers only valid in the cifinput section? I'm trying to use one as a blocking layer in the substrate of the extract rules, but not getting the results I expect, although no syntax errors.
Are the blocking layers of the substrate statement subtracted from the connection layers (as in and-not) or are they ignored if enclosed by a blocking layer?

Here's what I'm currently trying to do (a few changes from the previously reported method):

 # Create a temporary cumulative nwel region
 templayer nwellarea NWELL,nwelcheck
 copyup nwelcheck

 # create a cumulative isolation region from the bottom up
 templayer isoarea SUBCUT,loweriso
 copyup loweriso

 # create an isolation ring around the cumulative isolation areas, This has been verified to work correctly.
 layer isoring isoarea
 grow 100
 and-not isoarea

 # create a temporary cumulative bulk region for calculating pwell and dpwel. All inside SUBCUT becomes bulk.
 templayer bulk TAP,DIFF
 grow 180
 or SUBCUT,NWEL,DNWEL,SUBTXT,SUBPIN,lowerbulk
 grow 500
 shrink 500
 copyup lowerbulk

 # pwell is the bulk region except for the nwelarea and isoring. The isoring does not appear to be subtracted.
 layer pwell bulk
 and-not nwellarea,isoring
 variants (vendor)
 labels SUBTXT port
 variants ()
 labels SUBTXT text
 variants *
 labels SUBPIN port

 layer dnwell DNWELL
 labels DNWELL

 # Create a cumulative dnwel region
 templayer dnwellarea DNWELL,dnwellcheck
 copyup dnwellcheck

 # pwell is the bulk region except for the dnwelarea and isoring. The isoring does not appear to be subtracted 
 layer dpwell bulk
 and-not dnwellarea,isoring

 layer isosub SUBCUT

...
extract
...
  substrate dpwell,space/dwell dwell $SUB -isosub,isoring,loweriso

Here loweriso is a temporary layer that may not be usable here. isoring is a cumulative layer, but isosub is not: maybe this is the problem.
I am expecting everything on the substrate level to be implicitly connected, i.e. dpwell and space/dwell.
Inside SUBCUT, there is only dpwell or dnwell on the dwell plane.

Explaining this gave a couple ideas I can try. Please let me know if you have any suggestions.

[RTimothyEdwards]

Yes, for the question about the merge line in the .ext file. Each line that contains a bunch of numbers (usually mostly zeros) is starting a new net. That's followed by a series of merge connections of the form merge A B, merge B C, merge C D, etc., that all form a single net. So yes, the extraction deck you referenced implies that the SRAM ground is shorted to vccd1. However, the merge lines are not in any kind of connectivity order, so it will be difficult to determine what, exactly, is shorted. If you can select the whole net in magic, you can at least see if prior to extraction magic thinks these are shorted (although waiting for magic to trace through the entire power network of caravel can be painful) (although you can ctrl-C out of the search from the terminal where magic was launched from). If both networks appear shorted in magic, then from that massive selection you can do select short vssd1 vccd1 and get what might be a reasonably direct path between the two. If magic doesn't show that the nets are shorted by selection, then the issue is probably caused by extraction rules.

I have been working on these rules and the division into the deep-well and well planes for a while now, the purpose being to try to get the extraction to do the correct thing in the presence of deep nwell structures that may or may not be in the same cell as the transistors which are suposed to be in the isolated pwell. This has proven to be quite a pain. I know there are still issues with it, which is why trying to resolve the problems through manipulating the tech file might never achieve the desired result, because the issue is that the implementation is wrong in magic's source code, not the tech file.

I have not read completely through your comments above. I'll write more once I have.

[RTimothyEdwards]

@d-m-bailey : I just pushed a change to magic (8.3.269) that adds one more step to the extraction's preparation of the substrate plane, which is to erase all of the pwell layer (this is done under the assumption that "pwell" is declared in "substrate" along with "space/w", meaning that "pwell" is an optional layer that has no real meaning), followed by the existing steps of painting "pwell" back into all areas that are isolated substrate regions (pwell in deep nwell, or isosub regions). This may very well play havoc with your own modifications (although it's not supposed to). It does solve the issue that Anton Blanchard found where some substrate connections got isolated from the rest, and I think it should solve some of the issues that were showing up in the I/O cells (before you made modifications).

[d-m-bailey]

@RTimothyEdwards I think I'm going to give up on trying to put the substrate below dnwell. I can't figure out how magic handles hierarchical extraction where dnwell is added at a higher level as in the sram modules.
Do the changes in 8.3.269 require a corresponding rule change?

[d-m-bailey]

@RTimothyEdwards You mentioned that SUBCUT was tricky because it had to be present on all levels of the hierarchy. I'm thinking that the same might be true for DNWEL (also a substrate masking layer). When extracting from GDS, it might be possible to do this automatically with copyup, but I haven't been able to get anything functional.
pwel is created on cifinput from TAP and DIFF, but did you say that it gets erased during extraction (i.e., no connectivity) or was that just in regards to substrate calculation? How is SUBTXT handled?

[d-m-bailey]

@RTimothyEdwards magic 8.3.274 seems to be extracting the substrate node separately even when it's connected. This appears to happen only if there's a substrate shielding layer present. For example, extracting spare_logic_block standalone yields a netlist with VNB and VGND connected. However, when extracting as part of caravel, VNB and VGND are separate ports connected at the parent hierarchy. Still investigating and will hopefully be able to prepare a test case.

[d-m-bailey]

See #139

[d-m-bailey]

@RTimothyEdwards Thinking about substrate/well connectivity hierarchically.

The ext files contain connections for substrate/well that are used to merge abutting/overlapping tiles on the same plane, correct? That's one of the reasons that magic requires the same SUBCUT layer on all parent hierarchies, I think. chip_io extraction yields a bunch of disconnected nets to internal dnwell isolated pwell. I was wondering if it would be possible to define isolated wells that don't get propagated hierarchically. For example, pwell in dnwell and isosub could be defined to only have connectivity on the level they are first encountered. This would hopefully eliminate the extra chip_io ports and the need to propagate SUBCUT layers to higher hierarchies.