The LRM has as an example, this piece of code and text for race conditions. It seems to me still unclear how it interacts with the event scheduling.
I tried to map the code to the scheduler =>
first delta cycle:
1. assign p = q;
2. q = 1;
both get put into the active region. The net update gets scheduled for p when a change of q takes place, this creates an event and it gets puts into the inactive region…
so then q =1, then p = 1. everyone seems happy.
for the next delta cycle:
while all the 3 statements get put into the active region( the 2 red arrows and the 1 green arrow)
maybe this is wrong but the expectation is still that because the “initial begin{ }end” is one process, it gets put together into the active region, and then it processes through these statements in order, as these are blocking statements inside the begin end. so:
execution order
- q = 0; // this statement causes a change in q and thus schedules p = 0, for the inactive region.
- $display(p); // this should display p =1, because p has not changed yet as p=0 is scheduled for later;
I have tested this and 3/4 simulators show p = 1 from the $display task.
Why is there a race condition here? The order seems known?
From the text it seems to indicate that the “update event” of q also gets put into the first active region together with display?? is it really not put into the inactive region?