Extraneous internal nets become spice ports

[d-m-bailey]

When extracting the flattened (via gds flatglob) sky130_ef_io__vssio_hvc_clamped_pad cell, the nwell internal node w_880_5378# is promoted to a port even though it is later merged with VDDIO. In the final spice netlist, w_880_5378# is a disconnected port.

merge "w_880_5378#" "dw_1900_26360#"
merge "dw_1900_26360#" "sky130_fd_io__overlay_vssio_hvc_0/sky130_fd_io__com_bus_hookup_0/VDDIO"
merge "sky130_fd_io__overlay_vssio_hvc_0/sky130_fd_io__com_bus_hookup_0/VDDIO" "sky130_fd_io__overlay_vssio_hvc_0/VDDIO"
merge "sky130_fd_io__overlay_vssio_hvc_0/VDDIO" "VDDIO"

Magic 8.3 revision 253

Expected behavior: merged internal nets are not extracted as ports.

This may be related to merging nodes across hierarchical boundaries.

I've attached the extracted spice file and the ext file. sky130_ef_io__vssio_hvc_clamped_pad.spice.gz

sky130_ef_io__vssio_hvc_clamped_pad.ext.gz

[d-m-bailey]

The above was output when the layout cells corresponding to hierarchical spice subckts inside sky130_ef_io__vssio_hvc_clamped_pad were flattened.

However, the ext file still contained layout hierarchy cells that has no devices and thus were not output.

use sky130_ef_io__hvc_vssio_overlay sky130_ef_io__hvc_vssio_overlay_0 1 0 0 0 1 -1
use sky130_fd_io__overlay_vssio_hvc sky130_fd_io__overlay_vssio_hvc_0 1 0 0 0 1 -407
use sky130_fd_io__top_ground_hvc_wpad sky130_fd_io__top_ground_hvc_wpad_0 1 0 0 0 1 -407

Flattening these cells removed the unwanted port.

[RTimothyEdwards]

@d-m-bailey : I have a clue as to what's going on and how to fix it, but I need to reproduce the example exactly. What is the list of commands you used to read the GDS and extract?

[d-m-bailey]

I've moved some of the environment variables from config.tcl file to here, but this should be right.

set ::env(CURRENT_GDS) {chip_io.gds}
set ::env(MAGIC_EXT_USE_GDS) {1}
set ::env(MAGIC_GDS_FLATTEN_CELLS) {
  *_example_*
  *_cdns_*
  sky130_fd_io__gpiov2_pdpredrvr_strong
  sky130_fd_io__gpiov2_obpredrvr
  sky130_fd_io__gpiov2_amux_ls
  sky130_fd_io__gpiov2_octl_dat
  sky130_fd_io__gpiov2_amux_ctl_logic
  sky130_fd_io__gpiov2_amux
  sky130_fd_io__top_gpiov2
  sky130_ef_io__gpiov2_pad
  sky130_fd_io__top_ground_hvc_wpad
  sky130_fd_io__sio_clamp_pcap_4x5
  sky130_fd_io__com_busses_esd
  sky130_fd_io__esd_rcclamp_nfetcap
  sky130_fd_io__pad_esd
  sky130_fd_io__top_ground_lvc_wpad
  sky130_fd_io__gnd2gnd_120x2_lv_isosub
  sky130_fd_io__gnd2gnd_sub_dnwl
  sky130_fd_io__gnd2gnd_strap
  sky130_fd_io__gnd2gnd_diff
  sky130_fd_io__gnd2gnd_tap
  sky130_ef_io__lvc_vccdy_overlay

~~sky130_fd_iocom_bus_hookup sky130_fd_iocom_bus_slice sky130_ef_iohvc_vssio_overlay sky130_fd_iooverlay_vssio_hvc~~

}
if { [info exist ::env(MAGIC_EXT_USE_GDS)] && $::env(MAGIC_EXT_USE_GDS) } {
        if { [info exist ::env(MAGIC_GDS_FLATTEN_CELLS)] } {
                foreach cell $::env(MAGIC_GDS_FLATTEN_CELLS) {
                        gds flatglob $cell
                }
                # list cells to be flattened
                puts "Flattening [gds flatglob]"
                gds flatten yes
        }
        gds read $::env(CURRENT_GDS)
} else {
        lef read /home/user/pull-requests/openlane-efabless/pdks/sky130A/libs.ref/sky130_fd_sc_hd/techlef/sky130_fd_sc_hd.tlef
        if {  [info exist ::env(EXTRA_LEFS)] } {
                set lefs_in $::env(EXTRA_LEFS)
                foreach lef_file $lefs_in {
                        lef read $lef_file
                }
        }
        def read 0
}
load chip_io -dereference
cd /home/user/mpw-3/caravel-test/openlane/chip_io/runs/cvc/results/finishing/
extract do local
extract no capacitance
extract no coupling
extract no resistance
extract no adjust
if { ! 1 } {
        extract unique
}
# extract warn all
extract

ext2spice lvs
ext2spice -o /home/user/mpw-3/caravel-test/openlane/chip_io/runs/cvc/results/finishing/chip_io.gds.spice chip_io.ext
feedback save /home/user/mpw-3/caravel-test/openlane/chip_io/runs/cvc/logs/finishing/1-ext2gds.spice.feedback.txt

(edited)

[d-m-bailey]

@RTimothyEdwards actually, the flatten cell settings given above will produce the desired result. Let me see if I can fix it.

[RTimothyEdwards]

@d-m-bailey : The commit I just made is supposed to address this issue. The problem, as I understand it, is mainly that extra ports are made and removed during a flattening stage. These ports are all defined in a database that represents the flattened and optimized subcircuit. The routine that writes out the ports to the .subckt record, though, uses the port list from the original, unoptimized cell definition. I added some additional code to cross-check between the two, which allows ports that were optimized out to be removed from the cell definition's port list.

[RTimothyEdwards]

@d-m-bailey : I ran the new code on your example, and it does get rid of the disconnected nets in sky130_ef_io__vssio_hvc_clamped_pad. The extraction of all of chip_io is better with the new code than with the old, but it affects only a few subcircuits. Which sort of makes sense, because the code previously was generally working except for a few corner cases.

[d-m-bailey]

@RTimothyEdwards seems to be working! I'll wait until all the pads clear LVS and then close the issue.

[RTimothyEdwards]

@d-m-bailey : Unfortunately it also makes ext2spice go ballistic for large layouts. I knew that the implementation was not efficient, though, and I'm working on a better implementation of the same code.

[RTimothyEdwards]

@d-m-bailey : I did another commit at the end of the day yesterday, and that fixed the problem with the long runtimes without changing the behavior. I have confirmed that with the last fix, the LVS of the Caravel chip is working right, and has gotten rid of various substrate-related nets that were showing up as pins before. Those were not affecting the LVS results, as they were being treated as disconnected pins and discarded, but it's much cleaner now to not have them in the output.