sizing

[gene]

Following is a really short snippet. The idea is to stop counting
when the variable ,'bob', saturates at 0xFF. I thought using "~0"
would automatically size to whatever size 'bob' is - but that doesn't
seem to be the case. It would be slick if this worked, because the
condition will never have to be modified regardless of the size of
bob.

Any idea why it doesn't? How about an alternate?


reg [7:0] bob;

always @(posedge clock)
begin
if (bob < ~0)
bob <= bob + 1;
end

 

[John_H]

if( ~bob != 0 ) bob <= bob + 1;

Two wrongs don't make a right but three rights make a left.


"gene" <fazool1_2000@yahoo.com> wrote in message
news:adbf00ac.0405171249.3ed68231@posting.google.com...

Following is a really short snippet. The idea is to stop counting
when the variable ,'bob', saturates at 0xFF. I thought using "~0"
would automatically size to whatever size 'bob' is - but that doesn't
seem to be the case. It would be slick if this worked, because the
condition will never have to be modified regardless of the size of
bob.

Any idea why it doesn't? How about an alternate?


reg [7:0] bob;

always @(posedge clock)
begin
if (bob < ~0)
bob <= bob + 1;
end

 

[John_H]

if( bob == -1 ) bob <= bob + 1;

 

[Jurgen Schulz]

Two issues
you need to initialize bob, it will power up 'x'
~0 is -1 (signed integer), bob (a reg) is never < -1

what you want to do wont work, you need to define the width, either
directly or indirectly, eg.

....
always @(posedge clock) begin
if (rst) begin
bob <= 0;
end
else if (bob < ~8'd0) begin
bob <= bob + 1;
end
end
....

Regards, Jurgen.


gene wrote:

Following is a really short snippet. The idea is to stop counting
when the variable ,'bob', saturates at 0xFF. I thought using "~0"
would automatically size to whatever size 'bob' is - but that doesn't
seem to be the case. It would be slick if this worked, because the
condition will never have to be modified regardless of the size of
bob.

Any idea why it doesn't? How about an alternate?


reg [7:0] bob;

always @(posedge clock)
begin
if (bob < ~0)
bob <= bob + 1;
end

 

[gene]

"Bob" would normally be initialized (I was just trying to simplify the
discussion). I agree that ~0 is returning a signed number and that it
would never work - simulation shows that. Yes, your method works -
but I was looking for a clever way to code it up so that I don't have
to know the size of bob. That way I could change the size of bob at
its definition (i.e. reg [size] bob), and the rest of the code will
simply follow along.

Is there a method to cast ~0 to an unsigned number?



Jurgen Schulz <Schulz.Jurgen.reverseme@Sun.COM> wrote in message news:<40A948C2.9020700@Sun.COM>...

Two issues
you need to initialize bob, it will power up 'x'
~0 is -1 (signed integer), bob (a reg) is never < -1

 

[ka]

On 18 May 2004 07:38:20 -0700, fazool1_2000@yahoo.com (gene) wrote:

"Bob" would normally be initialized (I was just trying to simplify the
discussion). I agree that ~0 is returning a signed number and that it
would never work - simulation shows that. Yes, your method works -
but I was looking for a clever way to code it up so that I don't have
to know the size of bob. That way I could change the size of bob at
its definition (i.e. reg [size] bob), and the rest of the code will
simply follow along.

Try
if (!&bob) bob <= bob + 1;

 

[Steven Sharp]

fazool1_2000@yahoo.com (gene) wrote in message news:<adbf00ac.0405171249.3ed68231@posting.google.com>...

Following is a really short snippet. The idea is to stop counting
when the variable ,'bob', saturates at 0xFF. I thought using "~0"
would automatically size to whatever size 'bob' is - but that doesn't
seem to be the case. It would be slick if this worked, because the
condition will never have to be modified regardless of the size of
bob.

Any idea why it doesn't? How about an alternate?

~0 will not automatically size to the size of bob, it will size to
the size of the expression. That is the size of the widest operand
in the expression, which isn't bob here. You have used the "unsized"
constant 0, which is defined as having an implementation-defined
size of at least 32 bits. In practical terms, an unsized constant
like 0 or 927 or 'b101 is 32 bits wide. So your 0 is equivalent
to 32'd0.

If bob were wider than 32 bits, then this would work. The 0
would get extended to the width of bob, and then inverted. But
since the 0 is wider than bob, bob gets zero-extended instead to
32 bits and compared to ~32'd0 or 32'hFFFFFFFF. It will always
be less, so your code fails.

To make this work, you want a 0 that will not be wider than bob
to start with. If you replace (bob < ~0) with (bob < ~1'b0),
then it should work the way you want. Since 1'b0 can never
be wider than bob, no matter what the width of bob is, this
should work for any parameterized width.

 

[Steven Sharp]

fazool1_2000@yahoo.com (gene) wrote in message news:<adbf00ac.0405180638.5e3274b1@posting.google.com>...

I agree that ~0 is returning a signed number and that it
would never work - simulation shows that.

The issue of signedness is a red herring here; it is not the cause
of your problem. If it was doing a signed comparison of bob with -1,
then bob would never be less than ~0. But the behavior you are
presumably seeing is that bob is always less than ~0 (assuming you
have a standards-compliant implementation). That should tell you
that the signedness explanation is wrong.

The expression ~0 or -1 is in fact signed, though not because the
top bit is set. It is signed because unsized unbased decimal
constants are considered signed. This has to do with the type rules,
not the value. The expressions ~32'd0 or -32'd1 are unsigned, just
as the equivalent 32'hFFFFFFFF is unsigned, because based constants
are considered unsigned. Having the top bit set doesn't make a value
signed. If the value is signed, then it makes the value negative.
If the value is unsigned, then it makes the value large.

Anyway, the signedness of 0 or ~0 doesn't matter here. The reg bob
is unsigned. The type rules say that if there is an unsigned operand
in the expression, all the other operands in the expression become
unsigned. And since the operands are unsigned the comparison will
be an unsigned comparison. That means that the ~0 will be treated
just like 32'hFFFFFFFF, which is a large value, not a negative one.
And that is why your comparison is always saying that bob is smaller.

I posted a fuller version of the correct explanation previously.