Menu
▾
▴
#772 another possible sensitivity bug?
In this example, vcs halts but iverilog does not (it spins forever).
==========
= compilation and running
(a) iverilog (no flags, v0.9.2)
(spins forever)
(b) vcs (-full64, D-2009.12)
Compiler version D-2009.12_Full64; Runtime version D-2009.12_Full64; Feb 14 13:14 2010
x = 13
==========
= explanation
The structure of the always block is: always Stmt, with Stmt = @(x[0]) Stmt', with Stmt' = begin x = x + 1; end . It seems that iverilog is "fast forwarding" the execution of Stmt, resensitising it, before the completion of Stmt', causing it to loop forever.
source file
Like the previous report cver, veriwell and V0.8 have the user expected behavior (returns x = 13). V0.9 and development both get stuck in a zero time loop.
These or something like it could be the basis for the issue Guy was having with his code. See the feature request and the closed bug report (pr2933027). The report that Guy submitted was too large to notice something this subtle and adding a non-blocking assignment fixed the code. The description did not match the code so I assumed there was some other issue in his code. We should check that code once these problems have been fixed.
Is this another place were we need the pull capabilities of the planned expression rework?
The bug described here is caused by the combination of two things:
1) iverilog handles @() by synthesising a structural netlist for the event expression.
2) In a structural netlist, vvp does not immediately propogate changes to the output of a part select, but instead pushes a task to perform the propagation to the back of the active event queue.
As a result, it is possible for the always block to get back to waiting on the event before the structural netlist representing the event expression has been completely updated.
In the supplied example, this can be worked round by replacing @(x[0]) with @(x), but clearly this is not a general solution.
It may be possible to fix this by causing the vvp %wait instruction to push the calling thread to the back of the active event queue. This has some performance implications, but I guess is preferable to the alternative of removing delayed propagation from structural netlists (this would need to be done for any operator that could occur in an event expression, not just part selects).
Hi Cary,
I tried responding to your email directly but got a mail bounce. I will monitor this and rerun my testcase when you have it resolved.
- Guy
Just for some context. I emailed Guy suggesting that the problem he was experiencing in the bug report I closed could be related to this issue. His code was fairly involved and by inserting a non-blocking delay at the right point it worked just fine. I assumed it was a code issue not an Icarus problem. It didn't help that the description and code did not match.
Guy the reason it bounced was because I forgot to tell you to reply on SourceForge or directly to my development email address. I was getting some spam from the SourceForge email pass through feature so I turned it off.
I think the only plausible way to fix this is to use the "pull" behavior of the planned expression rework, as Cary suggested. And of course there is no way that is going to be done to v0.9, so I'm changing this report to devel. I think we're not going to fix it in 0.9.