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

Jim,

Interesting that the hard case in both options looks so similar:

> Y_sv <= B_sv + signed('0' & A_uv) ;

versus

> Y_sv <= A_sv * signed'("0110") ;

This may come down to style and preference. But the question is whether the
proposal should be codified in the standard, so style and preference may not
cut it. However, I think the proposal adds functionality that belongs and
should be accepted.

I like being able to multiply, add, etc. signed and unsigned values just
like I can integers and naturals. The operations are well-defined and
common in algorithms, at least in my limited experience. Mixed arithmetic
in no way decreases VHDL's type safety--just allows values of different
types to interact in a natural, desirable manner.

More on the style side, I prefer defining constants instead of using inline
literals:

   signal A_sv : signed(7 downto 0) ;
   signal Y_sv : signed(11 downto 0) ;
   constant B_const : signed(3 downto 0) := "1110";

   Y_sv <= A_sv * B_const ;

This solution removes the type ambiguity of the literal. Also, if the new
operators are included, this solution uses the operand types to deduce the
correct multiply operator--simultaneously hiding the unnecessary details and
doing the right thing.

However, it appears that this proposal would break existing code using
inline literals. Perhaps another set of functions could be defined that
took string operands and interpreted them as bit string literals of the
other operand type. More code to write, but I think it solves this problem.

---
Ryan Hinton
L-3 Communications / Communication Systems - West
ryan.w.hinton@L-3com.com
-----Original Message-----
From: Jim Lewis [mailto:Jim@SynthWorks.com]
Sent: Wednesday, June 23, 2004 11:31 AM
To: vhdlsynth@vhdl.org; vhdl-200x-ft@eda.org
Subject: 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
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~