Icarus Verilog

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.

Re: [Iverilog-devel] semantics question, possibly a bug. From: Martin Whitaker <mailing-list@ma...> - 2011-04-16 12:18 Hi Mike, I think the problem with your analysis is that you assume the #0 in the continuous assignment causes any updates of x to be scheduled as inactive events. But my reading of the standard is that this special treatment of #0 only applies to procedural code. Continuous assignments are always scheduled as active events (from section 11.6.1). So, starting from time step 2, Icarus Verilog is doing y = 4'b1010 executes y update event executes -> triggers always @(y == 4'b1010) x update event executes -> triggers always @(x == 4'b1010) y = 4'b1111 executes y update event executes -> triggers always @(y == 4'b1010) x update event executes -> triggers always @(x == 4'b1010) always @(y == 4'b1010) executes -> "ding!" always @(x == 4'b1010) executes -> "ding! ding!" and VCS is doing y = 4'b1010 executes y = 4'b1111 executes y update event executes -> doesn't trigger always @(y == 4'b1010) x update event executes -> doesn't trigger always @(x == 4'b1010) both of which are allowable. There are a number of other allowable variations as well. Hope this helps, Martin On 16/04/11 03:47, Michael Katelman wrote: > 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. > > ------------------------------------------------------------------------------ > Benefiting from Server Virtualization: Beyond Initial Workload > Consolidation -- Increasing the use of server virtualization is a top > priority.Virtualization can reduce costs, simplify management, and improve > application availability and disaster protection. Learn more about boosting > the value of server virtualization. http://p.sf.net/sfu/vmware-sfdev2dev > _______________________________________________ > Iverilog-devel mailing list > Iverilog-devel@... > https://lists.sourceforge.net/lists/listinfo/iverilog-devel

Re: [Iverilog-devel] semantics question, possibly a bug. From: Cary R. <cygcary@ya...> - 2011-04-16 16:52 I believe #0 in a continuous assignment is thrown out by the compiler so like Martin said it serves no purpose. What's confusing me and I'll admit I'm not fully awake is why is each always block executed twice. It's related to the equality check since @(x) if (x == 4'b1010) ... works differently (may work as Michael expects). I would expect @(x) and @(x == 4'b1010) to have the same sensitivity list, but that appears to not be the case. If there is a bug in Icarus that is where it is. FYI GPL cver and veriwell have the same output as Icarus. Cary --- On Sat, 4/16/11, Martin Whitaker <mailing-list@...> wrote: > From: Martin Whitaker <mailing-list@...> > Subject: Re: [Iverilog-devel] semantics question, possibly a bug. > To: iverilog-devel@... > Date: Saturday, April 16, 2011, 5:18 AM > Hi Mike, > > I think the problem with your analysis is that you assume > the #0 in the continuous > assignment causes any updates of x to be scheduled as > inactive events. But my reading > of the standard is that this special treatment of #0 only > applies to procedural code. > Continuous assignments are always scheduled as active > events (from section 11.6.1). > > So, starting from time step 2, Icarus Verilog is doing > >    y = 4'b1010 executes >    y update event executes -> triggers > always @(y == 4'b1010) >    x update event executes -> triggers > always @(x == 4'b1010) >    y = 4'b1111 executes >    y update event executes -> triggers > always @(y == 4'b1010) >    x update event executes -> triggers > always @(x == 4'b1010) >    always @(y == 4'b1010) executes -> > "ding!" >    always @(x == 4'b1010) executes -> > "ding! ding!" > > and VCS is doing > >    y = 4'b1010 executes >    y = 4'b1111 executes >    y update event executes -> doesn't > trigger always @(y == 4'b1010) >    x update event executes -> doesn't > trigger always @(x == 4'b1010) > > both of which are allowable. There are a number of other > allowable variations as well. > > Hope this helps, > > Martin > > On 16/04/11 03:47, Michael Katelman wrote: > > 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. > > > > > ------------------------------------------------------------------------------ > > Benefiting from Server Virtualization: Beyond Initial > Workload > > Consolidation -- Increasing the use of server > virtualization is a top > > priority.Virtualization can reduce costs, simplify > management, and improve > > application availability and disaster protection. > Learn more about boosting > > the value of server virtualization. http://p.sf.net/sfu/vmware-sfdev2dev > > _______________________________________________ > > Iverilog-devel mailing list > > Iverilog-devel@... > > https://lists.sourceforge.net/lists/listinfo/iverilog-devel > > > ------------------------------------------------------------------------------ > Benefiting from Server Virtualization: Beyond Initial > Workload > Consolidation -- Increasing the use of server > virtualization is a top > priority.Virtualization can reduce costs, simplify > management, and improve > application availability and disaster protection. Learn > more about boosting > the value of server virtualization. http://p.sf.net/sfu/vmware-sfdev2dev > _______________________________________________ > Iverilog-devel mailing list > Iverilog-devel@... > https://lists.sourceforge.net/lists/listinfo/iverilog-devel >

Re: [Iverilog-devel] semantics question, possibly a bug. From: Martin Whitaker <mailing-list@ma...> - 2011-04-16 17:25 On 16/04/11 17:52, Cary R. wrote: > I believe #0 in a continuous assignment is thrown out by the > compiler so like Martin said it serves no purpose. > > What's confusing me and I'll admit I'm not fully awake is why > is each always block executed twice. It's related to the > equality check since @(x) if (x == 4'b1010) ... works > differently (may work as Michael expects). I would expect @(x) > and @(x == 4'b1010) to have the same sensitivity list, but > that appears to not be the case. If there is a bug in Icarus > that is where it is. FYI GPL cver and veriwell have the same > output as Icarus. > This confused me to begin with too... The answer is that @(x == 4'b1010) triggers each time "x == 4'b1010" evaluates to a different value. At time 0, x has the value 4'bxxxx, so the expression evaluates to 1'bx. At time 1, x is assigned the value 4'b0000, so the expression evaluates to 1'b0, triggering the event, and causing the always block to get executed at this time. At time 2, x is assigned the value 4'b1010, so the expression evaluates to 1'b1, triggering the event once, and is then assigned the value 4'b1111, so the expression evaluates to 1'b0, triggering the event a second time. But because there is no delay between these two assignments, the always block only gets executed once at this time, despite being triggered twice. Where there does seem to be a bug in Icarus is if you change the expression to "x === 4'b1010". Then the always block gets executed at time 0, which I don't think is correct. Martin

Re: [Iverilog-devel] semantics question, possibly a bug. From: Cary R. <cygcary@ya...> - 2011-04-16 19:23 Thanks Martin, I just looked at the standard and figured this out myself. So it looks like Icarus is doing this correctly and VCS is missing one of the events. As far as === is concerned I think this arises because the implicit CA created by the expression to drive the @ construct is being initialized to 1'bx at T0. I think the only way to resolve this would be to calculate the initial net value for the === and !== operators assuming any signal was undefined so for this case we would get zero, but if you had two variables then you would get one since both sides of the === operator are undefined. I would certainly check what other simulators do before changing anything in Icarus. Cary --- On Sat, 4/16/11, Martin Whitaker <mailing-list@...> wrote: > From: Martin Whitaker <mailing-list@...> > Subject: Re: [Iverilog-devel] semantics question, possibly a bug. > To: iverilog-devel@... > Date: Saturday, April 16, 2011, 10:25 AM > On 16/04/11 17:52, Cary R. wrote: > > I believe #0 in a continuous assignment is thrown out > by the > > compiler so like Martin said it serves no purpose. > > > > What's confusing me and I'll admit I'm not fully awake > is why > > is each always block executed twice. It's related to > the > > equality check since @(x) if (x == 4'b1010) ... works > > differently (may work as Michael expects). I would > expect @(x) > > and @(x == 4'b1010) to have the same sensitivity list, > but > > that appears to not be the case. If there is a bug in > Icarus > > that is where it is. FYI GPL cver and veriwell have > the same > > output as Icarus. > > > This confused me to begin with too... > > The answer is that @(x == 4'b1010) triggers each time "x == > 4'b1010" evaluates to a > different value. At time 0, x has the value 4'bxxxx, so the > expression evaluates to > 1'bx. At time 1, x is assigned the value 4'b0000, so the > expression evaluates to > 1'b0, triggering the event, and causing the always block to > get executed at this > time. At time 2, x is assigned the value 4'b1010, so the > expression evaluates to > 1'b1, triggering the event once, and is then assigned the > value 4'b1111, so the > expression evaluates to 1'b0, triggering the event a second > time. But because there > is no delay between these two assignments, the always block > only gets executed once > at this time, despite being triggered twice. > > Where there does seem to be a bug in Icarus is if you > change the expression to "x === > 4'b1010". Then the always block gets executed at time 0, > which I don't think is correct. > > Martin > > ------------------------------------------------------------------------------ > Benefiting from Server Virtualization: Beyond Initial > Workload > Consolidation -- Increasing the use of server > virtualization is a top > priority.Virtualization can reduce costs, simplify > management, and improve > application availability and disaster protection. Learn > more about boosting > the value of server virtualization. http://p.sf.net/sfu/vmware-sfdev2dev > _______________________________________________ > Iverilog-devel mailing list > Iverilog-devel@... > https://lists.sourceforge.net/lists/listinfo/iverilog-devel >

Re: [Iverilog-devel] semantics question, possibly a bug. From: Michael Katelman <katelman@ui...> - 2011-04-16 20:02 I really appreciate all of the comments and have definitely found them helpful. I suppose that what I am struggling with at the moment is matching the description you gave regarding the enablement of processes waiting on an event, @(..) -- forgetting that the event in the example is not very intuitive --, and what is written in the standard. For the sake of argument, let's just consider that the program was written so that assign #0 x = y; was instead just assign x = y; which, if I understood you correctly, is essentially how it's being interpreted anyway. Aside from the #0, one other way in which your analysis differed from mine, and which I am now wondering about, was in the response to update events of processes waiting on a timing control event, @(..). In particular, in your analysis of what vcs was doing, you wrote (1) y = 4'b1010 executes (2) y = 4'b1111 executes (3) y update event executes -> doesn't trigger always @(y == 4'b1010) (4) x update event executes -> doesn't trigger always @(x == 4'b1010) I am quite sure that (3) has to precede (2), but the really surprising thing to me was it might be possible for the always @(y = 4'b1010) to not be triggered. I guess that my question is this: when an update event occurs and there is a process waiting on a timing control event @(T), and that event T is satisfied by the update event, is the process immediately added to the set of active processes (pending evaluation events?). The standard is not entirely clear to me (from 11.2) "Processes are sensitive to update events. When an update event is executed, all the processes that are sensitive to that event are evaluated in an arbitrary order. The evaluation of a process is also an event, known as an evaluation event." It is not entirely clear to me what "sensitive" means precisely, or what "evaluated" means precisely. Some parts of the standard seems to interpret sensitive as meaning the timing control event condition could possibly occur, because the variable is present in the expression, and at some places it indicates that sensitive means that the particular timing control event condition did actually occur, eg a positive edge. I suppose that in the interest of not rambling on and making the email any longer I'll just leave my evaluation at that and wait for further comments. Thanks again! -Mike p.s. For what it's worth, I agree with the analysis regarding ===, it should not be triggered at T0. On Sat, Apr 16, 2011 at 7:18 AM, Martin Whitaker <mailing-list@...> wrote: > Hi Mike, > > I think the problem with your analysis is that you assume the #0 in the continuous > assignment causes any updates of x to be scheduled as inactive events. But my reading > of the standard is that this special treatment of #0 only applies to procedural code. > Continuous assignments are always scheduled as active events (from section 11.6.1). > > So, starting from time step 2, Icarus Verilog is doing > >   y = 4'b1010 executes >   y update event executes -> triggers always @(y == 4'b1010) >   x update event executes -> triggers always @(x == 4'b1010) >   y = 4'b1111 executes >   y update event executes -> triggers always @(y == 4'b1010) >   x update event executes -> triggers always @(x == 4'b1010) >   always @(y == 4'b1010) executes -> "ding!" >   always @(x == 4'b1010) executes -> "ding! ding!" > > and VCS is doing > >   y = 4'b1010 executes >   y = 4'b1111 executes >   y update event executes -> doesn't trigger always @(y == 4'b1010) >   x update event executes -> doesn't trigger always @(x == 4'b1010) > > both of which are allowable. There are a number of other allowable variations as well. > > Hope this helps, > > Martin > > On 16/04/11 03:47, Michael Katelman wrote: >> 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. >> >> ------------------------------------------------------------------------------ >> Benefiting from Server Virtualization: Beyond Initial Workload >> Consolidation -- Increasing the use of server virtualization is a top >> priority.Virtualization can reduce costs, simplify management, and improve >> application availability and disaster protection. Learn more about boosting >> the value of server virtualization. http://p.sf.net/sfu/vmware-sfdev2dev >> _______________________________________________ >> Iverilog-devel mailing list >> Iverilog-devel@... >> https://lists.sourceforge.net/lists/listinfo/iverilog-devel > > > ------------------------------------------------------------------------------ > Benefiting from Server Virtualization: Beyond Initial Workload > Consolidation -- Increasing the use of server virtualization is a top > priority.Virtualization can reduce costs, simplify management, and improve > application availability and disaster protection. Learn more about boosting > the value of server virtualization. http://p.sf.net/sfu/vmware-sfdev2dev > _______________________________________________ > Iverilog-devel mailing list > Iverilog-devel@... > https://lists.sourceforge.net/lists/listinfo/iverilog-devel >

Re: [Iverilog-devel] semantics question, possibly a bug. From: Michael Katelman <katelman@ui...> - 2011-04-16 20:13 I guess to distill the main question in the longer email I just sent, the question I have at the moment is this: when an update event occurs and and there is a process P waiting on a timing control event @(T), is it the evaluation of T that gets added as a pending event to the "active" stratum of the event queue, OR is T evaluated right away, and if the event (used in a different way, sigh) indicated by T is found to have occurred, evaluation of P post @(T) is scheduled; OR neither? -Mike On Sat, Apr 16, 2011 at 3:02 PM, Michael Katelman <katelman@...> wrote: > I really appreciate all of the comments and have definitely found them helpful. > > I suppose that what I am struggling with at the moment is matching the > description you gave regarding the enablement of processes waiting on > an event, @(..) -- forgetting that the event in the example is not > very intuitive --, and what is written in the standard. > > For the sake of argument, let's just consider that the program was > written so that > > assign #0 x = y; > > was instead just > > assign x = y; > > which, if I understood you correctly, is essentially how it's being > interpreted anyway. > > Aside from the #0, one other way in which your analysis differed from > mine, and which I am now wondering about, was in the response to > update events of processes waiting on a timing control event, @(..). > In particular, in your analysis of what vcs was doing, you wrote > > (1)   y = 4'b1010 executes > (2)  y = 4'b1111 executes > (3)  y update event executes -> doesn't trigger always @(y == 4'b1010) > (4)  x update event executes -> doesn't trigger always @(x == 4'b1010) > > I am quite sure that (3) has to precede (2), but the really surprising > thing to me was it might be possible for the always @(y = 4'b1010) to > not be triggered. > > I guess that my question is this: when an update event occurs and > there is a process waiting on a timing control event @(T), and that > event T is satisfied by the update event, is the process immediately > added to the set of active processes (pending evaluation events?). > > The standard is not entirely clear to me (from 11.2) > > "Processes are sensitive to update events. When an update event is > executed, all the processes that are > sensitive to that event are evaluated in an arbitrary order. The > evaluation of a process is also an event, known > as an evaluation event." > > It is not entirely clear to me what "sensitive" means precisely, or > what "evaluated" means precisely. Some parts of the standard seems to > interpret sensitive as meaning the timing control event condition > could possibly occur, because the variable is present in the > expression, and at some places it indicates that sensitive means that > the particular timing control event condition did actually occur, eg a > positive edge. > > I suppose that in the interest of not rambling on and making the email > any longer I'll just leave my evaluation at that and wait for further > comments. > > Thanks again! > > -Mike > p.s. For what it's worth, I agree with the analysis regarding ===, it > should not be triggered at T0. > > > > > > > > On Sat, Apr 16, 2011 at 7:18 AM, Martin Whitaker > <mailing-list@...> wrote: >> Hi Mike, >> >> I think the problem with your analysis is that you assume the #0 in the continuous >> assignment causes any updates of x to be scheduled as inactive events. But my reading >> of the standard is that this special treatment of #0 only applies to procedural code. >> Continuous assignments are always scheduled as active events (from section 11.6.1). >> >> So, starting from time step 2, Icarus Verilog is doing >> >>   y = 4'b1010 executes >>   y update event executes -> triggers always @(y == 4'b1010) >>   x update event executes -> triggers always @(x == 4'b1010) >>   y = 4'b1111 executes >>   y update event executes -> triggers always @(y == 4'b1010) >>   x update event executes -> triggers always @(x == 4'b1010) >>   always @(y == 4'b1010) executes -> "ding!" >>   always @(x == 4'b1010) executes -> "ding! ding!" >> >> and VCS is doing >> >>   y = 4'b1010 executes >>   y = 4'b1111 executes >>   y update event executes -> doesn't trigger always @(y == 4'b1010) >>   x update event executes -> doesn't trigger always @(x == 4'b1010) >> >> both of which are allowable. There are a number of other allowable variations as well. >> >> Hope this helps, >> >> Martin >> >> On 16/04/11 03:47, Michael Katelman wrote: >>> 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. >>> >>> ------------------------------------------------------------------------------ >>> Benefiting from Server Virtualization: Beyond Initial Workload >>> Consolidation -- Increasing the use of server virtualization is a top >>> priority.Virtualization can reduce costs, simplify management, and improve >>> application availability and disaster protection. Learn more about boosting >>> the value of server virtualization. http://p.sf.net/sfu/vmware-sfdev2dev >>> _______________________________________________ >>> Iverilog-devel mailing list >>> Iverilog-devel@... >>> https://lists.sourceforge.net/lists/listinfo/iverilog-devel >> >> >> ------------------------------------------------------------------------------ >> Benefiting from Server Virtualization: Beyond Initial Workload >> Consolidation -- Increasing the use of server virtualization is a top >> priority.Virtualization can reduce costs, simplify management, and improve >> application availability and disaster protection. Learn more about boosting >> the value of server virtualization. http://p.sf.net/sfu/vmware-sfdev2dev >> _______________________________________________ >> Iverilog-devel mailing list >> Iverilog-devel@... >> https://lists.sourceforge.net/lists/listinfo/iverilog-devel >> >

Re: [Iverilog-devel] semantics question, possibly a bug. From: Martin Whitaker <mailing-list@ma...> - 2011-04-16 22:09 To answer your distilled question, it's the evaluation of T that gets added to the event queue (see section 11.4 of the standard). However, an implementation is free to either execute the evaluation event immediately (which is what Icarus is doing), or to execute any other active event (which is what VCS is doing). This is a major source of non-determinism in Verilog simulators (see section 11.4.2). So the upshot of this is that if you write x = 1; x = 0; an expression sensitive to x may either be evaluated once or twice, with either option being allowed by the standard. Martin P.S. Note that for some expressions, Icarus defers evaluation. Try this example: module ding; reg x = 0; reg y = 0; always @(x) $display("ding"); always @(x || y) $display("dong"); initial begin #1; x = 1; x = 0; end endmodule On 16/04/11 21:13, Michael Katelman wrote: > I guess to distill the main question in the longer email I just sent, > the question I have at the moment is this: > > when an update event occurs and and there is a process P waiting on a > timing control event @(T), is it the evaluation of T that gets added > as a pending event to the "active" stratum of the event queue, OR is T > evaluated right away, and if the event (used in a different way, sigh) > indicated by T is found to have occurred, evaluation of P post @(T) is > scheduled; OR neither? > > -Mike > > On Sat, Apr 16, 2011 at 3:02 PM, Michael Katelman<katelman@...> wrote: >> I really appreciate all of the comments and have definitely found them helpful. >> >> I suppose that what I am struggling with at the moment is matching the >> description you gave regarding the enablement of processes waiting on >> an event, @(..) -- forgetting that the event in the example is not >> very intuitive --, and what is written in the standard. >> >> For the sake of argument, let's just consider that the program was >> written so that >> >> assign #0 x = y; >> >> was instead just >> >> assign x = y; >> >> which, if I understood you correctly, is essentially how it's being >> interpreted anyway. >> >> Aside from the #0, one other way in which your analysis differed from >> mine, and which I am now wondering about, was in the response to >> update events of processes waiting on a timing control event, @(..). >> In particular, in your analysis of what vcs was doing, you wrote >> >> (1) y = 4'b1010 executes >> (2) y = 4'b1111 executes >> (3) y update event executes -> doesn't trigger always @(y == 4'b1010) >> (4) x update event executes -> doesn't trigger always @(x == 4'b1010) >> >> I am quite sure that (3) has to precede (2), but the really surprising >> thing to me was it might be possible for the always @(y = 4'b1010) to >> not be triggered. >> >> I guess that my question is this: when an update event occurs and >> there is a process waiting on a timing control event @(T), and that >> event T is satisfied by the update event, is the process immediately >> added to the set of active processes (pending evaluation events?). >> >> The standard is not entirely clear to me (from 11.2) >> >> "Processes are sensitive to update events. When an update event is >> executed, all the processes that are >> sensitive to that event are evaluated in an arbitrary order. The >> evaluation of a process is also an event, known >> as an evaluation event." >> >> It is not entirely clear to me what "sensitive" means precisely, or >> what "evaluated" means precisely. Some parts of the standard seems to >> interpret sensitive as meaning the timing control event condition >> could possibly occur, because the variable is present in the >> expression, and at some places it indicates that sensitive means that >> the particular timing control event condition did actually occur, eg a >> positive edge. >> >> I suppose that in the interest of not rambling on and making the email >> any longer I'll just leave my evaluation at that and wait for further >> comments. >> >> Thanks again! >> >> -Mike >> p.s. For what it's worth, I agree with the analysis regarding ===, it >> should not be triggered at T0. >> >> >> >> >> >> >> >> On Sat, Apr 16, 2011 at 7:18 AM, Martin Whitaker >> <mailing-list@...> wrote: >>> Hi Mike, >>> >>> I think the problem with your analysis is that you assume the #0 in the continuous >>> assignment causes any updates of x to be scheduled as inactive events. But my reading >>> of the standard is that this special treatment of #0 only applies to procedural code. >>> Continuous assignments are always scheduled as active events (from section 11.6.1). >>> >>> So, starting from time step 2, Icarus Verilog is doing >>> >>> y = 4'b1010 executes >>> y update event executes -> triggers always @(y == 4'b1010) >>> x update event executes -> triggers always @(x == 4'b1010) >>> y = 4'b1111 executes >>> y update event executes -> triggers always @(y == 4'b1010) >>> x update event executes -> triggers always @(x == 4'b1010) >>> always @(y == 4'b1010) executes -> "ding!" >>> always @(x == 4'b1010) executes -> "ding! ding!" >>> >>> and VCS is doing >>> >>> y = 4'b1010 executes >>> y = 4'b1111 executes >>> y update event executes -> doesn't trigger always @(y == 4'b1010) >>> x update event executes -> doesn't trigger always @(x == 4'b1010) >>> >>> both of which are allowable. There are a number of other allowable variations as well. >>> >>> Hope this helps, >>> >>> Martin >>> >>> On 16/04/11 03:47, Michael Katelman wrote: >>>> 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. >>>> >>>> ------------------------------------------------------------------------------ >>>> Benefiting from Server Virtualization: Beyond Initial Workload >>>> Consolidation -- Increasing the use of server virtualization is a top >>>> priority.Virtualization can reduce costs, simplify management, and improve >>>> application availability and disaster protection. Learn more about boosting >>>> the value of server virtualization. http://p.sf.net/sfu/vmware-sfdev2dev >>>> _______________________________________________ >>>> Iverilog-devel mailing list >>>> Iverilog-devel@... >>>> https://lists.sourceforge.net/lists/listinfo/iverilog-devel >>> >>> >>> ------------------------------------------------------------------------------ >>> Benefiting from Server Virtualization: Beyond Initial Workload >>> Consolidation -- Increasing the use of server virtualization is a top >>> priority.Virtualization can reduce costs, simplify management, and improve >>> application availability and disaster protection. Learn more about boosting >>> the value of server virtualization. http://p.sf.net/sfu/vmware-sfdev2dev >>> _______________________________________________ >>> Iverilog-devel mailing list >>> Iverilog-devel@... >>> https://lists.sourceforge.net/lists/listinfo/iverilog-devel >>> >> > > ------------------------------------------------------------------------------ > Benefiting from Server Virtualization: Beyond Initial Workload > Consolidation -- Increasing the use of server virtualization is a top > priority.Virtualization can reduce costs, simplify management, and improve > application availability and disaster protection. Learn more about boosting > the value of server virtualization. http://p.sf.net/sfu/vmware-sfdev2dev > _______________________________________________ > Iverilog-devel mailing list > Iverilog-devel@... > https://lists.sourceforge.net/lists/listinfo/iverilog-devel

Re: [Iverilog-devel] semantics question, possibly a bug. From: Michael Katelman <katelman@ui...> - 2011-04-16 22:31 Thanks, Martin. Do you know of anywhere in the standard the defines "sensitive" precisely (I searched the document and didn't find anything, so probably not)? As you indicated, the pseudocode in 11.4 says that you must "add evaluation events for sensitive processes to event queue" during an evaluation event, but the implications of that depend on what "sensitive" means. If I understand your meaning of sensitive, any event control expression T is sensitive to any change in any variable occurring in T. The standard seems to support this meaning on some occasions, eg 11.6.1 says "A continuous assignment statement corresponds to a process, sensitive to the source elements in the expression" but at other points the standard seems to indicate that sensitive means something more complicated, eg if T = posedge clk, that an actual positive edge occurred on clk, not just that clk changed. For example, 9.7.2 says: "A change of value in any operand of the expression without a change in the result of the expression shall not be detected as an event." So, perhaps it's a difference between @(T) and continuous assigns? -Mike On Sat, Apr 16, 2011 at 5:09 PM, Martin Whitaker <mailing-list@...> wrote: > To answer your distilled question, it's the evaluation of T that gets added to the > event queue (see section 11.4 of the standard). However, an implementation is free to > either execute the evaluation event immediately (which is what Icarus is doing), or > to execute any other active event (which is what VCS is doing). This is a major > source of non-determinism in Verilog simulators (see section 11.4.2). > > So the upshot of this is that if you write > >   x = 1; >   x = 0; > > an expression sensitive to x may either be evaluated once or twice, with either > option being allowed by the standard. > > Martin > > P.S. Note that for some expressions, Icarus defers evaluation. Try this example: > > module ding; > > reg x = 0; > reg y = 0; > > always @(x) $display("ding"); > > always @(x || y) $display("dong"); > > initial begin >   #1; >   x = 1; >   x = 0; > end > > endmodule > > On 16/04/11 21:13, Michael Katelman wrote: >> I guess to distill the main question in the longer email I just sent, >> the question I have at the moment is this: >> >> when an update event occurs and and there is a process P waiting on a >> timing control event @(T), is it the evaluation of T that gets added >> as a pending event to the "active" stratum of the event queue, OR is T >> evaluated right away, and if the event (used in a different way, sigh) >> indicated by T is found to have occurred, evaluation of P post @(T) is >> scheduled; OR neither? >> >> -Mike >> >> On Sat, Apr 16, 2011 at 3:02 PM, Michael Katelman<katelman@...>  wrote: >>> I really appreciate all of the comments and have definitely found them helpful. >>> >>> I suppose that what I am struggling with at the moment is matching the >>> description you gave regarding the enablement of processes waiting on >>> an event, @(..) -- forgetting that the event in the example is not >>> very intuitive --, and what is written in the standard. >>> >>> For the sake of argument, let's just consider that the program was >>> written so that >>> >>> assign #0 x = y; >>> >>> was instead just >>> >>> assign x = y; >>> >>> which, if I understood you correctly, is essentially how it's being >>> interpreted anyway. >>> >>> Aside from the #0, one other way in which your analysis differed from >>> mine, and which I am now wondering about, was in the response to >>> update events of processes waiting on a timing control event, @(..). >>> In particular, in your analysis of what vcs was doing, you wrote >>> >>> (1)   y = 4'b1010 executes >>> (2)  y = 4'b1111 executes >>> (3)  y update event executes ->  doesn't trigger always @(y == 4'b1010) >>> (4)  x update event executes ->  doesn't trigger always @(x == 4'b1010) >>> >>> I am quite sure that (3) has to precede (2), but the really surprising >>> thing to me was it might be possible for the always @(y = 4'b1010) to >>> not be triggered. >>> >>> I guess that my question is this: when an update event occurs and >>> there is a process waiting on a timing control event @(T), and that >>> event T is satisfied by the update event, is the process immediately >>> added to the set of active processes (pending evaluation events?). >>> >>> The standard is not entirely clear to me (from 11.2) >>> >>> "Processes are sensitive to update events. When an update event is >>> executed, all the processes that are >>> sensitive to that event are evaluated in an arbitrary order. The >>> evaluation of a process is also an event, known >>> as an evaluation event." >>> >>> It is not entirely clear to me what "sensitive" means precisely, or >>> what "evaluated" means precisely. Some parts of the standard seems to >>> interpret sensitive as meaning the timing control event condition >>> could possibly occur, because the variable is present in the >>> expression, and at some places it indicates that sensitive means that >>> the particular timing control event condition did actually occur, eg a >>> positive edge. >>> >>> I suppose that in the interest of not rambling on and making the email >>> any longer I'll just leave my evaluation at that and wait for further >>> comments. >>> >>> Thanks again! >>> >>> -Mike >>> p.s. For what it's worth, I agree with the analysis regarding ===, it >>> should not be triggered at T0. >>> >>> >>> >>> >>> >>> >>> >>> On Sat, Apr 16, 2011 at 7:18 AM, Martin Whitaker >>> <mailing-list@...>  wrote: >>>> Hi Mike, >>>> >>>> I think the problem with your analysis is that you assume the #0 in the continuous >>>> assignment causes any updates of x to be scheduled as inactive events. But my reading >>>> of the standard is that this special treatment of #0 only applies to procedural code. >>>> Continuous assignments are always scheduled as active events (from section 11.6.1). >>>> >>>> So, starting from time step 2, Icarus Verilog is doing >>>> >>>>    y = 4'b1010 executes >>>>    y update event executes ->  triggers always @(y == 4'b1010) >>>>    x update event executes ->  triggers always @(x == 4'b1010) >>>>    y = 4'b1111 executes >>>>    y update event executes ->  triggers always @(y == 4'b1010) >>>>    x update event executes ->  triggers always @(x == 4'b1010) >>>>    always @(y == 4'b1010) executes ->  "ding!" >>>>    always @(x == 4'b1010) executes ->  "ding! ding!" >>>> >>>> and VCS is doing >>>> >>>>    y = 4'b1010 executes >>>>    y = 4'b1111 executes >>>>    y update event executes ->  doesn't trigger always @(y == 4'b1010) >>>>    x update event executes ->  doesn't trigger always @(x == 4'b1010) >>>> >>>> both of which are allowable. There are a number of other allowable variations as well. >>>> >>>> Hope this helps, >>>> >>>> Martin >>>> >>>> On 16/04/11 03:47, Michael Katelman wrote: >>>>> 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. >>>>> >>>>> ------------------------------------------------------------------------------ >>>>> Benefiting from Server Virtualization: Beyond Initial Workload >>>>> Consolidation -- Increasing the use of server virtualization is a top >>>>> priority.Virtualization can reduce costs, simplify management, and improve >>>>> application availability and disaster protection. Learn more about boosting >>>>> the value of server virtualization. http://p.sf.net/sfu/vmware-sfdev2dev >>>>> _______________________________________________ >>>>> Iverilog-devel mailing list >>>>> Iverilog-devel@... >>>>> https://lists.sourceforge.net/lists/listinfo/iverilog-devel >>>> >>>> >>>> ------------------------------------------------------------------------------ >>>> Benefiting from Server Virtualization: Beyond Initial Workload >>>> Consolidation -- Increasing the use of server virtualization is a top >>>> priority.Virtualization can reduce costs, simplify management, and improve >>>> application availability and disaster protection. Learn more about boosting >>>> the value of server virtualization. http://p.sf.net/sfu/vmware-sfdev2dev >>>> _______________________________________________ >>>> Iverilog-devel mailing list >>>> Iverilog-devel@... >>>> https://lists.sourceforge.net/lists/listinfo/iverilog-devel >>>> >>> >> >> ------------------------------------------------------------------------------ >> Benefiting from Server Virtualization: Beyond Initial Workload >> Consolidation -- Increasing the use of server virtualization is a top >> priority.Virtualization can reduce costs, simplify management, and improve >> application availability and disaster protection. Learn more about boosting >> the value of server virtualization. http://p.sf.net/sfu/vmware-sfdev2dev >> _______________________________________________ >> Iverilog-devel mailing list >> Iverilog-devel@... >> https://lists.sourceforge.net/lists/listinfo/iverilog-devel > > > ------------------------------------------------------------------------------ > Benefiting from Server Virtualization: Beyond Initial Workload > Consolidation -- Increasing the use of server virtualization is a top > priority.Virtualization can reduce costs, simplify management, and improve > application availability and disaster protection. Learn more about boosting > the value of server virtualization. http://p.sf.net/sfu/vmware-sfdev2dev > _______________________________________________ > Iverilog-devel mailing list > Iverilog-devel@... > https://lists.sourceforge.net/lists/listinfo/iverilog-devel >

Re: [Iverilog-devel] semantics question, possibly a bug. From: Michael Katelman <katelman@ui...> - 2011-04-16 22:36 Perhaps my 9.7.2 quote isn't relevant, as they're using event in a different way there. Still, it would be nice if sensitive was defined precisely somewhere in the standard. -Mike On Sat, Apr 16, 2011 at 5:31 PM, Michael Katelman <katelman@...> wrote: > Thanks, Martin. > > Do you know of anywhere in the standard the defines "sensitive" > precisely (I searched the document and didn't find anything, so > probably not)? As you indicated, the pseudocode in 11.4 says that you > must "add evaluation events for sensitive processes to event queue" > during an evaluation event, but the implications of that depend on > what "sensitive" means. > > If I understand your meaning of sensitive, any event control > expression T is sensitive to any change in any variable occurring in > T. The standard seems to support this meaning on some occasions, eg > 11.6.1 says > > "A continuous assignment statement corresponds to a process, sensitive > to the source elements in  the expression" > > but at other points the standard seems to indicate that sensitive > means something more complicated, eg if T = posedge clk, that an > actual positive edge occurred on clk, not just that clk changed. For > example, 9.7.2 says: > > "A change of value in any operand of the expression without a change > in the result of the expression shall not be detected as an event." > > So, perhaps it's a difference between @(T) and continuous assigns? > > -Mike > > On Sat, Apr 16, 2011 at 5:09 PM, Martin Whitaker > <mailing-list@...> wrote: >> To answer your distilled question, it's the evaluation of T that gets added to the >> event queue (see section 11.4 of the standard). However, an implementation is free to >> either execute the evaluation event immediately (which is what Icarus is doing), or >> to execute any other active event (which is what VCS is doing). This is a major >> source of non-determinism in Verilog simulators (see section 11.4.2). >> >> So the upshot of this is that if you write >> >>   x = 1; >>   x = 0; >> >> an expression sensitive to x may either be evaluated once or twice, with either >> option being allowed by the standard. >> >> Martin >> >> P.S. Note that for some expressions, Icarus defers evaluation. Try this example: >> >> module ding; >> >> reg x = 0; >> reg y = 0; >> >> always @(x) $display("ding"); >> >> always @(x || y) $display("dong"); >> >> initial begin >>   #1; >>   x = 1; >>   x = 0; >> end >> >> endmodule >> >> On 16/04/11 21:13, Michael Katelman wrote: >>> I guess to distill the main question in the longer email I just sent, >>> the question I have at the moment is this: >>> >>> when an update event occurs and and there is a process P waiting on a >>> timing control event @(T), is it the evaluation of T that gets added >>> as a pending event to the "active" stratum of the event queue, OR is T >>> evaluated right away, and if the event (used in a different way, sigh) >>> indicated by T is found to have occurred, evaluation of P post @(T) is >>> scheduled; OR neither? >>> >>> -Mike >>> >>> On Sat, Apr 16, 2011 at 3:02 PM, Michael Katelman<katelman@...>  wrote: >>>> I really appreciate all of the comments and have definitely found them helpful. >>>> >>>> I suppose that what I am struggling with at the moment is matching the >>>> description you gave regarding the enablement of processes waiting on >>>> an event, @(..) -- forgetting that the event in the example is not >>>> very intuitive --, and what is written in the standard. >>>> >>>> For the sake of argument, let's just consider that the program was >>>> written so that >>>> >>>> assign #0 x = y; >>>> >>>> was instead just >>>> >>>> assign x = y; >>>> >>>> which, if I understood you correctly, is essentially how it's being >>>> interpreted anyway. >>>> >>>> Aside from the #0, one other way in which your analysis differed from >>>> mine, and which I am now wondering about, was in the response to >>>> update events of processes waiting on a timing control event, @(..). >>>> In particular, in your analysis of what vcs was doing, you wrote >>>> >>>> (1)   y = 4'b1010 executes >>>> (2)  y = 4'b1111 executes >>>> (3)  y update event executes ->  doesn't trigger always @(y == 4'b1010) >>>> (4)  x update event executes ->  doesn't trigger always @(x == 4'b1010) >>>> >>>> I am quite sure that (3) has to precede (2), but the really surprising >>>> thing to me was it might be possible for the always @(y = 4'b1010) to >>>> not be triggered. >>>> >>>> I guess that my question is this: when an update event occurs and >>>> there is a process waiting on a timing control event @(T), and that >>>> event T is satisfied by the update event, is the process immediately >>>> added to the set of active processes (pending evaluation events?). >>>> >>>> The standard is not entirely clear to me (from 11.2) >>>> >>>> "Processes are sensitive to update events. When an update event is >>>> executed, all the processes that are >>>> sensitive to that event are evaluated in an arbitrary order. The >>>> evaluation of a process is also an event, known >>>> as an evaluation event." >>>> >>>> It is not entirely clear to me what "sensitive" means precisely, or >>>> what "evaluated" means precisely. Some parts of the standard seems to >>>> interpret sensitive as meaning the timing control event condition >>>> could possibly occur, because the variable is present in the >>>> expression, and at some places it indicates that sensitive means that >>>> the particular timing control event condition did actually occur, eg a >>>> positive edge. >>>> >>>> I suppose that in the interest of not rambling on and making the email >>>> any longer I'll just leave my evaluation at that and wait for further >>>> comments. >>>> >>>> Thanks again! >>>> >>>> -Mike >>>> p.s. For what it's worth, I agree with the analysis regarding ===, it >>>> should not be triggered at T0. >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> On Sat, Apr 16, 2011 at 7:18 AM, Martin Whitaker >>>> <mailing-list@...>  wrote: >>>>> Hi Mike, >>>>> >>>>> I think the problem with your analysis is that you assume the #0 in the continuous >>>>> assignment causes any updates of x to be scheduled as inactive events. But my reading >>>>> of the standard is that this special treatment of #0 only applies to procedural code. >>>>> Continuous assignments are always scheduled as active events (from section 11.6.1). >>>>> >>>>> So, starting from time step 2, Icarus Verilog is doing >>>>> >>>>>    y = 4'b1010 executes >>>>>    y update event executes ->  triggers always @(y == 4'b1010) >>>>>    x update event executes ->  triggers always @(x == 4'b1010) >>>>>    y = 4'b1111 executes >>>>>    y update event executes ->  triggers always @(y == 4'b1010) >>>>>    x update event executes ->  triggers always @(x == 4'b1010) >>>>>    always @(y == 4'b1010) executes ->  "ding!" >>>>>    always @(x == 4'b1010) executes ->  "ding! ding!" >>>>> >>>>> and VCS is doing >>>>> >>>>>    y = 4'b1010 executes >>>>>    y = 4'b1111 executes >>>>>    y update event executes ->  doesn't trigger always @(y == 4'b1010) >>>>>    x update event executes ->  doesn't trigger always @(x == 4'b1010) >>>>> >>>>> both of which are allowable. There are a number of other allowable variations as well. >>>>> >>>>> Hope this helps, >>>>> >>>>> Martin >>>>> >>>>> On 16/04/11 03:47, Michael Katelman wrote: >>>>>> 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. >>>>>> >>>>>> ------------------------------------------------------------------------------ >>>>>> Benefiting from Server Virtualization: Beyond Initial Workload >>>>>> Consolidation -- Increasing the use of server virtualization is a top >>>>>> priority.Virtualization can reduce costs, simplify management, and improve >>>>>> application availability and disaster protection. Learn more about boosting >>>>>> the value of server virtualization. http://p.sf.net/sfu/vmware-sfdev2dev >>>>>> _______________________________________________ >>>>>> Iverilog-devel mailing list >>>>>> Iverilog-devel@... >>>>>> https://lists.sourceforge.net/lists/listinfo/iverilog-devel >>>>> >>>>> >>>>> ------------------------------------------------------------------------------ >>>>> Benefiting from Server Virtualization: Beyond Initial Workload >>>>> Consolidation -- Increasing the use of server virtualization is a top >>>>> priority.Virtualization can reduce costs, simplify management, and improve >>>>> application availability and disaster protection. Learn more about boosting >>>>> the value of server virtualization. http://p.sf.net/sfu/vmware-sfdev2dev >>>>> _______________________________________________ >>>>> Iverilog-devel mailing list >>>>> Iverilog-devel@... >>>>> https://lists.sourceforge.net/lists/listinfo/iverilog-devel >>>>> >>>> >>> >>> ------------------------------------------------------------------------------ >>> Benefiting from Server Virtualization: Beyond Initial Workload >>> Consolidation -- Increasing the use of server virtualization is a top >>> priority.Virtualization can reduce costs, simplify management, and improve >>> application availability and disaster protection. Learn more about boosting >>> the value of server virtualization. http://p.sf.net/sfu/vmware-sfdev2dev >>> _______________________________________________ >>> Iverilog-devel mailing list >>> Iverilog-devel@... >>> https://lists.sourceforge.net/lists/listinfo/iverilog-devel >> >> >> ------------------------------------------------------------------------------ >> Benefiting from Server Virtualization: Beyond Initial Workload >> Consolidation -- Increasing the use of server virtualization is a top >> priority.Virtualization can reduce costs, simplify management, and improve >> application availability and disaster protection. Learn more about boosting >> the value of server virtualization. http://p.sf.net/sfu/vmware-sfdev2dev >> _______________________________________________ >> Iverilog-devel mailing list >> Iverilog-devel@... >> https://lists.sourceforge.net/lists/listinfo/iverilog-devel >> >

Re: [Iverilog-devel] semantics question, possibly a bug. From: Martin Whitaker <mailing-list@ma...> - 2011-04-16 23:43 Unfortunately the standard isn't entirely consistent in its use of language. So we have to infer what sensitive means in the context of event control based on its use elsewhere. You do need to distinguish between the evaluation event for an event expression and the triggered event resulting from that evaluation. So for the event control @(posedge clk) the event expression "posedge clk" is sensitive to and (notionally) evaluated after every update of "clk", but only triggers another event (execution of the statement following the evenet control) when the evaluation results in a positive edge. Martin On 16/04/11 23:36, Michael Katelman wrote: > Perhaps my 9.7.2 quote isn't relevant, as they're using event in a > different way there. Still, it would be nice if sensitive was defined > precisely somewhere in the standard. > > -Mike > > On Sat, Apr 16, 2011 at 5:31 PM, Michael Katelman<katelman@...> wrote: >> Thanks, Martin. >> >> Do you know of anywhere in the standard the defines "sensitive" >> precisely (I searched the document and didn't find anything, so >> probably not)? As you indicated, the pseudocode in 11.4 says that you >> must "add evaluation events for sensitive processes to event queue" >> during an evaluation event, but the implications of that depend on >> what "sensitive" means. >> >> If I understand your meaning of sensitive, any event control >> expression T is sensitive to any change in any variable occurring in >> T. The standard seems to support this meaning on some occasions, eg >> 11.6.1 says >> >> "A continuous assignment statement corresponds to a process, sensitive >> to the source elements in the expression" >> >> but at other points the standard seems to indicate that sensitive >> means something more complicated, eg if T = posedge clk, that an >> actual positive edge occurred on clk, not just that clk changed. For >> example, 9.7.2 says: >> >> "A change of value in any operand of the expression without a change >> in the result of the expression shall not be detected as an event." >> >> So, perhaps it's a difference between @(T) and continuous assigns? >> >> -Mike >> >> On Sat, Apr 16, 2011 at 5:09 PM, Martin Whitaker >> <mailing-list@...> wrote: >>> To answer your distilled question, it's the evaluation of T that gets added to the >>> event queue (see section 11.4 of the standard). However, an implementation is free to >>> either execute the evaluation event immediately (which is what Icarus is doing), or >>> to execute any other active event (which is what VCS is doing). This is a major >>> source of non-determinism in Verilog simulators (see section 11.4.2). >>> >>> So the upshot of this is that if you write >>> >>> x = 1; >>> x = 0; >>> >>> an expression sensitive to x may either be evaluated once or twice, with either >>> option being allowed by the standard. >>> >>> Martin >>> >>> P.S. Note that for some expressions, Icarus defers evaluation. Try this example: >>> >>> module ding; >>> >>> reg x = 0; >>> reg y = 0; >>> >>> always @(x) $display("ding"); >>> >>> always @(x || y) $display("dong"); >>> >>> initial begin >>> #1; >>> x = 1; >>> x = 0; >>> end >>> >>> endmodule >>> >>> On 16/04/11 21:13, Michael Katelman wrote: >>>> I guess to distill the main question in the longer email I just sent, >>>> the question I have at the moment is this: >>>> >>>> when an update event occurs and and there is a process P waiting on a >>>> timing control event @(T), is it the evaluation of T that gets added >>>> as a pending event to the "active" stratum of the event queue, OR is T >>>> evaluated right away, and if the event (used in a different way, sigh) >>>> indicated by T is found to have occurred, evaluation of P post @(T) is >>>> scheduled; OR neither? >>>> >>>> -Mike >>>> >>>> On Sat, Apr 16, 2011 at 3:02 PM, Michael Katelman<katelman@...> wrote: >>>>> I really appreciate all of the comments and have definitely found them helpful. >>>>> >>>>> I suppose that what I am struggling with at the moment is matching the >>>>> description you gave regarding the enablement of processes waiting on >>>>> an event, @(..) -- forgetting that the event in the example is not >>>>> very intuitive --, and what is written in the standard. >>>>> >>>>> For the sake of argument, let's just consider that the program was >>>>> written so that >>>>> >>>>> assign #0 x = y; >>>>> >>>>> was instead just >>>>> >>>>> assign x = y; >>>>> >>>>> which, if I understood you correctly, is essentially how it's being >>>>> interpreted anyway. >>>>> >>>>> Aside from the #0, one other way in which your analysis differed from >>>>> mine, and which I am now wondering about, was in the response to >>>>> update events of processes waiting on a timing control event, @(..). >>>>> In particular, in your analysis of what vcs was doing, you wrote >>>>> >>>>> (1) y = 4'b1010 executes >>>>> (2) y = 4'b1111 executes >>>>> (3) y update event executes -> doesn't trigger always @(y == 4'b1010) >>>>> (4) x update event executes -> doesn't trigger always @(x == 4'b1010) >>>>> >>>>> I am quite sure that (3) has to precede (2), but the really surprising >>>>> thing to me was it might be possible for the always @(y = 4'b1010) to >>>>> not be triggered. >>>>> >>>>> I guess that my question is this: when an update event occurs and >>>>> there is a process waiting on a timing control event @(T), and that >>>>> event T is satisfied by the update event, is the process immediately >>>>> added to the set of active processes (pending evaluation events?). >>>>> >>>>> The standard is not entirely clear to me (from 11.2) >>>>> >>>>> "Processes are sensitive to update events. When an update event is >>>>> executed, all the processes that are >>>>> sensitive to that event are evaluated in an arbitrary order. The >>>>> evaluation of a process is also an event, known >>>>> as an evaluation event." >>>>> >>>>> It is not entirely clear to me what "sensitive" means precisely, or >>>>> what "evaluated" means precisely. Some parts of the standard seems to >>>>> interpret sensitive as meaning the timing control event condition >>>>> could possibly occur, because the variable is present in the >>>>> expression, and at some places it indicates that sensitive means that >>>>> the particular timing control event condition did actually occur, eg a >>>>> positive edge. >>>>> >>>>> I suppose that in the interest of not rambling on and making the email >>>>> any longer I'll just leave my evaluation at that and wait for further >>>>> comments. >>>>> >>>>> Thanks again! >>>>> >>>>> -Mike >>>>> p.s. For what it's worth, I agree with the analysis regarding ===, it >>>>> should not be triggered at T0. >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> On Sat, Apr 16, 2011 at 7:18 AM, Martin Whitaker >>>>> <mailing-list@...> wrote: >>>>>> Hi Mike, >>>>>> >>>>>> I think the problem with your analysis is that you assume the #0 in the continuous >>>>>> assignment causes any updates of x to be scheduled as inactive events. But my reading >>>>>> of the standard is that this special treatment of #0 only applies to procedural code. >>>>>> Continuous assignments are always scheduled as active events (from section 11.6.1). >>>>>> >>>>>> So, starting from time step 2, Icarus Verilog is doing >>>>>> >>>>>> y = 4'b1010 executes >>>>>> y update event executes -> triggers always @(y == 4'b1010) >>>>>> x update event executes -> triggers always @(x == 4'b1010) >>>>>> y = 4'b1111 executes >>>>>> y update event executes -> triggers always @(y == 4'b1010) >>>>>> x update event executes -> triggers always @(x == 4'b1010) >>>>>> always @(y == 4'b1010) executes -> "ding!" >>>>>> always @(x == 4'b1010) executes -> "ding! ding!" >>>>>> >>>>>> and VCS is doing >>>>>> >>>>>> y = 4'b1010 executes >>>>>> y = 4'b1111 executes >>>>>> y update event executes -> doesn't trigger always @(y == 4'b1010) >>>>>> x update event executes -> doesn't trigger always @(x == 4'b1010) >>>>>> >>>>>> both of which are allowable. There are a number of other allowable variations as well. >>>>>> >>>>>> Hope this helps, >>>>>> >>>>>> Martin >>>>>> >>>>>> On 16/04/11 03:47, Michael Katelman wrote: >>>>>>> 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. >>>>>>> >>>>>>> ------------------------------------------------------------------------------ >>>>>>> Benefiting from Server Virtualization: Beyond Initial Workload >>>>>>> Consolidation -- Increasing the use of server virtualization is a top >>>>>>> priority.Virtualization can reduce costs, simplify management, and improve >>>>>>> application availability and disaster protection. Learn more about boosting >>>>>>> the value of server virtualization. http://p.sf.net/sfu/vmware-sfdev2dev >>>>>>> _______________________________________________ >>>>>>> Iverilog-devel mailing list >>>>>>> Iverilog-devel@... >>>>>>> https://lists.sourceforge.net/lists/listinfo/iverilog-devel >>>>>> >>>>>> >>>>>> ------------------------------------------------------------------------------ >>>>>> Benefiting from Server Virtualization: Beyond Initial Workload >>>>>> Consolidation -- Increasing the use of server virtualization is a top >>>>>> priority.Virtualization can reduce costs, simplify management, and improve >>>>>> application availability and disaster protection. Learn more about boosting >>>>>> the value of server virtualization. http://p.sf.net/sfu/vmware-sfdev2dev >>>>>> _______________________________________________ >>>>>> Iverilog-devel mailing list >>>>>> Iverilog-devel@... >>>>>> https://lists.sourceforge.net/lists/listinfo/iverilog-devel >>>>>> >>>>> >>>> >>>> ------------------------------------------------------------------------------ >>>> Benefiting from Server Virtualization: Beyond Initial Workload >>>> Consolidation -- Increasing the use of server virtualization is a top >>>> priority.Virtualization can reduce costs, simplify management, and improve >>>> application availability and disaster protection. Learn more about boosting >>>> the value of server virtualization. http://p.sf.net/sfu/vmware-sfdev2dev >>>> _______________________________________________ >>>> Iverilog-devel mailing list >>>> Iverilog-devel@... >>>> https://lists.sourceforge.net/lists/listinfo/iverilog-devel >>> >>> >>> ------------------------------------------------------------------------------ >>> Benefiting from Server Virtualization: Beyond Initial Workload >>> Consolidation -- Increasing the use of server virtualization is a top >>> priority.Virtualization can reduce costs, simplify management, and improve >>> application availability and disaster protection. Learn more about boosting >>> the value of server virtualization. http://p.sf.net/sfu/vmware-sfdev2dev >>> _______________________________________________ >>> Iverilog-devel mailing list >>> Iverilog-devel@... >>> https://lists.sourceforge.net/lists/listinfo/iverilog-devel >>> >> > > ------------------------------------------------------------------------------ > Benefiting from Server Virtualization: Beyond Initial Workload > Consolidation -- Increasing the use of server virtualization is a top > priority.Virtualization can reduce costs, simplify management, and improve > application availability and disaster protection. Learn more about boosting > the value of server virtualization. http://p.sf.net/sfu/vmware-sfdev2dev > _______________________________________________ > Iverilog-devel mailing list > Iverilog-devel@... > https://lists.sourceforge.net/lists/listinfo/iverilog-devel

Re: [Iverilog-devel] semantics question, possibly a bug. From: Michael Katelman <katelman@ui...> - 2011-04-17 00:43 I certainly buy your interpretation as a valid one, though it would be nice if the standard was clearer about what sensitivity means, or what #0 means on an assign, etc. I do have one last question, just to make sure that I am clear on my understanding of your explanation of event controls @(T) are handled. If we take an example similar to what you had above, say always @(x) $display("ding!"); initial begin #1; x = 0; x = 1; end when x changes to 0 at time t1 an evaluation event for the always, which is waiting at @(x) is scheduled. Let's say that the next thing that happens is that x changes to 1, which I suppose should queue up a second evaluation event or simply replace the first one or whatever. So, now there is either a single evaluation event scheduled for the always, or two, thought that probably doesn't make much sense. Anyway, the next thing that happens is we execute the evaluation event. My question is this: in doing so, evaluating @(x), we have to consider a previous value of x as well as the current value of x, which is clearly 1, but what is the correct previous value of x? I could see two reasonable possibilities, either at time t0 when the @(x) underwent an earlier evaluation event, we store the value of x for the next evaluation event, in which case the previous value would be 1'bx, Otherwise, one could reasonably suppose that the previous value for x was its value before the last update event to x, which would be 1'b0. Thanks again, I am finding this extremely helpful and interesting. -Mike On Sat, Apr 16, 2011 at 6:43 PM, Martin Whitaker <mailing-list@...> wrote: > Unfortunately the standard isn't entirely consistent in its use of language. So we > have to infer what sensitive means in the context of event control based on its use > elsewhere. > > You do need to distinguish between the evaluation event for an event expression and > the triggered event resulting from that evaluation. So for the event control > >   @(posedge clk) > > the event expression "posedge clk" is sensitive to and (notionally) evaluated after > every update of "clk", but only triggers another event (execution of the statement > following the evenet control) when the evaluation results in a positive edge. > > Martin > > On 16/04/11 23:36, Michael Katelman wrote: >> Perhaps my 9.7.2 quote isn't relevant, as they're using event in a >> different way there. Still, it would be nice if sensitive was defined >> precisely somewhere in the standard. >> >> -Mike >> >> On Sat, Apr 16, 2011 at 5:31 PM, Michael Katelman<katelman@...>  wrote: >>> Thanks, Martin. >>> >>> Do you know of anywhere in the standard the defines "sensitive" >>> precisely (I searched the document and didn't find anything, so >>> probably not)? As you indicated, the pseudocode in 11.4 says that you >>> must "add evaluation events for sensitive processes to event queue" >>> during an evaluation event, but the implications of that depend on >>> what "sensitive" means. >>> >>> If I understand your meaning of sensitive, any event control >>> expression T is sensitive to any change in any variable occurring in >>> T. The standard seems to support this meaning on some occasions, eg >>> 11.6.1 says >>> >>> "A continuous assignment statement corresponds to a process, sensitive >>> to the source elements in  the expression" >>> >>> but at other points the standard seems to indicate that sensitive >>> means something more complicated, eg if T = posedge clk, that an >>> actual positive edge occurred on clk, not just that clk changed. For >>> example, 9.7.2 says: >>> >>> "A change of value in any operand of the expression without a change >>> in the result of the expression shall not be detected as an event." >>> >>> So, perhaps it's a difference between @(T) and continuous assigns? >>> >>> -Mike >>> >>> On Sat, Apr 16, 2011 at 5:09 PM, Martin Whitaker >>> <mailing-list@...>  wrote: >>>> To answer your distilled question, it's the evaluation of T that gets added to the >>>> event queue (see section 11.4 of the standard). However, an implementation is free to >>>> either execute the evaluation event immediately (which is what Icarus is doing), or >>>> to execute any other active event (which is what VCS is doing). This is a major >>>> source of non-determinism in Verilog simulators (see section 11.4.2). >>>> >>>> So the upshot of this is that if you write >>>> >>>>    x = 1; >>>>    x = 0; >>>> >>>> an expression sensitive to x may either be evaluated once or twice, with either >>>> option being allowed by the standard. >>>> >>>> Martin >>>> >>>> P.S. Note that for some expressions, Icarus defers evaluation. Try this example: >>>> >>>> module ding; >>>> >>>> reg x = 0; >>>> reg y = 0; >>>> >>>> always @(x) $display("ding"); >>>> >>>> always @(x || y) $display("dong"); >>>> >>>> initial begin >>>>    #1; >>>>    x = 1; >>>>    x = 0; >>>> end >>>> >>>> endmodule >>>> >>>> On 16/04/11 21:13, Michael Katelman wrote: >>>>> I guess to distill the main question in the longer email I just sent, >>>>> the question I have at the moment is this: >>>>> >>>>> when an update event occurs and and there is a process P waiting on a >>>>> timing control event @(T), is it the evaluation of T that gets added >>>>> as a pending event to the "active" stratum of the event queue, OR is T >>>>> evaluated right away, and if the event (used in a different way, sigh) >>>>> indicated by T is found to have occurred, evaluation of P post @(T) is >>>>> scheduled; OR neither? >>>>> >>>>> -Mike >>>>> >>>>> On Sat, Apr 16, 2011 at 3:02 PM, Michael Katelman<katelman@...>    wrote: >>>>>> I really appreciate all of the comments and have definitely found them helpful. >>>>>> >>>>>> I suppose that what I am struggling with at the moment is matching the >>>>>> description you gave regarding the enablement of processes waiting on >>>>>> an event, @(..) -- forgetting that the event in the example is not >>>>>> very intuitive --, and what is written in the standard. >>>>>> >>>>>> For the sake of argument, let's just consider that the program was >>>>>> written so that >>>>>> >>>>>> assign #0 x = y; >>>>>> >>>>>> was instead just >>>>>> >>>>>> assign x = y; >>>>>> >>>>>> which, if I understood you correctly, is essentially how it's being >>>>>> interpreted anyway. >>>>>> >>>>>> Aside from the #0, one other way in which your analysis differed from >>>>>> mine, and which I am now wondering about, was in the response to >>>>>> update events of processes waiting on a timing control event, @(..). >>>>>> In particular, in your analysis of what vcs was doing, you wrote >>>>>> >>>>>> (1)   y = 4'b1010 executes >>>>>> (2)  y = 4'b1111 executes >>>>>> (3)  y update event executes ->    doesn't trigger always @(y == 4'b1010) >>>>>> (4)  x update event executes ->    doesn't trigger always @(x == 4'b1010) >>>>>> >>>>>> I am quite sure that (3) has to precede (2), but the really surprising >>>>>> thing to me was it might be possible for the always @(y = 4'b1010) to >>>>>> not be triggered. >>>>>> >>>>>> I guess that my question is this: when an update event occurs and >>>>>> there is a process waiting on a timing control event @(T), and that >>>>>> event T is satisfied by the update event, is the process immediately >>>>>> added to the set of active processes (pending evaluation events?). >>>>>> >>>>>> The standard is not entirely clear to me (from 11.2) >>>>>> >>>>>> "Processes are sensitive to update events. When an update event is >>>>>> executed, all the processes that are >>>>>> sensitive to that event are evaluated in an arbitrary order. The >>>>>> evaluation of a process is also an event, known >>>>>> as an evaluation event." >>>>>> >>>>>> It is not entirely clear to me what "sensitive" means precisely, or >>>>>> what "evaluated" means precisely. Some parts of the standard seems to >>>>>> interpret sensitive as meaning the timing control event condition >>>>>> could possibly occur, because the variable is present in the >>>>>> expression, and at some places it indicates that sensitive means that >>>>>> the particular timing control event condition did actually occur, eg a >>>>>> positive edge. >>>>>> >>>>>> I suppose that in the interest of not rambling on and making the email >>>>>> any longer I'll just leave my evaluation at that and wait for further >>>>>> comments. >>>>>> >>>>>> Thanks again! >>>>>> >>>>>> -Mike >>>>>> p.s. For what it's worth, I agree with the analysis regarding ===, it >>>>>> should not be triggered at T0. >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> On Sat, Apr 16, 2011 at 7:18 AM, Martin Whitaker >>>>>> <mailing-list@...>    wrote: >>>>>>> Hi Mike, >>>>>>> >>>>>>> I think the problem with your analysis is that you assume the #0 in the continuous >>>>>>> assignment causes any updates of x to be scheduled as inactive events. But my reading >>>>>>> of the standard is that this special treatment of #0 only applies to procedural code. >>>>>>> Continuous assignments are always scheduled as active events (from section 11.6.1). >>>>>>> >>>>>>> So, starting from time step 2, Icarus Verilog is doing >>>>>>> >>>>>>>     y = 4'b1010 executes >>>>>>>     y update event executes ->    triggers always @(y == 4'b1010) >>>>>>>     x update event executes ->    triggers always @(x == 4'b1010) >>>>>>>     y = 4'b1111 executes >>>>>>>     y update event executes ->    triggers always @(y == 4'b1010) >>>>>>>     x update event executes ->    triggers always @(x == 4'b1010) >>>>>>>     always @(y == 4'b1010) executes ->    "ding!" >>>>>>>     always @(x == 4'b1010) executes ->    "ding! ding!" >>>>>>> >>>>>>> and VCS is doing >>>>>>> >>>>>>>     y = 4'b1010 executes >>>>>>>     y = 4'b1111 executes >>>>>>>     y update event executes ->    doesn't trigger always @(y == 4'b1010) >>>>>>>     x update event executes ->    doesn't trigger always @(x == 4'b1010) >>>>>>> >>>>>>> both of which are allowable. There are a number of other allowable variations as well. >>>>>>> >>>>>>> Hope this helps, >>>>>>> >>>>>>> Martin >>>>>>> >>>>>>> On 16/04/11 03:47, Michael Katelman wrote: >>>>>>>> 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. >>>>>>>> >>>>>>>> ------------------------------------------------------------------------------ >>>>>>>> Benefiting from Server Virtualization: Beyond Initial Workload >>>>>>>> Consolidation -- Increasing the use of server virtualization is a top >>>>>>>> priority.Virtualization can reduce costs, simplify management, and improve >>>>>>>> application availability and disaster protection. Learn more about boosting >>>>>>>> the value of server virtualization. http://p.sf.net/sfu/vmware-sfdev2dev >>>>>>>> _______________________________________________ >>>>>>>> Iverilog-devel mailing list >>>>>>>> Iverilog-devel@... >>>>>>>> https://lists.sourceforge.net/lists/listinfo/iverilog-devel >>>>>>> >>>>>>> >>>>>>> ------------------------------------------------------------------------------ >>>>>>> Benefiting from Server Virtualization: Beyond Initial Workload >>>>>>> Consolidation -- Increasing the use of server virtualization is a top >>>>>>> priority.Virtualization can reduce costs, simplify management, and improve >>>>>>> application availability and disaster protection. Learn more about boosting >>>>>>> the value of server virtualization. http://p.sf.net/sfu/vmware-sfdev2dev >>>>>>> _______________________________________________ >>>>>>> Iverilog-devel mailing list >>>>>>> Iverilog-devel@... >>>>>>> https://lists.sourceforge.net/lists/listinfo/iverilog-devel >>>>>>> >>>>>> >>>>> >>>>> ------------------------------------------------------------------------------ >>>>> Benefiting from Server Virtualization: Beyond Initial Workload >>>>> Consolidation -- Increasing the use of server virtualization is a top >>>>> priority.Virtualization can reduce costs, simplify management, and improve >>>>> application availability and disaster protection. Learn more about boosting >>>>> the value of server virtualization. http://p.sf.net/sfu/vmware-sfdev2dev >>>>> _______________________________________________ >>>>> Iverilog-devel mailing list >>>>> Iverilog-devel@... >>>>> https://lists.sourceforge.net/lists/listinfo/iverilog-devel >>>> >>>> >>>> ------------------------------------------------------------------------------ >>>> Benefiting from Server Virtualization: Beyond Initial Workload >>>> Consolidation -- Increasing the use of server virtualization is a top >>>> priority.Virtualization can reduce costs, simplify management, and improve >>>> application availability and disaster protection. Learn more about boosting >>>> the value of server virtualization. http://p.sf.net/sfu/vmware-sfdev2dev >>>> _______________________________________________ >>>> Iverilog-devel mailing list >>>> Iverilog-devel@... >>>> https://lists.sourceforge.net/lists/listinfo/iverilog-devel >>>> >>> >> >> ------------------------------------------------------------------------------ >> Benefiting from Server Virtualization: Beyond Initial Workload >> Consolidation -- Increasing the use of server virtualization is a top >> priority.Virtualization can reduce costs, simplify management, and improve >> application availability and disaster protection. Learn more about boosting >> the value of server virtualization. http://p.sf.net/sfu/vmware-sfdev2dev >> _______________________________________________ >> Iverilog-devel mailing list >> Iverilog-devel@... >> https://lists.sourceforge.net/lists/listinfo/iverilog-devel > > > ------------------------------------------------------------------------------ > Benefiting from Server Virtualization: Beyond Initial Workload > Consolidation -- Increasing the use of server virtualization is a top > priority.Virtualization can reduce costs, simplify management, and improve > application availability and disaster protection. Learn more about boosting > the value of server virtualization. http://p.sf.net/sfu/vmware-sfdev2dev > _______________________________________________ > Iverilog-devel mailing list > Iverilog-devel@... > https://lists.sourceforge.net/lists/listinfo/iverilog-devel >

Re: [Iverilog-devel] semantics question, possibly a bug. From: Martin Whitaker <mailing-list@ma...> - 2011-04-17 10:11 Answers inline. On 17/04/11 01:43, Michael Katelman wrote: > I certainly buy your interpretation as a valid one, though it would be > nice if the standard was clearer about what sensitivity means, or what > #0 means on an assign, etc. > It would be nice if the standard was clearer in many places! If you look back through the iverilog-devel archive, you'll find lots of discussions like this. > I do have one last question, just to make sure that I am clear on my > understanding of your explanation of event controls @(T) are handled. > > If we take an example similar to what you had above, say > > always @(x) $display("ding!"); > > initial > begin > #1; > x = 0; > x = 1; > end > > when x changes to 0 at time t1 an evaluation event for the always, > which is waiting at @(x) is scheduled. Let's say that the next thing > that happens is that x changes to 1, which I suppose should queue up a > second evaluation event or simply replace the first one or whatever. > So, now there is either a single evaluation event scheduled for the > always, or two, thought that probably doesn't make much sense. > In theory there are two evaluation events scheduled, but in practice a simulator can probably merge them into one event without affecting the observable behaviour (I can't think of any way the user could detect that two evaluations have occurred, but there may be something I've not considered). > Anyway, the next thing that happens is we execute the evaluation > event. My question is this: in doing so, evaluating @(x), we have to > consider a previous value of x as well as the current value of x, > which is clearly 1, but what is the correct previous value of x? I > could see two reasonable possibilities, either at time t0 when the > @(x) underwent an earlier evaluation event, we store the value of x > for the next evaluation event, in which case the previous value would > be 1'bx, Otherwise, one could reasonably suppose that the previous > value for x was its value before the last update event to x, which > would be 1'b0. > In the example above, I don't think there is an evaluation event at time 0 - variable initialisation should occur before any statements are executed. The simplified example may be too simplified in this case, and masking an important point. It is the previous result of evaluating the event expression that has to be stored, not the previous value of x. So before the first assignment to x, the event expression has never been evaluated and the previous result is unknown. Although the standard doesn't state this explicitly, this should probably be treated as a previous result of 1'bx (tests on various simulators agree with this). > Thanks again, I am finding this extremely helpful and interesting. > > -Mike > You're welcome, Martin

Re: [Iverilog-devel] semantics question, possibly a bug. From: Michael Katelman <katelman@ui...> - 2011-04-17 15:12 On Sun, Apr 17, 2011 at 5:11 AM, Martin Whitaker <mailing-list@...> wrote: > Answers inline. > > On 17/04/11 01:43, Michael Katelman wrote: >> I certainly buy your interpretation as a valid one, though it would be >> nice if the standard was clearer about what sensitivity means, or what >> #0 means on an assign, etc. >> > It would be nice if the standard was clearer in many places! If you look back through > the iverilog-devel archive, you'll find lots of discussions like this. > >> I do have one last question, just to make sure that I am clear on my >> understanding of your explanation of event controls @(T) are handled. >> >> If we take an example similar to what you had above, say >> >> always @(x) $display("ding!"); >> >> initial >> begin >>    #1; >>    x = 0; >>    x = 1; >> end >> >> when x changes to 0 at time t1 an evaluation event for the always, >> which is waiting at @(x) is scheduled. Let's say that the next thing >> that happens is that x changes to 1, which I suppose should queue up a >> second evaluation event or simply replace the first one or whatever. >> So, now there is either a single evaluation event scheduled for the >> always, or two, thought that probably doesn't make much sense. >> > In theory there are two evaluation events scheduled, but in practice a simulator can > probably merge them into one event without affecting the observable behaviour (I > can't think of any way the user could detect that two evaluations have occurred, but > there may be something I've not considered). > >> Anyway, the next thing that happens is we execute the evaluation >> event. My question is this: in doing so, evaluating @(x), we have to >> consider a previous value of x as well as the current value of x, >> which is clearly 1, but what is the correct previous value of x? I >> could see two reasonable possibilities, either at time t0 when the >> @(x) underwent an earlier evaluation event, we store the value of x >> for the next evaluation event, in which case the previous value would >> be 1'bx, Otherwise, one could reasonably suppose that the previous >> value for x was its value before the last update event to x, which >> would be 1'b0. >> > In the example above, I don't think there is an evaluation event at time 0 - variable > initialisation should occur before any statements are executed. Oops, fair enough. > > The simplified example may be too simplified in this case, and masking an important > point. It is the previous result of evaluating the event expression that has to be > stored, not the previous value of x. So before the first assignment to x, the event > expression has never been evaluated and the previous result is unknown. Although the > standard doesn't state this explicitly, this should probably be treated as a previous > result of 1'bx (tests on various simulators agree with this). Great, that's exactly what I was wanting to find out. Thanks again! -Mike > >> Thanks again, I am finding this extremely helpful and interesting. >> >> -Mike >> > You're welcome, > > Martin > > > ------------------------------------------------------------------------------ > Benefiting from Server Virtualization: Beyond Initial Workload > Consolidation -- Increasing the use of server virtualization is a top > priority.Virtualization can reduce costs, simplify management, and improve > application availability and disaster protection. Learn more about boosting > the value of server virtualization. http://p.sf.net/sfu/vmware-sfdev2dev > _______________________________________________ > Iverilog-devel mailing list > Iverilog-devel@... > https://lists.sourceforge.net/lists/listinfo/iverilog-devel >

2 messages have been excluded from this view by a project administrator.