Question about LVS: When two circuits are being compared, is it required that all of the subcircuits have identical names? In my example, I have instances of

sky130_fd_sc_hd__clkbuf_8

in the first circuit, and

extr_sky130_fd_sc_hd__clkbuf_8

in the second circuit. These should be equivalent, but netgen treats

extr_sky130_fd_sc_hd__clkbuf_8

as an "unmatched subcell" and flattens it. I believe this is why lvs fails in this case.

No, it's not required that they have identical names, but the automatic cell pairing is going to assume identical names when it tries to determine which cells it will attempt matching on. There is an

equate

command that forces a pairing. I have dealt with the problem you mention above, for the case where magic pulls an entire GDS file and then prefixes all of its contents. I have a good example of how to do this, if I could find where I put it. The idea is to add something like this to the LVS setup file:

set cells1 [cells list -all -circuit1]
set cells2 [cells list -all -circuit2]
foreach cell $cells1 {
    if {[lsearch $cells2 extr_$cell] >= 0} {
        equate classes "-circuit1 $cell" "-circuit2 extr_$cell"
    }
}
foreach cell $cells2 {
    if {[lsearch $cells1 extr_$cell] >= 0} {
        equate classes "-circuit1 extr_$cell" "-circuit2 $cell"
    }
}

Doing it in both directions means that you don't need to worry about whether it was the first or the second netlist that adds the prefix to the names. Now, note that if you have circuits that have mismatched names, the matching algorithm will simply say that it couldn't find a matching cell in the opposing netlist, and then it will flatten the cells with unmatched names on both sides. So having unmatched cell names will not, in and of itself, cause an LVS failure. But it will make the output messy if there is an actual LVS error, because you'll get an output with lots of transistor connection errors, instead of standard cell connection errors.

I manually renamed the std cells in my second circuit to match. Just to test. When I read the lvs output, it seems to say that cells such as

sky130_fd_sc_hd__clkbuf_8

are black boxes. Since the black boxes cannot be flattened, that helps explain the original issue I think. But even with the names matching, lvs still fails. I think this is because with the std cells as black boxes, there is no way for it to figure out the different port order. Should those std cells (in my original spice netlist) be black boxes, or do I also need to add definitions for those down the transistor level? Maybe I need to set some Xschem setting before generating the original netlist?

All of the files in the PDK should have the same port order. I do not know how your "extr_" versions of the standard cells have managed to scramble the port order, although it may have been lost in a translation through GDS. Your best bet is to add a ".include" statement in the schematic that includes the

sky130_fd_sc_hd.spice

library from the PDK. That way, both the layout and the schematic will represent the circuit down to the transistor level. The port order of the xschem symbols from the digital library match the port order of the SPICE library in the PDK.

@User Is your source netlist verilog or spice? Is your layout original magic data or imported GDS?

My source netlist is a spice netlist generated from my xschem schematic. My second netlist was a extracted from an original .mag file. @User I included the

sky130_fd_sc_hd.spice

 library to my original netlist and that fixed it! LVS now appears to work.