Re: [vhdl-200x-ft] binary representation of "real"

David,
> The big problem here is keeping ambiguity out
> of the language.
I agree.

>> > I would propose that we put these into the
>> > fixed and floating point packages.
>> I don't like the idea of these being in a
>> package other than std.standard/std.textio.
>>
>> Real is a signed floating point number.
>> If we don't require a sign (+ or -) then
>> an unsigned quantity must have a leading
>> zero.
>
>
> This is far too simplistic a way to look at a floating point
> number.
We already have:
     procedure READ(L:inout LINE; VALUE: out real; GOOD : out BOOLEAN);
     procedure READ(L:inout LINE; VALUE: out real);

How are your issues addressed by these?

> 1) Is it rounded? How is it rounded, there are 4 different
> ways. According to the spec, they are selectable.

Of the different modes available which are appropriate
for values that are read?
If we need these, then we need to be able to specify
them during a read (and write?).

> 2) How do you process "not a number" (NAN)? Infinity? If we treat it
> as a floating point number than "1111.1111" = NAN, and "1111.0000"
> = negative infinity.

Is there a way to handle these currently?
Long term we need to solve this, but if it is not
already handled by READ, then there is no reason
to withhold bread, oread, and hread.

Do we need to add identifiers associated with reading
to represent these values? (NAN, INF, INFINITY, ??)

With "1111.1111" does the "." mean E or does it
separate the whole value from the fraction?

> 3) What radix? 32 bit and 64 bits are defaults, but any width
> is allowed with IEEE 854.
What should happen if I try to read a 64 bit floating point
value into a 32 bit implementation?

>
>> Alternately if requiring a sign (+ or -) is
>> ok, then the read/write of all formats for
>> real and the proposed fixed and floating point
>> packages could be based on the current
>> read/write format for real (decimal).
>
>
> The problem here is that "real" is "implimentation_defined" in
> the 2002 LRM. Thus the binary representation can vary simulator
> to simulator. Again ambiguity.
>
>> A third alternative for real and integer is
>> to not implement bwrite/bread, owrite/oread,
>> and hwrite/hread.
>
>
> This sounds like a plan. At least for VHDL-200X-FT.
Agreed. Particularly if there are technical issues
that we need to solve. However, based on your concerns,
this would also seem to imply that we cannot do these
procedures for the proposed fixed point or floating point
packages as they would need to solve the same issues.

What is done for both of these would seem to need to be
consistent.

Cheers,
Jim

-- 
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Jim Lewis
Director of Training             mailto:Jim@SynthWorks.com
SynthWorks Design Inc.           http://www.SynthWorks.com
1-503-590-4787
Expert VHDL Training for Hardware Design and Verification
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~