Re: constants.vams

From: Jonathan Sanders <jons@cadence.com>
Date: Mon Aug 23 2004 - 12:09:57 PDT

Geoffrey,

See below.

Jon

At 06:26 AM 8/23/2004, 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.)

JONS: Don't think we caught this one, looks like a bug that needs to be
corrected.

>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.

JONS: This was correct back in v2.0 so it must have been broken in 2.1
when we fixed some typos and other NIST values. Should be P_H as it was
before.

>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.

This first issue is a bug in my opinion but based on stuff I have read in
various newsgroups on Verilog almost all Verilog solutions have the same
bug. Only DC and BuildGates support nested macros that I am aware
of. With that said rather than waiting for all the vendors to fix this
(don't hold your breath) lets just insert the value from above.

>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)
>

JONS: Hard to track a moving target. I had thought when we added the NIST
reference we were going to put a date on that so that it would cover stuff
like this. I think we should probably not change these but if the user
really want's the latest values they can use the value in the reference.

>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?

JONS: Actually I would probably fix 1-3 as (1) looks like a typo also.

>-Geoffrey

***********************************************************
Jonathan L. Sanders
Product Engineering Director
Custom IC Solutions
Cadence Design Systems, Inc.
555 River Oaks Pkwy
San Jose, CA. 95134
  INTERNET:jons@cadence.com Tel: (408) 428-5654 Fax : (408) 944-7027
***********************************************************
Received on Mon Aug 23 12:10:07 2004

This archive was generated by hypermail 2.1.8 : Mon Aug 23 2004 - 12:10:10 PDT