lvs issue with openlane

mattvenn commented 3 years ago

Hi Tim, when hardening the user project wrapper in openlane I get an LVS issue with logic analyser pin not being found.

multi_project_harness.lvs.log

but multi_project_harness.lvs.powered.v

shows input [127:0] la_data_in as a signal

let me know if you need any more info.

mattvenn commented 3 years ago

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

RTimothyEdwards commented 3 years ago

@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.

d-m-bailey commented 3 years ago

@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

mattvenn commented 3 years ago

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.

d-m-bailey commented 3 years ago

@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.

d-m-bailey commented 3 years ago

@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.

antonblanchard commented 3 years ago

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?

RTimothyEdwards / netgen

lvs issue with openlane #7