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 Mon Aug 23 20:14:30 2004