Instability / non-determinism in the spice netlist generation

[mithro]

Given the exact same input, magic produces non-deterministic spice output.

This seems to be because something is being sorted by the pointer location?

This can be most clearly seen from the following where the pin order changes from MET5 C1 C0 SUB to C0 C1 MET5 SUB

-.subckt sky130_fd_pr_rf2__rf2_xcmvpp11p5x11p7_m3_lim5shield MET5 C1 C0 SUB
+.subckt sky130_fd_pr_rf2__rf2_xcmvpp11p5x11p7_m3_lim5shield C0 C1 MET5 SUB

diff --git a/libraries/sky130_fd_pr_rf/v0.12.1/cells/aura_blocking/sky130_fd_pr_rf__aura_blocking.spice b/libraries/sky130_fd_pr_rf/v0.12.1/cells/aura_blocking/sky130_fd_pr_rf__aura_blocking.spice
index ccd682b94ed..93d4172ff8a 100644
--- a/libraries/sky130_fd_pr_rf/v0.12.1/cells/aura_blocking/sky130_fd_pr_rf__aura_blocking.spice
+++ b/libraries/sky130_fd_pr_rf/v0.12.1/cells/aura_blocking/sky130_fd_pr_rf__aura_blocking.spice
@@ -23,6 +23,25 @@ M1001 Source Gate Drain BULK pshort w=3e+06u l=150000u
 +  ad=0p pd=0u as=0p ps=0u
 .ends

+.subckt sky130_fd_pr_rf__rf_nlowvt_w3p0_l0p15_8f SUBSTRATE Source Drain Gate
+M1000 Drain Gate Source SUBSTRATE nlowvt w=3e+06u l=150000u
++  ad=3.36e+12p pd=2.624e+07u as=4.2e+12p ps=3.28e+07u
+M1001 Source Gate Drain SUBSTRATE nlowvt w=3e+06u l=150000u
++  ad=0p pd=0u as=0p ps=0u
+M1002 Source Gate Drain SUBSTRATE nlowvt w=3e+06u l=150000u
++  ad=0p pd=0u as=0p ps=0u
+M1003 Drain Gate Source SUBSTRATE nlowvt w=3e+06u l=150000u
++  ad=0p pd=0u as=0p ps=0u
+M1004 Source Gate Drain SUBSTRATE nlowvt w=3e+06u l=150000u
++  ad=0p pd=0u as=0p ps=0u
+M1005 Drain Gate Source SUBSTRATE nlowvt w=3e+06u l=150000u
++  ad=0p pd=0u as=0p ps=0u
+M1006 Source Gate Drain SUBSTRATE nlowvt w=3e+06u l=150000u
++  ad=0p pd=0u as=0p ps=0u
+M1007 Drain Gate Source SUBSTRATE nlowvt w=3e+06u l=150000u
++  ad=0p pd=0u as=0p ps=0u
+.ends
+
 .subckt sky130_fd_pr_rf__aura_blocking D_N2 G_N2 S G_P2 S_P2 S_P G G_P S_N2 D_P2 VPWR
 + D_P VGND NWELL B_P
 Xsky130_fd_pr_rf__rf_nlowvt_w0p42_l0p15_2f_0 sky130_fd_pr_rf__rf_nlowvt_w3p0_l0p15_8f_0/SUBSTRATE
@@ -31,5 +50,7 @@ Xsky130_fd_pr_rf__rf_pshort_w0p84_l0p15_2f_0 B_P S_P D_P sky130_fd_pr_rf__rf_nlo
 + G_P sky130_fd_pr_rf__rf_pshort_w0p84_l0p15_2f
 Xsky130_fd_pr_rf__rf_pshort_w3p0_l0p15_2f_0 B_P S_P2 D_P2 sky130_fd_pr_rf__rf_nlowvt_w3p0_l0p15_8f_0/SUBSTRATE
 + G_P2 sky130_fd_pr_rf__rf_pshort_w3p0_l0p15_2f
+Xsky130_fd_pr_rf__rf_nlowvt_w3p0_l0p15_8f_0 sky130_fd_pr_rf__rf_nlowvt_w3p0_l0p15_8f_0/SUBSTRATE
++ S_N2 D_N2 G_N2 sky130_fd_pr_rf__rf_nlowvt_w3p0_l0p15_8f
 .ends

diff --git a/libraries/sky130_fd_pr_rf2/v0.10.0/cells/rf2_xcmvpp11p5x11p7_m3_lim5shield/sky130_fd_pr_rf2__rf2_xcmvpp11p5x11p7_m3_lim5shield.spice b/libraries/sky130_fd_pr_rf2/v0.10.0/cells/rf2_xcmvpp11p5x11p7_m3_lim5shield/sky130_fd_pr_rf2__rf2_xcmvpp11p5x11p7_m3_lim5shield.spice
index 86d4ca2f484..1c8b3c7b01a 100644
--- a/libraries/sky130_fd_pr_rf2/v0.10.0/cells/rf2_xcmvpp11p5x11p7_m3_lim5shield/sky130_fd_pr_rf2__rf2_xcmvpp11p5x11p7_m3_lim5shield.spice
+++ b/libraries/sky130_fd_pr_rf2/v0.10.0/cells/rf2_xcmvpp11p5x11p7_m3_lim5shield/sky130_fd_pr_rf2__rf2_xcmvpp11p5x11p7_m3_lim5shield.spice
@@ -1,5 +1,5 @@
 * NGSPICE file created from sky130_fd_pr_rf2__rf2_xcmvpp11p5x11p7_m3_lim5shield.ext - technology: sky130A

-.subckt sky130_fd_pr_rf2__rf2_xcmvpp11p5x11p7_m3_lim5shield MET5 C1 C0 SUB
+.subckt sky130_fd_pr_rf2__rf2_xcmvpp11p5x11p7_m3_lim5shield C0 C1 MET5 SUB
 .ends

diff --git a/libraries/sky130_fd_pr_rf2/v0.10.0/cells/xcmvpp4p4x4p6_m3_lim5shield_top/sky130_fd_pr_rf2__xcmvpp4p4x4p6_m3_lim5shield_top.spice b/libraries/sky130_fd_pr_rf2/v0.10.0/cells/xcmvpp4p4x4p6_m3_lim5shield_top/sky130_fd_pr_rf2__xcmvpp4p4x4p6_m3_lim5shield_top.spice
index 83ba6c75bb0..c62d9ff836e 100644
--- a/libraries/sky130_fd_pr_rf2/v0.10.0/cells/xcmvpp4p4x4p6_m3_lim5shield_top/sky130_fd_pr_rf2__xcmvpp4p4x4p6_m3_lim5shield_top.spice
+++ b/libraries/sky130_fd_pr_rf2/v0.10.0/cells/xcmvpp4p4x4p6_m3_lim5shield_top/sky130_fd_pr_rf2__xcmvpp4p4x4p6_m3_lim5shield_top.spice
@@ -1,9 +1,9 @@
 * NGSPICE file created from sky130_fd_pr_rf2__xcmvpp4p4x4p6_m3_lim5shield_top.ext - technology: sky130A

 .subckt sky130_fd_pr_rf2__xcmvpp4p4x4p6_m3_lim5shield_top M5 SUB C0 C1
-Xsky130_fd_pr_rf2__rf2_xcmvpp4p4x4p6_m3_lim5shield_0[0|0] C0 C1 M5 SUB sky130_fd_pr_rf2__rf2_xcmvpp4p4x4p6_m3_lim5shield
-Xsky130_fd_pr_rf2__rf2_xcmvpp4p4x4p6_m3_lim5shield_0[1|0] C0 C1 M5 SUB sky130_fd_pr_rf2__rf2_xcmvpp4p4x4p6_m3_lim5shield
-Xsky130_fd_pr_rf2__rf2_xcmvpp4p4x4p6_m3_lim5shield_0[0|1] C0 C1 M5 SUB sky130_fd_pr_rf2__rf2_xcmvpp4p4x4p6_m3_lim5shield
-Xsky130_fd_pr_rf2__rf2_xcmvpp4p4x4p6_m3_lim5shield_0[1|1] C0 C1 M5 SUB sky130_fd_pr_rf2__rf2_xcmvpp4p4x4p6_m3_lim5shield
+Xsky130_fd_pr_rf2__rf2_xcmvpp4p4x4p6_m3_lim5shield_0[0|0] M5 C0 C1 SUB sky130_fd_pr_rf2__rf2_xcmvpp4p4x4p6_m3_lim5shield
+Xsky130_fd_pr_rf2__rf2_xcmvpp4p4x4p6_m3_lim5shield_0[1|0] M5 C0 C1 SUB sky130_fd_pr_rf2__rf2_xcmvpp4p4x4p6_m3_lim5shield
+Xsky130_fd_pr_rf2__rf2_xcmvpp4p4x4p6_m3_lim5shield_0[0|1] M5 C0 C1 SUB sky130_fd_pr_rf2__rf2_xcmvpp4p4x4p6_m3_lim5shield
+Xsky130_fd_pr_rf2__rf2_xcmvpp4p4x4p6_m3_lim5shield_0[1|1] M5 C0 C1 SUB sky130_fd_pr_rf2__rf2_xcmvpp4p4x4p6_m3_lim5shield
 .ends

diff --git a/libraries/sky130_fd_pr_rf2/v0.10.0/cells/xcmvpp6p8x6p1_polym4shield_top/sky130_fd_pr_rf2__xcmvpp6p8x6p1_polym4shield_top.spice b/libraries/sky130_fd_pr_rf2/v0.10.0/cells/xcmvpp6p8x6p1_polym4shield_top/sky130_fd_pr_rf2__xcmvpp6p8x6p1_polym4shield_top.spice
index 962df4be7fb..7d1aed9e04c 100644
--- a/libraries/sky130_fd_pr_rf2/v0.10.0/cells/xcmvpp6p8x6p1_polym4shield_top/sky130_fd_pr_rf2__xcmvpp6p8x6p1_polym4shield_top.spice
+++ b/libraries/sky130_fd_pr_rf2/v0.10.0/cells/xcmvpp6p8x6p1_polym4shield_top/sky130_fd_pr_rf2__xcmvpp6p8x6p1_polym4shield_top.spice
@@ -1,9 +1,9 @@
 * NGSPICE file created from sky130_fd_pr_rf2__xcmvpp6p8x6p1_polym4shield_top.ext - technology: sky130A

 .subckt sky130_fd_pr_rf2__xcmvpp6p8x6p1_polym4shield_top SUB C0 C1 M4
-Xsky130_fd_pr_rf2__rf2_xcmvpp6p8x6p1_polym4shield_0[0|0] C0 C1 M4 SUB sky130_fd_pr_rf2__rf2_xcmvpp6p8x6p1_polym4shield
-Xsky130_fd_pr_rf2__rf2_xcmvpp6p8x6p1_polym4shield_0[1|0] C0 C1 M4 SUB sky130_fd_pr_rf2__rf2_xcmvpp6p8x6p1_polym4shield
-Xsky130_fd_pr_rf2__rf2_xcmvpp6p8x6p1_polym4shield_0[0|1] C0 C1 M4 SUB sky130_fd_pr_rf2__rf2_xcmvpp6p8x6p1_polym4shield
-Xsky130_fd_pr_rf2__rf2_xcmvpp6p8x6p1_polym4shield_0[1|1] C0 C1 M4 SUB sky130_fd_pr_rf2__rf2_xcmvpp6p8x6p1_polym4shield
+Xsky130_fd_pr_rf2__rf2_xcmvpp6p8x6p1_polym4shield_0[0|0] M4 C0 C1 SUB sky130_fd_pr_rf2__rf2_xcmvpp6p8x6p1_polym4shield
+Xsky130_fd_pr_rf2__rf2_xcmvpp6p8x6p1_polym4shield_0[1|0] M4 C0 C1 SUB sky130_fd_pr_rf2__rf2_xcmvpp6p8x6p1_polym4shield
+Xsky130_fd_pr_rf2__rf2_xcmvpp6p8x6p1_polym4shield_0[0|1] M4 C0 C1 SUB sky130_fd_pr_rf2__rf2_xcmvpp6p8x6p1_polym4shield
+Xsky130_fd_pr_rf2__rf2_xcmvpp6p8x6p1_polym4shield_0[1|1] M4 C0 C1 SUB sky130_fd_pr_rf2__rf2_xcmvpp6p8x6p1_polym4shield
 .ends

[mithro]

FYI - This is probably blocking the skywater low level primitive release.

[RTimothyEdwards]

If you do parasitic capacitance extraction, you get behavior that is non-deterministic based on pointers to memory in a hash table. This is something different. You are getting a different pin order on your output. The extracted output pin order in the layouts should be enforced by doing "readspice" in magic to pull a CDL or SPICE file that has the pin order in it (only SPICE netlists require a specific pin order) and use that pin order to annotate the layout view with port indexes that match that pin order. But I thought you were doing this? Or is there no CDL or SPICE entry for the device sky130_fd_pr_rf2__rf2_xcmvpp6p8x6p1_polym4shield? The pin order here does make a difference, as C0 and C1 are the capacitor ports, but M4 is the metal shield, so scrambling them is bad.

[RTimothyEdwards]

I think I answered that question; only the "_top" cell has a SPICE file associated with it. So magic is free to use whatever pin order it decides on. I believe we talked about enforcing an alphabetical order by default so that it is consistent between runs. I will work on this.

[RTimothyEdwards]

@mithro : What is the source file that the above SPICE file is derived from?

[RTimothyEdwards]

@mithro : More research. . . If these cells come from the "vcells" files, then the problem is a disconnect between the original GDS file and CDL file. The GDS has cell name "s8rf_xcmvpp6p8x6p1_polym4shield" and has pins "c0", "c1", "c2", and "sub". The CDL has cell name "xcmvpp6p8x6p1_polym4shield" and has pins "pin0", "pin1", "pin2", and "pin3'. If the CDL source is corrected, then the "readspice" should work correctly for that cell, and the errors should go away.

[RTimothyEdwards]

@mithro : Even more research. . . The real underlying problem is that the SPICE for the lowest level device, which is xcmvpp11p5x11p7_m3_lishield, is in the device models under "xcmvpp_pqonly.mod". It is listed there as "inline subckt". There is still a discrepancy between the names in the GDS and .mod files, but I'm assuming that the usual regeneration of everything with the sky130_fd_pr_rf prefix will resolve that? If so, then the remaining problems are in converting SPECTRE to SPICE. The "inline subkt" line in the model will not be recognized by ngspice, and the SPECTRE-to-ngspice conversion must map this to a standard ".subckt" subcircuit. Once that is done, then the "readspice" script can read the subcircuit and use that to annotate the port order of the layout, so that the output of the device top will match the subcircuit definition. This depends on my working on the SPECTRE to SPICE conversion.

[mithro]

@RTimothyEdwards -- So it sounds like there are two issues; (a) Magic output not being deterministic (b) Something around reading the CDL files?

[RTimothyEdwards]

@mithro : Yes. Although there is no non-determinism if everything else is being done correctly. I would suggest that the non-determinism is best left as it is, as it is helping to flag other problems. The other problem is actually two problems in itself: (1) The names still disagree between layout and SPICE, and (2) The SPICE is in SPECTRE format so I can't read it. For (2), I could enhance the "readspice" command so that it can read the SPECTRE "inline subckt" syntax. However, it remains true that we need to convert these to SPICE anyway. So, my suggestion is to get the SPECTRE format converted to SPICE, then resolve the differences in names, and after that the rest of building the PDK IP library for sky130_fd_pr_rf2 should work.

[RTimothyEdwards]

The immediate pin ordering problem has been solved by extending the "port" command with the option "port renumber", which numbers all ports in the edit cell by alphabetical (strcmp) order.

[mithro]

@RTimothyEdwards So, I should use "port renumber" if I don't have a CDL file with the port order?

[RTimothyEdwards]

@mithro : Yes, although it should be okay to use "port renumber" regardless, since reading the SPICE or CDL file will just renumber it again. Just don't renumber the ports after reading a SPICE or CDL file.