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

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

Steve's point that the time control requires the whole begin...end block 
to be executed as a single event does mean that I am wrong and the vvp 
behaviour is broken. See the second example I gave in

https://github.com/steveicarus/iverilog/issues/321#issuecomment-626305761

If update events are not allowed to be executed during the begin...end 
blocks, the wires should never reflect the glitches.

On 16/05/2020 23:52, Stephen Williams wrote:
> This is an interesting problem, and has come down to an unwritten rule
> that sequential statements are executed without interruption until
> they voluntarily yield by a time or event statement. Many people who
> tried to implement multi-threaded Verilog simulators have discovered
> this assumption the hard way. The problem is that Verilog has no
> thread synchronization primitives other than the time and event
> controls, and so every Verilog programmer has used these controls
> exactly that way. So:
> 
> always @(a or b) begin
>    temp = a & b;
>    c = temp;
> end
> 
> Once this thread is started, it will run, uninterrupted, until it gets
> to the @(...) statement, which yields the CPU.
> 
> Now, it can also be pointed out that this is technically only a single
> statement. The @(a or b)... is a single statement that has as a
> sub-statement a begin..end block. People don't usually think about it
> that way, but it is technically true.
> 
> On Sat, May 16, 2020 at 3:05 PM Julian Thomas Parkin
> <jtp...@uw...> wrote:
>>
>> 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
> 
> 
>