mirror of
https://github.com/verilator/verilator.git
synced 2025-01-24 07:14:22 +00:00
519792d02b
Event-triggered coroutines live in two stages: 'uncommitted' and 'ready'. First they land in 'uncommitted', meaning they can't be resumed yet. Only after coroutines from the 'ready' queue are resumed, the 'uncommitted' ones are moved to the 'ready' queue, and can be resumed. This is to avoid self-triggering in situations like waiting for an event immediately after triggering it. However, there is an issue with `wait` statements. If you have a `wait(b)`, it's being translated into a loop that awaits a change in `b` as long as `b` is false. If `b` is false at first, the coroutine is put into the `uncommitted` queue. If `b` is set to true before it's committed, the coroutine won't get resumed. This patch fixes that by immediately committing event controls created from `wait` statements. That means the coroutine from the example above will get resumed from now on.
16 lines
824 B
Plaintext
16 lines
824 B
Plaintext
%Warning-WAITCONST: t/t_timing_wait1.v:48:12: Wait statement condition is constant
|
|
48 | wait(1);
|
|
| ^
|
|
... For warning description see https://verilator.org/warn/WAITCONST?v=latest
|
|
... Use "/* verilator lint_off WAITCONST */" and lint_on around source to disable this message.
|
|
%Warning-WAITCONST: t/t_timing_wait1.v:50:14: Wait statement condition is constant
|
|
50 | wait(0 < 1) $write("*-* All Finished *-*\n");
|
|
| ^
|
|
%Warning-WAITCONST: t/t_timing_wait1.v:54:17: Wait statement condition is constant
|
|
54 | initial wait(0) $stop;
|
|
| ^
|
|
%Warning-WAITCONST: t/t_timing_wait1.v:55:19: Wait statement condition is constant
|
|
55 | initial wait(1 == 0) $stop;
|
|
| ^~
|
|
%Error: Exiting due to
|