Velocity Reviews - Computer Hardware Reviews

Velocity Reviews > Newsgroups > Programming > VHDL > Signed, Unsigned syntax issues. Please help, I'm stumped

Thread Tools

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

Posts: n/a

"MikeWhy" <(E-Mail Removed)> wrote in message
news:FsK4k.13880$(E-Mail Removed)...
> "rickman" <(E-Mail Removed)> wrote in message
> news:(E-Mail Removed)...
> I can see some issues. But so far, it sounds like you only want to better
> define assignment of signed/unsigned integer values and literal constants.
> Size promotion rules will cover it without fighting that battle.
> What other use would you have for assignment overload?

I second Jonathon's post. The new fixed/floating point library is an
excellent example of why you would want this. While it's great that it can
be used with existing VHDL-93, having to put the size of the thing being
assigned to on the right hand side just so the function can know the size of
the thing being assigned to really clutters up and obscures things. The
declaration of a signal becomes quite interesting in how to format it to
even look intelligible to the reader.

Kevin Jennings

Reply With Quote
Posts: n/a

"Jim Lewis" <(E-Mail Removed)> wrote in message
news:(E-Mail Removed)...
> KJ,
>>> 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
>>> important
>>> as this is what lets them know the VHDL community wants the new
>>> features.

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

> Don't hold your breath.

I never do, I find work arounds instead...much more effective than breath

> The only way to get what you can live with (not necessarily even
> what you want) is to participate in the standards development.

I think you misinterpreted what I meant. By saying "I'll wait for one I
like to see first" I was simply stating that this particular member of the
VHDL community wasn't going to bug the vendors for *this* particular
enhancement to be implemented since I just don't see myself using it for the
reasons that have been pointed out. A new feature that I *am* interested in
using is something I would bug them for if it wasn't already implemented.

Presumably the indiviauals that thought the 'D' 'X' notation is what the
VHDL world needs are the ones that should be voicing their needs if their
tools don't support it.

> Yacking out here is like screaming at a mountain.

Not really, it's an open forum to discuss problems that others might know a
solution for. Kind of a pre-screening before submitting a bug/enhancement
request. Sometimes the gripe ends in a legitimate enhancement request,
sometimes it ends in the griper learning something they didn't know.

> P.S.
> If you are an expert VHDL coder there is no reason you should
> not be participating.

No idea whether I would qualify as an expert, but I can peruse Accelera and
see what the needs might be.

Kevin Jennings

Reply With Quote
Posts: n/a

"Jim Lewis" <(E-Mail Removed)> wrote in message
news:(E-Mail Removed) treetonline...
> Jonathan,
>> More important still, it would prevent errors that are currently
>> unavoidable: if you use := or <= to copy a fixed-point value from one
>> place to another, and the target object is of the wrong subytpe, you can
>> get its
>> fixed-point scaling silently and disastrously screwed-up.

> For fixed point math, to address the range issue, this seems
> reasonable, but it also seems open other issues. For example,
> if I use an intermediate object that is too small, overloading
> ":=" will automatically downsize it.

Another solution might be to allow a function access to attributes of the
thing being copied to. Similar to C++ and 'this', maybe a function that
could get the range of the target with something like that'range. So you
could do

function blah(a, b:ufixed) return ufixed is
variable ReturnVal: ufixed(that'range);

Or (perhaps simpler), 'that' would be the thing that can be assigned to and
returned. It would likely require the user of function blah to explicitly
define the range of the target so composing multiple function like

y <= blah(a, blah(b, c))

might not be possible....or maybe it could if the function would define the
range that *it* thought was correct, and just use that'range to error out if
the range wasn't appropriate. In any case, it would give the function some
knowledge of attributes of the target beyond just the signal/variable type.

Kevin Jennings

Reply With Quote
Posts: n/a
On Jun 11, 10:52 am, rickman <(E-Mail Removed)> wrote:
> On Jun 10, 5:59 pm, Andy <(E-Mail Removed)> wrote:
> > One more point: just try to design a fixed or floating point
> > arithmetic design with verilog!

> Is that a point? What was the point? Are you trying to say that
> users don't design arithmetic circuits in Verilog??? I am pretty sure
> that the limited work I have done in Verilog has included arithmetic.
> I must be missing your point.

My point is FIXED or FLOATING point arithmetic, not just arithmetic in
general. Verilog as a language does not pass index ranges along with
vectors into operators or functions, so verilog has no means of either
handling a user-definable data subtype that communicates the location
of binary point, or of defining operators and functions that can
operate on those subtypes automatically. Of course, verilog can do
arithmetic, but for FIXED/FLOATING, you have to manage the binary
point (and/or exponent) manually. Sometimes a little language
complexity makes the big picture a lot less complex and error prone.

Reply With Quote
Posts: n/a
On Jun 15, 1:06*pm, Jim Lewis <(E-Mail 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 'A-D' 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.


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

Reply With Quote
Posts: n/a
On Jun 15, 8:43*pm, "KJ" <(E-Mail Removed)> wrote:
> "Jim Lewis" <(E-Mail Removed)> wrote in message

A bit of a follwup on the previous post. After pondering a bit more
it seems that having an optional keyword on function declarations
might do the trick.


function foo(a, b: ufixed) return constrained ufixed;

Such a function could then query attributes of the target type to get
the info that it needs (i.e. target'left, target'right, target'range,
target'length) to do it's job. A function without the 'constrained'
keyword would be today's ordinary function call which of course would
have to determine the range of the thing that it is going to return
based on the input parameters alone.

function foo(a, b: ufixed) return ufixed;

These functions would be overloaded, the compiler would choose the
appropriate one based on whether or not the target has a defined range
or not. If it did, it would call the 'constrained' version, if not it
would call the 'classic' version.

Such a method would:
- Allow for functions to be aware of attributes of the target that are
important to the function, not just the base type of the target.
- Not require overloading "<=" or ":="
- Still allow for different functions (i.e. the 'classic' version) to
exist which determine the output range based on the input ranges of
the input parameters.

It would eliminate the possibility of getting something wrong in
things where you need to provide attribute information about the
target through a separate input parameter; the classic example being

x <= to_unsigned(Some_Constant, x'length);

Just a thought.

Kevin Jennings
Reply With Quote

Thread Tools

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are Off

Similar Threads
Thread Thread Starter Forum Replies Last Post
(int) -> (unsigned) -> (int) or (unsigned) -> (int) -> (unsigned):I'll loose something? pozz C Programming 12 03-20-2011 11:32 PM
stumped on syntax yet again! Shannon VHDL 22 05-12-2008 04:53 PM
unsigned long to unsigned char Python 1 06-01-2005 07:00 PM
unsigned int const does not match const unsigned int Timo Freiberger C++ 3 10-30-2004 07:02 PM
Assigning unsigned long to unsigned long long George Marsaglia C Programming 1 07-08-2003 05:16 PM