Velocity Reviews - Computer Hardware Reviews

Velocity Reviews > Newsgroups > Programming > VHDL > Representing INF in a real?

Reply
Thread Tools

Representing INF in a real?

 
 
Paul Johnson
Guest
Posts: n/a
 
      01-27-2006
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].
 
Reply With Quote
 
 
 
 
Ben Jones
Guest
Posts: n/a
 
      01-27-2006

"Paul Johnson" <abuse@127.0.0.1> wrote in message
news(E-Mail Removed)...
> 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/...ML/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-


 
Reply With Quote
 
 
 
 
sharp@cadence.com
Guest
Posts: n/a
 
      01-27-2006
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.

 
Reply With Quote
 
Mike Treseler
Guest
Posts: n/a
 
      01-27-2006
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.

-- Mike Treseler
_____________________________

library ieee;
use ieee.std_logic_1164.all;
use ieee.numeric_std.all;
use ieee.math_real.all;
-- Fri Jan 27 10:25:29 2006 M.Treseler
entity test_real_big is
end test_real_big;

architecture sim of test_real_big
is
-- constant infinity : real := 1.0/0.0;
-- ** Error: Static divide by zero.
-- (vcom-1144) Value inf is out of real range -1e+308 to 1e+308.
-- (Quartus 5.1 says: "Value cannot contain divisor of zero.")
------------------------------------------------------------------
constant real_right : real := real'right;
constant real_right_str : string := real'image(real'right);
begin
process is
begin
report "maximum real value is " & real_right_str;
assert real_right = 1.0e+308 report "real_right not 1.0e+308";
wait;
end process;
end sim;

--------------------------------------------------------------------
--# 6.1c
--# vsim -c test_real_big
--# Loading /flip/usr1/modeltech/linux/../std.standard
--# Loading /flip/usr1/modeltech/linux/../ieee.std_logic_1164(body)
--# Loading /flip/usr1/modeltech/linux/../ieee.numeric_std(body)
--# Loading /flip/usr1/modeltech/linux/../ieee.math_real(body)
--# Loading work.test_real_big(sim)

--VSIM 1> run
--# ** Note: maximum real value is 1.000000e+308
--# Time: 0 ns Iteration: 0 Instance: /test_real_big
 
Reply With Quote
 
Paul Johnson
Guest
Posts: n/a
 
      01-27-2006
On Fri, 27 Jan 2006 11:00:15 -0800, Mike Treseler
<(E-Mail Removed)> 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
 
Reply With Quote
 
Paul Johnson
Guest
Posts: n/a
 
      01-27-2006
On 27 Jan 2006 10:45:52 -0800, http://www.velocityreviews.com/forums/(E-Mail Removed) 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
 
Reply With Quote
 
sharp@cadence.com
Guest
Posts: n/a
 
      01-30-2006
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.

 
Reply With Quote
 
 
 
Reply

Thread Tools

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
Simple pattern for representing a view of a domain object? Karl Seguin ASP .Net 1 12-09-2005 01:58 AM
How to force Tomcat to reload WEB-INF/lib and WEB-INF/classes ??? Hans Java 3 05-16-2004 04:57 PM
Representing signed numbers in VHDL Kingsley Oteng VHDL 0 05-04-2004 02:00 AM
std_logic_vector representing one bit ALuPin VHDL 3 02-25-2004 08:41 PM
XML DTD or schema for representing entities and relationships (SQL)? Simon Brooke XML 0 10-12-2003 02:05 PM



Advertisments