Representing INF in a real?

[Paul Johnson]

I've got the following legacy (VHDL) code, which is meant to detect an
INF condition and store it in 'result':

variable result : real;
....
result := 1.0 / 0.0;

However, when this runs on Modelsim, I get this fatal error:

** Fatal: (vsim-3421) Value inf is out of range 1e+308 to -1e+308.

Well, that makes sense, except that this code is known to work (unless
this line was never executed; I'm not sure). It ran on Modelsim (and
compiled on DC), although on an older version of Modelsim.

Could this code have ever worked? And how? A quick look through the
Modelsim manuals doesn't give any hits on INF or NAN.

Many thanks -

Paul

[I've copied comp.lang.verilog as I don't think that this is
language-specific].

 

[Ben Jones]

"Paul Johnson" <abuse@127.0.0.1> wrote in message
news8dkt1pn5kq2nupuaa879hetqqqr1daiou@4ax.com...

I've got the following legacy (VHDL) code, which is meant to detect an
INF condition and store it in 'result':

variable result : real;
...
result := 1.0 / 0.0;

However, when this runs on Modelsim, I get this fatal error:

** Fatal: (vsim-3421) Value inf is out of range 1e+308 to -1e+308.

Well, that makes sense, except that this code is known to work

So now, it's also know *not* to work.

A quick glance at the VHDL LRM, e.g.:

http://www.microlab.ch/courses/vlsi/vhdl-ieee/TUTORIAL/IEEE/HTML/1076_3.HTM#
3.1.4

....tells me that implementations are not required to support any
"meta-values" such as NaNs or infinities, nor any exceptional conditions nor
denormalized numbers.

I guess this doesn't really answer your question, but it looks like
Modelsim's implementation of "real" is basically double-precision
floating-point but shorn of its meta-values.

I can imagine possibly creating a record type containing a real and a small
"tag" to hold FP metadata (inf,nan,exceptions), then overloading all the
operators to make it look like a real IEEE floating-point implementation -
but I think I'd rather remove my own corneas with a sharp implement

-Ben-

 

Your machine's floating point hardware presumably supports full IEEE
floating point, including Inf. So I would guess that Modelsim must be
explicitly testing for such values and producing an error, for some
reason. I don't know whether there is anything in the VHDL definition
that requires software intervention in the floating point calculations,
which might have prompted them to simplify them this way, or whether
this was an arbitrary decision on their part. It may be that they
didn't do this in an older version.

 

[Paul Johnson]

On Fri, 27 Jan 2006 11:00:15 -0800, Mike Treseler
<mike_treseler@comcast.net> wrote:

Ben Jones wrote:

Modelsim's implementation of "real" is basically double-precision
floating-point but shorn of its meta-values.

That is the case. See below.

Paul:

I expect that the statement
result := 1.0 / 0.0;
was never compiled on modelsim and if it
got by DC, that is a bug.
Just add a test for zero to your code.

The idea behind the original code was to store INF in 'result'. The FP
code in this chip handles infinities so this is, in principle, a
reasonable thing to do. The LRM doesn't prohibit this - it just
doesn't require it.

Noted that Quartus doesn't like this, but DC didn't complain. It would
be nice to see what logic it generated, but unfortunately I can't do
that.

BTW, the code compiles and elaborates on Modelsim without problems;
the error is a run-time range-checking error.

Paul

 

[Paul Johnson]

On 27 Jan 2006 10:45:52 -0800, sharp@cadence.com wrote:

Your machine's floating point hardware presumably supports full IEEE
floating point, including Inf. So I would guess that Modelsim must be
explicitly testing for such values and producing an error, for some
reason. I don't know whether there is anything in the VHDL definition
that requires software intervention in the floating point calculations,
which might have prompted them to simplify them this way, or whether
this was an arbitrary decision on their part. It may be that they
didn't do this in an older version.

I think you're basically right. The LRM doesn't require them to detect
values outside whatever range they support, but they've obviously
decided to do so. In principle, I can turn off all range checking with
a -nocheck flag in compilation, but I haven't yet got this to work
(and I don't want to, because the original code doesn't appear to do
this).

The original code ran on SPARC, and I'm now on x86. I guess it's
possible that the FPUs were set up differently, and Modelsim is using
an exception from the FPU to detect this condition on x86, but not on
SPARC.

Paul

 

I know of one area where the x86 floating point unit doesn't comply
with the IEEE floating point standard (specifically, in rounding).
This requires some extra software adjustment of the results if
compliant results are required. So it is certainly possible that
Modelsim is handling floating point differently on x86 and SPARC.