Hello, am having some trouble with LVS. In short, the L side has less nets than the S--I'm assuming a short somewhere. But where? I'm drowning in information in the lvs report, how do I get netgen to just spit out everything connected in nets for which it can't find a correspondence on the other side?

Can you paste the report ? It should show for the non matched nets the devices it connects to.

Here it is... must say there's still a lot I don't get in this but I can't figure out where the issue actually lies. It has crazy deltas, like

VPWR = 114                               |  VPWR = 4

Gimme a sec to look that over.

All the sub cells used within pass LVS. One of them is verilog (passes too), only the top level fails... have been stumped.

I think the power connections are not correct.

Yes, exactly that. But they're connected. Does it matter? Also, the side with the least nets is on the "left" (the first, layout, side)... does that mean that I shouldn't be connecting these domains or something?

Maybe the issue is in the schematic part ...

(also, how can you tell they are split? I mean they have the same names and are electrically connected.

In line 864 you can see that it finds a net

VPWR

with a bunch of stuff on one side and much less on the other.

@Pat Deegan: The output is saying that the circuit

ringtest

contains a handful of subcells (

ring

,

driver

, and

mux4onehot_b

) which have power and ground properly connected, and a bunch of standard cells, which seem to all have power and ground connected together (on unnamed net that have been named

dummy_*

), but apparently disconnected from the power and ground for the subcells and pins. Side note: If you're running netgen locally and can update, I suggest using the most recent version (1.5.282) because I found a bug a few days ago that causes netgen, under some circumstances, to dump more output than necessary, making the output harder to read. There is a

debug on

command that you can add to the script, but that outputs a huge amount of information, so not recommended unless you just cannot see the error in the output (and it's likely that previous times I had to resort to

debug on

were probably caused by the bug that I just mentioned and just fixed). That is probably not relevant in this case.

@Pat Deegan Did you find/fix the issue ?

@Pat Deegan unfortunately, the version of netgen that you are using

1.5.270

does not work when you have spice that calls verilog modules. The terminal log is showing

Subcircuit pins:
Circuit 1: _PLACEHOLDER_                   |Circuit 2: simplecounter
-------------------------------------------|-------------------------------------------
(no matching pin)                          |1
(no matching pin)                          |2
(no matching pin)                          |3
(no matching pin)                          |4
(no matching pin)                          |5
(no matching pin)                          |6
(no matching pin)                          |7
(no matching pin)                          |8
(no matching pin)                          |9
(no matching pin)                          |10
(no matching pin)                          |11
(no matching pin)                          |12
(no matching pin)                          |13
(no matching pin)                          |14
VGND                                       |(no matching pin)
VPWR                                       |(no matching pin)
clk                                        |(no matching pin)
enable                                     |(no matching pin)
counter[9]                                 |(no matching pin)
counter[8]                                 |(no matching pin)
counter[7]                                 |(no matching pin)
counter[6]                                 |(no matching pin)
counter[5]                                 |(no matching pin)
counter[4]                                 |(no matching pin)
counter[3]                                 |(no matching pin)
counter[2]                                 |(no matching pin)
counter[1]                                 |(no matching pin)
counter[0]                                 |(no matching pin)
---------------------------------------------------------------------------------------
Treating empty subcircuits as black-box cells

You’ll probably have better luck with the latest version

1.5.282

or the last known version that worked with spice calling verilog modules

1.5.269

. When you do call verilog modules from spice, there are a couple things that need to be considered. 1. Since spice calls are by position, the verilog symbols should be created with the ports in the same order as the the verilog module. This may be a manual process. I find it easiest to open the

*.sym

file in an editor and rearrange the physical order of the pins there (if there is no schematic). I also add a

type=primitive

property to the symbol to prevent the creation of an empty subckt. If you do have an empty subcircuit, the symbol pins will be output in the order of the pins in the schematic (with a recent version of xschem). 2. Spice is case insensitive, verilog is case sensitive. The default for netgen is to follow what ever is read first. You might consider using the LVS system in the

caravel_user_project/Makefile

. For any

lvs/<cellname>/lvs_config.json

file, you can simply run

make lvs-cellname

. All the extraction and LVS parameters are in the

lvs_config.json

file and you can include the lower level config files in the upper level hierarchy. The

lvs_config.json

options are explained here.

Hello, thanks for your input... sorry for the delay, was away at a con. @tnt still no success but some progress. @Tim Edwards and @Mitch Bailey: I thought netgen was happy with the verilog, since it was passing my simplecounter.v checks when run standalone, but it does look like there was some issue when combining everything together. I've updated to latest netgen, have changed all analog circuits to use VDD/VSS and left anything with std cells as VPWR/VGND to attempt to disambiguate, and the output still isn't an LVS pass but is looking more clear. I wind up with a failure around

---------------------------------------------------------------------------------------

Instance: simplecounter:x4                 |Instance: simplecounter:4

VPWR = 5                                 |  2 = 5

clk = 3                                  |  3 = 3

enable = 1                               |  4 = 1

counter[0] = 1                           |  14 = 1

counter[1] = 1                           |  13 = 1

counter[2] = 1                           |  12 = 2

counter[3] = 2                           |  11 = 1

counter[4] = 1                           |  10 = 1

counter[5] = 1                           |  9 = 1

counter[6] = 1                           |  8 = 2

counter[7] = 2                           |  7 = 1

counter[8] = 1                           |  6 = 1

counter[9] = 1                           |  5 = 1

VGND = 4                                 |  1 = 4

---------------------------------------------------------------------------------------

Netlists do not match.

Port matching may fail to disambiguate symmetries.

which, but for the ordering, looks like a match to me (full report attached here). I've played with the ordering of ports a good deal to no avail, but will give Mitch's lvs_config system a try. If you see anything obvious in the report, please let me know.

@Pat Deegan Could you post also the verilog netlist (and/or schematic spic) you're comparing against and the extracted spice ?

Yeah, am going to push everything to github... will ping.

This looks like a failure to read in all the verilog components when setting up the input to netgen. The

simplecounter

module is being treated as a black box, so netgen has not seen the module definition.

@Tim Edwards that's odd... I have a

readnet verilog ../verilog/gl/simplecounter.v $source

line, which barfs if I change the path to something invalid, and outputs

Verilog placeholder module simplecounter replaced by module definition

when running (log attached).

@Pat Deegan: Try reading

simplecounter.v

before you read the top level verilog. And keep the existing files because I may need to use them to debug.

ACK. will be pushing everything in 5 mins.

@Pat Deegan Can you check the bus order for the counter signal? Looks like it might be reversed from verilog to spice.

counter[0] = 1                           |  14 = 1                                   
  counter[1] = 1                           |  13 = 1                                   
  counter[2] = 1                           |  12 = 2                                   
  counter[3] = 2                           |  11 = 1                                   
  counter[4] = 1                           |  10 = 1                                   
  counter[5] = 1                           |  9 = 1                                    
  counter[6] = 1                           |  8 = 2                                    
  counter[7] = 2                           |  7 = 1                                    
  counter[8] = 1                           |  6 = 1                                    
  counter[9] = 1                           |  5 = 1

So the verilog has descending bus indices

module simplecounter (VGND,
    VPWR,
    clk,
    enable,
    counter);
 inout VGND;
 inout VPWR;
 input clk;
 input enable;
 output [9:0] counter;

While the spice has

x4 VSS VDD drv_out enable_counter net2 net3 net4 counter3 net5 net6 net7 counter7 net8 net9 simplecounter

which looks like the ports are in ascending order. From the

xschem/simplecounter.sym

file

B 5 17.5 -32.5 22.5 -27.5 {name=VGND dir=in}
B 5 17.5 -62.5 22.5 -57.5 {name=VPWR dir=in}
B 5 17.5 -202.5 22.5 -197.5 {name=clk dir=in}
B 5 17.5 -182.5 22.5 -177.5 {name=enable dir=in}
B 5 177.5 -202.5 182.5 -197.5 {name=counter[0] dir=out}
B 5 177.5 -182.5 182.5 -177.5 {name=counter[1] dir=out}
B 5 177.5 -162.5 182.5 -157.5 {name=counter[2] dir=out}
B 5 177.5 -142.5 182.5 -137.5 {name=counter[3] dir=out}
B 5 177.5 -122.5 182.5 -117.5 {name=counter[4] dir=out}
B 5 177.5 -102.5 182.5 -97.5 {name=counter[5] dir=out}
B 5 177.5 -82.5 182.5 -77.5 {name=counter[6] dir=out}
B 5 177.5 -62.5 182.5 -57.5 {name=counter[7] dir=out}
B 5 177.5 -42.5 182.5 -37.5 {name=counter[8] dir=out}
B 5 177.5 -22.5 182.5 -17.5 {name=counter[9] dir=out}

You should be ok with just changing the order of the lines in this file (not just the indices!).

B 5 17.5 -32.5 22.5 -27.5 {name=VGND dir=in}
B 5 17.5 -62.5 22.5 -57.5 {name=VPWR dir=in}
B 5 17.5 -202.5 22.5 -197.5 {name=clk dir=in}
B 5 17.5 -182.5 22.5 -177.5 {name=enable dir=in}
B 5 177.5 -22.5 182.5 -17.5 {name=counter[9] dir=out}
B 5 177.5 -42.5 182.5 -37.5 {name=counter[8] dir=out}
B 5 177.5 -62.5 182.5 -57.5 {name=counter[7] dir=out}
B 5 177.5 -82.5 182.5 -77.5 {name=counter[6] dir=out}
B 5 177.5 -102.5 182.5 -97.5 {name=counter[5] dir=out}
B 5 177.5 -122.5 182.5 -117.5 {name=counter[4] dir=out}
B 5 177.5 -142.5 182.5 -137.5 {name=counter[3] dir=out}
B 5 177.5 -162.5 182.5 -157.5 {name=counter[2] dir=out}
B 5 177.5 -182.5 182.5 -177.5 {name=counter[1] dir=out}
B 5 177.5 -202.5 182.5 -197.5 {name=counter[0] dir=out}

Yeah, I found that too but that doesn't seem to be the only issue.

@Mitch Bailey I played with it a ton, manual style in the spice, and never got good results. Weirdly, when I run extraction/lvs on just the simplecounter, the extracted spice matches the "correct" port order from xschem, but not when I get it from top level.

Weirdly, when I run extraction/lvs on just the simplecounter, the extracted spice matches the “correct” port order from xschem, but not when I get it from top level.

The port order between the schematic and extracted layout is irrelevant. It’s the port order between the schematic and verilog that’s important.

@Mitch Bailey !! Was just playing with that, and it failed... must've done it wrong. You did this in symplecounter.sym ?

Right, I opened the file in

vi

and changed the order of the lines.

@Mitch Bailey ok, wait, there's something I'm not getting. Running this same set of scripts for LVS on the mux4onehot_b component, which includes sub-cells and, in there, bunch of standard cells, without including all these manual additional reads into $source works fine. Does this mean the LVS OK result in this case is illusory?

netgen, by default, will blackbox and port match missing subcircuits. So, yes, you could have an LVS error in a sub block that may pass if the source netlist for that block is missing. The precheck LVS looks for the string

will not flatten

in the

lvs.report

and the strings

Matching pins

and

contains no devices

in the

lvs.log

(stdout). These will flag all the primitive devices, so those are filtered out. Anything else causes LVS to fail even if the

Circuits match uniquely

.

though I was blind, now I see

All the

sky130_ef_sc_hd

cells may not be necessary.

Ok, I have to start from the bottom, I think. BTW, a paste of the .sym and the lvs script still didn't pass... Thanks for your assistance, will dig in a try to validate every step up the chain. I wish I could get xschem to dump out a full hierarchy (like the extracted spice from magic's side)--adding the underlying/included spice into the LVS script seems dumb.

You have a bunch of absolute path in xschem files btw.

I have the driver as primitive... ugh. Ok, will fix and investigate.

Did you recreate the spice netlist from the schematic? You can see the

decap_12

cell being blackboxed in the original log file.

Creating placeholder cell definition for module sky130_ef_sc_hd__decap_12.
...
Circuit sky130_ef_sc_hd__decap_12 contains no devices.

and the original report file

Circuit 2 cell sky130_ef_sc_hd__decap_12 is a black box; will not flatten Circuit 1

Subcircuit pins:
Circuit 1: sky130_ef_sc_hd__decap_12       |Circuit 2: sky130_ef_sc_hd__decap_12       
-------------------------------------------|-------------------------------------------
VGND                                       |VGND                                       
VPWR                                       |VPWR                                       
VPB                                        |VPB                                        
VNB                                        |VNB                                        
---------------------------------------------------------------------------------------
Cell pin lists are equivalent.
Device classes sky130_ef_sc_hd__decap_12 and sky130_ef_sc_hd__decap_12 are equivalent.

Yes, I did regen the spice. On one hand, I have bugs because I was forcing the driver/inverter symbols to be primitive (it's a Matt project and I originally didn't want to duplicate in my repo). So I have to fix that before going again. Then I'll check the simplecounter port order again, see that it comes out like you. As for the decap and all that, I'm not sure why I should care that standard cells are blackboxed since I trust their guts.

The driver and ring as primitives are fine as long as you include the respective spice in the lvs.script.

Ok. I'd just prefer not doing that so I can have one lvs_netgen.tcl script to rule them all.

@Pat Deegan As a side note, to pass pre-check you'll need the pin area for the power stripes to extend to the whole length vertically and not just small squares.

Congratulations! The latest version of xshcem is supposed to pick up the pin order from the schematic (if it exists) even with primitive symbols. Don’t know if that’s related to what you’re seeing.

@tnt The project is something like attached--are you referring to something you saw in there? And If so, am not clear on what you mean (about to push it up and see what the prechecks say, but if you've seen a prob, your output is a lot easier on the brain that what I've dealt with from the scripts, so would like to know).

On your

met4

power strips, you see the defined pas area as a small cyan outline on them in the upper part with the label written on it.

Oh, you mean the label/port square thingies? Ok.