On Jun 15, 1:06*pm, Jim Lewis <(EMail Removed)> wrote:
> KJ,
>
> > 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 couple of comments.
> Which of these solutions work for numbers larger than 31 bits?
>
Trick question...VHDL does not guarantee support for 'numbers' beyond
+/ 2**31 (or thereabouts) so 'AD' do not, they do work over the
entire range of input parameters, which is what you would expect of a
good function. Once the Accelera folks see fit to either extend
integers (or create a new type) that can even represent 'numbers' with
more than 32 bits of precision these functions would still work.
'E' and 'F' do not work with 'numbers' they work with a pair of
literal text strings.
> Beyond strong typing, I think the array sizing rules are important.
Definitely.
>
> For details about signed, unsigned, meaning of D or X, see my presentations.
> Since I have been posting links to the presentation, I am surprised you
> waited to reflect such negative comments.
>
Negative only in the sense that it is not a solution for converting an
integer into a (un)signed except in the most constrained case (i.e.
the constant will never have a need to change or be parameterized, and
the target length will never a need to change or be parameterized).
Once you get outside of that boundary that notation won't help. Over
the years, I've found that 'never' happens quite frequently.
The fact that it is useful in those constrained cases may make it
useful to some and I won't begrudge them the opportunity to make the
language easier for them if they think it helps even if I see no
benefit to me. For me, I rarely come across an unsigned that I won't
want to have a parameterized length.
> If you want to have an opinion in what is done, I suggest that you
> PARTICIPATE in the standards.
>
I've submitted a couple enhancements that I believe were accepted.
KJ
