FPGA Central

Here's a snippet of code that doesn't work as expected.

What I'm trying to do is have a parameter control the size of the
compare so that I can override the parameter at simulation time to
speed up the compare event;

The parameter TRANSMIT_SYNC_RANGE_PARAM is set to 7 by the simulation,
otherwise it is defaulted to 15.

The first compare of comparing txcounter[7:0] to 8'b11111111 works as
expected. The second compare of txcounter[7:0] to 16'hFFFF never
asserts. I thought that verilog would have just ignored the upper 8
bits of the compare to value but instead it must be extending the LHS
of the compare.

What are the verilog rules on vector extension?

always @ (posedge TX_DATACLK_i or posedge RESET_i)
begin
if (RESET_i) begin
txcounter <= 0;
change <= 0;
dbg_change <= 0;
end //if
else
begin
txcounter <= txcounter + 1;

if (txcounter[7:0] == 8'b11111111)
dbg_change <= 1;
else
dbg_change <= 0;

if (txcounter[TRANSMIT_SYNC_RANGE_PARAM:0] == 16'hffff)
change <= 1;
else
change <= 0;

I believe that verilog will extend the smaller vector to the size of the
larger vector. Thus, extending 8'hFF to 16 bits becomes 16'h00FF.
To make your compare work using the parameter code, use something like:

if (your_reg[YOUR_PARAM:0] == {(YOUR_PARAM+1){1'b1}}) begin ....

JB

"JT" <[email protected]> wrote in message
news:[email protected] om...
> Here's a snippet of code that doesn't work as expected.
>
> What I'm trying to do is have a parameter control the size of the
> compare so that I can override the parameter at simulation time to
> speed up the compare event;
>
> The parameter TRANSMIT_SYNC_RANGE_PARAM is set to 7 by the simulation,
> otherwise it is defaulted to 15.
>
> The first compare of comparing txcounter[7:0] to 8'b11111111 works as
> expected. The second compare of txcounter[7:0] to 16'hFFFF never
> asserts. I thought that verilog would have just ignored the upper 8
> bits of the compare to value but instead it must be extending the LHS
> of the compare.
>
> What are the verilog rules on vector extension?
>
> always @ (posedge TX_DATACLK_i or posedge RESET_i)
> begin
> if (RESET_i) begin
> txcounter <= 0;
> change <= 0;
> dbg_change <= 0;
> end //if
> else
> begin
> txcounter <= txcounter + 1;
>
> if (txcounter[7:0] == 8'b11111111)
> dbg_change <= 1;
> else
> dbg_change <= 0;
>
> if (txcounter[TRANSMIT_SYNC_RANGE_PARAM:0] == 16'hffff)
> change <= 1;
> else
> change <= 0;

[email protected] (JT) wrote in message news:<[email protected] com>...
> Here's a snippet of code that doesn't work as expected.
>
> What I'm trying to do is have a parameter control the size of the
> compare so that I can override the parameter at simulation time to
> speed up the compare event;
>
> The parameter TRANSMIT_SYNC_RANGE_PARAM is set to 7 by the simulation,
> otherwise it is defaulted to 15.
>
> The first compare of comparing txcounter[7:0] to 8'b11111111 works as
> expected. The second compare of txcounter[7:0] to 16'hFFFF never
> asserts. I thought that verilog would have just ignored the upper 8
> bits of the compare to value but instead it must be extending the LHS
> of the compare.
>
> What are the verilog rules on vector extension?
>
> always @ (posedge TX_DATACLK_i or posedge RESET_i)
> begin
> if (RESET_i) begin
> txcounter <= 0;
> change <= 0;
> dbg_change <= 0;
> end //if
> else
> begin
> txcounter <= txcounter + 1;
>
> if (txcounter[7:0] == 8'b11111111)
> dbg_change <= 1;
> else
> dbg_change <= 0;
>
> if (txcounter[TRANSMIT_SYNC_RANGE_PARAM:0] == 16'hffff)
> change <= 1;
> else
> change <= 0;

First, you don't tell us how you've declared txcounter! Is it an
integer, or is it reg [15:0] txcounter, or what? This is important
because integers are signed, and regs are unsigned, and that affects
how they are expanded.

Unsigned values are zero-extended -- the new left-hand bits are fill
with zero. Signed values are sign-extended -- the new left-hand bits
are filled with the MSB of the vector.

The comparison gets more confusing:

If _any_ operator is unsigned, then unsigned arithmetic is used.
If _all_ operators are signed, then signed arithmetic is used.

So, we still need to know how txcounter is declared before we can tell
you why your comparison failed.

-a

"Andy Peters" <[email protected]> wrote in message
news:[email protected] om...
> [email protected] (JT) wrote in message
news:<[email protected] com>...

(cut)
> > if (txcounter[TRANSMIT_SYNC_RANGE_PARAM:0] == 16'hffff)
> > change <= 1;
> > else
> > change <= 0;
>
> First, you don't tell us how you've declared txcounter! Is it an
> integer, or is it reg [15:0] txcounter, or what? This is important
> because integers are signed, and regs are unsigned, and that affects
> how they are expanded.
>
In this particular case it doesn't matter and you said it yourself below ;o)

(cut)
> The comparison gets more confusing:
>
> If _any_ operator is unsigned, then unsigned arithmetic is used.
> If _all_ operators are signed, then signed arithmetic is used.
>
Since 16'hffff is unsigned (the "_any_" one) signedness of the left operand
of comparison is not important.
Moreover in this example left operand is a partselect and partselects are
always unsigned, so not only any operand is unsigned but both.
Since the expression is unsigned partselect on the left is zero extended for
TRANSMIT_SYNC_RANGE_PARAM < 15 and this extra zeros never match 1's in the
right operand which means that comparison gives logical 0 as a result (even
if selected fragment of txcounter contains x/z bits).