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

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
>>SynthWorks Design Inc. 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.