![[logo]](/img/veripool_small.png)
Issue #224
Level sensitive always blocks are executed even when nothing has changed
| Status: | WillNotFix | Start date: | 03/17/2010 | |
|---|---|---|---|---|
| Priority: | Normal | Due date: | ||
| Assignee: | - | % Done: | 0% |
|
| Category: | - | |||
| Target version: | - |
Description
The Verilator manual says that code such as "always @ (x) y = x & z;" will be executed if x or z has changed, however it appears to get executed even if nothing has changed. This is a problem for system functions such as $display/$fwrite because it will be called on every eval().
A testcase is attached that passes with VCS.
History
Updated by Wilson Snyder about 3 years ago
- Status changed from New to WillNotFix
I reworded it
always @ (x) y = x & z;"This will recompute y when there is even a potential for change in x or a change in z, that is when the flops computing x or z evaluate (which is what Design Compiler will synthesize.) A compliant simulator would only calculate y if x changes. Use verilog-mode's /*AS*/ or Verilog 2001's always @* to reduce missing activity items. Avoid putting $displays in combo blocks, as they may print multiple times when not desired, even on compliant simulators as event ordering is not specified."
The (mis-)functionality itself is core to how code scheduling works and won't be changed until there's a fundamental rewrite, probably Verilator 4. That will decrease performance when it does work, though.
Updated by Byron Bradley about 3 years ago
Thanks Wilson. I wasn't expecting a change for Verilator 3 (I'd already looked at how V3Active works), but I thought I'd report the difference since it took me a while to track it down.
Manually adding the code to execute the block only on a change reduced performance by almost 10% compared to just deleting the $display, so it is probably best avoided anyway.
Also available in: Atom