Magic fails to write out 'device mosfet' with ihp-sg13g2 since Ver.8.3.590

[H-Ojiro]

Dear @RTimothyEdwards,

This issue could be related to PR#480: Changed bjt device parameter processing to match *subckt devices.
I noticed that magic fails to extract 'device mosfet' since v8.3.590

In the ihp-sg13g2-extract.tech, MOSFET device is defined for variants (lvs) as follows

 # MOSFET
 device mosfet sg13_lv_nmos nfet *ndiff *ndiff pwell,space/w error

which causes empty .subckt ~ .ends in spice file

* NGSPICE file created from sg13_lv_nmos_top.ext - technology: ihp-sg13g2

.global pwell $SUB 

.subckt sg13_lv_nmos_top sub S1 D1 G1
.ends

As is the case with PR#480, contained 'device mosfet' definition in the .ext file

device mosfet sg13_lv_nmos -8 40 -7 41 26 30 "sub" "G1" 52 0 "S1" 30 4020,268 "D1" 30 4020,268

When I apply magic Ver8.3.589 or earlier, I can get the extracted spice file correctly.

* NGSPICE file created from sg13_lv_nmos_top.ext - technology: ihp-sg13g2

.global pwell $SUB 

.subckt sg13_lv_nmos_top sub S1 D1 G1
M1000 D1 G1 S1 sub sg13_lv_nmos w=0.15u l=0.13u
+  ad=0.1005p pd=1.34u as=0.1005p ps=1.34u
.ends

Here is a test case file which contains two cases; one for using 'device msubcircuit' in ngspice() style as a reference
and another for 'device mosfet' in ngspice(lvs) style

testcase-regression_unit-mos_devices.tar.gz

@d-m-bailey

[RTimothyEdwards]

There were a lot of code changes at version 8.3.590. I ran many test cases, but apparently something is broken, which is odd, because "device mosfet" is pretty standard and the use case for IHP sg13g2 shouldn't be any different from sky130 or gf180mcu, both of which were tested heavily. Thanks for the example test case.

[RTimothyEdwards]

Also you shouldn't have ".global pwell $SUB". "pwell" isn't a valid node in the subcircuit, and "$SUB" should have been substituted with the Tcl variable value, not left as a variable name. But that's a different problem and appears to predate this issue. I can confirm the issue as well as several error messages appearing during extraction. I will work on this now.

[RTimothyEdwards]

Looking into it further, I agree with your assessment that it is an unanticipated consequence of PR#480 and the patch for BJT device parsing.

[RTimothyEdwards]

Okay, I have a fix and will push shortly. In PR#480, I should have changed the argument count only for the BJT, not for the BJT and the MOSFETs.

[RTimothyEdwards]

Magic version 8.3.594 fixes this error, as well as another error I found in which magic was printing an unnecessary error message when reading in the tech file. I also discovered an error in the tech file for the rfcmim device for which I will make a pull request to the IHP open PDK repository. Thank you for the reproducible example.