Re: [myhdl-list] AttributeError in 0.8-dev but not in 0.7

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

On 1/24/2013 7:41 AM, Per Karlsson wrote:
> The problem is that val is an intbv (that is checked) but next is a bool
> (and next is never checked). So next has no ._val
> I don't think the problem can be reproduced using mere assignments. It is,
> I think, the mixed types in the conditionals that cause the error.
> I'll make another try at reproducing it 'in vitro' once I get the time.
> /Per
>
> On Thu, Jan 24, 2013 at 1:15 PM, Christopher Felton
> <chr...@gm...>wrote:
>
>> The /self._val._val = next._val/ is correct, it says
>> assign the /Signal.intbv._val/, the _val of the signal
>> is an intbv (per the check right before).
>>
>

Hmmm, I don't think a conditional will cause the the
myhdl.simulator to invoke the /update/ functions.

Looking at the code, I could see the attribute hazard in
the /_update()/ function if:

     _val  : type == intbv
     _next : type == bool

But for the above to occur the /Signal._SetNextVal/ would
need to be assigned to /Signal._SetNextBool/.  Now, for that
to occur the /Signal/ would need to be instantiated with a
/bool/ ...

Do you see the error now?  You need a complex set of
events.  You need to create a /Signal/ of type /bool/
then assign it to and /intbv/ and then assign it to a
/bool/ again.  If your code inter-mixes /bool/ and
/intbv[1:]/ a bunch there is this potential to hit this.

code snip:

     x = Signal(bool(0))
     x.next = intbv(1)[1:]
     print(type(x._val), type(x._next))
     x._update()
     print(type(x._val), type(x._next))
     x.next = False
     print(type(x._val), type(x._next))
     x._update()


The above will cause the error you are seeing.

Now the question is, does the design intend for /bool/
and /intbv[1:]/ interchanged.  If it does then this needs
to be fixed, if it doesn't then we need to add an assert
that prevents the first /intbv/ assignment to the bool.

Regards,
Chris Felton