RE: [vhdlsynth] Re: [vhdl-200x-ft] More ideas on 1164 and 1076.3

In my opinion, there's no reason to put it in commented out. If synthesis vendors don't support it, then they can explain that to their customers.

Most users have no ability to go in and modify sources of standard packages and then recompile them. Those libraries are setup in a common install area that only sysAdmins have control over.

-Steve Bailey

> -----Original Message-----
>
> Yes, this is a known issue, even with the "numeric_std" package.
> Many synthesis vendors do not support a signed or unsigned divide.
>
> Commented out in the "fphdl_base_pkg_body.vhd" you will find
> the following routine:
>
> -- function "/" (
> -- lx,rx: unsigned)
> -- return unsigned is
> -- -- This is a special divider for the floating point routines.
>
> Uncomment it, and your synthesis should work.
>
> What does anybody think of putting such a routine in numeric_std?
> Commented out like this one is.
>
> This is a special divider for the floating point packages. I
> shift the divisor so that there is always a "1" in the MSB.
> Thus the number of subtractor stages I need is always the
> width of the dividend, making it easier to pipeline.
>
> Ibrahim A. Abdurrazaq wrote:
> > Dear all,
> >
> > Has any one ever synthesis the divide function of the
> floating point
> > package. I am getting an error message once I tried to synthesis
> > using the Synplify tool. the error pointed at the right
> argument of
> > the "/" function "unsigned division" to be a power of two.
> the right
> > argument that I using is an unsigned variable. Any help
> please. It
> > has been commented by the FPhdl_pakg writer that it is
> synthesizable,
> > but I am not seem to getting it synthesized.
> >
> > Thank you
> > ----- Original Message -----
> > From: "Jim Lewis" <Jim@SynthWorks.com>
> > To: <vhdlsynth@vhdl.org>; <vhdl-200x-ft@eda.org>
> > Sent: Thursday, June 24, 2004 1:31 AM
> > Subject: [vhdlsynth] Re: [vhdl-200x-ft] More ideas on 1164
> and 1076.3
> >
> >
> >
> >>Ryan,
> >>If I want to mix signed and unsigned, I would rather make
> it happen by
> >>type conversion. I think it better illuminates the code
> and preserves
> >>the VHDL intent of type safety.
> >>
> >> signal A_uv : unsigned(6 downto 0) ;
> >> signal B_sv : signed(7 downto 0) ;
> >> signal Y_sv : signed(7 downto 0) ;
> >>
> >> Y_sv <= B_sv + signed('0' & A_uv) ;
> >>
> >>
> >>Back to literals,
> >>without these additional functions the bit string literals that are
> >>used with a given type are of that particular type. Consider
> >>multiplication:
> >>
> >> signal A_sv : signed(7 downto 0) ;
> >> signal Y_sv : signed(11 downto 0) ;
> >>
> >> Y_sv <= A_sv * "0110" ;
> >>
> >>Include these functions and you must add a type qualifier:
> >> Y_sv <= A_sv * signed'("0110") ;
> >>
> >>
> >>The sizing rule for integers assumes that the integer
> argument is the
> >>same size of as the array argument.
> >>Hence, for the following to be legal, Y_sv must be
> >>16 bits rather than 12:
> >>
> >> signal A_sv : signed(7 downto 0) ;
> >> signal Y_too_big_sv : signed(15 downto 0) ;
> >>
> >> Y_too_big_sv <= A_sv * 6 ;
> >>
> >>
> >>
> >>Cheers,
> >>Jim
> >>
> >>
> >>>Jim,
> >>>
> >>>My personal opinion is the opposite of yours in this case.
> >>>
> >>>
> >>>
> >>>>>Another one is that in the numeric_std package, often
> you need to
> >>>>>do operations on both signed and unsigned numbers. The way we
> >>>>>handle this now with casting is clumsy.
> >>>>>
> >>>>><proposal>
> >>>>>Add the following functions to numeric_std and numeric_bit:
> >>>>> function "+"(L : UNSIGNED; R: SIGNED) return SIGNED; function
> >>>>>"+"(L : SIGNED; R: UNSIGNED) return SIGNED;
> >>>>
> >>>>. . .
> >>>>
> >>>>
> >>>>> function "<="(L : UNSIGNED; R: SIGNED) return boolean;
> function
> >>>>>"<="(L : SIGNED; R: UNSIGNED) return boolean; </proposal>
> >>>>
> >>>>This would be bad. Currently this is done in std_logic_arith and
> >>>>causes ambiguity with literals:
> >>>>
> >>>> signal A_sv, Y_sv : signed(7 downto 0) ;
> >>>>
> >>>> Y_sv <= A_sv + "1111" ; -- is it signed or unsigned.
> >>>
> >>>
> >>>I have written my own versions of these functions, and I
> use them often.
> >>>
> >>>Is the literal signed or unsigned? Excellent question!
> Should it be
> >>
> > signed
> >
> >>>just because the other operand is signed? I don't see an
> unambiguous
> >>>"right" way to interpret the bit literal, so I think we're missing
> >>
> > useful
> >
> >>>functionality to preserve an ambiguous interpretation of
> intent. (I
> >>
> > think
> >
> >>>using a qualified expression or integer is a better indication of
> >>
> > intent.)
> >
> >>>---
> >>>Ryan Hinton
> >>>L-3 Communications / Communication Systems - West
> >>>ryan.w.hinton@L-3com.com
> >>>
> >>>
> >>
> >>
> >>--
> >>~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> >>Jim Lewis
> >>Director of Training mailto:Jim@SynthWorks.com <mailto:Jim@SynthWorks.com>
> >>SynthWorks Design Inc. http://www.SynthWorks.com <http://www.SynthWorks.com>
> >>1-503-590-4787
> >>
> >>Expert VHDL Training for Hardware Design and Verification
> >>~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> >>
> >>
> >
> >
> >
> >
>
>
> --
> David W. Bishop dbishop@vhdl.org All standard disclaimers apply.
>
>
Received on Thu Jun 24 06:02:01 2004