Dual MOSFET devices A and B simulation pin & model name conflict

[roweaver6]

QUICK SUMMARY
LOCATION: Sub-dialog “Simulation Model…” in Symbol Properties.
The problem is lack of independence of pin assignments and SUBCKT names of A an B devices of a part. Changing device A pins and MODEL name changes device B pins and name the same way, whereas they should not interact.

DETAIL:
6-pin complementary MOSFET part DMC2053UVT is in the 8.0 default library. Its schematic has A and B devices, which are a N-channel and a P-channel device, respectively. D G S pins are 6 1 5 and 2 3 4, respectively. No obvious problem found with the symbol.

From Diodes, Inc. I downloaded a “Dual MOSFETs.spice.txt” spice model file, which I shortened to “Dual MOSFETs.spice”. I tried to use this entire file, but there was a formatting error in an irrelevant part, so I copied the existing DMC2053UVT_N and DMC2053UVT_P definitions to a separate file “DMC2053UVT.spice”, containing two .SUBCKT 's:
.SUBCKT DMC2053UVT_N 10 20 30
and
.SUBCKT DMC2053UVT_P 10 20 30

That model text is reproduced at the bottom of this description.

The A and B devices of the symbol are identified correctly in the Properties. However, setting device A pin assignments and model name sets device B the same way. Setting B conversely forces A to look like B. So the complementary pair cannot be defined properly and of course has no chance of simulating properly.

Either I don’t understand how to setup the sub-devices of a part, or there is a serious bug.

Spice model file “DMC2053UVT.spice”, complete:

*---------- DMC2053UVT Spice Model ----------
.SUBCKT DMC2053UVT_N 10 20 30 
*     TERMINALS:  D  G  S
M1 1 2 3 3 NMOS L = 1E-006 W = 1E-006 
RD 10 1 0.01959 
RS 30 3 0.001 
RG 20 2 3.61 
CGS 2 3 3.675E-010 
EGD 12 0 2 1 1 
VFB 14 0 0 
FFB 2 1 VFB 1 
CGD 13 14 5.2E-010 
R1 13 0 1 
D1 12 13 DLIM 
DDG 15 14 DCGD 
R2 12 15 1 
D2 15 0 DLIM 
DSD 3 10 DSUB 
.MODEL NMOS NMOS LEVEL = 3 VMAX = 5.378E+005 ETA = 0.001 VTO = 0.9393 
+ TOX = 6E-008 NSUB = 1E+016 KP = 37.46 U0 = 400 KAPPA = 10 
.MODEL DCGD D CJO = 2.015E-010 VJ = 0.7935 M = 0.6 
.MODEL DSUB D IS = 3.075E-010 N = 1.17 RS = 0.03137 BV = 26 CJO = 5E-011 VJ = 0.6 M = 0.748 TT = 3.4E-009 
.MODEL DLIM D IS = 0.0001 
.ENDS
.SUBCKT DMC2053UVT_P 10 20 30 
*     TERMINALS:  D  G  S
M1 1 2 3 3 PMOS L = 1E-006 W = 1E-006 
RD 10 1 0.04439 
RS 30 3 0.001 
RG 20 2 8.47 
CGS 2 3 3.947E-010 
EGD 12 30 2 1 1 
VFB 14 30 0 
FFB 2 1 VFB 1 
CGD 13 14 7.7E-010 
R1 13 30 1 
D1 13 12 DLIM 
DDG 14 15 DCGD 
R2 12 15 1 
D2 30 15 DLIM 
DSD 10 3 DSUB 
.MODEL PMOS PMOS LEVEL = 3 U0 = 400 VMAX = 1E+006 ETA = 0.001 
+ TOX = 6E-008 NSUB = 1E+016 KP = 28.79 KAPPA = 19.32 VTO = -0.919 
.MODEL DCGD D CJO = 4.315E-010 VJ = 0.6 M = 0.7569 
.MODEL DSUB D IS = 1.86E-008 N = 1.276 RS = 0.06967 BV = 27 CJO = 7.361E-011 VJ = 0.6 M = 0.6276 TT = 4.2E-009 
.MODEL DLIM D IS = 0.0001 
.ENDS
*Diodes DMC2053UVT Spice Model v1.0M Last Revised 2018/2/5

[holger]

There is no bug.

You have a symbol with 6 pins, but your model descriptions do have only 3 pins each. So you need to translate between the two, again with another subcircuit. This one handles the 3 to 6 pin translation, but cares also for the correct pin sequence.

* new subcircuit DMC2053UVT
* pin sequence     1  2  3  4  5  6  as given by the symbol
.subckt DMC2053UVT GN SP GP DP SN DN
* include the model file
.include DMC2053UVT.spice
* call the NMOS
* pin sequence given by the model
XN DN GN SN DMC2053UVT_N
* call the PMOS
* pin sequence given by the model
XP DP GP SP DMC2053UVT_P
.ends

Put this into a file and attach it to the symbol.

Not tested!

EDIT: symbol pins are D G S 6 1 5 and 4 3 2 !

[roweaver6]

Thank you for the solution, and for detecting my DGS pin assignment error on the P-MOSFET. I got the simulation working.

As a comment, I can’t help but still feel that what I was trying to do, i.e., assigning and wiring distinct SUBCKT’s to units A and B, was legitimate and should be supported. The UI kind of fooled me into believing it would work, since it lets us open separate dialogs explicitly invoking either unit A or unit B, but then still shares the model settings between units, which in general makes no sense. It forces an extra layer of complexity and interdependence. If there were enough community support for it, I would make it a feature request. I am a very inexperienced user, so I hesitate to press the point at this time. There is clearly a valid work-around.

Thanks again, for the high-quality help.