Re: [myhdl-list] intbv with max != 2**n. Error or annoyance?

[Christopher F. <chr...@gm...>]

On 1/28/2013 5:54 AM, Per Karlsson wrote:
> Hi!
> Over the weekend I have come to the conclusion that it is an error.
>
> Checking the value of a combinatorical net before it has settled has to be
> wrong. So depending on implementation feasibility and in order of
> preference we could:
>
> - Wait until the net has stabilized before checking the range, or
> - Disable range checks for combinatorical nets, or
> - Assert whenever a signal with range delimiters != 2**n is used as a
> combinatorical net.
>
> What do you say guys?
> /Per
>
>
>
>
> On Fri, Jan 25, 2013 at 1:08 PM, Per Karlsson <bas...@gm...>wrote:
>
>> Hi!
>> Here is something that I can't make up my mind if it is an error or just
>> plain annoying:
>>
>> I have a signal where the max value is not an even 2**n, and I
>> combinatorically assign it the value of a signal with a higher max value,
>> but only on the condition that the value is within range. This is fine.
>>
>> But if the condition is moved to a separate @always_comb driving a flag
>> and the flag gates the assignment, then there is a ValueError. The
>> generated verilog is fine of course.
>> /Per
>>
<snip>

I haven't had much time to look at this issue, I have
been busy trying to reproduce and understand the other
items that may or may not be issues :)

In this case, the Verilog works because it blindly assigns
the value, so /capped/ might momentarily have the incorrect
value but Verilog isn't concerned with an out of range value.
Now, with MyHDL, because of the constraint int behavior the
momentary assignment fails.  The momentary assignment occurs
depending on the order of events in the delta cycle.  In
this case /setcapped/ has both /less_flag/ and /cnt/ in the
sensitivity list.  So, /setcapped/ or /setless/ could execute
first.

What are the rules here?  For an intbv object any time it is
assigned a new value the bounds are checked.

    x = intbv(0, min=0, max=5)
    x[:] = 6   # exception

The simulator doesn't know specifics about the types inside a
signal.  It (the simulator) doesn't discriminate between
different signals (e.g. defer scheduling).  I don't believe
this is something you want to add to the simulator's scheduler.

My view is that you want to avoid this type of modeling
where you have multiple @always_comb dependent on each other
like the example provided.  The power of the bound checking
is greater than the limitations imposed.

I don't think the error is that you get the /ValueError/ on
the delta-cycle but possibly inconsistent behavior (?).  What
I mean by this is if the schedulers always schedules

    /setcapped/ -> /setless/

on the delta-cylces then it is consistent.  If there is the
possibility that

    /setless/ -> /setcapped/

can be scheduled then, this would be an error.  Because
one case you get the /ValueError/ and the other not.  But
I don't know (or forgot) the delta-cycle scheduling rules.
I believe your example demonstrates this?  By simply
changing capped_max you get different behavior.  Should
see if this failed in 0.7 or only 0.8dev?

I would suggest fixing it in the description to something
like:

     @always_comb
     def setcapped():
         if cnt < capped_max:
             capped.next = cnt[capped_width:]
         else:
             capped.next = 0

I realize this might be your *sandbox* example and a
larger design might be organized different.

Thanks for communicating the possible error.
Regards,
Chris