Thanks for the clarification John, and sorry about the munged subject line.I would like to take a stab at Summarizing this if I can, I'm not sure it's completely accurate, so anyone should feel free to make corrections.
Different versions of spice use different methods of modeling non-linear dependent sources, Eg. ASRC, Bxxxx, Exxxx, Gxxxx, Fxxxx, Hxxxx, etc...
Some like NGspice use arbitrary expressions with conditionals, others like GNUcap use polynomials and curve fitting. The POLY function seems to be the least common denominator of these, though Spice3 doesn't support them. Polynomials were the first tool used to approximate non-linear relationships because they are well behaved and spice can easily find the derivative at a point which is used in the numerical solutions. The down side is you have to do some extra work with other tools to get the coefficients for your polynomial description.
As John points out below, common problems with polynomial approximations are:
1. They rapidly become useless outside a limited domain. BSIM models are indeed prone to unphysical behavior at operating points outside the domain of their approximations because they use polynomial adjustments for some computations.
2. It takes a lot of terms to do a decent approximation of a function whose shape isn't very "polynomial like"
The other method is to use an arbitrary expression with something like if-then-else functionality or the piece wise linear functions. This is simpler to formulate but incurs the risk of discontinuities which can cause serious convergence problems. However they are much more convenient for hacking something together.
A lot of effort has gone into having the best of both worlds. The PWL functions often use small curves to smooth the transition from one derivative to the next. and the expressions using the if-then-else functions are forced to make gradual transitions between different values. In general the libraries use polynomial approximations where they can and constrain them to areas where they are useful. Examples of this in GNUcap are the fit and table statements.
However, if you want to try out your models in other spice versions you'll probably want to do the extra work to describe their behavior in terms of the poly statement which unfortunately is not documented very well in ngspice or gnucap. Here is one place it is:
http://newton.ex.ac.uk/teaching/CDHW/Electronics2/userguide/secC.htmlTo do the curve fitting I suppose you could use tools like gnuplot, grace, or simfit.
Note that for NGspice to support POLYs you need to set that compile time option see:
http://www.brorson.com/gEDA/SPICE/x496.html Clif
Date: Fri, 12 Nov 2010 08:28:06 -0700 From: John Doty <jpd@xxxxxxxxx> Subject: Re: gEDA-user: geda-user Digest, Vol 54, Issue 32 To: gEDA user mailing list <geda-user@xxxxxxxxxxxxxx> Message-ID: <D16AFF7E-DEC3-4F74-917F-735BBFF5FAFC@xxxxxxxxx> Content-Type: text/plain; charset=us-ascii On Nov 11, 2010, at 9:58 PM, clif@xxxxxxxxxxxxx wrote:You can configure ngspice to support POLY. See http://www.brorson.com/gEDA/SPICE/x496.html.Yes but there isn't much in the way of examples on how to use them.Are POLYs really that much better at solving convergence problems to be worth the extra trouble? Is there a good into or howto on how to use them?There is a vast literature on the subject of constructing polynomial approximations to functions. Google for "polynomial approximation". You'll never be able to digest it all.True, but that dosn't help with for exmaple how to make models for multiple variables. Apparently you can say something like POLY(2) or POLY(3) but then how do you list the values? In Gnucap it seems you list the coeficent of X^0 (1) but a lot of models start with X^1. It would be helpfull to have a howto that described the best practices for all of this with some example problems.http://newton.ex.ac.uk/teaching/CDHW/Electronics2/userguide/secC.htmlAlso some discussion on when to use them vs arbituray expressions as in Bxxxx sources. Naively one might assume that becuase they should be well behaived functions that each point would have a usable first or even second derivative, and this would help convergance. Though here is a quote from the NGspice manual Chapt 12.2.7 BSIM1 model (level 4): "A known problem of this model is the negative output conductance and the convergence problems, both related to poor behavior of the polynomial equations."Common problems with polynomial approximations: 1. They rapidly become useless outside a limited domain. BSIM models are indeed prone to unphysical behavior at operating points outside the domain of their approximations because they use polynomial adjustments for some computations. 2. It takes a lot of terms to do a decent approximation of a function whose shape isn't very "polynomial like".So it's not even obvious that they will perform better. Are they there just to support legacy models, or are there times when they are the best tool we have?Most special function libraries use polynomial approximations heavily, so if you're using Bxxxx you're almost certainly using polynomials implicitly. The advantage of the library functions is that they've generally been designed to use a given polynomial only within the domain in which it behaves well. John Doty Noqsi Aerospace, Ltd. http://www.noqsi.com/ jpd@xxxxxxxxx
_______________________________________________ geda-user mailing list geda-user@xxxxxxxxxxxxxx http://www.seul.org/cgi-bin/mailman/listinfo/geda-user