#495 Unexpected race of modpath "if" expressions (pr1877743.v)

[Stephen Williams]

While working on unrelated changes, pr1877743.v in the ivtest suite stopped working. This highlighted a bug in the handling of conditional specify paths.

The ivl core generates "net" code for conditional expressions, where inputs to the condition run through evaluation of the condition along with all other continuous assignment expressions. Unfortunately, this creates a race condition with the delay processing. If the output to the module arrives and is tested for delays before the specify path condition finishes evaluating, the wrong specify path may be chosen. This is a bug in Icarus Verilog because I do not believe the Verilog-LRM allows for any nondeterminism of the modpath condition expression.

The proper fix, which is painful, is to handle modpath condition expressions by evaluating them completely when they are tested. This is a completely new mechanism for the vvp runtime:-(

A short term expediant may be to generate "push" flags for expression nodes used in modpath conditions that pushes the expression value for any input change.

[Stephen Williams]

Logged In: YES
user_id=97566
Originator: YES

Priority kicked to 7 because this bug renders conditional modpaths unreliable without any warning or any clear workaround.

[Stephen Williams]

The workaround is to use -gno-specify. Since this is the default for 0.9, I'm reducing the priority to 6.

[Cary R.]

This is now working again, but the fundamental issue still exists. The condition needs to be calculated when the input changes (pulled) not whenever the value gets propagates. We had also missed adding -gspecify to the test suite so I'm not sure exactly when this started working. We think it was the T0 fixes, but I'd need to investigate that more to know for sure. I'm going to leave this open since there is a real issue that can appear with the modpath if construct.