Representing INF in a real?

Discussion in 'VHDL' started by Paul Johnson, Jan 27, 2006.

  1. Paul Johnson

    Paul Johnson Guest

    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].
    Paul Johnson, Jan 27, 2006
    #1
    1. Advertising

  2. Paul Johnson

    Ben Jones Guest

    "Paul Johnson" <abuse@127.0.0.1> wrote in message
    news:p...
    > 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-
    Ben Jones, Jan 27, 2006
    #2
    1. Advertising

  3. Paul Johnson

    Guest

    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.
    , Jan 27, 2006
    #3
  4. 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
    Mike Treseler, Jan 27, 2006
    #4
  5. Paul Johnson

    Paul Johnson Guest

    On Fri, 27 Jan 2006 11:00:15 -0800, Mike Treseler
    <> 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, Jan 27, 2006
    #5
  6. Paul Johnson

    Paul Johnson Guest

    On 27 Jan 2006 10:45:52 -0800, 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
    Paul Johnson, Jan 27, 2006
    #6
  7. Paul Johnson

    Guest

    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.
    , Jan 30, 2006
    #7
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. senthil
    Replies:
    5
    Views:
    1,380
    senthil
    Jan 24, 2004
  2. ALuPin
    Replies:
    3
    Views:
    3,432
    Egbert Molenkamp
    Feb 25, 2004
  3. Kingsley Oteng

    Representing signed numbers in VHDL

    Kingsley Oteng, May 4, 2004, in forum: VHDL
    Replies:
    0
    Views:
    750
    Kingsley Oteng
    May 4, 2004
  4. Hans
    Replies:
    3
    Views:
    2,480
    Ryan Stewart
    May 16, 2004
  5. Curious Trigger
    Replies:
    2
    Views:
    1,813
    Curious Trigger
    Sep 9, 2006
Loading...

Share This Page