Subject: Re: adding NaN to Verilog-AMS
From: Pragmatic C Software (sjmeyer@pragmatic-c.com)
Date: Mon May 13 2002 - 17:38:26 PDT
I think tryhing to add an X value for reals (such as Nan) in digital code
is a very bad idea since it will break many legacy designs that use real
?: operator with reg selector as part of test bench. Statements
such as "d1 = (bus) ? 5.0 : -5.0;" need to set d1 to 0.0 for x/z bus.
Quoting Kevin Cameron x3251 (Kevin.Cameron@nsc.com):
> > 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.
>
>
>
>
>
-- Steve Meyer sjmeyer@pragmatic-c.com
This archive was generated by hypermail 2b28 : Mon May 13 2002 - 17:45:54 PDT