Subject: Re: adding NaN to Verilog-AMS
From: Kevin Cameron x3251 (Kevin.Cameron@nsc.com)
Date: Mon May 13 2002 - 15:20:04 PDT
> From owner-verilog-ams@eda.org Mon May 13 14:34:15 2002
> content-class: urn:content-classes:message
> Subject: adding NaN to Verilog-AMS
> X-MS-Has-Attach:
> X-MS-TNEF-Correlator:
>
> I asked someone here, Steve Sharp, who was on Verilog-2001 committee about
> using NaN as a kind of real X (unknown).
>
> Here is his feedback;
>
> I don't know of any languages that have found the need to be able to
> reference the value of NaN explicitly. There is not much point in
> assigning it explicitly, since it will arise naturally in arithmetic
> situations where the IEEE standard calls for it. And trying to compare
> a value to it doesn't work, since NaN does not compare equal to
> anything, including NaN. So (r == NaN) is false even if r is NaN.
> That seriously limits the usefulness of having it available as a
> constant.
The usual usage (in C) is to use the isnanf/isnand macros in ieeefp.h
to determine if the number is NaN or not (only the exponent bits are
used). NaN is available as a constant for users to assign to variables
as necessary.
> Converting X to a real is probably rare enough that it wouldn't cause
> severe backward compatibility problems. However, if NaN is considered
> to be the floating point equivalent of X, shouldn't reals have an
> initial value of NaN at the start of simulation to match non-real
> variables which start at X? But that would cause severe backward
> compatibility issues. There is probably plenty of code that relies
> on reals to be initialized to zero (or at least to a value that doesn't
> contaminate everything computed from it, potentially creating closed
> loops of computation stuck at NaN).
Initial value of 0.0 is fine - C does that with static data. The issue
is run-time conversion of X/Z's.
An X bit in digital Verilog is usually absolutely unknown, it can therfore
be taken as 1 or 0 - the decision to take 0 (in bitstoreal) is arbitrary.
Changing that to be the appropriate bit from NaN would not make a
simulation more or less valid; it may be more likely to fail (with a
run-time error), but I would view that as better behavior.
> NaN behaves more pessimistically than X, since it represents mathematical
> impossibility, rather than just uncertainty between valid possibilities.
I think division by zero falls in the latter category :-) - just more
values to choose from.
> I don't think it makes sense to spend a lot of time worrying about NaN.
> It seldom comes up in normal programming, and the usual action when
> it does come up is to fix the bug in the code so that it doesn't. Note
> that there is no mention of it anywhere in the Verilog standard. It
> just isn't important to a user. Only hardcore numerical algorithms need
> to worry about it, and the users of the algorithms generally don't care
> as long as it was done right so they know whether their results are valid.
Normal (C) programming doesn't have X's, and (as far as I can tell) the
digital simulation folk rarely do floating point arithmetic and usually
don't worry about analog issues at all. Verilog-A is mostly floating point
arithmetic.
Using NaN appropriately will let the floating point hardware handle the
cases where X's propagate into the matrix much more efficiently than the
other approaches offered both from a simulation throughput and user usage
perspective.
Kev.
This archive was generated by hypermail 2b28 : Mon May 13 2002 - 15:23:03 PDT