@Mitch Bailey Any suggestion how to fix this lvs issue

core_debug[7]                              |core_debug[7]                              
core_debug[8]                              |core_debug[6] **Mismatch**                 
core_debug[6]                              |core_debug[8] **Mismatch**                 
core2dmem_addr_o[7]                        |core2dmem_addr_o[7]

How about swapping

core_debug[6]

and

core_debug[8]

?

how to do that? output logic [48:0] core_debug ,

Can you swap in the layout or is this autorouted?

Its auto-routed with OpenLane flow. No other mismatches

Can I get your verilog and gds?

give me min

Can I get your gate level verilog? Either gds should be fine - they should be equal.

updated

Is that the correct gate level verilog? There are no

decap

cells in it.

@Vijayan Krishnan: The issue here looks like it's caused by you having in the verilog gate level netlist:

sky130_fd_sc_hd__buf_2 _40295_ (
    .A(\i_pipe_top.exu2idu_rdy ),
    .X(core_debug[6])
  );
...
  sky130_fd_sc_hd__buf_2 _40297_ (
    .A(\i_pipe_top.exu2idu_rdy ),
    .X(core_debug[8])
  );

So core_debug[6] and core_debug[8] are connected to the same signal. If I trace the layout, these signals are clearly connected to different nets. There seems to be much more going on here than just a pin swap. But if it really is just the two pins connected to the same net, then you should set

ext2spice short resistor

in magic before doing extraction, so that it will keep the two port names separated.

Tim, unless I'm mistaken, the verilog that you snipped does not show that

core_debug[6]

and

core_debug[8]

are connected to the same signal, but rather that they are outputs of 2 separate buffers with the same input, meaning that they are interchangeable from a topological standpoint (unless they are connected to something else). I thought netgen does a port check after the topology check to resolve these types of automorphisms.

Ah, yes, you are absolutely right, and if all else is connected correctly, then it should be a symmetry issue and pins would be matched correctly through the symmetry-breaking code. I traced the layout behind both buffers and they aren't the same net, though.

@Mitch Bailey @Tim Edwards Thanks for looking into it. Here is user repo: https://github.com/dineshannayya/riscduino, with MPW6 openlane no LVS issues. But with 2022.06.27_01.36.21 openlane tag i am facing LVS issues. Where I need to start trace for this issue?

I've seen similar mismatches where the number of buffers has been different between the gate level netlist and the layout.

is something we can do it with OpenLane flow scripts?

I don't think the data you sent corresponds to input for your lvs results. The gate level netlist you sent shows

core_debug[6]

and

core_debug[8]

as outputs of 2 separate buffers with the same input. However, tracing these nets in the layout, has

core_debug[6]

as a buffer output, but

core_debug[8]

is not only an output of a buffer, but also input to 3 logic gates. I'll take a look at the repo data on Monday.

Also, the verilog file has no power pins, which is going to cause an LVS nightmare by itself. There should be some final gate-level verilog produced by openlane that has all added components such as decap and input/output buffers, and which also has power pins for every macro. That must be the verilog netlist you used, or else you would not have gotten to pin matching. Please post that verilog file.

@Tim Edwards Here is detailed routing stage netlist file

Do you have the gds you used? The gds in

ycr_gds.zip

doesn't appear to match your lvs results. In the netlist, the difference between

core_debug[6]

and

core_debug[8]

is the number of diodes connected to the previous buffer input. They are logically equivalent.

signoff folder all gds files attached

I've duplicated your results and will investigate the cause.