David,
>> One thing I missed in your last proposal was that
>> you were fixing the size of the fraction and exponent
>> with type generics. I still think we should have a
>> package that allows the user to define the size of
>> floating and fixed point numbers they want. Perhaps
>> with the package interface:
>>
>> package fphdl_pkg is
>> generic ( fp_round_style : round_type := round_nearest; -- rounding
>> fp_denormalize : BOOLEAN := true; -- Denormal numbers
>> fp_check_error : BOOLEAN := true; -- NAN processing
>> fp_guard_bits : NATURAL := 3 ); -- guard bits
>
>
> Actually, one of the beauties of the package generics is that you do NOT
> need to do this any more.
>
> Suppose I have an architecture which have very efficient 18 bit
> multipliers. Then I can set up my floating point number accordingly
>
> library ieee;
> use ieee.fphld_base_pkg.all;
> package fphdl26_pkg is new ieee.fphdl32_pkg
> generic map (fp_fraction_width => 16,
> fp_exponent_width => 9,
> fp_round_style => round_nearest,
> fp_denormalize => false,
> fp_check_error => false,
> fp_guard_bits => 1);
>
> use work.fphdl26_pkg.all;
> entity....
> architecture ...
>
>
> In side the multiply routine:
> The floating point fraction will be read in as 16 bits.
> 1 bit will be added to the top (implied 1.0)
> 1 bit will be added to the bottom (1 guard bit)
> The result will be 18 bits wide.
>
> Because "fp_denormalize" is truned off the exponent does not need
> to be checked in every operation and does not have to be tied to the
> fraction.
>
> Because "fp_check_error" is turned off bounds on the shift registers
> no longer need to be checked.
>
> Because fp_guard_bits is "1" and "fp_round_style" is set to
> "round_nearest" then a "1" in the lower bit so the result will result
> in a round and a zero will not, simplifying the round routine.
If one decides to only use one size of floating point, then
the use model of each is similar.
However, if you have more than one size of floating point,
they are different.
To get a generic type plus a variety of "standard" floating
point types, I think we should be keeping the type an
unconstrained type and then make the standard types subtypes
of the unconstrained type to implement the different sizes:
If we were to use a package of the type:
package fphdl_pkg is
generic ( fp_round_style : round_type := round_nearest; -- rounding
fp_denormalize : BOOLEAN := true; -- Denormal numbers
fp_check_error : BOOLEAN := true; -- NAN processing
fp_guard_bits : NATURAL := 3 ); -- guard bits
and then in that package, define fp (as it is now):
type fp is array (INTEGER range <>) of STD_LOGIC; -- main type
Create a set of standard subtypes to replace the other packages:
subtype fp16 is fp ( 9 downto -6);
subtype fp32 is fp (23 downto -8);
subtype fp64 is fp (52 downto -11);
subtype fp128 is fp (95 downto -32);
With the packages you propose, you
will need to have a package instantiation for each size
of floating point you need. This is no big deal as you
can put it in any given file, compile it and the new package
ends up in the library. The notable thing is referring to
the type. You will have to refer to it by:
ieee.fphdl64_pkg.fp;
You suggested to use an alias. Where do you define the alias?
In every architecture that references the package?
alias fp64 is ieee.fphdl64_pkg.fp;
Regards,
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 Sun Nov 7 18:26:37 2004
This archive was generated by hypermail 2.1.8 : Sun Nov 07 2004 - 18:26:40 PST