Re: [vhdl-200x-ft] Re: floating point, thinking out loud

Jim Lewis wrote:

> or change to_fp to take an object and let the function
> use 'high and 'low on the object:
>
> function to_fp (arg : real; obj : fp) ;
>
> Y_fp32 <= to_fp(7.5, Y_fp32) ;

I though of this for the fixed point packages too. I'd
like to get the groups concensus before I make a change like this.

You would be able to say
yfixed <= to_ufixed (7.5, yfixed'high, yfixed'low);
or
yfixed <= to_ufixed (7.5, yfixed);
Where "yfixed" would not have a default, and only the size would be
used. I would like to hear what the language guys have to say about
this one.

Extending to floating point:
y_fp18 <= to_fp (7.5, y_fp18'high, -y_fp18'low);
or
y_fp18 <= to_fp (7.5, y_fp18);

We could even extend this to numeric_std:
ysigned <= to_signed(7, ysigned);

>>> On the other hand, lets suppose that I have fp32 defined
>>> as a subtype of fp and all math operations are implemented
>>> for the type fp.
>>> subtype fp32 is fp(8 downto -23) ;
>>>
>>> Can't I coerce the string literal using a type qualifier
>>> as follows?
>>> Y_fp32 <= A_fp32 + fp32'("11000000110100000000000000000000") ;
>>
>> Yes, this would work, and it is the same model as we have to use
>> for fixed point.
>>
>> The issue is that the typical user will select ONE format for floating
>> point, and convert to and from it.
>
> I would expect fp_round_style, fp_denormal, and fp_check_error
> to stay the same. I was wondering if people change the number
> of bits they use and perhaps even the number of guard bits they
> use depending on the precision they need.
>
> For example do I want more guard bits for a multiply than
> for an add/subtract?

Yes, you might want to do that. Originally we had the base package.
Now that the base package is hidden we may want to break out
add, subtract, and multiply the same way we do divide.

In the package we have:
function "/" (l,r: fp) return fp;
and
function divide (l,r : fp, denormalize : boolean, guard_bits : natural....);
We can do the same for add, subtract, and multiply (and mod and rem).

> I would really like to see some of the FP experts who have
> joined the reflector to comment on this.

Comments?

>> Think about this use model:
>>
>> package fphdl_types is
>> .....
>> type float is array (INTEGER range <>) of STD_LOGIC;
>> subtype fp32 is float (8 downto -23);
>> subtype fp64 ....
>>
>> end package fphdl_types;
>
>
> Why do we need a separate types package?
>
> I suspect that if we define float, fp32, fp64 in a
> separate package from fphdl_pkg, then if we instantiate
> the package more than once (probably rare with the
> modified interface) it will create homographs
> of the operators and functions.

That is why they are in the "fphdl_types_pkg" package. We
still need it.

> I think we either need all of these types in the fphdl_pkg
> or we need a float type in the types package and an
> identically defined fp type in the fphdl_pkg. I think
> this is similar to the package architecture you had before.

Yes, but they are all one package now, the fphdl_types_pkg package.
Thus we will no longer need to define them in the fphdl_pkg,
in fact doing so would create a homograph.

> I like what you are proposing with the fphdl_pkg interface
> and use model below:
>
>> package fphdl_pkg is
>> generic (
>> -- NO fraction_width and exponet_width generics
>> fp_round_style : round_type;
>> fp_denormalize : BOOLEAN;
>> fp_check_error : BOOLEAN;
>> fp_guard_bits : NATURAL
>> );
>>
>> function to_fp (arg : real;
>> exponent_width : natural;
>> fraction_width : natural);
>> function to_fp32 (arg : real);
>> function to_fp64 (arg : real);
>> function to_fp128 (arg : real); -- For all standard widths
>> .....
>> end package body fphdl_pkg;
>>
>> package fphdl_IEEE is new IEEE.fphdl_pkg
>> generic map (
>> fp_round_style := round_nearest;
>> fp_denormal := true;
>> fp_check_error := true;
>> fp_guard_bits := 3);
>>
>>
>> Then the use model would be:
>>
>> use ieee.fphdl_types.all;
>> use ieee.fphdl_ieee.all;
>> signal xxx, yyy : fp32;
>> begin
>> yyy <= to_fp32(3.14);
>> xxx <= xxx + yyy;
>>
>> IF the user wanted to create their own type they could do this:
>>
>> use ieee.fphdl_types.all;
>> use ieee.fphdl_ieee.all;
>> subtype fp18 is float (7 downto -10);
>> signal xxx, yyy : fp18;
>> begin
>> yyy <= to_fp18(3.14, yyy'high, -yyy'low);
>> xxx <= xxx + yyy;
>>
>> IF a user doesn't want IEEE rounding and denormal numbers, they can
>> do this:
>>
>> use ieee.fphdl_types.all;
>> package fphdl_small is new IEEE.fphdl_pkg
>> fp_round_style := round_zero;
>> fp_denormal := false;
>> fp_check_error := false;
>> fp_guard_bits := 0);
>>
>> use work.fphdl_small.all;
>> signal xxx, yyy : fp32;
>> begin
>> yyy <= to_fp32(3.14);
>> xxx <= xxx + yyy;
>
>
> Does the use model need to allow a user to be able
> to switch (while doing trade-offs) between floating point
> and fixed point? Granted this would complicate the
> package design.

Yes. With this model you could do this:

signal sf7 : sfixed (3 downto -3);
signal f7 : float (3 downto -3);
....

f7 := to_fp (sf7, f7);
or
f7 := to_fp (sf7, f7'high, -f7'low);
....
sf7 := to_sfixed (f7, sf7);
or
sf7 := to_sfixed (f7, sf7'high, sf7'low);

The floating point package is built on top of the fixed point and
numeric_std package. Thus all of the converstions to the lower level
types are defined.

-- 
NAME:     David W. Bishop           INTERNET: dbishop@vhdl.org