Missing connectivity in extracted spice netlist

[d-m-bailey]

I've noticed a few examples of the extracted netlist missing the expected connectivity. Manual inspection of the layout seems to show the desired connectivity.

Case 1. https://github.com/efabless/caravel.git commit 40f091a8

Make the following changes to the Makefile

@@ -313,7 +313,9 @@ LVS_GDS_BLOCKS = $(foreach block, $(BLOCKS), lvs-gds-$(block))
 $(LVS_GDS_BLOCKS): lvs-gds-% : ./gds/%.gds ./verilog/gl/%.v
        echo "Extracting $*"
        mkdir -p ./gds/tmp
-       echo "gds read ./$*.gds;\
+       echo "gds flatglob \"*_example_*\";\
+                gds flatten true;\
+                gds read ./$*.gds;\
                load $* -dereference;\
                select top cell;\
                extract no all;\

And then make lvs-gds-chip_io to create the extracted netlist spi/lvs/chip_io.spice DRVLO_H_N is supposed to connect sky130_fd_io__com_opath_datoev2 to sky130_fd_io__gpiov2_obpredrvr. The unconnected nets are marked with '**'

.subckt sky130_fd_io__gpiov2_octl_dat VPWR VGND VCC_IO VPWR_KA SLOW HLD_I_H_N HLD_I_OVR_H
+ OD_H SLOW_H_N DRVHI_H PU_H_N[3] PU_H_N[2] PU_H_N[1] PU_H_N[0] PD_H[1] PD_H[0] PD_H[4]
+ DM_H_N[2] DM_H_N[0] DM_H[2] DM_H[1] DM_H[0] OUT OE_N DM_H_N[1] PD_H[3] PD_H[2] DM_H[1]_uq0
...
Xsky130_fd_io__com_opath_datoev2_0 OUT OE_N DRVHI_H **sky130_fd_io__com_opath_datoev2_0/DRVLO_H_N**
+ VCC_IO VGND HLD_I_OVR_H VPWR_KA sky130_fd_io__com_opath_datoev2_0/OE_H OD_H sky130_fd_io__com_opath_datoev2_0/sky130_fd_io__com_cclat_0/PD_DIS_H
+ VGND sky130_fd_io__com_opath_datoev2_0/li_5565_99# OD_H sky130_fd_io__com_opath_datoev2
Xsky130_fd_io__gpiov2_obpredrvr_0 PD_H[3] PD_H[2] sky130_fd_io__gpiov2_octl_0/PDEN_H_N[1]
+ DRVHI_H **sky130_fd_io__gpiov2_obpredrvr_0/DRVLO_H_N** VGND PU_H_N[3] PU_H_N[2] PU_H_N[1]
+ PU_H_N[0] PD_H[1] PD_H[0] PD_H[4] sky130_fd_io__gpiov2_octl_0/SLOW_H sky130_fd_io__gpiov2_obpredrvr_0/PUEN_H[1]
+ sky130_fd_io__gpiov2_obpredrvr_0/PUEN_H[0] sky130_fd_io__gpiov2_octl_0/PDEN_H_N[0]

However, the layout appears connected

[RTimothyEdwards]

The layout looks like it was done by a summer intern unfamiliar with layout tools, and is giving magic quite the challenge trying to work through the awkward contortions of the layout (Cypress Semiconductor, I'm looking at you. . . ) (come to think of it, this is probably another reason that foundries don't like to open source their stuff).

At any rate, it looks like the underlying issue is that the pin label DRVLO_H_N is sitting by itself in the cell gpiov2_octl_dat and attached to no metal by itself, just implicitly connected to the metal wire in the cell underneath it. It would have been much better if the pin were just connected to the metal2 line just to the left of it, which is the wire that connects the two cells. So anyway, while the .ext file has the correct merge statement connecting the two cells together, it has no "node" or "port" statement for the isolated label "DRVLO_H_N", so the merge of the nets gets stopped there.

Now that I understand the underlying problem, it should be pretty easy to track down and fix.

[RTimothyEdwards]

@d-m-bailey : Okay, I've skirted around this issue before, although in a slightly different context. There is an extract option called "extract do labelcheck" that fixes the problem. There was an open question as to whether that should not even be a setting but should just be set always. That is still an open question, but there was one point in the code that checks the "labelcheck" flag that clearly should be run regardless, because otherwise it creates this situation where the .ext file contains references to undeclared nodes and/or ports, and ext2spice then fails to perform the correct net merges. So I have fixed that issue (just pushed version 8.3.226 to opencircuitdesign.com). Jury's still out on the need for the "labelcheck" option. . .