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

You present a nice list.  Thanks.

On Jun 13, 8:24 am, KJ <kkjenni...@[EMAIL PROTECTED]
> wrote:
> On Jun 12, 2:42 pm, Jim Lewis <j...@[EMAIL PROTECTED]
> wrote:
>
> > > Here is an example.
>
> > > CTPBitCnt is an unsigned.
>
> > > What I mean...
> > >   CTPBitCnt <= 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 <= 15D"1" ;   -- Decimal notation
> > CTPBitCnt <= 15X"1" ;   -- Hex notation
>
> The type of syntax only a mother could love...
>
> Let's take a look at some notations
>
> A: CTPBitCnt <= 1;
> B: CTPBitCnt <= to_unsigned(1);
> C: CTPBitCnt <= to_unsigned(1, CTPBitCnt'length);
> D: set(CTPBitCnt, "<=", 1);
> E: CTPBitCnt <= 15D"1"
> F: CTPBitCnt <= CTPBitCnt'length D"1";??
>
> 'A' has the advantage of clarity of intent...it has the drawback of
> requring loose type checking in the language.

This is the issue that I am struggling with understanding.  Strong
type checking is good in many contexts.  But I fail to understand why
it has to prevent me in this case.  In fact, I think that someone said
that this is being proposed for the next, next rev of the language.
So obviously it does not present any real issues to make it
incompatible with strong type checking.

I see it as akin to the issue that had previously existed with string
literals.  It has been quite a while, so maybe I don't recall
correctly, but I think there was a time when hex constants could not
be used with the slv type.  Since then this has been added so I don't
have to convert a bit string literal to an slv literal.  I don't know
how they did it and I don't care a lot.  I just see that it was pretty
durn obvious that it would have been desirable to sup****t this from
the start and it was not done.

Likewise it seems to me that making version A acceptable is obviously
desirable and it sounds like it is going to happen.  But why did it
take 20 years for someone to figure it out?


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

I honestly don't understand why the intent is not clear in example A.
I specified that CTPBitCnt was an unsigned signal in the declaration.
Does it make any sense to assume that I mean the literal 1 to be
anything other than an unsigned equivalent?  Maybe my software courses
in college were too long ago for me to have learned why strong typing
has to be so ***bersome.


> '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.

Yes, and errors are what we are trying to prevent.  Of course this
will be caught before it is turned in to a chip, but that whole cycle
of edit-compile-test, even if it is shortened to edit-compile is a
PITA.  Maybe I am admitting to being a poor programmer, but today I
actually spend over 15 minutes dealing with compiler complaints about
locally static stuff that is totally obvious to anyone reading the
code.  And all that was from a 2 minute code change!  I don't memorize
things very well.  I expect my tools to be obvious and intuitive...
maybe I should stick to hammers, chisels and sanders?   I may get
frustrated, but this stuff does pay a lot better.


> '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).

I assume this is a special procedure to perform the required function
by reading the middle term?  Interesting...


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

To be honest, I don't see how this one can even work.  Is this
intended to indicate a signed or an unsigned value?  How do you
indicate the other?  I don't need to say anything about the 15 part...


> '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 '<=' and ':='
>
> 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.  This is
im****tant
> > 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.

The more I read about this, the more I like Verilog... at least until
I start using it ;^)

Rick