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
>
|