myhdl-list

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

[Per K. <bas...@gm...>]

Hi!
There is probably something fishy about the lines 184-192 in _Signal.py in
0.8dev
With 0.8-dev I get:
    File [...]/_Signal.py", line 195, in _update
     self._val._val = next._val
AttributeError: 'bool' object has no attribute '_val'
With 0.7 it works fine. Also toVerilog works fine in both 0.7 and 0.8-dev
and iverilog cosimulation passes.

I have not been (immediately) able to reproduce the error outside of the
project (which I'm afraid I can't show you), but I have pinpointed the
lines that cause the error. They are perfectly ordinary. (if b==0: a.next =
1 basically)

When I debug I see that 'next' is a bool and val is an 'intbv', whereas
normally both are 'intbv'.

I know this is a bit vague, but perhaps Jan can recall what he was doing in
May 2011 and figure it out. :)
/Per

ps. Anyone got any general tips for myhdl debugging?

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

[Per K. <bas...@gm...>]

Hi!
I have dug a little deeper, and it has to do with using Signal(bool(False))
and Signal(intbv(0)[1:0]).
If I use only the latter and make all comparisons explicit ("if flag==1"
instead of just "if flag") the AttributeError goes away.
I have also seen that even if I don't get the attribute error there are
simulation mismatches between the verilog and the myhdl when intbv and bool
are mixed.

I've seen this discussed on the boards before, and I think it is obvious
that we need to support "if not flag:"-like syntax. It makes the code
easier to read, and it works in both python and verilog.
/Per



On Wed, Jan 23, 2013 at 11:15 PM, Per Karlsson <bas...@gm...>wrote:

> Hi!
> There is probably something fishy about the lines 184-192 in _Signal.py in
> 0.8dev
> With 0.8-dev I get:
>     File [...]/_Signal.py", line 195, in _update
>      self._val._val = next._val
> AttributeError: 'bool' object has no attribute '_val'
> With 0.7 it works fine. Also toVerilog works fine in both 0.7 and 0.8-dev
> and iverilog cosimulation passes.
>
> I have not been (immediately) able to reproduce the error outside of the
> project (which I'm afraid I can't show you), but I have pinpointed the
> lines that cause the error. They are perfectly ordinary. (if b==0: a.next =
> 1 basically)
>
> When I debug I see that 'next' is a bool and val is an 'intbv', whereas
> normally both are 'intbv'.
>
> I know this is a bit vague, but perhaps Jan can recall what he was doing
> in May 2011 and figure it out. :)
>  /Per
>
> ps. Anyone got any general tips for myhdl debugging?
>

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

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

On 1/24/2013 5:49 AM, Per Karlsson wrote:
> Hi!
> I have dug a little deeper, and it has to do with using Signal(bool(False))
> and Signal(intbv(0)[1:0]).
> If I use only the latter and make all comparisons explicit ("if flag==1"
> instead of just "if flag") the AttributeError goes away.
> I have also seen that even if I don't get the attribute error there are
> simulation mismatches between the verilog and the myhdl when intbv and bool
> are mixed.
>
> I've seen this discussed on the boards before, and I think it is obvious
> that we need to support "if not flag:"-like syntax. It makes the code
> easier to read, and it works in both python and verilog.
> /Per
>

Thanks for the additional information but I still can't
reproduce the error with 0.8-dev (ignoring conversion
for now).  If I understand correctly you are saying if
you use /if Signal(intbv):/ and /if not Signal(intbv):/
it should cause the problem?

The following little test, works:

     def test():
         #flag = Signal(bool(0))
         flag = Signal(intbv(0)[1:])
         @instance
         def tb_stim():
             print('myhdl version %s' % (myhdl.__version__))
             print('start ...')
             for ii in range(3):
                 if not flag:
                     flag.next = not flag
                 yield delay(10)
                 print("%8d : %s" % (now(), repr(flag)))
                 if flag:
                     flag.next = not flag
                 yield delay(10)
                 print("%8d : %s" % (now(), repr(flag)))
             print('... end')

         return tb_stim

produces:
     >>> Simulation(test()).run()
     myhdl version 0.8dev
     start ...
           10 : Signal(intbv(True))
           20 : Signal(intbv(False))
           30 : Signal(intbv(True))
           40 : Signal(intbv(False))
           50 : Signal(intbv(True))
           60 : Signal(intbv(False))
     ... end

And I ran the same test with /flag = Signal(bool)/ and I
did not observe an issue either?

Regards,
Chris Felton

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

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

On 1/23/13 4:15 PM, Per Karlsson wrote:
> Hi!
> There is probably something fishy about the lines 184-192 in _Signal.py
> in 0.8dev
> With 0.8-dev I get:
>      File [...]/_Signal.py", line 195, in _update
>      self._val._val = next._val
> AttributeError: 'bool' object has no attribute '_val'
> With 0.7 it works fine. Also toVerilog works fine in both 0.7 and
> 0.8-dev and iverilog cosimulation passes.
>
> I have not been (immediately) able to reproduce the error outside of the
> project (which I'm afraid I can't show you), but I have pinpointed the
> lines that cause the error. They are perfectly ordinary. (if b==0:
> a.next = 1 basically)
>
> When I debug I see that 'next' is a bool and val is an 'intbv', whereas
> normally both are 'intbv'.
>
> I know this is a bit vague, but perhaps Jan can recall what he was doing
> in May 2011 and figure it out. :)
> /Per
>
> ps. Anyone got any general tips for myhdl debugging?
>
>

I was not able to reproduce the error that fits the
description.  I believe you were referring to line 187
in the following view:

http://hg.myhdl.org/cgi-bin/hgwebdir.cgi/myhdl/file/7869342e341a/myhdl/_Signal.py

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).

I thought a /Signal(intbv).next = bool/ might cause
the error but the following code snip works fine in
0.8-dev

     import myhdl
     print(myhdl.__version__)
     from myhdl import *
     x = Signal(intbv(0, min=-8, max=8))
     print(repr(x)); assert x == 0
     x.next = 1
     x._update()
     print(repr(x)); assert x == 1
     x.next = intbv(4)[3:]
     x._update()
     print(repr(x)); assert x == 4
     x.next = bool(1)
     x._update()
     print(repr(x)); assert x == True
     x.next = Signal(bool(0))
     x._update()
     print(repr(x)); assert x == False
     x.next = Signal(intbv(-3, min=-16, max=5))
     x._update()
     print(repr(x)); assert x == -3

or similar run through the simulator

     x = Signal(intbv(0, min=-8, max=8))
     def test_next():
         @instance
         def tb_test():
             x.next = 1
             yield delay(2)
             x.next = True
             yield delay(2)
             x.next = False
             yield delay(2)
             x.next = intbv(4)[3:];
             yield delay(2)
             x.next = -6
             yield delay(2)
         return tb_test
     Simulation(test_next()).run()


Regards,
Chris Felton

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

[Per K. <bas...@gm...>]

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).
>

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

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

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

On 1/24/2013 8:08 AM, Christopher Felton wrote:
> 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
>
>

I did not test the above with 0.7 as you indicated, you only
observed the issue with 0.8-dev.  I can diff the version and
see what might have changed (at some point).

Regards,
Chris

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

[Per K. <bas...@gm...>]

Yes, I think you're right! It is mixing intbv[1:0] and bool that causes it.

If that is to be forbidden, there needs to be an assert as soon as
possible. But I don't see why we should disallow it.
The reason I didn't see it sooner was that the bool and the intbv were
instantiated in separate modules. And unless we ban one-bit intbvs or bools
outright I don't see how that sort of thing can be avoided. One hardware
designer's bool is another's one bit integer. :)
/Per

On Thu, Jan 24, 2013 at 3:08 PM, Christopher Felton
<chr...@gm...>wrote:

> 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
>
>
>
>
> ------------------------------------------------------------------------------
> Master Visual Studio, SharePoint, SQL, ASP.NET, C# 2012, HTML5, CSS,
> MVC, Windows 8 Apps, JavaScript and much more. Keep your skills current
> with LearnDevNow - 3,200 step-by-step video tutorials by Microsoft
> MVPs and experts. ON SALE this month only -- learn more at:
> http://p.sf.net/sfu/learnnow-d2d
> _______________________________________________
> myhdl-list mailing list
> myh...@li...
> https://lists.sourceforge.net/lists/listinfo/myhdl-list
>

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

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

On 1/24/13 8:39 AM, Per Karlsson wrote:
> Yes, I think you're right! It is mixing intbv[1:0] and bool that causes it.
>

Looking at this a little more the 0.7 code didn't check
the types in the /_update/ function it simply assigned
the /next/.  I think the changes in 0.8 help support
/Signal/s that contain different objects.  I think the
changes are good (it was a quick look, so I might be off).

The simple change I made was to have the _setNextBool to
always cast to a bool type.  That way we won't have the
/val/ of a /Signal/ changing from one type to another.
Made a similar change with the _setNextInt


This error should block 0.8 from being released.  I will
make a patch and post it with the description.  I have
not resolved the mixing /bool/ and /intbv(0)[1:]/ in the
VHDL conversion.  This should also be fixed and submitted
as a single patch, when I get some more time I will tackle
this next (or if someone resolves the issue :) ).

All the non-conversion unit test in 0.8dev pass with these
changes.  All the general conversion tests pass also with
the exception of two VHDL analyzed with GHDL tests but these
two tests failed before the changes.

Regards,
Chris

[1] 
https://bitbucket.org/cfelton/myhdl_tests/src/tip/test_mix_intbv_bool.py?at=default

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

[Jan D. <ja...@ja...>]

On 01/24/2013 03:39 PM, Per Karlsson wrote:
> Yes, I think you're right! It is mixing intbv[1:0] and bool that
> causes it.
>
> If that is to be forbidden, there needs to be an assert as soon as
> possible. But I don't see why we should disallow it. The reason I
> didn't see it sooner was that the bool and the intbv were
> instantiated in separate modules. And unless we ban one-bit intbvs or
> bools outright

I don't see what you mean here. You could just use intbv[0] to
assign to a boolean Signal.

  I don't see how that sort of thing can be avoided. One
> hardware designer's bool is another's one bit integer. :) /Per

We are talking about intbv versus bool. Intbv also has a "bit-vector"
meaning. To me, a bit-vector with a width 1 is just a degenerated
vector, not the same as a single bit variable/signal. In VHDL it is
also like that - therefore if we start changing this there will be
all kinds of tricky issues after conversion.

For single bit variables/Signal, the idiomatic MyHDL way is bool,
not intbv[1:0], which looks like a user error to me.
I agree that there is should be a direct error check to prevent assigning
an intbv[1:0] to a bool Signal however, so that the issue if
flagged early on.

Jan

-- 
Jan Decaluwe - Resources bvba - http://www.jandecaluwe.com
     Python as a HDL: http://www.myhdl.org
     VHDL development, the modern way: http://www.sigasi.com
     World-class digital design: http://www.easics.com