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

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

That is an interesting bug report. Assuming that update events
should not be processed during the always block for sanity reasons,
then your second example with the continuous assignment (or the
original report using modules) shouldn't be an infinite loop.

I think your first example without any wires or module ports between
the mutual triggering always blocks should be an infinite loop. The
assignment to 0 should schedule an evaluation event for the other
block, which can't be unscheduled by the assignment to 1. That being
said, I tried it under ModelSim for comparison and it stops looping
after one iteration of unchanged values (i.e. once tmp0 = 1 and
tmp1 = 1, each always block runs one more time), a behavior which I
don't see an explanation for.


-Julian

________________________________
From: Martin Whitaker <ic...@ma...>
Sent: Sunday, May 17, 2020 5:33 AM
To: ive...@li... <ive...@li...>
Subject: Re: [Iverilog-devel] Verilog execution of always block as multiple events

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



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