huh?? compare problem with vector length??

[JT]

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;

 

[JB]

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" <jthibeault@yahoo.com> wrote in message
news:ea38511d.0310220723.2fd12e59@posting.google.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;

 

[Andy Peters]

jthibeault@yahoo.com (JT) wrote in message news:<ea38511d.0310220723.2fd12e59@posting.google.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

 

[ABW]

"Andy Peters" <Bassman59a@yahoo.com> wrote in message
news:9a2c3a75.0310231239.5e64b4d6@posting.google.com...

jthibeault@yahoo.com (JT) wrote in message
news:<ea38511d.0310220723.2fd12e59@posting.google.com>...

(cut)

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