#37 Bound check race condition

[Christopher L. Felton]

In some circumstances and Signal containing an intbv can be assigned a value outside the intbv range. But the value is assigned on a delta-cycle and the original intended is that there was some mechanism to gate the invalid value. But the invalid value *sneaks* through but the actual final value is within the range. It appears the intbv bound checks need to be deferred till the end of the simulation cycle?

I have a test here:
https://bitbucket.org/cfelton/myhdl_tests/src/tip/test_bound_err.py?at=default
that demonstrates the failure.

This has been discussed on the mailing-list:
http://comments.gmane.org/gmane.comp.python.myhdl/3031
http://comments.gmane.org/gmane.comp.python.myhdl/3044

[Christopher L. Felton]

The attached test is a stand-alone no dependent
test. It is based on the example Per provided
in the mailing-list.

The error that is reported is a bound error
(value outside the min-max of the intbv). But
the bound error occurs on an intermediate value,
the design intends a signal to gate the value,
the intermediate value occurs on a delta-cycle and
hence the bound assertion occurs on a delta-cycle,
by the end of the time-step the value would have resolved
itself to be within bounds.

[Christopher L. Felton]

This was discussed on the mailing-list at this
point it is a pending-no-issue. As soon as I
figure out how to change the state, I will update
this issue (change it to closed shortly after).

[Christopher L. Felton]

This non-issue was discussed on the mailing-list and is
really a feature and not an issues. From the discussions
there is no limitation by the bound checking as soon as the
assignment is made, the behavior can be described without
causing the bound check error. The alternative descriptions
are preferred.

The example provided can easily be modified to prevent the
bound check and maintain the same logic.