Menu
▾
▴
iverilog-devel
|
From: Larry D. <ldo...@re...> - 2008-04-02 20:25:29
Attachments:
tern.v
|
Guys -
The attached code shows a change in behavior in recent
(as of March 20) git. It triggered a failure in my
inverse regression test. I need to know if my Verilog
assumptions are wrong, or the new Icarus behavior is wrong.
iverilog -Wall tern.v -o tern && vvp tern
Used to print out
x x
42 21
But after commit 01eb298228d0adce9d62818e21d47fb274af9060 prints
x z
42 21
- Larry
|
|
From: Cary R. <cy...@ya...> - 2008-04-02 21:29:44
|
--- Larry Doolittle <ldo...@re...> wrote:
> The attached code shows a change in behavior in recent
> (as of March 20) git. It triggered a failure in my
> inverse regression test. I need to know if my Verilog
> assumptions are wrong, or the new Icarus behavior is wrong.
This does seem to be slightly incorrect. Section 3.6 in 1364-2001 implies
that the initial value should be z, but then the driver value should
propagate. Given that this hasn't happened after #10 implies that the x is
not propagating after the initial z.
For clarity this is how I am thinking things should work.
assign tmp = 1'bx;
should set tmp to x sometime during the first time step.
assign #1 tmp = 1'bx;
should set tmp to x during the 1 time step and tmp is z before that.
Your case is clearly the first case and the x value is not propagating
correctly. This could be a far reaching problem since the basic code in
the patch you referenced is at least conceptually copied from other
places.
Cary
____________________________________________________________________________________
You rock. That's why Blockbuster's offering you one month of Blockbuster Total Access, No Cost.
http://tc.deals.yahoo.com/tc/blockbuster/text5.com
|
|
From: Larry D. <ldo...@re...> - 2008-04-02 21:38:51
|
Cary - On Wed, Apr 02, 2008 at 02:29:45PM -0700, Cary R. wrote: > --- Larry Doolittle <ldo...@re...> wrote: > > > The attached code shows a change in behavior in recent > > (as of March 20) git. It triggered a failure in my > > inverse regression test. I need to know if my Verilog > > assumptions are wrong, or the new Icarus behavior is wrong. > > This does seem to be slightly incorrect. Section 3.6 in 1364-2001 implies > that the initial value should be z, but then the driver value should > propagate. Given that this hasn't happened after #10 implies that the x is > not propagating after the initial z. Icarus, both before and after the patch in question, gives "x" for the uninitialized fdbk_err_wide (sorry about the strange names, this was stripped from a larger code base and I didn't bother to change names). The behavior change is how "x" propagates through the ternary expression. The old result (that I expect) is it comes out "x". After the commit in question, it comes out "z". I din't try to isolate this to a particular mux input; in this case all three mux inputs are derived from fdbk_err_wide. My wild guess is that the confusion comes from the control input to the mux. - Larry |
|
From: Cary R. <cy...@ya...> - 2008-04-02 21:54:27
|
--- Larry Doolittle <ldo...@re...> wrote:
> Icarus, both before and after the patch in question,
> gives "x" for the uninitialized fdbk_err_wide.
A register is different than a net! Registers have x as their default
value. Nets use z.
The problem is likely that since the z was already scheduled to appear at
T0 it did not propagate the x correctly.
Cary
____________________________________________________________________________________
You rock. That's why Blockbuster's offering you one month of Blockbuster Total Access, No Cost.
http://tc.deals.yahoo.com/tc/blockbuster/text5.com
|
|
From: Stephen W. <st...@ic...> - 2008-04-04 01:04:19
|
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Larry Doolittle wrote: > Cary - > > On Wed, Apr 02, 2008 at 02:29:45PM -0700, Cary R. wrote: >> --- Larry Doolittle <ldo...@re...> wrote: >> >>> The attached code shows a change in behavior in recent >>> (as of March 20) git. It triggered a failure in my >>> inverse regression test. I need to know if my Verilog >>> assumptions are wrong, or the new Icarus behavior is wrong. >> This does seem to be slightly incorrect. Section 3.6 in 1364-2001 implies >> that the initial value should be z, but then the driver value should >> propagate. Given that this hasn't happened after #10 implies that the x is >> not propagating after the initial z. > > Icarus, both before and after the patch in question, > gives "x" for the uninitialized fdbk_err_wide (sorry > about the strange names, this was stripped from a larger > code base and I didn't bother to change names). That's correct. variables have an initial value of x, and wires have an initial value of z. > The behavior change is how "x" propagates through the ternary > expression. The old result (that I expect) is it comes out "x". > After the commit in question, it comes out "z". > > I din't try to isolate this to a particular mux input; in this > case all three mux inputs are derived from fdbk_err_wide. My > wild guess is that the confusion comes from the control input > to the mux. Could be. The first place to look for this would be constant inputs to functors that are not being propagated. - -- 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 iD8DBQFH9X6OrPt1Sc2b3ikRAs0CAJ4gowxIqmyi6ED98Lp/XW0EgcUvMwCg5F9q c5nA7gD/MCmf6F4VjqYGrhk= =6T0T -----END PGP SIGNATURE----- |
|
From: Stephen W. <st...@ic...> - 2008-04-04 01:02:33
|
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Cary R. wrote: > --- Larry Doolittle <ldo...@re...> wrote: > >> The attached code shows a change in behavior in recent >> (as of March 20) git. It triggered a failure in my >> inverse regression test. I need to know if my Verilog >> assumptions are wrong, or the new Icarus behavior is wrong. > > This does seem to be slightly incorrect. Section 3.6 in 1364-2001 implies > that the initial value should be z, but then the driver value should > propagate. Given that this hasn't happened after #10 implies that the x is > not propagating after the initial z. > > For clarity this is how I am thinking things should work. > > assign tmp = 1'bx; > > should set tmp to x sometime during the first time step. > > assign #1 tmp = 1'bx; > > should set tmp to x during the 1 time step and tmp is z before that. > > Your case is clearly the first case and the x value is not propagating > correctly. This could be a far reaching problem since the basic code in > the patch you referenced is at least conceptually copied from other > places. I agree. This deserves a bug report. the bug is probably that the initial conditions are not being propagated through some net operators. - -- 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 iD8DBQFH9X4XrPt1Sc2b3ikRAvrtAJ9kExfubA0mHL9dDAye4CMmGRhEEwCfeZ6T K+Oplb/gcunuBPVttq+Nlac= =ffJL -----END PGP SIGNATURE----- |
Thanks for helping keep SourceForge clean.
X