#677 C. assigns with zero delay can create zero width glitches

[Robert Jackson]

Hi

The attached test case is an asynchronous register with clear/preset and a synchronous enable.

The clear and preset are driven by the following logic:
nCLR = ~(~npre | ~nclr) | ~npre;
nPRE = ~(~npre | ~nclr) | npre;

Unfortunately these expressions appear to be incorrectly evaluated, as they should be equivalent to the following simplification:
nCLR = nclr | ~npre;
nPRE = npre;

I've attached a test case along with the simulation logs from some commercial simulators.

I am using git from 4th March 2009.

Cheers

Robert

[Robert Jackson]

Testcase

[Cary R.]

Invalid results with out an error so +2 on the priority.

[Cary R.]

There may be other issues in the full example, but here is a significantly reduced example that demonstrates at least one problem you are seeing. The problem is that the complex expression is glitching when npre changes from 0 to 1. If you simplify the reduced example expression to npre | ~npre it does not glitch.

[Cary R.]

reduced example file

[Cary R.]

Another update.

Adding some delay to the expressions will remove the glitch (assign #1). This may still be an Icarus problem, but this may also be in the realm of acceptable behavior. Because of this and because there is now a simple and common work around I'm dropping the priority by one.

[Cary R.]

This appears to be a real bug. From 1364-2005 section 6.1.2 page 70.

In other words, whenever an operand in the righthand
expression changes value, the whole right-hand side
shall be evaluated.

In the case of Icarus the different parts of the equation are processed in different delta cycles resulting in the zero time glitch. Steve and I have discussed what likely needs to be done to fix this problem. It is uncertain if this fix will go into V0.9 or if it will be restricted to development.

[Cary R.]

After further investigation this appears to be a more fundamental problem and likely will require a significant rework of how expressions are handled in the run time. The basic problem is that Icarus does not have the ability to request that other operands to a functor (expression operator) be evaluated. We do schedule the change to remove glitches in the same delta cycle, but that does not help when the glitch is created by changes in different delta cycles.

Using my reduced example code, the following:

wire nCLR = ~(~npre) | ~npre;

glitches, but this equivalent equation does not.

wire nCLR ~npre | ~(~npre);

For now reordering the equation or adding delay will need to suffice.

I'm renaming the report to better reflect the underlying problem so other users can find it easier.