Original Redmine Comment
Author Name: Wilson Snyder (@wsnyder)
Original Date: 2010-03-17T12:56:40Z

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.

Original Redmine Comment
Author Name: Byron Bradley (@bbradley)
Original Date: 2010-03-17T14:25:15Z

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.