Hello All, I am trying to run LVS to an analog cell layed out modifying generated cells. For some reason, a reference voltage label VSS, generated using "label VSS e li" over a poligon of local interconnect layer that merges all the VSS nodes of the cells, doesn't appear at the higher hierarchy as seen (I hope) in the attached netlist generated from magic. This means that the VSS nodes are generated locally at the subcircuits but don't propagate to the top cell, and thus extra local VSS nodes are generated and the comparison fails. What is the recommended flow for LVS between xschem-generated and magic-generated netlists for cells including subcircuits? Any recommended options to be set at magic and/or xschem sides to avoid these issues?

It's hard to see exactly what the situation is without looking at the layout, but basically, if you have a subcell and it has a pin that doesn't connect to anything in the top level, then it will be treated as a local node in that subcircuit during extraction. If you want it to show up in the output as a port, then either (1) declare it as a port (with "port make") in the subcell, or (2) connect it to something in the top level (even just a piece of metal overlapping it).

@User First, your top level is not being extracted as a subckt. Make sure you have pins defined in the layout at the top level

OSC_v2p1

. Do you have VSS defined as a pin at both the

INVandCAP_v1p1

and

INV_v1p1

levels in the layout? Also, what commands are you using for extraction?

Thanks both for the replies. @User for option (1), I'm not declaring any label as a port. I was reading the documentation with a bit more attention, but I can't really grab the difference between label and port when ext2spice is used., can you briefly explain this in the context of LVS? As you say, what I'm doing resembles more what you mention in (2), but for some reason it's not working. @User I'm using "ext2spice lvs" (to avoid parasitics in the netlist) and then "ext2spice". VSS is defined in both

INVandCAP_v1p1

and

INV_v1p1

cells as labels, is this what you mean when you say "define as a pin"? Otherwise I would really appreciate your explanation.

@User: "extract" and "ext2spice" don't trust the designer. . . So if you make a connection to a subcircuit, that connection will become a port of the subcircuit whether or not it's declared to be a port. So you should be able to correctly extract a circuit with or without ports. The difference is that with the ports, you are declaring what you intend the port connections to be, and you can specify various properties like direction, use, index, etc., that allow magic and other tools to run various sanity checks on the design. It just makes the intent of the design clearer.

Thanks, Tim. Although, I think that if there are no explicit pins at the top layout, magic does not extract ports and therefore, the top level has no subckt even with

ext2spice lvs

. At least that's been my experience. @User I'd suggest adding port layers on the top level

OSC_v2p1

.

@User thanks please find the .mag attached @User thank you! I'll try this

I need the layouts for the subcells as well.

true, sorry! please find them attached

Still missing the cell INVandCAP_v1p1.

voila, sorry

Also

sky130_fd_pr__cap_mim_m3_2_LHJMGU

.

sorry, I didn't generate this one, it seems to be auto-generated

@User: Legacy interface stupidity. . . "save" doesn't actually do what you think it does. It sets the file name associated with the cell but doesn't actually write anything unless the file doesn't exist. Use "write all"; also "quit" will prompt to handle unsaved changes. Never use "exit" on the command line because it bypasses that check.

Nothing to apologize about, and thanks a lot for taking a look. As conclusion, to minimize chances of hitting these errors, the advice is to always use ports at all hierarchies?

@User: I tracked this down to some obscure method I put in a long time ago that makes nets global if there is a Tcl variable of the same name as the net. This is an awkward method to begin with, and it conflicts with a later method that uses the variables VDD and GND to denote the default names for power and ground. So the sky130A .magicrc file sets VDD and GND, so a circuit that uses the name "VDD" like yours gets it treated like a global and so it doesn't show up as a port (apparently the method was either not fully implemented or else it was only partially removed, because otherwise it should put ".option global VDD" at the top of the SPICE netlist). I just removed the method from the magic source code. You can do any of the following: (1) pick up the new code from the git repository on opencircuitdesign.com today, or (2) from the git repository on github tomorrow, or (3) run "unset VDD" in the command window before doing ext2spice, or (4) change the name of the power rail to something other than VDD. Thanks for supplying the files for debugging!

hello @User, thanks for the explanation. Actually, the issue I'm facing is the opposite of what you describe: I have VSS as reference node, which is named differently to the GND token you define as global name, and thus the VSS nodes of subcells appear a different nodes in the extraction for LVS, even if I set them as ports using 'port make', as suggested by @User. What's your advice to make merge all the VSSs into one node to avoid LVS error for node number incompatibility? set VSS as global maybe? or rename it GND? or something else?

@User: what version of magic and what version of netgen are you using?

magic v8.3.230 and netgen v1.5.211

Hi @User I use the openlane

flow.tcl

script to run LVS. If you're working on a design for caravel, it shouldn't be too hard to incorporate your design into the flow. Most of the parameters come from the

<design>/config.tcl

file. This is the command I run in docker in the

caravel_user_project/openlane

directory.

flow.tcl -design <design_name> -lvs -gds ../gds/<design_name>.gds -net ../verilog/gl/<design_name>.v

It creates a netgen setup file in

<design_name>/runs/<tag>/tmp/finishing/#-setup_file.gds.lvs

. You can modify this file as needed (for example, to use a spice file instead of verilog). The

flow.tcl

script will automatically pull in the

STD_CELL_LIBRARY

spice, but you'll need to specify extra verilog or spice files in the

config.tcl

using the

LVS_EXTRA_GATE_LEVEL_VERILOG

or

LVS_EXTRA_STD_CELL_LIBRARY

env variables.

LVS_EXTRA_STD_CELL_LIBRARY

will handle any spice file (not just libraries). If you want to look at the internal operation, checkout openlane's

scripts/tcl_commands/magic.tcl

for magic extraction and

scripts/tcl_commands/lvs.tcl

for netgen LVS.

@User thanks a lot!