@Tim Edwards Running LVS on slot-036 of MPW-2. The

user_proj_example

has the following assign statements for top level signals.

assign la_data_out[27] = io_out[35];
   assign la_data_out[26] = io_out[34];
   assign la_data_out[25] = io_out[33];
   assign la_data_out[24] = io_out[32];
   assign la_data_out[23] = io_out[31];
   assign la_data_out[22] = io_out[30];
   assign la_data_out[21] = io_out[29];
   assign la_data_out[20] = io_out[28];
   assign la_data_out[19] = io_out[27];
   assign la_data_out[18] = io_out[26];
   assign la_data_out[17] = io_out[25];
   assign la_data_out[16] = io_out[24];
   assign la_data_out[15] = io_out[23];
   assign la_data_out[14] = io_out[22];
   assign la_data_out[13] = io_out[21];
   assign la_data_out[12] = io_out[20];
   assign la_data_out[11] = io_out[19];
   assign la_data_out[10] = io_out[18];
   assign la_data_out[9] = io_out[17];
   assign la_data_out[8] = io_out[16];
   assign la_data_out[7] = io_out[15];
   assign la_data_out[6] = io_out[14];
   assign la_data_out[5] = io_out[13];
   assign la_data_out[4] = io_out[12];
   assign la_data_out[3] = io_out[11];
   assign la_data_out[2] = io_out[10];
   assign la_data_out[1] = io_out[9];
   assign la_data_out[0] = io_out[8];
   assign io_oeb[35] = io_oeb[10];
   assign io_oeb[34] = io_oeb[10];
   assign io_oeb[33] = io_oeb[10];
   assign io_oeb[32] = io_oeb[10];
   assign io_oeb[31] = io_oeb[10];
   assign io_oeb[30] = io_oeb[10];
   assign io_oeb[29] = io_oeb[10];
   assign io_oeb[28] = io_oeb[10];
   assign io_oeb[27] = io_oeb[10];
   assign io_oeb[26] = io_oeb[10];
   assign io_oeb[25] = io_oeb[10];
   assign io_oeb[24] = io_oeb[10];
   assign io_oeb[23] = io_oeb[10];
   assign io_oeb[22] = io_oeb[10];
   assign io_oeb[21] = io_oeb[10];
   assign io_oeb[20] = io_oeb[10];
   assign io_oeb[19] = io_oeb[10];
   assign io_oeb[18] = io_oeb[10];
   assign io_oeb[17] = io_oeb[10];
   assign io_oeb[16] = io_oeb[10];
   assign io_oeb[15] = io_oeb[10];
   assign io_oeb[14] = io_oeb[10];
   assign io_oeb[13] = io_oeb[10];
   assign io_oeb[12] = io_oeb[10];
   assign io_oeb[11] = io_oeb[10];
   assign io_oeb[9] = io_oeb[10];
   assign io_oeb[8] = io_oeb[10];

This results in shorts between pins at the top level. To prevent magic from deleting the shorted pins, I’m using

ext2spice short resistor

This preserves all the pins in the layout, but still getting these messages (maybe from verilog?)

Duplicate pin io_oeb[34] in cell user_project_wrapper
Duplicate pin la_data_out[27] in cell user_project_wrapper
Duplicate pin la_data_out[26] in cell user_project_wrapper
Duplicate pin la_data_out[25] in cell user_project_wrapper
Duplicate pin la_data_out[24] in cell user_project_wrapper
Duplicate pin la_data_out[23] in cell user_project_wrapper
Duplicate pin la_data_out[22] in cell user_project_wrapper
Duplicate pin la_data_out[21] in cell user_project_wrapper
Duplicate pin la_data_out[20] in cell user_project_wrapper
Duplicate pin la_data_out[19] in cell user_project_wrapper
Duplicate pin la_data_out[18] in cell user_project_wrapper
Duplicate pin la_data_out[17] in cell user_project_wrapper
Duplicate pin la_data_out[16] in cell user_project_wrapper
Duplicate pin la_data_out[15] in cell user_project_wrapper
Duplicate pin la_data_out[14] in cell user_project_wrapper
Duplicate pin la_data_out[13] in cell user_project_wrapper
Duplicate pin la_data_out[12] in cell user_project_wrapper
Duplicate pin la_data_out[11] in cell user_project_wrapper
Duplicate pin la_data_out[10] in cell user_project_wrapper
Duplicate pin la_data_out[9] in cell user_project_wrapper
Duplicate pin la_data_out[8] in cell user_project_wrapper
Duplicate pin la_data_out[7] in cell user_project_wrapper
Duplicate pin la_data_out[6] in cell user_project_wrapper
Duplicate pin la_data_out[5] in cell user_project_wrapper
Duplicate pin la_data_out[4] in cell user_project_wrapper
Duplicate pin la_data_out[3] in cell user_project_wrapper
Duplicate pin la_data_out[2] in cell user_project_wrapper
Duplicate pin la_data_out[1] in cell user_project_wrapper
Duplicate pin la_data_out[0] in cell user_project_wrapper

and LVS yields a matching topology with pin mismatches.

(no matching pin)       |io_oeb[35]                  
(no matching pin)       |io_out[35]                  
(no matching pin)       |io_out[34]                  
(no matching pin)       |io_out[33]                  
(no matching pin)       |io_out[32]                  
(no matching pin)       |io_out[31]                  
(no matching pin)       |io_out[30]                  
(no matching pin)       |io_out[29]                  
(no matching pin)       |io_out[28]                  
(no matching pin)       |io_out[27]                  
(no matching pin)       |io_out[26]                  
(no matching pin)       |io_out[25]                  
(no matching pin)       |io_out[24]                  
(no matching pin)       |io_out[23]                  
(no matching pin)       |io_out[22]                  
(no matching pin)       |io_out[21]                  
(no matching pin)       |io_out[20]                  
(no matching pin)       |io_out[19]                  
(no matching pin)       |io_out[18]                  
(no matching pin)       |io_out[17]                  
(no matching pin)       |io_out[16]                  
(no matching pin)       |io_out[15]                  
(no matching pin)       |io_out[14]                  
(no matching pin)       |io_out[13]                  
(no matching pin)       |io_out[12]                  
(no matching pin)       |io_out[11]                  
(no matching pin)       |io_out[10]                  
(no matching pin)       |io_out[9]                   
(no matching pin)       |io_out[8]                   
io_oeb[35]              |(no matching pin)           
io_out[35]              |(no matching pin)           
io_out[34]              |(no matching pin)           
io_out[33]              |(no matching pin)           
io_out[32]              |(no matching pin)           
io_out[31]              |(no matching pin)           
io_out[30]              |(no matching pin)           
io_out[29]              |(no matching pin)           
io_out[28]              |(no matching pin)           
io_out[27]              |(no matching pin)           
io_out[26]              |(no matching pin)           
io_out[25]              |(no matching pin)           
io_out[24]              |(no matching pin)           
io_out[23]              |(no matching pin)           
io_out[22]              |(no matching pin)           
io_out[21]              |(no matching pin)           
io_out[20]              |(no matching pin)           
io_out[19]              |(no matching pin)           
io_out[18]              |(no matching pin)           
io_out[17]              |(no matching pin)           
io_out[16]              |(no matching pin)           
io_out[15]              |(no matching pin)           
io_out[14]              |(no matching pin)           
io_out[13]              |(no matching pin)           
io_out[12]              |(no matching pin)           
io_out[11]              |(no matching pin)           
io_out[10]              |(no matching pin)           
io_out[9]               |(no matching pin)           
io_out[8]               |(no matching pin)

These pins should match, as far as I can tell. This output is from netgen’s

MatchPins

routine after printing the matching pins. So maybe the deleted pins are causing the routine to stop before it should. I’ll look into it a little more, but would welcome any advice. I think that ideally, LVS should not delete shorted pins, but rather check that all pins are shorted in the same manner in both the layout and source. (The

user_proj_example

level does not have text, so extracting the gds, as is, isn’t very helpful. I flattened

user_proj_example

in the

user_project_wrapper

layout, but when running LVS, netgen takes 8 hours to flatten the verilog side of

user_proj_example

. Since the verilog top is just a wrapper, I replaced the

user_proj_example

call in

user_project_wrapper

with the actual contents of

user_proj_example

and netgen runs in about 5 mins.)

I think that the problem is that the wire connection implied by the verilog

assign la_data_out[27] = io_out[35]

cannot be represented in SPICE except by a zero-ohm resistor or a zero-voltage source, but the

ext2spice short resistor

isn't a perfect solution because it does not know where to put the resistor except where there is a one-to-one connection. That appears to be the case above, where the LVS doesn't complain about the one-to-one

la_data_out

pins but is complaining about the many-to-one

io_out

connections (the

Duplicate pin

message may warrant looking into, although it appears only to be a warning message without any impact on the LVS result). I recall looking into the problem before and deciding that it was a non-trivial problem, but it is certainly worth revisiting.

@Tim Edwards yes. Sorry for the red herring. No problems with the latest version of netgen.