Concat on RHS of for-loop incrementer?

[Sam Lay]

What is the significance of the curlies (concat operator)
on the RHS of the loop counter incrementer in the following
code:

function [WIDTH-1:0] crulyfunc;
input [WIDTH-1:0] my_input;
integer i;
begin
curlyfunc[WIDTH-1] = my_input[WIDTH-1]
/* Here */
for (i=WIDTH; i >= 0; i={i-1})
/* ^ ^ */
curlyfinc =curlyfunc[i+1] ^my_input;
end
endfunction

Some have told me that it causes the carry out to be discarded, thus
keeping the RHS and LHS the same size. Others have siad that the
concat op can be used on the LHS of an assignment for the same purpose.
I can't get much out of the LRM on this.

What are the simulation and synthesis implications of using or not using the
curlies in such cases?

Thanks, Sam

 

[Steven Sharp]

"Sam Lay" <sam.lay@earthlink.net> wrote in message news:<JPp1b.341$1Q3.58@newsread1.news.atl.earthlink.net>...

What is the significance of the curlies (concat operator)
on the RHS of the loop counter incrementer in the following
code:
for (i=WIDTH; i >= 0; i={i-1})

Some have told me that it causes the carry out to be discarded, thus
keeping the RHS and LHS the same size. Others have siad that the
concat op can be used on the LHS of an assignment for the same purpose.
I can't get much out of the LRM on this.

In this particular example, it has no effect at all. I can only
speculate what it might be used for in other situations.

There are two major effects of putting this expression inside
a concatenation (three if you count some simulators considering
this illegal because the number 1 is unsized).

1. An expression inside a concatenation has a self-determined width.
If it were not inside the concatenation, it would have a context-
determined width, which could cause it to be evaluated at a wider
width. In this case it is irrelevant, since the self-determined
width of the expression is 32 bits (widest of i and constant 1),
and the context-determined width without the concatenation would
also be 32 bits (widest of expression and LHS of assignment). If
the LHS were wider than the RHS, then this would make a difference.
In this case, with the concatenation, the subtract would be performed
at the width of the RHS, which could lose any carry or borrow out.
Without the concatenation, the operands would be widened to the same
width as the LHS before the subtraction, effectively keeping any
carry or borrow.

A concatenation on the LHS would not have this same effect. The
width of the RHS would still be context-determined, and the width
of the LHS would still be the same as before. So the subtract
would still be done at the width of the LHS.

2. The second effect is that a concatenation is always considered
to be an unsigned value. Without the concatenation, integer i and
an unsized decimal constant would be considered signed, making the
result signed. However, the signedness associated with the result
value is irrelevant here. The same bits get assigned either way.
Nor does the signedness of the result of the concatenation affect
the signedness of the subtract, since the expression is self-
determined. And even if it did affect the signedness of the
subtract, it wouldn't matter because signedness is irrelevant to
a subtract operation (that is why we use 2's complement).

So my best guess would be an attempt to avoid getting a borrow
out, even though it is irrelevant here. Verilog rules are
designed to prevent unintentional overflow whenever possible.
Perhaps someone got burned once because they expected an
overflow, and now they overcompensate by putting concatenations
around all of their subtractions.