Re: Signed, Unsigned syntax issues. Please help, I'm stumped

"Jim Lewis" <jim@[EMAIL PROTECTED]
> wrote in message 
news:fOidnaO0J_eR88zVnZ2dnUVZ_tninZ2d@[EMAIL PROTECTED]
> rickman
>> Here is an example.
>>
>> CTPBitCnt is an unsigned.
>>
>> What I mean...
>>   CTPBitCnt <= 1;
>>
>> What I have to write...
>>   CTPBitCnt <= to_unsigned(1, CTPBitCnt'length);
>>

>
> Jonathan just submitted a language feature request WRT to overloading
> assignment, however, the standard is already at the balloting point so
> it will not make the 2008 revision.
>
> What has been added is a decimal notation for bit string literals
> and a sizing indication.
>
> signal CTPBitCnt : unsigned (14 downto 0) ; -- 15 bits
> . . .
> -- Representing 1 as a 15 bit object in either hex or decimal
>
> CTPBitCnt <= 15D"1" ;   -- Decimal notation
> CTPBitCnt <= 15X"1" ;   -- Hex notation
>

The type of syntax only a mother could love.  Let's compare the approaches
A: CTPBitCnt <= 1;
B: CTPBitCnt <= to_unsigned(1, CTPBitCnt'length);
C: CTPBitCnt <= to_unsigned(1);
D: set(CTPBitCnt, "<=", 1)
E: CTPBitCnt <= CTPBitCnt'lengthD"1" ;  or CTPBitCnt <=
CTPBitCnt'lengthX"1" 
??
F: CTPBitCnt <= 8D"1" ;  or CTPBitCnt <= 8X"1"

'A' is illegal, but represents what is intended.  Violates strong type 
checking which is a 'good' thing about VHDL (in my opinion).

'B' has been valid since VHDL'93 but is overly wordy and prone to error if

you inadvertnatly take the 'length of something other than the left side
of 
the statement.  Has an issue that you would need separately names
procedures 
if the thing being assigned to is a signal or a variable.  Jim, is there 
anything on the table about being able to overload procedures when 
parameters differ by class so that a single name could be used?  If not, 
maybe I'll submit it for consideration.

'C' is illegal, but represents what is intended and conforms nicely with
the 
strong type checking of VHDL.  Requires acceptance of overloading of the 
"<=" and ":=" operators as Jonathon has proposed.

'D' is valid VHDL where 'set' is a procedure that implements the syntax of

'B'.  No chance for the possible user error mentioned above for 'B'.  The 
second parameter "<=" is not used in the procedure it is there simply to
aid 
the user of the procedure.

'E' may be valid VHDL'2008 (not sure if the bit width specification needs
to 
be a hard coded can be replaced with something that will be maintainable
if 
'CTPBitCnt' is subject to size changes ....ummm, kind of at a loss to say 
anything that I like about that syntax.
'F' is valid VHDL'2008 but again can't say what there may be to like about

it from the perspective of someone looking at the code or writing it.

If I were to rank them by personal preference the ordering would be
1.  C (clear and consise)
2.  D (kinda kludgy but does the trick)
3.  B (it's legal after all)
4. A (I'd almost rather have less strong type checking then 'E' or 'F').
5. E or F....the designer's intent has been completely lost.....to me

> BTW, these are also in Accellera standard VHDL-2006-rev3.0, so
> if your vendors were looking out for your interests, they would
> have already should implemented these.
>
> Make sure to submit these as bug/enhancement requests.  This is
im****tant
> as this is what lets them know the VHDL community wants the new
features.
>

I'll wait for one I like to see first.

Kevin Jennings