lvs issue with openlane about netgen HOT 7 OPEN

I have another project with the same kind of lvs issues.
verilog is here: https://git.sr.ht/~jersey99/asicfreq/tree/master/asic_freq.v

And again the report gives circuit match:

Netlists match with 2 symmetries.
Circuits match correctly.

but then there are pin problems

grep matching ./results/lvs/freq_cnt.lvs.log
seg_drvs[2] |(no matching pin)
col_drvs[0] |(no matching pin)
col_drvs[2] |(no matching pin)
col_drvs[4] |(no matching pin)
col_drvs[5] |(no matching pin)
col_drvs[1] |(no matching pin)
The top level cell failed pin matching.

from netgen.

@mattvenn : If you look at the layout, is there anything obviously wrong with that pin (or those pins, in the 2nd case)? The error is very specific to la_data_in[2], so I'm guessing that either (1) the pin did not get routed to (this would result in a correct LVS up to the pin match), or (2) the pin label got disconnected from the metal to which it was supposed to be attached.

from netgen.

@RTimothyEdwards It may also be a problem with net name assignment after buffering. There was a case on the zipdiv design. https://skywater-pdk.slack.com/archives/C017UA7LEUV/p1605706697015700

Ahmed Ghazy said there were no errors in the rc5 flow.

@mattvenn Can you verify that the unmatched pins exist in the extracted netlist? I think it's in results/magic/*spice

from netgen.

Here's the definition of the module from results/magic/freq_cnt.spice:

subckt freq_cnt addr[0] addr[1] addr[2] addr[3] clk col_drvs[0] col_drvs[1] col_drvs[2]
+ col_drvs[3] col_drvs[4] col_drvs[5] col_drvs[6] col_drvs[7] col_drvs[8] o[0] o[10]
+ o[11] o[12] o[13] o[14] o[15] o[16] o[17] o[18] o[19] o[1] o[20] o[21] o[22] o[23]
+ o[24] o[25] o[26] o[27] o[28] o[29] o[2] o[30] o[31] o[3] o[4] o[5] o[6] o[7] o[8]
+ o[9] oc[0] oc[10] oc[11] oc[12] oc[13] oc[14] oc[15] oc[16] oc[17] oc[18] oc[19]
+ oc[1] oc[20] oc[21] oc[22] oc[23] oc[24] oc[25] oc[26] oc[27] oc[28] oc[29] oc[2]
+ oc[30] oc[31] oc[3] oc[4] oc[5] oc[6] oc[7] oc[8] oc[9] rst samplee seg_drvs[0]
+ seg_drvs[1] seg_drvs[2] seg_drvs[3] seg_drvs[4] seg_drvs[5] seg_drvs[6] seg_drvs[7]
+ strobe tx value[0] value[10] value[11] value[12] value[13] value[14] value[15] value[16]
+ value[17] value[18] value[19] value[1] value[20] value[21] value[22] value[23] value[24]
+ value[25] value[26] value[27] value[28] value[29] value[2] value[30] value[31] value[3]
+ value[4] value[5] value[6] value[7] value[8] value[9] VPWR VGND

All the missing pins are there.

from netgen.

@mattvenn Thanks for checking.
FWIW, I don't think the error is that the pins are missing, but rather that since the circuits match, the pins are being matched to a different net. When I looked at a similar error in zipdiv, it was something like
Schematic: output->buffer->pin->buffer->buffer->logic
Layout: output->buffer->buffer->pin->buffer->logic
Logically equivalent but LVS doesn't match the pins. Don't know if this is true in all cases, though.

from netgen.

@mattvenn @RTimothyEdwards
I've seen this error on other designs. I think mgmt_core had 2 such errors.
The "missing" pins actually exist and are on the correct buffer chain, but at a different location. The netlists are functionally equivalent but not topologically.
After I manually changed the netlist (swapped the pin name with net at the expected position in the buffer chain), the netlists matched.
I'm thinking this may be caused by the buffer insertion program that might create a difference in the gate level verilog and the DEF.

In summary, I don't think the problem is with netgen and maybe this issue should be closed and another opened for the appropriate program.

from netgen.

I think I'm hitting this in my design. In my case io_oeb[27] is failing to match and netgen shows the pin twice in the pin summary:

io_oeb[27]                                 |(no matching pin)                          
...
io_oeb[27]                                 |io_oeb[27]                                 

The verilog shows it as an output as expected:

  sky130_fd_sc_hd__o22a_4 _60339_ (
    .A1(_23771_),
    .A2(wb_rst_i),
    .B1(la_data_in[65]),
    .B2(la_oen[65]),
    .VGND(vssd1),
    .VNB(vssd1),
    .VPB(vccd1),
    .VPWR(vccd1),
    .X(io_oeb[27])
  );

But it is also feeds a buffer:

  sky130_fd_sc_hd__buf_8 psn_inst_psn_buff_171 (
    .A(io_oeb[27]),
    .VGND(vssd1),
    .VNB(vssd1),
    .VPB(vccd1),
    .VPWR(vccd1),
    .X(psn_net_171)
  );

This got introduced by openphysyn I think. If so, openphsyn should create a new net when doing this, but shouldn't netgen collapse these into the same pin and match correctly?

from netgen.