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

On Jun 12, 2:42=A0pm, Jim Lewis <j...@[EMAIL PROTECTED]
> wrote:
> > Here is an example.
>
> > CTPBitCnt is an unsigned.
>
> > What I mean...
> > =A0 CTPBitCnt <=3D 1;
>

>
> 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 <=3D 15D"1" ; =A0 -- Decimal notation
> CTPBitCnt <=3D 15X"1" ; =A0 -- Hex notation
>

The type of syntax only a mother could love...

Let's take a look at some notations

A: CTPBitCnt <=3D 1;
B: CTPBitCnt <=3D to_unsigned(1);
C: CTPBitCnt <=3D to_unsigned(1, CTPBitCnt'length);
D: set(CTPBitCnt, "<=3D", 1);
E: CTPBitCnt <=3D 15D"1"
F: CTPBitCnt <=3D CTPBitCnt'length D"1";??

'A' has the advantage of clarity of intent...it has the drawback of
requring loose type checking in the language.

'B' has the advantage of clarity of intent...and it meets the
requirements of strong type checking and is not overly wordy.
Requires the "<=3D" and the ":=3D" operators to be overriddent in the
language (in other words just like all the other operators).

'C' is valid VHDL'93 syntax.  It is too verbose and subject to error
if one inadverantly does not have the same signal name preceding the
'length attribute that is on the left hand side of the statement.

'D' is kludgy but fairly succint in getting the intent across.  Has
the drawback that one would need separately named functions to assign
signals versus variables (why the language does not allow an override
in this case is pointless...but a separate grouse).

'E' is valid VHDL'2008 that has lost the designer's intent...15B??
hmmm....

'F' might be valid VHDL'2008, not sure.  But in order to write code
that you don't have to keep re-writing when the width of 'CTPBitCnt'
changes is how you would want to express it.  Even if it were legal,
it is just a butt ugly version of what is currently available with
VHDL'93.  It's not an improvement, it's worse.  Not only do you have
to specify the width (as you do today) but now the intent of the
statement is only clear to those who understand that a 'D' or an 'X'
preceding a constant is specifying the bit width of the
constant....ummmm....OK, I think I'll stick with today's to_unsigned
notation.

Were I to rank them in order of preference it would be
1. 'B', it has everything that a strongly typed language requires and
succintly captures the designer's intent which is to assign an integer
value to an unsigned signal.

2. 'D' has all the same benefits of 'B' but is somewhat klunky and is
only a kludge to get around the unneeded language limitation that
prohibits overriding '<=3D' and ':=3D'

3. 'C'...all the benefits of 'B' but is overly wordy as has already
been pointed out.

4. 'A'...I'd be comfortable with relax strong type checking in this
particular narrow instance before I'd take the final choices

5. 'E' and 'F'.  Absolutely nothing about it is better than what we
have with today's to_unsigned() function and it is far worse in that
the designer's intent has been lost.


> 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. =A0This is
im****tan=
t
> as this is what lets them know the VHDL community wants the new
features.
>

I think I'll sit out requesting this particular enhancement from the
vendors.

Kevin Jennings