when i crawl the sky130 primitives spice decks with bigspicy i find that some primitives are instantiated with a substrate connection that doesn't exist, e.g.

warning: instance Xsky130_fd_pr__rf_pfet_01v8_aF02W3p00L0p15_0 of module sky130_fd_pr__rf_pfet_01v8_aF02W3p00L0p15 has too many connections; signal [signal: SUBS w=1] will not be connected
	known ports: ['d', 'g', 's', 'b']
	instance connections: D_P2, S_P2, G_P2, B_P, SUBS

in this case

sky130_fd_pr__rf_pfet_01v8_aF02W3p00L0p15

has two

subckt

definitions and neither has a 5th terminal:

./sky130_fd_pr__rf_pfet_01v8_aF02W3p00L0p15.spice:18:.subckt sky130_fd_pr__rf_pfet_01v8_aF02W3p00L0p15 BULK DRAIN GATE SOURCE
./sky130_fd_pr__rf_pfet_01v8.pm3.spice:184:.subckt  sky130_fd_pr__rf_pfet_01v8_aF02W3p00L0p15 d g s b

anyone know what's going on?

Looks like this instance (and other 5 terminal mosfet) are from

sky130_fd_pr__rf_aura_blocking

,

sky130_fd_pr__rf_aura_drc_flag_check

,

sky130_fd_pr__rf_aura_lvs_drc

. Example:

.subckt sky130_fd_pr__rf_aura_blocking B_P D_N2 D_P D_P2 G G_N2 G_P G_P2 NWELL S S_N2
+ S_P S_P2 VGND VPWR
Xsky130_fd_pr__rf_pfet_01v8_aF02W3p00L0p15_0 D_P2 S_P2 G_P2 B_P SUBS sky130_fd_pr__rf_pfet_01v8_aF02W3p00L0p15
Xsky130_fd_pr__rf_nfet_01v8_lvt_aF08W3p00L0p15_0 D_N2 G_N2 S_N2 SUBS sky130_fd_pr__rf_nfet_01v8_lvt_aF08W3p00L0p15
Xsky130_fd_pr__rf_pfet_01v8_aF02W0p84L0p15_0 D_P S_P G_P B_P SUBS sky130_fd_pr__rf_pfet_01v8_aF02W0p84L0p15
Xsky130_fd_pr__rf_nfet_01v8_lvt_aF02W0p42L0p15_0 VPWR G S SUBS sky130_fd_pr__rf_nfet_01v8_lvt_aF02W0p42L0p15
.ends

As you can see, both the nfets and pfets have 5 terminals, with the 5th terminal being connected to the local

SUBS

net. Looks like the spice files were originally extracted with each containing a full hierarchy, but subsequently all the child subckts were removed. @Tim Edwards any ideas?

@Mitch Bailey: I believe the

aura

macros have no layout, so they are basically irrelevant. For a lot of devices, though, such as the ones @aryap mentioned, where there are two subcircuit definitions, the one with the file name equal to the subcircuit name (e.g.,

sky130_fd_pr__rf_pfet_01v8_aF02W3p00L0p15.spice

) was extracted by magic from layout; where there exists an actual model for the device (e.g.,

sky130_fd_pr__rf_pfet_01v8.pm3.spice

), this is a characterized model of the exact layout, is preferred, and will be the one pointed to by the hierarchy of model files descending from

sky130.lib.spice

. At the time that the open PDK was created, the SPICE files were extracted by magic and no attempt was made to determine if any of the subcircuits already had models of the same name. I have since added behavior in

open_pdks

that looks for layouts that have (subcircuit) models of the same name, and adds to the magic view of the layout the property

device primitive

, which tells magic not to extract the subcircuit at all, and any instances of that subcircuit will be extracted as if they were low-level devices, and the only pin connections output are pins declared in the layout.

ah i see, thanks for looking into it