RE: constants.vams

I had one thought over night. to avoid possible issues with physical constants changing,
should there be some form of version control and access, or naming that
uniquely identifies the source?, e.g. having the constants in named include
`include "constants_NIST2004.h"
or having the constant names include a source ID tag, `P_K_NIST2004?

these constants should NEVER change once they are defined.

colin

-----Original Message-----
From: owner-verilog-ams-devmod@eda.org [mailto:owner-verilog-ams-devmod@eda.org] On Behalf Of Chandrasekaran Srikanth-A12788
Sent: Monday, August 23, 2004 8:14 PM
To: 'Geoffrey.Coram'
Cc: 'VerilogA Device Modeling Reflector'; verilog-ams@eda.org
Subject: RE: constants.vams

Geoffrey,

I changed some of the numbers in the constants.vams file last time around based on what it was in the NIST webpage. Didn't realize it has changed after that.(infact I remember that's why I put in the reference around last time so that people can get latest values from the website). I agree that 2 & 3 should definitely be fixed.

I am not sure about the procedure - ie. The other TCC committees have a deadline of 28th August to make any recommendations, point out any mistakes in the LRM that need to be fixed. Probably it would fall under that bucket.

Regards,
Sri

> -----Original Message-----
> From: Jonathan Sanders [mailto:jons@cadence.com]
> Sent: Tuesday, August 24, 2004 4:40 AM
> To: Geoffrey.Coram; Chandrasekaran Srikanth-A12788
> Cc: VerilogA Device Modeling Reflector; verilog-ams@eda.org
> Subject: Re: constants.vams
>
>
> 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 Tue Aug 24 08:12:57 2004