Subcell not showing up in LVS netlist extraction

barlow

I have a weird issue with LVS extraction in hierarchal cells. I'm trying to sanitize my circuit as much as possible, but I don't have an example GDS/SPICE to share and I think I need to isolate the problem better to make a test case using public kits. The GDS file originates from a separate tool from KLayout. My circuit uses hierarchy. Previously, I verified that this cell is LVS clean with a flattened hierarchy check. I have verified all subcells at all levels are LVS clean in both flat and hierarchal checks. Moving to a hierarchal check, I'm expecting green all around. Below is the cell hierarchy, which should be identical in both the schematic and layout:

When I run LVS hierarchically, the Cross-reference tab is complaining that the "BUF1" cell is not found in the layout extracted netlist. I've tried renaming this cell to various things to ensure that there isn't something odd with similar-looking names. There are 8 instances of the BUF1 cell in the layout, and none of them are showing up in the hierarchal extracted netlist (see below).

Now I have been able to identify a way to get the "BUF1" cell to show up. In the layout, every other "BUF1" cell is mirrored around the X-axis (vertically flipped). There is overlap on both the top and bottom of each cell. If I delete all the flipped instances of "BUF1" from "TOPCELL", LVS doesn't pass (obviously) but the "BUF1" cell shows up in the extracted netlist. The overlapping nature of these cells seems to result in the BUF1 cell being removed from the hierarchy.

This feels like a bug to me, but I could be doing something wrong as well. I'm hoping this is enough to go on, but if not I can try to work on a fully-sanitized case.

laurent_c

Do you have some connection by drain/source merge by overlapping 2 cells ?
If yes, you may need the cheat command line :

cheat("BUF1", "any_other_CELL") {

   the extract_devices lines of your LVS 

}

You have an example in that LVS script :
https://github.com/laurentc2/FreePDK45_for_KLayout/blob/master/lvs/lvs_freepdk45.lylvs

BRgds,
Laurent

barlow

@laurent_c Yes, I have sources overlapping in the design. The gate is fully formed (e.g. BUF1 passes DRC and LVS by itself). Looking at the "cheat" command now to better understand what's going on there.

Matthias

Hi @barlow,

I think that @laurent_c is pointing in the right direction.

The following happens: when devices overlap across hierarchies, they are not be "complete" in the context of their own cell. This means: their footprint - including all shapes attached to drain or source - is not contained entirely in the local cell.

Why this is important can be seen on this somewhat contrived example:

Here two inverters overlap in a way that the PMOS forms a new, wider device. This device is not inside the inverter and all PMOS of the inverters will be removed and placed outside the inverter subcircuit. In the extreme case - if all devices are removed - the subcircuit itself will vanish.

Matthias

barlow

@Matthias, Thanks for your response. I'll be perfectly honest, it has been so long since I designed that layout that I had forgot that the sources overlap. I agree that the closer you get layouts, the more likely you are to get into trouble with hierarchy, and I know commercial tools put a lot of sweat and tears into hierarchal verification for these very reasons. I think I have a few follow-up questions/concerns. I really want to avoid using the cheat method because I'm trying to avoid hard-coding cell names into a LVS deck, and I also don't want to give a cell a free pass on verification in case someone accidentally changes something.

• What causes the overlap fault mode specifically? I know there is some tolerance for cells overlapping when it's just metal layers. Is there some internal pseudolayer for device outlines that gets checked for cell-cell overlap or something?

• Can you identify if overlap has happened during LVS deck execution that results in layouts being thrown out? I'm certain that I didn't understand what the LVS debug window was telling me in the results, but I also don't know if there was a warning or flag that I can also check that will help identify this edge case. Ideally I would like to know in code and in the result browser.

• Can you force a partial flat mode extraction?

Matthias

Hi @barlow,

The problem is not a "fault mode". It is actually a logic thing. It applies to devices only, not to wiring.

Looking at a planar FET, the device is complete when you know the entire gate region and all source and drain regions that attach to it. Having this information allows you to extract all FET parameters: width, length, source and drain area and perimeter.

A device hence is made up from a number of polygons. A device is "complete" if you have collected all those polygons. If all these polygons come from one cell, the device sits in that cell. If parts of these polygons come from outside the cell - e.g. from an overlapping neighbor cell - the device is not complete within it's original cell. This means, some instances of the cell may feature different devices than others. This also means, either one has to create variants (hence breaking the correspondence between schematic and layout) or the device needs to be propagated up in the hierarchy.

If sources or drains overlap between different cells, the source and drain regions of the involved devices are not complete on level of the local cell. So these devices are taken out of the cell and promoted up in the hierarchy where the cell interaction happens.

KLayout uses a two-phase approach: first, the polygons are collected ("clusters") and then the device is analyzed based on the extraction recipe (the "device extractor"). A more elaborate solution could involve analyzing the different hierarchical variations of the clusters and promoting devices only in case of a parameter change triggered by an overlapping shape or device. Right now, this solution is not in place.

Partial flattening is possible by using "netlist.flatten_circuit", but that also needs cell names. You can try flattening the partially overlapping cells. You will need to flatten bot the schematic circuits (through "schematic.flatten_circuit") and the same circuits from the extracted netlist. That should solve the problem, but maybe create performance issues if there are a lot of these overlapping cells.

Matthias

dick_freebird

This is one area where "asserted" recognition and connect-
targets might be superior to logical recognition. Not that
this is available here and now, on this DB. I believe the deal
is "merging gone too far" (or too flat).

But question the present recognition and the assertion that
"everything has to be fully formed" to recognize the FET.
Problem appears to me, to be "figuring out who owns what"
when the "device" is aggregated polygons without referring
to context.

For this kind of thing I have seen extract rules containing a
comprehension of a "cutter" layer which can be drawn (a
zero width or wider path?) to forcibly split a merged device
into its consituents' portions. Device_extent gets split in two
and there's your two devices. But now every recognition has
that additional ANDNOT inline. And the layout & rules would
lack this "post facto" patch until somebody opens the can.

Matthias

Hi @dick_freebird,

yes, you're probably right with "merging gone too far".

I have started some experimental branch where I tried extracting "semi-formed" devices on lower hierarchy levels and leaving them there unless the device is fundamentally modified up in the hierarchy.

This works, if one takes care not to spoil the recognition layer hierarchy (i.e. as long as computed gate shapes are low in the hierarchy). However, drain and source area and perimeter are usually no longer correct for overlapping devices. As these parameters are considered secondary and are not participating in the device compare, this is acceptable I assume.

Matthias

barlow

I finally got some time to dip back into this topic. To get around this issue, my solution included some use of the "cheat" function, but that did not consistently fix the issues I was dealing with. I understand the concerns you ( @Matthias ) raise about source/drain geometry changing, but you also are correct in that I don't care about precise source/drain geometry in a purely LVS context. I have some observations and thoughts after working on this layout:

First, the user feedback on what is going on is not great in the LVS results viewer. In my experience, the LVS engine "deletes" the overlapping shape from both layouts, resulting in that finger/device not being extracted. The only notice that goes up is the warning about only having one diffusion shape surrounding a gate. Going to the highlighted part in the layout leads to more confusion because the layout "looks" fine and has two diffusions.

A warning of "Diffusion/Geometry deleted due to hierarchy overlap" or something similar would be appreciated.

One thing I tried was similar to what @dick_freebird suggested - creating a small derived source/drain layer. Briefly, an example code, where the "sized" dimension is smaller than the overlapped region:

nfet_sd = ACT_drw.and(NIMP_drw).not(POLY_drw)
nfet_sd_eff = nfet_sd.and(nfet_gate.sized(0.1))
extract_device(mos4("nfet4"), {"SD"=>nfet_sd_eff, "G"=>nfet_gate, "W"=>nfet_body, ... })

And this doesn't work. I'm guessing that it's not enough that the actual layers fed into the extractor are isolated - the source layers must be isolated as well? For LVS I would be happy with this fidelity of extraction.

dick_freebird

This might be a use for a "cutter" feature, a path or polygon
that would ANDNOT with things coincident for extract logic
purposes only? Like for occasions when "connect" logic
connects things you didn't mean to and breaks device-
extents.

Mentioned this above, is there any traction for the idea? I
guess that some changes might ripple outward.

Matthias

Hi @barlow,

"cheat" comes with side effects, that it is why it is called "cheat".

I have started to work on improving the device extraction. This may render "cheat" unnecessary in many cases. The branch is here: https://github.com/KLayout/klayout/tree/device-extraction-improvement

But I can only emphasize, that KLayout is a spare time hobby project. Don't expect a quick progress in that area. A hierarchical layout engine is a tricky topic.

Matthias

dick_freebird

Re the cutter experiment that didn't work out - might need to look
at the logic of the "source" terminal identification, may be that
things still get "over-merged" by some other layers' meddling?
Like connect statement if the metal is not also cut, or something
like that?