[Iverilog-devel] semantics question, possibly a bug.

[Michael K. <kat...@ui...>]

Hi,

I was wondering if someone might help me understand what the allowable
behaviors are for a small Verilog program I wrote. The program is
available from the following link:

https://gist.github.com/922787

I have run the program using iverilog 0.9.2, as well as vcs. The
output differs between the two simulators (see link above), both of
which differ from what I expect given my understanding of the IEEE
standard (also given at the link). So, there is a bug somewhere,
either in my understanding of the standard or in one or both of
simulators that I ran, and I am trying to understand where.

Here is what I expect to happen and why:

(1) (y == 4'b1010) and (x == 4'b1010) are currently1'bx
(2) the initial and always blocks start executing
(3) the initial block stops, delayed 1 sim. cycle, and the two always
blocks stop, waiting for changes in their event expressions, which
currently evaluate to 1'bx.
(4) sim. time steps to 1, enabling the initial block
(5) y <- 4'b0000; inactive event scheduled for x <- 4'b0000
(6) (y == 4'b1010) subsequently becomes 1'b0, activating the first always block
ding!
(7) first always block stops again waiting for (y == 4'b1010) to change
(8) inactive event gets scheduled, x <- 4'b0000.
(9) (x == 4'b1010) subsequently becomes 1'b0, activating the second always block
ding! ding!
(10) second always block stops again waiting for (x == 4'b1010) to change
(11) initial block delays 1 sim cycle
(12) sim. time steps to 2, enabling the initial block.
(13) y <- 4'b1010 executes and (y == 4'b1010) evaluates to 1'b1, the
first always block activates.
ding!
(14) an inactive event is scheduled for (x <- 4'b1010)
(15) x <- 4'b1111 executes and (y == 4'b1010) evaluates to 1'b0, the
first always block may or may not activate, depending of if its
execution continued back to the @ after the previous "ding!", so a
possible third "ding!"
**(16) this is the important part, my reading of 6.1.3 of the standard
(pasted below) leads me to believe that the pending inactive event x
<- 4'b1010 is descheduled and replaced with x <- 4'b1111
(17) inactive events start
(18) x <- 4'b1111, (x == 4'b1010) continues to evaluate to 1'b0, so
the second always block continues waiting.
(19) done.

So, according to the above analysis, the output should either be:

ding!
ding! ding!
ding!

OR

ding!
ding! ding!
ding!
ding!

If that is indeed the case, note that the output of iverilog would
have an issue both with the set of display statements executed, but
with their ordering.

I apologize for the relatively long analysis above. If anyone can shed
some light on what the correct behavior of this example should be and
why, I would greatly appreciate it.

Thanks!

-Mike

appendix, from 6.1.3 of the standard:

In situations where a right-hand operand changes before a previous
change has had time to propagate to the
left-hand side, then the following steps are taken:
a) The value of the right-hand expression is evaluated.
b) If this right-hand side value differs from the value currently
scheduled to propagate to the left-hand
side, then the currently scheduled propagation event is descheduled.
c) If the new right-hand side value equals the current left-hand side
value, no event is scheduled.
d) If the new right-hand side value differs from the current left-hand
side value, a delay is calculated in
the standard way using the current value of the left-hand side, the
newly calculated value of the
right-hand side, and the delays indicated on the statement; a new
propagation event is then sched-
uled to occur delay time units in the future.