RE: constants.vams

We believe that it is best not to rely on constants defined outside of the
model definition. The only way to enforce consistency for a model
definition is to include all mathematical constants in that definition. At
Tek, we explicitly define such constants as part of the model definition so
there is never a question about exact values and how they might affect both
parameter extraction and model implementation/translation.
   As Colin points out, the most important thing is that the parameter
extraction for a given model correlates to a known set of mathematical
constants.
   Of course, these issues are purely related to methodology, since nobody
is forced to use the constants which are predefined in some auxiliary file.

Adam

Adam W. DiVergilio
Tektronix, Inc.

-----Original Message-----
From: owner-verilog-ams-devmod@eda.org
[mailto:owner-verilog-ams-devmod@eda.org] On Behalf Of McAndrew Colin-rp3881
Sent: Monday, August 23, 2004 10:18 AM
To: 'Kevin Cameron'; Geoffrey.Coram
Cc: Chandrasekaran Srikanth-A12788; VerilogA Device Modeling Reflector;
verilog-ams@eda.org
Subject: RE: constants.vams

one comment: if the values of `P_K and/or `P_Q change then
simulation results for all previous Verilog-A models
that use these constants will change. the change does not look to be much,
but `P_K/`P_Q appears in some models as part of an argument to exp(),
which will magnify the effect of the change.

for a diode like current, at -50C with 1 volt across it
the difference in current from the difference in physical constants
is 0.15%. at 27C and 0.8 volt the difference is 0.09%.

these are non-trivial differences. if models have parameters,
these will be have been extracted consistently with the existing `P_
physical constants.

the issue of updating the `P_ values needs to be considered carefully.
do you want all existing models that use these constants to give
different simulation results?

this is the reason I do not use these constants when I define models,
I explicitly define the constants I need as part of a model definition.

colin

-----Original Message-----
From: owner-verilog-ams-devmod@eda.org
[mailto:owner-verilog-ams-devmod@eda.org] On Behalf Of Kevin Cameron
Sent: Monday, August 23, 2004 9:19 AM
To: Geoffrey.Coram
Cc: Srikanth Chandrasekaran; VerilogA Device Modeling Reflector;
verilog-ams@eda.org
Subject: Re: constants.vams

Geoffrey.Coram wrote:

>Sri -
>I was having a look through the "constants.vams" file listing in the
>AMS LRM and found the following mistakes:
>
>1) M_TWO_PI should end with "93" rather than "52"
>(The 9 is obvious from doubling M_PI; I confirmed this with Abramowitz
>and Stegun.)
>
>2) Planck's constant is listed as P_K, which conflicts with the
>definition of Boltzmann's constant; I believe the macro should be P_H.
>
You could add P_H - removing P_K would probably be a bad idea, and
changing P_K to be something else would be a very bad idea. Maybe
add a comment the P_K will be deprecated.

>3) The definition of P_U0 has extra text on the end, indicating the
>value of (4.0e-7 * `M_PI), but if the file were used as-is, it would
>create a syntax error for the parser.
>
>Also, it appears that the values of P_Q and P_K have been updated by
>NIST since the constants were taken from http:://physics.nist.gov
>
>4) the current value for P_Q is 1.60217653e-19
>(the "53" used to be "462")
>5) the current value for P_K is 1.3806505e-23
>(last digit was 3)
>
>
>At least one Spice-like simulator uses traditional Spice values for
>these constants (P_K = 1.3806226e-23), so these last two aren't
>critical.
>
>Do you think (2) and (3) should be fixed in LRM 2.2?
>
>
If the constant definitions are wrong I would certainly vote for fixing
them ASAP.

Kev.

>-Geoffrey
>
>
Received on Mon Aug 23 11:28:31 2004