MOSFET as black box in LVS

[circuitking]

Hello, I don't have a symbol for a MOSFET in my PDK. I made a layout for it and used some other MOSFET symbol for simulations. During LVS run, I got errors. How do I fix it? I heard about LVS box but the procedure to do it is not clear to me.

 

[timof]

LVS should "recognize" this device, from the layout.
"Device recognition" is a standard step in LVS, and a very smart one - it's an automated way to identify the the devices in the layout, from layout shapes.

LVS creates "derived layers" from the GDS layers, using geometrical operations, e.g. "g_poly = poly and active", "sd = active not poly", etc.
Then g_poly is used as a "seed layer", and "sd " as "terminal layers", and their "interaction" - overlap or abutting - creates a device.

LVS passes this information to parasitic extraction tool, which then extracts some parasitics (R and C) (some devcie-related parasitics are ignored, or "blocked", in parasitic extraction), and creates "device instance pins" within the terminal layers, where device SPICE model will connected to, to the resistive network.

In Calibre LVS (by far the most popular LVS/DRC tool in the industry), device recognition command starts from "DEVICE" statement - you can look it up in the Calibre rule file, and create your custom device recognition.

You can verify the derived layers by opening and reviewing LVS database (using calibredrv tool), or, if you use CCI interface, open AGF file(annotated GDS file), and look ti up there.

 

[sleepy_shiba]

If you are doing this with LVS BOX, you need to create a symbol(let's say name it "MOSFET_SCHEMATIC ") with nothing but pins in it (for MOSFET, put D/S/G/B pins), and add "LVS BOX MOSFET_LAYOUT MOSFET_SCHEMATIC" in your LVS command file and create your layout (name it "MOSFET_LAYOUT") also with pins in it.
but with this way, it's better to match 1 layout with 1 symbol only (or you may lose the track of property), if you have more sizes mosfet, this method is not that practical...

 

[dick_freebird]

Some design tools use / require auxiliary views to make the
extraction work. Like Cadence first makes an "extracted" view
from the layout which looks like the source layout but places
alternate views rather than layout view, which contain explicit
connectivity. Others just spit out a netlist line right from
the extraction process, into a text file.

You need to better determine what's the missing piece(s).

I've also encountered situations where the foundry maintains
"two sets of books" - a fully detailed SPICE model tree where
the devices you think you're using, contain the parasitic
devices (buried in the subcircuit include-chain, not at the
schematic level), and one that only includes the explicit
device - that one will match simple schematics, while the
"realistic" ones carry extra PNPs that will have no schematic
equivalent (hence fail, bigly). If you are using a SPICE:SPICE
LVS in some lower-tier tool (like Tanner, Silvaco, open source)
be sure you are grabbing the "LVS SPICE" branch for your
include-chain.