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.html
To 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 <[email protected]>
Subject: Re: gEDA-user: geda-user Digest, Vol 54, Issue 32
To: gEDA user mailing list <[email protected]>
Message-ID: <[email protected]>
Content-Type: text/plain; charset=us-ascii
On Nov 11, 2010, at 9:58 PM, [email protected] 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.html
Also 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/
[email protected]
_______________________________________________
geda-user mailing list
[email protected]
http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
