@User: I happen to have been working on the same cell this morning. The clear issue with LVS here is that the overlay cell shorts VSSIO to VSSIO_Q directly in the cell, and the place where the vias are that short the two pins overlaps the label area, so that without modifying the label areas, there is no place to drop a metal resistor to separate the two pin names so that they can be on independent nets. I am vaguely aware that there are conditions under which the shorted nets don't get reported, but I haven't looked into the specifics, so while your theory about it sounds plausible, I can't confirm it. Magic keeps labels and geometry in completely different records. The handling in GDS is somewhat complicated, but I think the upshot is that the text purpose ends up as the label in magic; the label in magic is associated with a rectangle and a layer type, but that layer type is not actual geometry. It just identifies what layout layer the label is associated with. In the case of VSSIO_Q, the label (one of them) is associated with metal4, but the geometry underneath the label area contains both metal and contact cuts from the overlay cell. Those contacts short VSSIO_Q on metal4 to VSSIO on metal3 directly underneath, and so the two nets cannot be separated unless the VSSIO_Q label is cleanly separated from those contacts. Since the label in question is in the top level cell, I can just modify the layout to keep it from overlapping the overlay cell contacts.

@User Looking at the flattened

sky130_ef_io__vssio_hvc_clamped_pad

layout, I'm thinking it might be possible to add

met3/short

layers above and below the left and right

via3

for

VSSIO_Q

(a total of 4 locations).

VSSIO

is connected on the top and bottom to 3 of the 4 vertical wide

met3

.

No, there shouldn't be a limit to

flatglob

, so that might need to be debugged. Thanks for getting the

vssio_hvc_clamped_pad

through LVS. I started off a few days ago by looking for the short between

VSSIO

and

VSSIO_Q

and discovering that magic's

select short

was recursive and ran out of stack space, so I got sidetracked fixing that. Then I found I could do

select short VSSIO_Q VSSIO

but not

select short VSSIO VSSIO_Q

and have so far tracked it down to some low-level issue in the net selection mechanism that seems rather important to get solved. Hopefully I can get that done today and move on to other things.

I think I figured out why

flatglob

wasn't working like I expected. For example, I wasn't able to flatten the following subckt even though it contained no devices.

.subckt sky130_fd_io__gnd2gnd_sub_dnwl sky130_fd_io__gnd2gnd_tap_0[4]/sky130_fd_io__gnd2gnd_strap_0/li_0_0#
+ sky130_fd_io__gnd2gnd_tap_0[3]/sky130_fd_io__gnd2gnd_strap_0/li_0_0# sky130_fd_io__gnd2gnd_tap_0[2]/sky130_fd_io__gnd2gnd_strap_0/li_0_0#
+ sky130_fd_io__gnd2gnd_tap_0[1]/sky130_fd_io__gnd2gnd_strap_0/li_0_0# sky130_fd_io__gnd2gnd_diff_0[3]/sky130_fd_io__gnd2gnd_strap_0/li_0_0#
+ sky130_fd_io__gnd2gnd_tap_0[0]/sky130_fd_io__gnd2gnd_strap_0/li_0_0# sky130_fd_io__gnd2gnd_diff_0[2]/sky130_fd_io__gnd2gnd_strap_0/li_0_0#
+ sky130_fd_io__gnd2gnd_diff_0[1]/sky130_fd_io__gnd2gnd_strap_0/li_0_0# sky130_fd_io__gnd2gnd_diff_0[0]/sky130_fd_io__gnd2gnd_strap_0/li_0_0#
.ends

Turns out I need to flatten the layout cells it contains

sky130_fd_io__gnd2gnd_tap

and

sky130_fd_io__gnd2gnd_strap

also.

I guess you can flag that as another issue on the github tracker. Either it should just allow the flattening or else state why it isn't doing it.