Hello everyone! I'm working on 6 inverters (specifically the sky130_fd_sc_hd__inv_2) connected in parallel, but I'm struggling with LVS. For some reason, the magic-generated spice is getting 2 nets more than the xschem-generated spice, causing a net mismatch. Does anyone know how I can debug it or solve this issue? thanks in advance 🙂

@Kevin Pizarro 1. Please include the command(s) that you use to run netgen. 2. When you create the netlist from xschem, be sure to set the

Simulation

->

LVS netlist: top level is a .subckt

option. 3. As a rule, it might be best to not put the

.include

statements in LVS schematics. Make a test bench wrapper circuit for simulation and include them there. (that said, you’ll still need to add the standard cell spice to get LVS to pass - it’s just not recommended to do that in the schematic.) 4. The layout is missing

sky130_fd_sc_hd__tapvpwrvgnd_1

cells so the nwell is not connected to power and the psubstrate is not connected to ground.

Hi David, This compressed file contains everything related to the problem. So your recommendations are: • Use

tapvpwrvgnd_1

instead of

tap1

. I'm going to test it rn • Should we make a schematic with the design and the

.include

directives? Should we do this for each design in the project? • If we use a tcl script for netgen that includes all the spices from the pdk before running lvs, could it be an alternative for the previous point?

I don't understand why you would need to use flatglob with standard cells. . .

I have port mismatching on

inv_2

, Magic doesn't generate the same disposition. Maybe I could use

readspice

on stdcells when extracting the gds... In that case I should apply this on each PDK spice, just to mantain the port order. What could be the side-effects of using

readspice

with big spices? Is going to slow the procedure? Increment complexity?

You shouldn't need to use either

flatglob

or

readspice

. As long as you include the standard cell SPICE library for the HD standard cells into the schematic-captured netlist, netgen should match the

inv_2

cells against each other and match the port order.

The addition of the

.include <stdcell>.spice

statements on the

INV.sch

could have any unwanted side-effect? I think it might require the

only_toplevel=1

property to avoid problems. I want a solution that doesn't require manual addition of the

.import

statements on each xschematic extracted netlist, I think intermediate files should not be manually edited to get the expected results. I though that the netgen tcl interface could help me with this (I was reading the 3rd presentation, a bit short on netgen but very useful) but if this can be solved at schematic level, it would be great.

@aquiles viza I don’t think it wise to use

.include

statements on every xschem schematic. I’m of the opinion that

.include

statements should not be used on schematics used for LVS. The

.include

statements should be used on test bench schematics that instantiate the LVS schematics. When using standard cells in xschem, the output spice will not include the spice for each standard cell. You can create a

script

for running netgen like this

set layout [readnet spice <extracted_spice>]
set source [readnet spice <spice_library_from_pdk>]
readnet spice <xschem_netlist> $source
lvs "$layout user_analog_project_wrapper" "$source user_analog_project_wrapper" $env(PDK_ROOT)/$env(PDK)/libs.tech/netgen/$env(PDK)_setup.tcl lvs.report

and then

netgen -batch source script

@aquiles viza: The typical use case is that the testbench schematic will include the netlists of any library components you use: That includes standard cell libraries as well as the primitive device models. The circuit being designed should not have any include statements at all; it should be self-contained, and it should rely on the testbench schematic to pull in all the dependent libraries. For that reason, though, when you run LVS on the design only (not the testbench), you will also need to include the same library files (on the schematic side only, of course; the layout side will be extracted all the way down to the transistor level and should be completely self-contained).