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

[Martin W. <mai...@ma...>]

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