Hello, I am experiencing an issue regarding an LVS for an encoder using standard cells. I appears as though, from the immediate lvs report, that there are two extra instances of an nfet and pfet in my circuit 2(Mag spice, or the longer file). However, looking at the spice file for circuit 2, there are no fet instances when looking at the top level subcircuit. I do not know if this issue is because of the use of standard cells and I am missing something, or something else entirely.

@Travis Jakl What command are you using for netgen?

netgen lvs "/home/tjdjakl/asic-reram-test-chip/xschem/StandardCells/dec24/Priority_Encoder_16t4.spice Priority_Encoder_16t4" "/home/tjdjakl/asic-reram-test-chip/mag/dec24/Priority_Encoder_16t4.spice Priority_Encoder_16t4" sky130B_setup.tcl

@Travis Jakl the source side netlist doesn’t include the standard cell spice library. There are probably a couple ways to solve the problem (including adding the standard cell spice library to the source file), but I prefer to use an lvs script file and run

netgen -batch source lvs.script

Here is a sample

lvs.script

that might work for your case.

puts "Reading layout mag/dec24/Priority_Encoder_16t4.spice ..."
set layout [readnet spice mag/dec24/Priority_Encoder_16t4.spice]
set source [readnet spice /dev/null]
puts "Reading source $env(PDK_ROOT)/$env(PDK)/libs.ref/sky130_fd_sc_hd/spice/sky130_ef_sc_hd__decap_12.spice..."
readnet spice $env(PDK_ROOT)/$env(PDK)/libs.ref/sky130_fd_sc_hd/spice/sky130_ef_sc_hd__decap_12.spice $source
puts "Reading source $env(PDK_ROOT)/$env(PDK)/libs.ref/sky130_fd_sc_hd/spice/sky130_fd_sc_hd.spice..."
readnet spice $env(PDK_ROOT)/$env(PDK)/libs.ref/sky130_fd_sc_hd/spice/sky130_fd_sc_hd.spice $source
puts "Reading source xschem/StandardCells/dec24/Priority_Encoder_16t4.spice..."
readnet spice xschem/StandardCells/dec24/Priority_Encoder_16t4.spice $source
lvs "$layout Priority_Encoder_16t4" "$source Priority_Encoder_16t4" $env(PDK_ROOT)/$env(PDK)/libs.tech/netgen/$env(PDK)_setup.tcl

I get a similar lvs result, but the comp.out does look a lot better than before. One thing to mention is that I am doing this lvs on a component that I received from another person, so I have not made the layout or schematic for this. What I am noticing from this comp.out is: 1) The power and ground nodes are present for both the layout and schematic, but the lvs is seeing them seperately. 2) There are instances of a sky130_fd_sc_hd__decap_8:FILLER_ component within the layout, which does not exist in the schematic.

The decap cells are what is causing the discrepancy. The LVS setup in Efabless’ precheck supports both decap and fill cell checks even though they don’t affect the logic output of the circuit. Can you add the decap cells to the schematic? You could add one instance of each type and then set the instance name to an array with a size that matches the count. Ex.

Xdecap1[5:0]

if there were 6 instances. You can also modify the setup file to ignore decap cells (but this may cause problems with precheck because precheck checks them).

That worked out great, but I am still recieving an error regarding the power and ground nets. It appears as though two are missing from my LVS layout. I will provide updated spice files, and might as well throw in the setup.tcl as well

@Travis Jakl 2 things you might try. 1. the decap_12 cell has been modified by Efabless. That’s why you get

Flattening unmatched subcell sky130_fd_sc_hd__decap_12 in circuit Priority_Encoder_16t4 (1)(4 instances)

Flattening instances of sky130_ef_sc_hd__decap_12 in cell Priority_Encoder_16t4 (0) makes a better match

In the schematic, try changing the prefix for the

decap_12

cell to

sky130_ef_sc_hd__

. 2. The bulk and nwell connections for the decap cells in the schematic should probably be

VPWR

and

VGND

. Currently the pins appear to be

VNB

and

VPB

.

(no matching net)                          |Net: VNB                                   
                                           |  sky130_fd_sc_hd__decap_8/VNB = 1         
                                           |  sky130_fd_sc_hd__decap_3/VNB = 1         
                                           |  sky130_fd_sc_hd__decap_6/VNB = 1         
                                           |  sky130_fd_pr__nfet_01v8/4 = 1            
                                           |                                           
(no matching net)                          |Net: VPB                                   
                                           |  sky130_fd_sc_hd__decap_8/VPB = 1         
                                           |  sky130_fd_sc_hd__decap_3/VPB = 1         
                                           |  sky130_fd_sc_hd__decap_6/VPB = 1         
                                           |  sky130_fd_pr__pfet_01v8_hvt/4 = 1

Just edit the symbol properties to

VPB=VPWR VNB=VGND

. Let me know if that cleans things up.

Changing the prefix and the symbol priorities didnt seem to affect much, I am still receiving a similar problem.

Almost there! Check the decap_8 connections again.

(no matching net)                          |Net: VNB                                   
                                           |  sky130_fd_sc_hd__decap_8/VNB = 1         
                                           |                                           
(no matching net)                          |Net: VPB                                   
                                           |  sky130_fd_sc_hd__decap_8/VPB = 1

Oops. That looks a lot better but still unsuccessful? Now I'm really confused

The

decap_12

cell has reversed connections in the schematic.

Net: VPWR                                  |Net: VPWR                                  
...
  sky130_ef_sc_hd__decap_12/VPWR = 1       |  sky130_ef_sc_hd__decap_12/VNB = 1        
                                           |                                           
Net: VGND                                  |Net: VGND                                  
...
  sky130_ef_sc_hd__decap_12/VNB = 1        |  sky130_ef_sc_hd__decap_12/VPWR = 1

Nice find. However, I am unsure as to how to resolve this. The filler properties in the schematic are the same as the others(minus the different prefix). And same goes with the spice file. I rewrote the properties and reran the lvs but nothing changed.

Argh. Looks like you’ve uncovered a discrepancy in the decap_12 pdk spice files between the skywater version and the Efabless version.

.subckt sky130_fd_sc_hd__decap_12 VGND VNB VPB VPWR

vs

.subckt sky130_ef_sc_hd__decap_12 VGND VPWR VPB VNB

The quick and dirty fix is to change the property on the schematic instance from

sky130_ef_sc_hd__

(back) to

sky130_ef_sc_hd__

. This will cause an unmatch on the cell names and flatten the cells so that LVS should pass. The other way would be to modify the

lvs_format

property on

decap_12

symbol to match the spice order. However, this is a pdk file, so anytime the pdk gets updated, you’d have to fix it again. You could make a local copy of the symbol, but I think it should be fixed in the by the pdk owners. I’ll log an issue. Thanks for reporting.

Yes! Changing the pin order in

libs.ref/sky130_fd_sc_hd/spice/sky130_ef_sc_hd__decap_12.spice

lead to a successful LVS. Thank you very much for your help!