Icarus bug on y[1<<2]?

T

Tommy Thorn

Guest
I just distilled a non-working Verilog simulation down to

module evidence;
reg [4:0] y = 5'h10;
initial $display(y[4], y[1&lt;&lt;2]);
endmodule

which I would have expected to emit 11, but under Icarus Verilog (0.8.2)
it emits 10. Before I file another bug report into a black hole, is
there some reason for y[4] and y[1&lt;&lt;2] to be different?

Thanks
Tommy
 
"Tommy Thorn" &lt;foobar@nowhere.void&gt; a écrit dans le message de news:
450d84c4$0$96235$742ec2ed@news.sonic.net...
I just distilled a non-working Verilog simulation down to

module evidence;
reg [4:0] y = 5'h10;
initial $display(y[4], y[1&lt;&lt;2]);
endmodule

which I would have expected to emit 11, but under Icarus Verilog (0.8.2)
it emits 10. Before I file another bug report into a black hole, is there
some reason for y[4] and y[1&lt;&lt;2] to be different?

Thanks
Tommy
Click to expand...
Hi,

I agree, this should emit 11 and ModelSim does emit 11. Seems a bug in
Icarus Verilog.
Serge
 
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Tommy Thorn wrote:
I just distilled a non-working Verilog simulation down to

module evidence;
reg [4:0] y = 5'h10;
initial $display(y[4], y[1&lt;&lt;2]);
endmodule

which I would have expected to emit 11, but under Icarus Verilog (0.8.2)
it emits 10. Before I file another bug report into a black hole, is
there some reason for y[4] and y[1&lt;&lt;2] to be different?
Click to expand...
That's a bug alright. I checked, and 0.8 and the current snapshots
print 10.

P.S. I'm sorry you feel that the bug database is a "black hole".
I do try to work through the bug reports, although I admit that
recently I've been focusing on work not in the bugs database. In
any case, once a report goes into the database, it will be remembered,
and that is valuable to me. Thank you for finding and reporting
the bug.

- --
Steve Williams "The woods are lovely, dark and deep.
steve at icarus.com But I have promises to keep,
http://www.icarus.com and lines to code before I sleep,
http://www.picturel.com And lines to code before I sleep."
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.2 (GNU/Linux)
Comment: Using GnuPG with SUSE - http://enigmail.mozdev.org

iD8DBQFFDsfNrPt1Sc2b3ikRAj/5AJwNh+uB+QqhXQsfLOqo6anktfpFxACgyM/0
vcdIncCSjBnMDMs8HdgBhjQ=
=dEWm
-----END PGP SIGNATURE-----
 
Hi Stephen,

P.S. I'm sorry you feel that the bug database is a "black hole".
I do try to work through the bug reports, although I admit that
recently I've been focusing on work not in the bugs database. In
any case, once a report goes into the database, it will be remembered,
and that is valuable to me. Thank you for finding and reporting
the bug.
Click to expand...
My apologies. Icarus Verilog is a wonderful tool that I use a lot and
really appreciate.

I reported another bug, but never heard anything back. It's possible I
reported it wrongly, but it's been a long time so I don't recall how I
reported it.

I have noted a number of bugs in $monitor() where non-trivial
expressions (IIRC, stuff like (... expression ...)[10:4]) would cause
various failures, but this is the first I've seen in $display() and it
wasn't a crash so it took longer to understand.

All the best,
Tommy
 
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Tommy Thorn wrote:
Hi Stephen,

P.S. I'm sorry you feel that the bug database is a "black hole".
I do try to work through the bug reports, although I admit that
recently I've been focusing on work not in the bugs database. In
any case, once a report goes into the database, it will be remembered,
and that is valuable to me. Thank you for finding and reporting
the bug.

My apologies. Icarus Verilog is a wonderful tool that I use a lot and
really appreciate.

I reported another bug, but never heard anything back. It's possible I
reported it wrongly, but it's been a long time so I don't recall how I
reported it.

I have noted a number of bugs in $monitor() where non-trivial
expressions (IIRC, stuff like (... expression ...)[10:4]) would cause
various failures, but this is the first I've seen in $display() and it
wasn't a crash so it took longer to understand.
Click to expand...
Hm... I don't see any bug reports from you in the sourceforge-
based bug tracker. Are you referring to older bugs that were filed
in the now-dead Jitterbug based system? (rummaging...) Hmm...,
don't see anything obviously from you there.

Maybe it *is* in a black hole somewhere!? :)

In any case, the bug report of this thread definitely warrants a
bug report (please in the newer sourceforge-based database) and is
certainly something I can and should fix.

- --
Steve Williams "The woods are lovely, dark and deep.
steve at icarus.com But I have promises to keep,
http://www.icarus.com and lines to code before I sleep,
http://www.picturel.com And lines to code before I sleep."
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.2 (GNU/Linux)
Comment: Using GnuPG with SUSE - http://enigmail.mozdev.org

iD8DBQFFEBpZrPt1Sc2b3ikRAtYuAJsExgzP5ZOo89TbVQodG9riOCVsGwCeIqLI
KZvuSAxJ7QIRvN5Gkht2Log=
=vNfs
-----END PGP SIGNATURE-----
 
On Sun, 17 Sep 2006 10:24:19 -0700, Tommy Thorn &lt;foobar@nowhere.void&gt;
wrote:

I just distilled a non-working Verilog simulation down to

module evidence;
reg [4:0] y = 5'h10;
initial $display(y[4], y[1&lt;&lt;2]);
endmodule

which I would have expected to emit 11,
Click to expand...
Indeed, but it might be worth pointing out that
y[1'b1 &lt;&lt; 2 ]
should come out as equivalent to y[1'b0] because
the subscript is a self-determined expression.

In general I find that the various subtle interactions
between Verilog's expression bit width rules and
the behaviour of shift operators make my head hurt
badly enough that I try to avoid them.
--
Jonathan Bromley, Consultant

DOULOS - Developing Design Know-how
VHDL * Verilog * SystemC * e * Perl * Tcl/Tk * Project Services

Doulos Ltd., 22 Market Place, Ringwood, BH24 1AW, UK
jonathan.bromley@MYCOMPANY.com
http://www.MYCOMPANY.com

The contents of this message may contain personal views which
are not the views of Doulos Ltd., unless specifically stated.
 
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Jonathan Bromley wrote:
On Sun, 17 Sep 2006 10:24:19 -0700, Tommy Thorn &lt;foobar@nowhere.void
wrote:

I just distilled a non-working Verilog simulation down to

module evidence;
reg [4:0] y = 5'h10;
initial $display(y[4], y[1&lt;&lt;2]);
endmodule

which I would have expected to emit 11,

Indeed, but it might be worth pointing out that
y[1'b1 &lt;&lt; 2 ]
should come out as equivalent to y[1'b0] because
the subscript is a self-determined expression.
Click to expand...
And that is exactly where Icarus Verilog is getting the
anomalous result. Icarus Verilog, as an extension, treats
unsized constants as infinitely large so that you don't have
strange situations where you type large constants into your
source and have the compiler quietly overflow it. But since
it obviously can't allocate infinite space for a constant,
it uses "just enough". But that "just enough" is not quite
enough for this particular constant expression in this sort
of context.

It's amazing how these sorts of subtleties can get ya' in
round-about ways.

In general I find that the various subtle interactions
between Verilog's expression bit width rules and
the behaviour of shift operators make my head hurt
badly enough that I try to avoid them.
Click to expand...
And here I'm trying to do tricks with 'em. Sometimes more
then just my head hurts:p

- --
Steve Williams "The woods are lovely, dark and deep.
steve at icarus.com But I have promises to keep,
http://www.icarus.com and lines to code before I sleep,
http://www.picturel.com And lines to code before I sleep."
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.2 (GNU/Linux)
Comment: Using GnuPG with SUSE - http://enigmail.mozdev.org

iD8DBQFFEE/jrPt1Sc2b3ikRAsVJAJ4wNfKPW+GOzEJAycF4kFGDkbZ0NQCg3bPa
F1nGS+tegjR3WVDQonzzRcY=
=5fRM
-----END PGP SIGNATURE-----
 
"Stephen Williams" &lt;spamtrap@icarus.com&gt; wrote in message news:Zsqdne8XhbB70o3YnZ2dnUVZ_sidnZ2d@giganews.com...

[...]
And that is exactly where Icarus Verilog is getting the
anomalous result. Icarus Verilog, as an extension, treats
unsized constants as infinitely large so that you don't have
strange situations where you type large constants into your
source and have the compiler quietly overflow it. But since
it obviously can't allocate infinite space for a constant,
it uses "just enough". But that "just enough" is not quite
enough for this particular constant expression in this sort
of context.

It's amazing how these sorts of subtleties can get ya' in
round-about ways.

In general I find that the various subtle interactions
between Verilog's expression bit width rules and
the behaviour of shift operators make my head hurt
badly enough that I try to avoid them.

And here I'm trying to do tricks with 'em. Sometimes more
then just my head hurts:p
Click to expand...
I feel your pain.
Not just the size/sign rules in Verilog are non-trivial and non-intuitive, but many, many
other constructs are also ambiguously or poorly explained in the LRM.
Not to mention the loads of features that are not in the LRM, but implemented in
simulators any way.
System Verilog implementation has cost me massive headaches at times.
Please keep up the good work.

- --
Steve Williams "The woods are lovely, dark and deep.
steve at icarus.com But I have promises to keep,
http://www.icarus.com and lines to code before I sleep,
http://www.picturel.com And lines to code before I sleep."
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.2 (GNU/Linux)
Comment: Using GnuPG with SUSE - http://enigmail.mozdev.org

iD8DBQFFEE/jrPt1Sc2b3ikRAsVJAJ4wNfKPW+GOzEJAycF4kFGDkbZ0NQCg3bPa
F1nGS+tegjR3WVDQonzzRcY=
=5fRM
-----END PGP SIGNATURE-----
Click to expand...
 
Stephen Williams wrote:
And that is exactly where Icarus Verilog is getting the
anomalous result. Icarus Verilog, as an extension, treats
unsized constants as infinitely large so that you don't have
strange situations where you type large constants into your
source and have the compiler quietly overflow it. But since
it obviously can't allocate infinite space for a constant,
it uses "just enough". But that "just enough" is not quite
enough for this particular constant expression in this sort
of context.
Click to expand...
Aiee!!! I thought unsigned constants were 32-bits by default, seeing
that the Quartus synthesizer treat them as such. Having them
"infinitely" large is definitely better, but now I'm worried about the
bugs that might creep in from the synthesizer having a different point
of view (especially as I use a lot of &gt; 32 bit values).

On a related note, I hate to have to explicitly size my constants to get
rid of all the "Warning (10230): Verilog HDL assignment warning at ...:
truncated value with size 32 to match size of target (15)" that Quartus
dumps on me. It should treat constants as infinitely sized and it
shouldn't warn when only zero bits are chopped off (for unsigned values).

BTW, is there a way to get Icarus Verilog to warn/error on undefined
nets? I've been bitten by silent typo's more than once.

Cheers,
Tommy
 
"Tommy Thorn" &lt;foobar@nowhere.void&gt; wrote in message news:4510b09c$0$96213$742ec2ed@news.sonic.net...
[...]
On a related note, I hate to have to explicitly size my constants to get rid of all the "Warning (10230): Verilog HDL assignment
warning at ...: truncated value with size 32 to match size of target (15)" that Quartus dumps on me. It should treat constants as
infinitely sized and it shouldn't warn when only zero bits are chopped off (for unsigned values).
Click to expand...
Actually, Quartus should not give that warning if only 0's are chopped off.
It should only warn if you are actually loosing some data bits.
Do you have an example where that is not the case ?

Also, does Quartus have a way to suppress this warning (by message number) ?
If not, you might want to file an enhancement request for that with Altera.

BTW, is there a way to get Icarus Verilog to warn/error on undefined nets? I've been bitten by silent typo's more than once.

Cheers,
Tommy
Click to expand...
 
Rob Dekker wrote:
Actually, Quartus should not give that warning if only 0's are chopped off.
It should only warn if you are actually loosing some data bits.
Do you have an example where that is not the case ?
Click to expand...
Hmm, you're right, but it doesn't make me feel any better.

The examples I could find were mostly variants of

small_reg &lt;= small_reg + 1;

Yes, once the addition overflows, it will wrap around. Not exactly
surprising. OTOH, I do agree with a warning in these cases

small_reg &lt;= large_reg;

In essence, I'd want the synthesizer/simulator to infer the size of
constants from the context where possible (constrained of course to fit
all the bits). However, I see how this would make the already
complicated rules even worse. Sigh.


Also, does Quartus have a way to suppress this warning (by message number) ?
If not, you might want to file an enhancement request for that with Altera.
Click to expand...
There's no obvious way to do this and as I don't want to miss the latter
case I'd rather not turn it off completely.

Cheers,
Tommy
 
BTW, is there a way to get Icarus Verilog to warn/error on undefined
nets? I've been bitten by silent typo's more than once.
Click to expand...
Verilog2001 LRM has defined in built macros.
Use in built macro outside module : `default_nettype none

After this it will always give warning/error if you are using implicit
net types.

Regards
Mukesh

Tommy Thorn wrote:
Stephen Williams wrote:
And that is exactly where Icarus Verilog is getting the
anomalous result. Icarus Verilog, as an extension, treats
unsized constants as infinitely large so that you don't have
strange situations where you type large constants into your
source and have the compiler quietly overflow it. But since
it obviously can't allocate infinite space for a constant,
it uses "just enough". But that "just enough" is not quite
enough for this particular constant expression in this sort
of context.

Aiee!!! I thought unsigned constants were 32-bits by default, seeing
that the Quartus synthesizer treat them as such. Having them
"infinitely" large is definitely better, but now I'm worried about the
bugs that might creep in from the synthesizer having a different point
of view (especially as I use a lot of &gt; 32 bit values).

On a related note, I hate to have to explicitly size my constants to get
rid of all the "Warning (10230): Verilog HDL assignment warning at ...:
truncated value with size 32 to match size of target (15)" that Quartus
dumps on me. It should treat constants as infinitely sized and it
shouldn't warn when only zero bits are chopped off (for unsigned values).

BTW, is there a way to get Icarus Verilog to warn/error on undefined
nets? I've been bitten by silent typo's more than once.

Cheers,
Tommy
Click to expand...
 
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Tommy Thorn wrote:
Stephen Williams wrote:
And that is exactly where Icarus Verilog is getting the
anomalous result. Icarus Verilog, as an extension, treats
unsized constants as infinitely large so that you don't have
strange situations where you type large constants into your
source and have the compiler quietly overflow it. But since
it obviously can't allocate infinite space for a constant,
it uses "just enough". But that "just enough" is not quite
enough for this particular constant expression in this sort
of context.

Aiee!!! I thought unsigned constants were 32-bits by default, seeing
that the Quartus synthesizer treat them as such. Having them
"infinitely" large is definitely better, but now I'm worried about the
bugs that might creep in from the synthesizer having a different point
of view (especially as I use a lot of &gt; 32 bit values).
Click to expand...
The standard does not (does *not*) define how big unsized constants
are. Some compilers truncate at 32bits, some at 64, some not at all.
I chose the latter.

On a related note, I hate to have to explicitly size my constants to get
rid of all the "Warning (10230): Verilog HDL assignment warning at ...:
truncated value with size 32 to match size of target (15)" that Quartus
dumps on me. It should treat constants as infinitely sized and it
shouldn't warn when only zero bits are chopped off (for unsigned values).
Click to expand...
Some tools (including Xilinx xst) pad/truncate unsized constants to
exactly N-bits (32 usually) and give warnings like this. Icarus Verilog
will be able to tell from the context the size the constant needs to
be and will warn if there are non-pad bits lost.

BTW, is there a way to get Icarus Verilog to warn/error on undefined
nets? I've been bitten by silent typo's more than once.
Click to expand...
The -Wimplicit flag will get warnings for implicit nets.

It also supports `default_nettype none to turn off implicit nets.

- --
Steve Williams "The woods are lovely, dark and deep.
steve at icarus.com But I have promises to keep,
http://www.icarus.com and lines to code before I sleep,
http://www.picturel.com And lines to code before I sleep."
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.2 (GNU/Linux)
Comment: Using GnuPG with SUSE - http://enigmail.mozdev.org

iD8DBQFFEVzHrPt1Sc2b3ikRAvWOAJ9MWeEDZlHS+qynVf7ZinigVbGkYACggxN/
ln+M9Z6RFjrRRhxSuQLEkEs=
=7b9a
-----END PGP SIGNATURE-----
 
on 9/19/2006 10:59 PM PDT Tommy Thorn wrote:
Rob Dekker wrote:
Actually, Quartus should not give that warning if only 0's are chopped
off.
It should only warn if you are actually loosing some data bits.
Do you have an example where that is not the case ?

Hmm, you're right, but it doesn't make me feel any better.

The examples I could find were mostly variants of

small_reg &lt;= small_reg + 1;

Yes, once the addition overflows, it will wrap around. Not exactly
surprising. OTOH, I do agree with a warning in these cases

small_reg &lt;= large_reg;

In essence, I'd want the synthesizer/simulator to infer the size of
constants from the context where possible (constrained of course to fit
all the bits). However, I see how this would make the already
complicated rules even worse. Sigh.


Also, does Quartus have a way to suppress this warning (by message
number) ?
If not, you might want to file an enhancement request for that with
Altera.

There's no obvious way to do this and as I don't want to miss the latter
case I'd rather not turn it off completely.

Cheers,
Tommy
Click to expand...
In Quartus I find that with
reg [7:0]a;

a &lt;= a+1;
is the same as
a &lt;= a+32'b1;

and will result in a
Warning (10230): truncated value with size 32 to match size of target (8)
message, while
a &lt;= a+1'b1;
works fine, the 1'b1 is quietly promoted to 8'b1

In the Quartus GUI you can right click on the warning message and select
"suppress this type of warning". But then if you have syntax like

a &lt;= a+16'h0101;

you won't get a warning, and you would probably want it in this case.

I think the best thing is to always define the constant size when using
Quartus.

Ivor

--
Posted via a free Usenet account from http://www.teranews.com
 
"Stephen Williams" &lt;spamtrap@icarus.com&gt; wrote in message news:UO-dnUikOt5XwYzYnZ2dnUVZ_qqdnZ2d@giganews.com...
[...]
bugs that might creep in from the synthesizer having a different point
of view (especially as I use a lot of &gt; 32 bit values).

The standard does not (does *not*) define how big unsized constants
are.
Click to expand...
It's all a bit messy around this in the LRM, but at least there is this :

LRM 2001 4.4.1. "Rules for expression bit lengths", Table 29 :
expression:Unsized constant number bit length: same as integer.

and :
LRM 2001 3.9 : integer variables are at least 32 bits.

Some compilers truncate at 32bits, some at 64, some not at all.
I chose the latter.
Click to expand...
Truncation is only allowed to occur if the constant is already specifying data in &gt;32 bits.
For a simple unsized constant (like 1 or `b1) the constant would need to be extended first, to at least 32 bits.

I think that's where the original example y[1&lt;&lt;2] went wrong....

On a related note, I hate to have to explicitly size my constants to get
rid of all the "Warning (10230): Verilog HDL assignment warning at ...:
truncated value with size 32 to match size of target (15)" that Quartus
dumps on me. It should treat constants as infinitely sized and it
shouldn't warn when only zero bits are chopped off (for unsigned values).

Some tools (including Xilinx xst) pad/truncate unsized constants to
exactly N-bits (32 usually) and give warnings like this. Icarus Verilog
will be able to tell from the context the size the constant needs to
be and will warn if there are non-pad bits lost.

BTW, is there a way to get Icarus Verilog to warn/error on undefined
nets? I've been bitten by silent typo's more than once.

The -Wimplicit flag will get warnings for implicit nets.

It also supports `default_nettype none to turn off implicit nets.

- --
Steve Williams "The woods are lovely, dark and deep.
steve at icarus.com But I have promises to keep,
http://www.icarus.com and lines to code before I sleep,
http://www.picturel.com And lines to code before I sleep."
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.2 (GNU/Linux)
Comment: Using GnuPG with SUSE - http://enigmail.mozdev.org

iD8DBQFFEVzHrPt1Sc2b3ikRAvWOAJ9MWeEDZlHS+qynVf7ZinigVbGkYACggxN/
ln+M9Z6RFjrRRhxSuQLEkEs=
=7b9a
-----END PGP SIGNATURE-----
Click to expand...
 
"Ivor Bowden" &lt;ivorlist@peritek.com&gt; wrote in message news:4511642c$0$19667$88260bb3@free.teranews.com...
[....]
In Quartus I find that with
reg [7:0]a;

a &lt;= a+1;
is the same as
a &lt;= a+32'b1;

and will result in a
Warning (10230): truncated value with size 32 to match size of target (8)
message, while
a &lt;= a+1'b1;
works fine, the 1'b1 is quietly promoted to 8'b1
Click to expand...
Right. That is because with "a &lt;= a + 1'b1" the language DEFINES that the result must be truncated.
So there is no chance that any tool interprets this differently. So no warning is needed.

However, with "a &lt;= a + 1" the language does NOT define what happens for an overflow.
That means that there is a potential danger that you will get tool (simulator-synthesis) differences,
and that is why Quartus correctly issues a warning stating that (at least it) truncates (rather than
set the result to x or something else.

Rob
 
Stephen Williams &lt;spamtrap@icarus.com&gt; wrote:

Tommy Thorn wrote:

module evidence;
reg [4:0] y = 5'h10;
initial $display(y[4], y[1&lt;&lt;2]);
endmodule

which I would have expected to emit 11, but under Icarus Verilog (0.8.2)
it emits 10.

That's a bug alright. I checked, and 0.8 and the current snapshots
print 10.
Click to expand...
FWIW, it works if you cread a field-select of the right width:

3'd1 &lt;&lt; 3'd2

instead of 1 &lt;&lt; 2.

I agree it's a bug though.

Steve
 
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Steve Pope wrote:
Stephen Williams &lt;spamtrap@icarus.com&gt; wrote:

Tommy Thorn wrote:

module evidence;
reg [4:0] y = 5'h10;
initial $display(y[4], y[1&lt;&lt;2]);
endmodule

which I would have expected to emit 11, but under Icarus Verilog (0.8.2)
it emits 10.

That's a bug alright. I checked, and 0.8 and the current snapshots
print 10.

FWIW, it works if you cread a field-select of the right width:

3'd1 &lt;&lt; 3'd2

instead of 1 &lt;&lt; 2.

I agree it's a bug though.
Click to expand...
.... Which has been fixed in both the devel and v0.8 branches.

- --
Steve Williams "The woods are lovely, dark and deep.
steve at icarus.com But I have promises to keep,
http://www.icarus.com and lines to code before I sleep,
http://www.picturel.com And lines to code before I sleep."
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.2 (GNU/Linux)
Comment: Using GnuPG with SUSE - http://enigmail.mozdev.org

iD8DBQFFItaLrPt1Sc2b3ikRAh+cAKC5za7gr0nBn07Oyneh2X3rPO2HpgCfT8xT
og/i0/cS86KLN2Kl9kYAfZc=
=RfE0
-----END PGP SIGNATURE-----
 
You must log in or register to reply here.

Welcome to EDABoard.com

Sponsor

Back
Top