Re: [Iverilog-devel] Verilog execution of always block as multiple events

[Julian T. P. <jtp...@uw...>]

Thanks for the explanations everyone, very helpful.

Would I be correct in summarizing this as, the standard doesn't
strictly require an always block to run uninterrupted until it
suspends on its own, but there's a lot of inertia behind the
assumption that it does (an "unwritten rule" as Steve calls it) to
the point that it's a safe assumption to make when writing Verilog.


-Julian

________________________________
From: Julian Thomas Parkin <jtp...@uw...>
Sent: Saturday, May 16, 2020 4:55 PM
To: ive...@li... <ive...@li...>
Subject: [Iverilog-devel] Verilog execution of always block as multiple events

This isn't an issue with iverilog, but I have a question about the
execution semantics of Verilog. There isn't much information online
and a lot of it points to this mailing list
(e.g. https://sourceforge.net/p/iverilog/mailman/message/36358575/)
so I'm hoping it's alright if I ask here.

In 1364-2005, section 11.4.2 includes the following sentence (which
is also present in SystemVerilog): "Another source of nondeterminism
is that statements without time-control constructs in behavioral
blocks do not have to be executed as one event."

As an example, it presents the following:

  assign p = q;
  initial begin
      q = 1;
      #1 q = 0;
      $display(p);
  end

The simulator is allowed to process the "q = 0" assignment, then
suspend execution in favour of updating p, and then display p as 0.

Does this also apply to the typical style of always process used
to express combinatorial circuits ?

For example, if someone were to implement an and gate using a
temporary variable:

  always @(a or b) begin
      temp = a & b;
      c = temp;
  end

Say a and b both have pending update events. Could the simulator
update a, see that the always has been activated, execute
"temp = a | b;", then suspend execution to update b ? At which
point the always block is not sensitive to changes because it is
still being executed, so it ends up missing the second update even
though b is in the sensitivity list.

Is this valid behavior according to the standard ? Or does
"statements without time-control constructs" apply to the
"begin end" block as a whole and prevent it from being executed as
multiple events because it does have a time-control ? If this is
valid, do iverilog or other simulators ever behave in this manner ?


Thanks,

-Julian


_______________________________________________
Iverilog-devel mailing list
Ive...@li...
https://lists.sourceforge.net/lists/listinfo/iverilog-devel