Debugging SPICE Model

336 views
Skip to first unread message

Woofuls Wolla

unread,
Feb 21, 2020, 12:08:00 PM2/21/20
to xyce-users
Hello,

I was looking for additional information on how to better debug a SPICE model that is not behaving, presumably due to some error on my part. I am now having a convergence issues, but I assumate it is actually a translation error. I wanted to import existing model of INA225, a Texas Instruments voltage-output current-sense amplifier. I have followed your Reference Guide's "Differences Between Xyce and PSpice", which helped me identify a number of earlier problems with the model. I am more interested in how you go about debugging it rather than exactly what I have done wrong here. I will walk you through what I have done thus far.

The attached tar file contains:
sboom881a.sch --- gschem of the overall circuit
sboom81a.cir --- this is the overall circuit
IDA225.sym --- symbol for INA225 in gschem
INA225.cir --- modified version of subcircuit from TI meant to work in Xyce
out --- contains the detailed output from my recompiled verison of Xyce
TIVERSION --- contains the original TINA-TI PSPICE version of the model

The manufacturer supplies a PSPICE model that I am attempting to translate into a format that is interpretable by XYCE. In TI’s TINA simulator, they provide a circuit and results that I think can be useful for verification/validation, as pictured below:

TI_Spice.png


In gschem I have attempted to recreate a simpler version of the schematic, as pictured below:

SPICE.png


The symbol for INA225, IDA225.sym, has the following appearance:

INA225.png


I replaced all variable statements such as ES0 NS0 0 VALUE = {0.5*(1 + SGN(V(GS0)-VTHR))} with ES0 NS0 0 VALUE = '0.5*(1 + SGN(V(GS0)-VTHR))'

I replaced parameters such as .PARAM GPSRR = {PWR(10,-PSRR/20)/RPSRR} with .FUNC GPSRRF(PWR,PSRR,RPSRR) {PWR(10,-PSRR/20)/RPSRR}

I replaced statements such as VSENSE VI VO DC = 0 with VSENSE VI VO DC 0

I moved some global param from the subcircuit level up

I recompiled Xyce with --enable-verbose_nonlinear--enable-verbose_time, but have not had any success in understanding exactly what is failing.


Do you have any advice on how to proceed further with respect to the debugging? Would you recommend I recompile and debug using something like gdb?

spicetranslation.tar

xyce-users

unread,
Feb 21, 2020, 5:54:47 PM2/21/20
to xyce-users
I can't give you a quick answer here, but a couple of things stand out as translation errors.  Some of the things you're doing are unnecessary, and possibly a source of error:

I replaced all variable statements such as ES0 NS0 0 VALUE = {0.5*(1 + SGN(V(GS0)-VTHR))} with ES0 NS0 0 VALUE = '0.5*(1 + SGN(V(GS0)-VTHR))'


This is unnecessary.  Xyce's native expression delimiter is the curly brace.  The single-quote delimiter is an HSPICE compatibility hack that is translated at an early stage of parsing into the brace delimited version.  You should leave these as is.


I replaced parameters such as .PARAM GPSRR = {PWR(10,-PSRR/20)/RPSRR} with .FUNC GPSRRF(PWR,PSRR,RPSRR) {PWR(10,-PSRR/20)/RPSRR}


This is also unnecessary, and possibly an error.  Xyce should handle ".PARAM GPSRR = {PWR(10,-PSRR/20)/RPSRR}" just fine, and given your netlist, should end up setting GPSRR to 1e-7.


Neither of those things is likely to be the source of your convergence problems.  However...


You've got a large number of warnings about nodes that are connected to only one device.  These warnings are usually the sign of a real problem that can result in convergence problems, and Xyce is trying to tell you that there's a problem.  Of the warnings I've looked at in your circuit, most appear to be nodes of voltage-controlled voltage sources that are then not connected to anything, but whose values are used in expressions later.  This is a real connectivity error, and may very well be responsible for your problems.  For example, Xyce is complaining:

Netlist warning: Voltage Node (X1:X_U14:NOUTMAX) connected to only 1 device


And if you look at TIVERSION, you'll see that NOUTMAX only appears in two lines:
EOUTMAX NOUTMAX GNDF VALUE = {MAX(MIN(GL*(VpinDelta-V(OUT,VCC)),1),0)}
ERO  NRO  GNDF VALUE = {V(NREFMAX,GNDF)*V(NOUTMAX,GNDF)*V(NREFMIN,GNDF)
+                      *V(NOUTMIN,GNDF)}



The EOUTMAX voltage source has a branch current, and Xyce is trying to compute the value of the branch current that satisfies the Kirchoff current law at node NOUTMAX --- but this cannot be done because there is nowhere for current to go when it's dumped into node NOUTMAX.  ERO has the same problem, because NRO is connected to nothing.  Your circuit is chock full of things like this, and Xyce is warning about them.  Your best bet is to fix up your circuit so that these warnings go away.  For every VCVS that has this problem, just add a 1 ohm resistor between the problematic node and ground, and then Xyce should be able to solve the system of equations.  For example:
EOUTMAX NOUTMAX GNDF VALUE = {MAX(MIN(GL*(VpinDelta-V(OUT,VCC)),1),0)}
ROUTMAX NOUTMAX GNDF 1
ERO  NRO  GNDF VALUE = {V(NREFMAX,GNDF)*V(NOUTMAX,GNDF)*V(NREFMIN,GNDF)
+                      *V(NOUTMIN,GNDF)}
RRO NRO GNDF 1


I cannot say for sure that Xyce will run your circuit without problems after fixing all this, but this sort of thing is very much a smoking gun.

xyce-users

unread,
Feb 23, 2020, 5:09:40 PM2/23/20
to xyce-users

Just as an aside, the addition of resistors to tie dangling nodes (i.e. those attached only to one device) can be automated using the ".preprocess" directive as described in the Xyce users' guide in section 13.4.  If you use this, you would be well advised to make absolutely certain that the resistors added by this technique are only being added to these defective E source instances.

Add ".preprecess addresistors oneterminal 1" to your netlist, and Xyce will then emit a modified netlist with "_xyce" appended to its name that contains the 1 ohm resistors necessary to tie off the dangling nodes.

Normally one uses a very large resistance for this option, but if (and pretty much only if) the error involved is this specific one of E sources with nothing connected to them, any resistance should do the trick.

You would not want to use this option to correct other dangling node mistakes, though, which is why it wasn't the first thing I suggested.  Carefully reviewing your circuit to make sure that all of it is connected correctly is the first step.  If all the mistakes are E sources with no complete circuit attached to them, then the .preprocess statement will cause Xyce to emit a netlist with the defects corrected.  See chapter 13 of the users' guide for full details.
Reply all
Reply to author
Forward
0 new messages