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

From: Jim Lewis <Jim@SynthWorks.com>
Date: Mon Jun 28 2004 - 11:53:27 PDT

David,
>> 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?
>
>
> Here you are representing a real number like this:
> 2.5, -2.5, 25.4E-5
> No binary numbers involved, thus no ambiguity.
> The problem is one of translating binary to real and back, and
> being consistant about it.

For binary -2.5, why can't we use:
   Either: 10.1 (interpreting sign bit)
   Or: -10.1 (no binary sign bit)

For binary 2.5, why can't we use:
   Either: 010.1 (interpreting sign bit)
   Or: 10.1 (no binary sign bit
   Or: +10.1 (no binary sign bit)

I like requiring +/- because it is consistent
with the current real number format.

It would still require additional parameters to be
specified in the read.

>> 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.
>
>
> Correct. You would have to do it like this:
>
> HREAD (L : inout LINE; VALUE : out FP32); (or UFIXED, SFIXED, fp, etc).
> realvar := to_real (VALUE);
>
> If I overloaded it for real, and you used both the fixed and floating
> point packages, you would have an ambiguity problem.

So inside of either the package that defines FP32 or
the type itself, you have specified additional parameters
somehow (rounding, ...).

Have you documented how this works?

When we review the package, we will need to review this.

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
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Received on Mon Jun 28 11:53:29 2004

This archive was generated by hypermail 2.1.8 : Mon Jun 28 2004 - 11:53:30 PDT