myhdl-list — Mailing list for discussions on MyHDL

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

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

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
>
> ps. Here is an example:
>
> from myhdl import *
>
> def range_check(capped, clk, rstn, cnt_max):
>     cnt       = Signal(intbv(0, min=0, max=cnt_max))
>     less_flag = Signal(intbv(0)[1:0])
>
>     cnt_max      = cnt.max
>     capped_max   = capped.max
>     capped_width = len(capped)
>
>     @always(clk.posedge, rstn.negedge)
>     def count():
>         if rstn==0:
>             cnt.next = 0
>         else:
>             if cnt + 1 == cnt_max:
>                 cnt.next = 0
>             else:
>                 cnt.next = cnt + 1
>
>     @always_comb
>     def setcapped():
>         if less_flag==1:
>             capped.next = cnt[capped_width:]
>         else:
>             capped.next = 0
>
>     @always_comb
>     def setless():
>         if cnt < capped_max:
>             less_flag.next = 1
>         else:
>             less_flag.next = 0
>
>     return instances()
>
> def tb(capped_max):
>     clk   = Signal(intbv(0)[1:0])
>     rstn  = Signal(intbv(0)[1:0])
>
>     @instance
>     def rstngen():
>         rstn.next = 0
>         yield delay(100)
>         rstn.next = 1
>         yield delay(10000)
>         raise StopSimulation
>
>     @always(delay(10))
>     def clkgen():
>         clk.next = not clk
>
>     capped  = Signal(intbv(0, min=0, max=capped_max))
>     cnt_max = 15
>     dut   = range_check(capped, clk, rstn, cnt_max)
>     return instances()
>
> s = Simulation(tb(4))
> s.run()
> print "4 is OK"
> s = Simulation(tb(5))
> s.run()
> print "5 is not"
>
>

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] VHDL Conversion Errors

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

<snip>
>
>          1 = /if not reset/
>          2 = /reset == False/
>          3 = /reset == bool(0)/
>          4 = /reset == 0/
>          5 = /reset == intbv(0)/
>
>         simulation:
> 	all pass
>
>         vhdl:
>          1 converted vhdl, ok
>          2 converted vhdl, ok
>          3 converted vhdl, ok
>          4 converted vhdl, ok
>          5 converted vhdl, no warning given, converted code is not correct.

Norbo, thanks for posting this.  I think we got
a little off track with this "issue", which I don't
think is an issue.  The errors we were seeing were with
the special case of *reset*.  As you demonstrated the
different conditional statements work fine (except case 5).
It is only the *reset* case that raises some questions with
VHDL conversion or more generally an edge sensitive signal
other than a clock.

In the manual [1] Jan calls out /reset == 0/.  I think this
is ok to require this for the reset cases.  It can be an
enhancement to add /reset == False/ but I don't think it
is a bug and I think it would be low priority enhancement.
Since the four cases work fine in the other uses, I don't
see the *reset* case being much worry, especially since we
can use the /@always_seq/ with the latest 0.8dev.

I had created some tests [2] and added combinatorial and
sequential conditionals.  As discussed all four cases
convert unless used as a reset, reset has to be explicitly
/reset == 0/ or /reset == 1/ (or use @always_seq).

The last case , case 5, I think will fall under the general
mixing of /bool/ and /intbv[1:]/.  I am going to remove the
conditional from the short list of bugs that I am keeping.

Here is the summary from the tests I ran and can be found
at [2].  Like I said, I think we should remove this one
from the "bug" list (low priority and is document how
the modeling is expected).  The biggest issue would be
the mismatch in MyHDL simulation and Verilog conversion.
My cases are the same as you enumerated, we could have
removed case 3 it is the same as 2.

    myhdl   :test_ifnot_comb_1: success
    ghdl    :test_ifnot_comb_1: success
    icarus  :test_ifnot_comb_1: success

    myhdl   :test_ifnot_comb_2: success
    ghdl    :test_ifnot_comb_2: success
    icarus  :test_ifnot_comb_2: success

    myhdl   :test_ifnot_comb_3: success
    ghdl    :test_ifnot_comb_3: success
    icarus  :test_ifnot_comb_3: success

    myhdl   :test_ifnot_comb_4: success
    ghdl    :test_ifnot_comb_4: success
    icarus  :test_ifnot_comb_4: success

    myhdl   :test_ifnot_comb_5: success
    ghdl    :test_ifnot_comb_5: failed
    icarus  :test_ifnot_comb_5: success

    myhdl   :test_ifnot_reset_1: success
    ghdl    :test_ifnot_reset_1: failed
    icarus  :test_ifnot_reset_1: success

    myhdl   :test_ifnot_reset_2: success
    ghdl    :test_ifnot_reset_2: failed
    icarus  :test_ifnot_reset_2: success

    myhdl   :test_ifnot_reset_3: success
    ghdl    :test_ifnot_reset_3: failed
    icarus  :test_ifnot_reset_3: success

    myhdl   :test_ifnot_reset_4: success
    ghdl    :test_ifnot_reset_4: success
    icarus  :test_ifnot_reset_4: success

    myhdl   :test_ifnot_reset_5: success
    ghdl    :test_ifnot_reset_5: failed
    icarus  :test_ifnot_reset_5: success

    myhdl   :test_ifnot_seq_1: success
    ghdl    :test_ifnot_seq_1: success
    icarus  :test_ifnot_seq_1: success

    myhdl   :test_ifnot_seq_2: success
    ghdl    :test_ifnot_seq_2: success
    icarus  :test_ifnot_seq_2: success

    myhdl   :test_ifnot_seq_3: success
    ghdl    :test_ifnot_seq_3: success
    icarus  :test_ifnot_seq_3: success

    myhdl   :test_ifnot_seq_4: success
    ghdl    :test_ifnot_seq_4: success
    icarus  :test_ifnot_seq_4: success

    myhdl   :test_ifnot_seq_5: success
    ghdl    :test_ifnot_seq_5: failed
    icarus  :test_ifnot_seq_5: success

Regards,
Chris

[1] http://www.myhdl.org/doc/current/manual/modeling.html#sequential-logic

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

Re: [myhdl-list] VHDL Conversion Errors

[Norbo <Nor...@gm...>]

Am 23.01.2013, 20:15 Uhr, schrieb Christopher Felton
<chr...@gm...>:

> On 1/23/2013 10:35 AM, Norbo wrote:
>>> On the #2 issues, since the MyHDL simulation != VHDL
>>> simulation, does this constitute an error, not sure?  I
>>> had a similar issue, I often used:
>>>
>>>          if reset:
>>>
>>> The myhdl simulation worked and Verilog conversion worked
>>> but the VHDL did not, the fix was to explicitly state:
>>>
>>>          if reset == False:
>>>
>>> Even though there was a simulation mismatch it was suggested
>>> that the "reset == False", is the desired form.  I am not sure
>>> if the mixed type comparison should be converted?  Instead, we
>>> probably want the converter to raise a conversion exception and
>>> not convert the code.
>>
>> i am a bit confused:
>> when a negedge event on the reset is inserted in the sensitivity list,
>> then it would
>> look like the following, right?
>>
>> ############## case 1 ###########
>>
>>       if reset:
>>
>> -->> conversion to vhdl works but would be the wrong value for the  
>> negedge
>> event. right?
>>
>>
>>
>> ############## case 2 ###########
>>
>>       if not reset:
>>
>> -->> conversion to vhdl fails, with: Error:  No proper edge value test
>>
>>
>> ############## case 3 ###########
>>
>>       if reset== False:
>>
>> -->> conversion to vhdl fails, with: Error:    No proper edge value test
>>
>>
>> ############## case 4 ###########
>>
>>       if reset== bool(0):
>>
>> -->> conversion to vhdl fails, with: Error:    No proper edge value test
>>
>>
>> ############## case 5 ###########
>>
>>       if reset==0:
>>
>> -->> The working version !!
>>
>>
>> greetings
>> Norbo
>>
>>
>
> Correct, if we create an example(s):
>
>     @always(clock.posedge, reset.negedge)
>     def hdl():
>        if reset == False:
>        ...
>
> The only version that appears to convert with 0.8 is the
> /reset == 0/?  That seems wrong?  I will have to try 0.7
> and think about this a little more.  Will need to get a
> bunch of caffeine for tonight :)  Unless anyone else has
> some insight?
>
> The results from the code snip below (same as Norbo's):
>
>     1 = /if not reset/
>     2 = /reset == False/
>     3 = /reset == bool(0)
>     4 = /reset == 0/
>
>     1 error vhdl in file tb_ifnot.py, line 8:
>         No proper edge value test
>     2 error vhdl in file tb_ifnot.py, line 17:
>         No proper edge value test
>     3 error vhdl in file tb_ifnot.py, line 26:
>         No proper edge value test
>     4 converted vhdl
>
>     1 converted verilog
>     2 converted verilog
>     3 converted verilog
>     4 converted verilog
>


The following is the result for an example which looks like this (when the
if is used in a combinatorical statement and
not as a reset):

       @always_comb
       def read():
         if reset==False:
	......
         else:
           ....


        1 = /if not reset/
        2 = /reset == False/
        3 = /reset == bool(0)/
        4 = /reset == 0/
        5 = /reset == intbv(0)/

       simulation:
	all pass

       vhdl:
        1 converted vhdl, ok
        2 converted vhdl, ok
        3 converted vhdl, ok
        4 converted vhdl, ok
        5 converted vhdl, no warning given, converted code is not correct.



here is the code:
#####################################

   from myhdl import *
def selecttry_1(reset,dout):
       @always_comb
       def read():
         if not reset:
	dout.next=5
         else:
           dout.next=6
       return read

def selecttry_2(reset,dout):
       @always_comb
       def read():
         if reset==False:
	dout.next=5
         else:
           dout.next=6
       return read

def selecttry_3(reset,dout):
       @always_comb
       def read():
         if reset==bool(0):
	dout.next=5
         else:
           dout.next=6
       return read


def selecttry_4(reset,dout):
       @always_comb
       def read():
         if reset==0:
	dout.next=5
         else:
           dout.next=6
       return read

def selecttry_5(reset,dout):
       @always_comb
       def read():
         if reset==intbv(0):
	dout.next=5
         else:
           dout.next=6
       return read

cases=[globals()[x] for x in dir() if "selecttry_" in x]


### simulating all cases
for func in cases:
     def testbench():
       sel=Signal(bool(0))
       dout=Signal(intbv(0)[8:])
       dut_inst=func(sel,dout)

       @instance
       def tb_stim():
           print 'Start sim of:',func.func_name,
           sel.next = False
           yield delay(10)
           assert dout==5
           sel.next = True
           yield delay(10)
           assert dout==6

           print ' sim completed'

           raise StopSimulation

       return dut_inst, tb_stim

     Simulation(testbench()).run()


## converting to VHDL with bool as select signal
sel=Signal(bool(0))
dout=Signal(intbv(0)[8:])
for index, func in enumerate(cases):
     try:
       toVHDL(func,sel,dout)
       print "Converting ",func.func_name, " completed"
     except:
       print "Error in ", func.func_name


greetings
Norbo

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

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

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

ps. Here is an example:

from myhdl import *

def range_check(capped, clk, rstn, cnt_max):
    cnt       = Signal(intbv(0, min=0, max=cnt_max))
    less_flag = Signal(intbv(0)[1:0])

    cnt_max      = cnt.max
    capped_max   = capped.max
    capped_width = len(capped)

    @always(clk.posedge, rstn.negedge)
    def count():
        if rstn==0:
            cnt.next = 0
        else:
            if cnt + 1 == cnt_max:
                cnt.next = 0
            else:
                cnt.next = cnt + 1

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

    @always_comb
    def setless():
        if cnt < capped_max:
            less_flag.next = 1
        else:
            less_flag.next = 0

    return instances()

def tb(capped_max):
    clk   = Signal(intbv(0)[1:0])
    rstn  = Signal(intbv(0)[1:0])

    @instance
    def rstngen():
        rstn.next = 0
        yield delay(100)
        rstn.next = 1
        yield delay(10000)
        raise StopSimulation

    @always(delay(10))
    def clkgen():
        clk.next = not clk

    capped  = Signal(intbv(0, min=0, max=capped_max))
    cnt_max = 15
    dut   = range_check(capped, clk, rstn, cnt_max)
    return instances()

s = Simulation(tb(4))
s.run()
print "4 is OK"
s = Simulation(tb(5))
s.run()
print "5 is not"

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/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] VHDL Conversion Errors

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

On 1/24/2013 1:58 AM, Thomas Heller wrote:
> Am 23.01.2013 03:38, schrieb Christopher Felton:
>>
>> Let me try and summarize, we believe we have encountered
>> three different VHDL conversion errors.
>>
>>       1. bitwise multiplication (there was the wider
>>       question if the types were correct but since the ops
>>       were invalid it was a moot point).
>>
>>       2. An odd intbv(val) == bool(val) comparison error,
>>       python allows this check (what is the rule?) but when
>>       converted the mixed types is not a valid comparison?
>>
>>       3. More than two operand math operations and resizing.
>>
>> On the #2 issues, since the MyHDL simulation != VHDL
>> simulation, does this constitute an error, not sure?
>
> Same for +3.
>
> It would be nice to hear some 'official words' on that from Jan.
>

Yes of course, but we can help quite a bit by generating
unit tests (I think I have all these) and suggesting possible
fixes and/or reasons whey we think the *issues* we are observing
should be supported.

It is common for most of us, that our responsibilities fluctuate,
hence we are busier at certain times than others.  I think we can
help keep the ball moving forward by organizing these issues.

>>
>> Now, the best way to keep track of these so we don't loose
>> track of them?
>
> The general answer to this, of course, is to submit an item into
> the tracker (after discussion in this newsgroup).

The only question, the sourceforge tracker has never been used
(best of my knowledge).  Do we use the sourceforge tracker or ???

Regards,
Chris Felton

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

[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/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...>]

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] VHDL Conversion Errors

[Thomas H. <th...@ct...>]

Am 23.01.2013 03:38, schrieb Christopher Felton:
>
> Let me try and summarize, we believe we have encountered
> three different VHDL conversion errors.
>
>      1. bitwise multiplication (there was the wider
>      question if the types were correct but since the ops
>      were invalid it was a moot point).
>
>      2. An odd intbv(val) == bool(val) comparison error,
>      python allows this check (what is the rule?) but when
>      converted the mixed types is not a valid comparison?
>
>      3. More than two operand math operations and resizing.
>
> On the #2 issues, since the MyHDL simulation != VHDL
> simulation, does this constitute an error, not sure?

Same for +3.

It would be nice to hear some 'official words' on that from Jan.

>
> Now, the best way to keep track of these so we don't loose
> track of them?

The general answer to this, of course, is to submit an item into
the tracker (after discussion in this newsgroup).

Thomas

[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] VHDL Conversion Errors

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

On 1/23/2013 10:35 AM, Norbo wrote:
>> On the #2 issues, since the MyHDL simulation != VHDL
>> simulation, does this constitute an error, not sure?  I
>> had a similar issue, I often used:
>>
>>          if reset:
>>
>> The myhdl simulation worked and Verilog conversion worked
>> but the VHDL did not, the fix was to explicitly state:
>>
>>          if reset == False:
>>
>> Even though there was a simulation mismatch it was suggested
>> that the "reset == False", is the desired form.  I am not sure
>> if the mixed type comparison should be converted?  Instead, we
>> probably want the converter to raise a conversion exception and
>> not convert the code.
>
> i am a bit confused:
> when a negedge event on the reset is inserted in the sensitivity list,
> then it would
> look like the following, right?
>
> ############## case 1 ###########
>
>       if reset:
>
> -->> conversion to vhdl works but would be the wrong value for the negedge
> event. right?
>
>
>
> ############## case 2 ###########
>
>       if not reset:
>
> -->> conversion to vhdl fails, with: Error:  No proper edge value test
>
>
> ############## case 3 ###########
>
>       if reset== False:
>
> -->> conversion to vhdl fails, with: Error:    No proper edge value test
>
>
> ############## case 4 ###########
>
>       if reset== bool(0):
>
> -->> conversion to vhdl fails, with: Error:    No proper edge value test
>
>
> ############## case 5 ###########
>
>       if reset==0:
>
> -->> The working version !!
>
>
> greetings
> Norbo
>
>

Correct, if we create an example(s):

    @always(clock.posedge, reset.negedge)
    def hdl():
       if reset == False:
       ...

The only version that appears to convert with 0.8 is the
/reset == 0/?  That seems wrong?  I will have to try 0.7
and think about this a little more.  Will need to get a
bunch of caffeine for tonight :)  Unless anyone else has
some insight?

The results from the code snip below (same as Norbo's):

    1 = /if not reset/
    2 = /reset == False/
    3 = /reset == bool(0)
    4 = /reset == 0/

    1 error vhdl in file tb_ifnot.py, line 8:
        No proper edge value test
    2 error vhdl in file tb_ifnot.py, line 17:
        No proper edge value test
    3 error vhdl in file tb_ifnot.py, line 26:
        No proper edge value test
    4 converted vhdl

    1 converted verilog
    2 converted verilog
    3 converted verilog
    4 converted verilog


Regards,
Chris

~~~ Code Snip ~~~
from myhdl import *
import subprocess

def ifnot_1(clock,reset,a,b):
     @always(clock.posedge, reset.negedge)
     def hdl():
         if not reset:
             b.next = False
         else:
             b.next = not a
     return hdl

def ifnot_2(clock,reset,a,b):
     @always(clock.posedge, reset.negedge)
     def hdl():
         if reset == False:
             b.next = False
         else:
             b.next = not a
     return hdl

def ifnot_3(clock,reset,a,b):
     @always(clock.posedge, reset.negedge)
     def hdl():
         if reset == bool(0):
             b.next = False
         else:
             b.next = not a
     return hdl

def ifnot_4(clock,reset,a,b):
     @always(clock.posedge, reset.negedge)
     def hdl():
         if reset == 0:
             b.next = False
         else:
             b.next = not a
     return hdl

def tb_ifnot():
     clock,reset = [Signal(bool(0)) for ii in range(2)]
     a = Signal(bool(0))
     b = [Signal(bool(0)) for ii in range(4)]

     tb_dut = [None for ii in range(4)]
     #b1,b2,b3,b4 = b  # no LoS ports
     tb_dut[0] = ifnot_1(clock,reset,a,b[0])
     tb_dut[1] = ifnot_2(clock,reset,a,b[1])
     tb_dut[2] = ifnot_3(clock,reset,a,b[2])
     tb_dut[3] = ifnot_4(clock,reset,a,b[3])

     @always(delay(2))
     def tb_clk():
         clock.next = not clock

     @instance
     def tb_stim():
         print('start')
         reset.next = False
         yield delay(10)
         for ii in range(4):
             assert b[ii] == False

         reset.next = True
         yield delay(10)
         for ii in range(4):
             assert b[ii] == (not a)
         print('end')

         raise StopSimulation

     return tb_clk, tb_stim, tb_dut

def convert_vhdl():
     clock,reset = [Signal(bool(0)) for ii in range(2)]
     a = Signal(bool(0))
     b = [Signal(bool(0)) for ii in range(4)]
     b1,b2,b3,b4 = b

     try:
         toVHDL(ifnot_1,clock,reset,a,b1)
         print('1 converted vhdl')
     except Exception, err:
         print('1 error vhdl %s' % (err))

     try:
         toVHDL(ifnot_2,clock,reset,a,b2)
         print('2 converted vhdl')
     except Exception, err:
         print('2 error vhdl %s' % (err))

     try:
         toVHDL(ifnot_3,clock,reset,a,b3)
         print('3 converted vhdl')
     except Exception, err:
         print('3 error vhdl %s' % (err))

     try:
         toVHDL(ifnot_4,clock,reset,a,b4)
         print('4 converted vhdl')
     except Exception, err:
         print('4 error vhdl %s' % (err))

def convert_verilog():
     clock,reset = [Signal(bool(0)) for ii in range(2)]
     a = Signal(bool(0))
     b = [Signal(bool(0)) for ii in range(4)]
     b1,b2,b3,b4 = b

     try:
         toVerilog(ifnot_1,clock,reset,a,b1)
         print('1 converted verilog')
     except Exception, err:
         print('1 error verilog %s' % (err))

     try:
         toVerilog(ifnot_2,clock,reset,a,b2)
         print('2 converted verilog')
     except Exception, err:
         print('2 error verilog %s' % (err))

     try:
         toVerilog(ifnot_3,clock,reset,a,b3)
         print('3 converted verilog')
     except Exception, err:
         print('3 error verilog %s' % (err))

     try:
         toVerilog(ifnot_4,clock,reset,a,b4)
         print('4 converted verilog')
     except Exception, err:
         print('4 error verilog %s' % (err))

if __name__ == '__main__':
     Simulation(tb_ifnot()).run()
     convert_vhdl()
     convert_verilog()
     toVHDL(tb_ifnot)
     subprocess.check_call('vcom pck_myhdl_08.vhd tb_ifnot.vhd', shell=True)
     subprocess.check_call('vsim -c -do -t 1ns run.do work.tb_ifnot', 
shell=True)
~~~~~~~~~~~~~~~~~

Re: [myhdl-list] VHDL Conversion Errors (was: Bug in generated code?)

[Norbo <Nor...@gm...>]

> On the #2 issues, since the MyHDL simulation != VHDL
> simulation, does this constitute an error, not sure?  I
> had a similar issue, I often used:
>
>         if reset:
>
> The myhdl simulation worked and Verilog conversion worked
> but the VHDL did not, the fix was to explicitly state:
>
>         if reset == False:
>
> Even though there was a simulation mismatch it was suggested
> that the "reset == False", is the desired form.  I am not sure
> if the mixed type comparison should be converted?  Instead, we
> probably want the converter to raise a conversion exception and
> not convert the code.

i am a bit confused:
when a negedge event on the reset is inserted in the sensitivity list,  
then it would
look like the following, right?

############## case 1 ###########

     if reset:

-->> conversion to vhdl works but would be the wrong value for the negedge  
event. right?



############## case 2 ###########

     if not reset:

-->> conversion to vhdl fails, with: Error:  No proper edge value test


############## case 3 ###########

     if reset== False:

-->> conversion to vhdl fails, with: Error:    No proper edge value test


############## case 4 ###########

     if reset== bool(0):

-->> conversion to vhdl fails, with: Error:    No proper edge value test


############## case 5 ###########

     if reset==0:

-->> The working version !!


greetings
Norbo

Re: [myhdl-list] VHDL Conversion Errors

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

On 1/22/2013 8:38 PM, Christopher Felton wrote:
> On 1/20/13 6:01 AM, Norbo wrote:
>> This Code i think actually shows two glitches in the VHDL converter.
>> One was already discussed here, but i think it has been forgotten. This is
>> just to remember.
>> Here the link: http://permalink.gmane.org/gmane.comp.python.myhdl/2218
>>
>>
> <snip>
>>
>
> Let me try and summarize, we believe we have encountered
> three different VHDL conversion errors.
>
>      1. bitwise multiplication (there was the wider
>      question if the types were correct but since the ops
>      were invalid it was a moot point).
>
>      2. An odd intbv(val) == bool(val) comparison error,
>      python allows this check (what is the rule?) but when
>      converted the mixed types is not a valid comparison?
>
>      3. More than two operand math operations and resizing.
>
> On the #2 issues, since the MyHDL simulation != VHDL
> simulation, does this constitute an error, not sure?  I
> had a similar issue, I often used:
>
>          if reset:
>
> The myhdl simulation worked and Verilog conversion worked
> but the VHDL did not, the fix was to explicitly state:
>
>          if reset == False:
>
> Even though there was a simulation mismatch it was suggested
> that the "reset == False", is the desired form.  I am not sure
> if the mixed type comparison should be converted?  Instead, we
> probably want the converter to raise a conversion exception and
> not convert the code.
>
> Now, the best way to keep track of these so we don't loose
> track of them?
>
> Regards,
> Chris
>
>

I should back up, I might not be recalling some of this
correctly or it has been modified recently.  I ran a small
test and some of the above worked.  I need some more time
and contemplation to articulate the possible issues.

I will post a follow-up tonight when I, hopefully, have some
time.

Regards,
Chris

Re: [myhdl-list] VHDL Conversion Errors (was: Bug in generated code?)

[Angel E. <ang...@gm...>]

On Wed, Jan 23, 2013 at 3:38 AM, Christopher Felton
<chr...@gm...> wrote:
> On 1/20/13 6:01 AM, Norbo wrote:
>> This Code i think actually shows two glitches in the VHDL converter.
>> One was already discussed here, but i think it has been forgotten. This is
>> just to remember.
>> Here the link: http://permalink.gmane.org/gmane.comp.python.myhdl/2218
>>
>>
> <snip>
>>
>
> Let me try and summarize, we believe we have encountered
> three different VHDL conversion errors.
>
>     1. bitwise multiplication (there was the wider
>     question if the types were correct but since the ops
>     were invalid it was a moot point).
>
>     2. An odd intbv(val) == bool(val) comparison error,
>     python allows this check (what is the rule?) but when
>     converted the mixed types is not a valid comparison?
>
>     3. More than two operand math operations and resizing.
>
> On the #2 issues, since the MyHDL simulation != VHDL
> simulation, does this constitute an error, not sure?  I
> had a similar issue, I often used:
>
>         if reset:
>
> The myhdl simulation worked and Verilog conversion worked
> but the VHDL did not, the fix was to explicitly state:
>
>         if reset == False:
>
> Even though there was a simulation mismatch it was suggested
> that the "reset == False", is the desired form.  I am not sure
> if the mixed type comparison should be converted?  Instead, we
> probably want the converter to raise a conversion exception and
> not convert the code.

Personally I would really like if MyHDL was able to understand "if
boolean:" and even "if integer:" (intb, etc) types of "if statements".
That is a very common python coding style and it would be really nice
to be able to write MyHDL code that still feels as python. Besides I
am sure this is a common and easy mistake to make if do any regular
python programming.

Cheers,

Angel

[myhdl-list] VHDL Conversion Errors (was: Bug in generated code?)

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

On 1/20/13 6:01 AM, Norbo wrote:
> This Code i think actually shows two glitches in the VHDL converter.
> One was already discussed here, but i think it has been forgotten. This is
> just to remember.
> Here the link: http://permalink.gmane.org/gmane.comp.python.myhdl/2218
>
>
<snip>
>

Let me try and summarize, we believe we have encountered
three different VHDL conversion errors.

    1. bitwise multiplication (there was the wider
    question if the types were correct but since the ops
    were invalid it was a moot point).

    2. An odd intbv(val) == bool(val) comparison error,
    python allows this check (what is the rule?) but when
    converted the mixed types is not a valid comparison?

    3. More than two operand math operations and resizing.

On the #2 issues, since the MyHDL simulation != VHDL
simulation, does this constitute an error, not sure?  I
had a similar issue, I often used:

        if reset:

The myhdl simulation worked and Verilog conversion worked
but the VHDL did not, the fix was to explicitly state:

        if reset == False:

Even though there was a simulation mismatch it was suggested
that the "reset == False", is the desired form.  I am not sure
if the mixed type comparison should be converted?  Instead, we
probably want the converter to raise a conversion exception and
not convert the code.

Now, the best way to keep track of these so we don't loose
track of them?

Regards,
Chris

Re: [myhdl-list] Bug in generated code?

[Norbo <Nor...@gm...>]

This Code i think actually shows two glitches in the VHDL converter.
One was already discussed here, but i think it has been forgotten. This is  
just to remember.
Here the link: http://permalink.gmane.org/gmane.comp.python.myhdl/2218


       from myhdl import *
       from random import randrange

       def TOP(outvalue,sel_value):

	  @always_comb
	  def combi_sel():
	    outvalue.next=1
	    if sel_value == bool(0):
	      outvalue.next=8
	    elif sel_value == bool(1):
	      outvalue.next[0]=sel_value[2]*sel_value[0] #8  
#sel_value[0]+sel_value[0]
	
	  return combi_sel
	
	
       def test_bench():
	  outsignal=Signal(intbv(0)[4:])
	  sel_value=Signal(intbv(0)[4:])
	  ###### add the unit too be tested#######
	  instanc_top=TOP(outsignal,sel_value)
	
	  @instance
	  def stimulus():
	    sel_value.next=0
	    yield delay(10)
	    for i in range(sel_value.max):
		sel_value.next=i
		yield delay(10)
		print "sel_value: ",sel_value,"\toutsignal:", outsignal
		
	    raise StopSimulation
	
	
	  return  stimulus,instanc_top

	
       if __name__ == '__main__':
	
	  ############ Simulation ################
	  sim = Simulation(test_bench())
	  print "#"*10+"Simulation Started" + "#"*10
	  sim.run()
	  print "#"*10+"Simulation Finished" + "#"*10
	
	
	
	  ############### Conversion ###############
	  print "Conversion To VHDL Started" + "-"*30
	  outsignal=Signal(intbv(0)[4:])
	  sel_value=Signal(intbv(0)[4:])
	  toVHDL(TOP,outsignal,sel_value)



Conclusion:
Simulation works !!,
VHDL conversion result with 0.8 dev version:


       -- File: TOP.vhd
       -- Generated by MyHDL 0.8dev
       -- Date: Sun Jan 20 12:50:43 2013


       library IEEE;
       use IEEE.std_logic_1164.all;
       use IEEE.numeric_std.all;
       use std.textio.all;

       use work.pck_myhdl_08.all;

       entity TOP is
	  port (
	      outvalue: out unsigned(3 downto 0);
	      sel_value: in unsigned(3 downto 0)
	  );
       end entity TOP;


       architecture MyHDL of TOP is


       begin




       TOP_COMBI_SEL: process (sel_value) is
       begin
	  outvalue <= "0001";
	  if (sel_value = False) then
	      outvalue <= "1000";
	  elsif (sel_value = True) then
	      outvalue(0) <= stdl(to_unsigned(sel_value(2), 1) *  
to_unsigned(sel_value(0), 1));
	  end if;
       end process TOP_COMBI_SEL;

       end architecture MyHDL;



Issues:
* There is no compare operator for unsigned(x downto 0) with the False.
In Line: "if (sel_value = False) then"
* There is no Function stdl(arg: unsigned) which takes the unsigned in the  
pck_myhdl_08.
In Line: "outvalue(0) <= stdl(to_unsigned(sel_value(2), 1) *  
to_unsigned(sel_value(0), 1));"




greetings

Norbo

Re: [myhdl-list] Bug in generated code?

[Thomas H. <th...@ct...>]

Christopher,

I changed your tb_stim instance slightly so that it produces
more output on mismatch.

     def tb_stim():
         print('start')
         for aa in range(a.min, a.max):
             for bb in range(b.min, b.max):
                 for cc in range (c.min, c.max):
                     for dd in range(d.min, d.max):
                         a.next = aa
                         b.next = bb
                         c.next = cc
                         d.next = dd
                         yield delay(4)
                         if x != (aa+bb - (cc+dd)):
                             print "Error in", aa, bb, cc, dd
                             print "Is", x, "Should be", (aa+bb - (cc+dd))
##                        assert x == (aa+bb - (cc+dd))
         print('end')
         raise StopSimulation

     return tb_dut, tb_stim

The myhdl simulation still runs without any errors or output,
simulating the VHDL code in xilinx isim starts with this output:

Simulator is doing circuit initialization process.
start
Finished circuit initialization process.
Error in 0 0 1 63
Is 0 Should be -64
Error in 0 0 2 62
Is 0 Should be -64
Error in 0 0 2 63
Is -1 Should be -65
ISim>
# run 1.00us
Error in 0 0 3 61
Is 0 Should be -64
Error in 0 0 3 62
Is -1 Should be -65
Error in 0 0 3 63
Is -2 Should be -66
Error in 0 0 4 60
Is 0 Should be -64
Error in 0 0 4 61
Is -1 Should be -65
Error in 0 0 4 62
Is -2 Should be -66
Error in 0 0 4 63
Is -3 Should be -67

So, MyHDL and VHDL disagree.  Changing the expression in math_abcd()
makes isim and myhdl agree:

def math_abcd(a,b,c,d,x):
     @always_comb
     def hdl():
         x.next = a + b - c - d
     return hdl

Thomas

Re: [myhdl-list] Bug in generated code?

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

On 1/18/13 2:43 PM, Thomas Heller wrote:
> Am 18.01.2013 21:11, schrieb Tom Dillon:
>> Thanks for the education. I would have to say I have been coding with
>> MyHDL like a "Verilog die-hard". I have been resizing myself never
>> thinking MyHDL might do that for me.
>>
>> One question, does MyHDL produce an error in simulation if (c + d) > 255?
>
> No, the MyHDL simulation worked perfectly; but the hardware (compiled
> from toVHDL and loaded into a FPGA) produced wrong results.  It took
> me some time to find the reason.
>
> Maybe I should have simulated the VHDL code also, but I did not.
>

I put an example that runs the MyHDL, VHDL, and Verilog
simulations here:

https://bitbucket.org/cfelton/examples/src/tip/math/example_math.py

As discussed, the VHDL simulation will fail and the MyHDL
and Verilog do not.  This is a simulation mismatch and it
is an issue that needs to be resolved.

Some thoughts on the correction.  One approach would to
resize all the operands to match the type of the LHS?

Regards,
Chris

Re: [myhdl-list] Bug in generated code?

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

On 1/18/2013 2:43 PM, Thomas Heller wrote:
> Am 18.01.2013 21:11, schrieb Tom Dillon:
>> Thanks for the education. I would have to say I have been coding with
>> MyHDL like a "Verilog die-hard". I have been resizing myself never
>> thinking MyHDL might do that for me.
>>
>> One question, does MyHDL produce an error in simulation if (c + d) > 255?
>
> No, the MyHDL simulation worked perfectly; but the hardware (compiled
> from toVHDL and loaded into a FPGA) produced wrong results.  It took
> me some time to find the reason.
>
> Maybe I should have simulated the VHDL code also, but I did not.
>
<snip>

I started attempting to compare the MyHDL simulation
vs. the VHDL simulation, I put the following together:

     from myhdl import *

     def math_abcd(a,b,c,d,x):
         @always_comb
         def hdl():
             x.next = a + b - (c + d)
         return hdl

     def example_math():
         Omax = 64
         Xmin,Xmax = (-1*(Omax*4), Omax*4)
         x = Signal(intbv(0, min=Xmin, max=Xmax))
         a = Signal(intbv(0, min=0, max=Omax))
         b = Signal(intbv(0, min=0, max=Omax))
         c = Signal(intbv(0, min=0, max=Omax))
         d = Signal(intbv(0, min=0, max=Omax))
         tb_dut = math_abcd(a,b,c,d,x)
         @instance
         def tb_stim():
             print('start')
             for aa in range(a.min, a.max):
                 for bb in range(b.min, b.max):
                     for cc in range (c.min, c.max):
                         for dd in range(d.min, d.max):
                             a.next = aa
                             b.next = bb
                             c.next = cc
                             d.next = dd
                             yield delay(4)
                             assert x == (a+b - (c+d))
             print('end')
             raise StopSimulation

         return tb_dut, tb_stim

     if __name__ == '__main__':
         Simulation(example_math()).run()
         toVHDL(example_math)
         toVerilog(example_math)


The MyHDL simulation works fine (as expected) for
all inputs (I reduced the bit widths so it would
run faster).  I did not get time to run the sims
yet.  The converter will create the above simple
test cases, should be able to run the VHDL and
Verilog directly.  Not sure when I will have time to
complete this ...

Regards,
Chris

Re: [myhdl-list] Bug in generated code?

[Thomas H. <th...@ct...>]

Am 18.01.2013 21:11, schrieb Tom Dillon:
> Thanks for the education. I would have to say I have been coding with
> MyHDL like a "Verilog die-hard". I have been resizing myself never
> thinking MyHDL might do that for me.
>
> One question, does MyHDL produce an error in simulation if (c + d) > 255?

No, the MyHDL simulation worked perfectly; but the hardware (compiled
from toVHDL and loaded into a FPGA) produced wrong results.  It took
me some time to find the reason.

Maybe I should have simulated the VHDL code also, but I did not.

Let me describe the approach that I took in my work (in case this is
interesting to on this mailing list):

The goal of my FPGA is to find the x/y coordinates of a small light
point on a 4-quadrant photodiode.  The equations for this are:

x = (a+b) - (c+d) / (a+b+c+d)
y = (a+d) - (b+c) / (a+b+c+d)

where a, b, c, d are the digitized currents through the four quadrants
of the photodetector, and x and y are the final coordinates.

First, my fpga read the digitized intensity values and transfers them
to the PC.  The PC calculates the x/y values with the above formulas and
displays the result x1/y1.

Then, I wrote a MyHDL module which (with some pipelining) also
calculates these values.  I constructed a simulation object, and fed
the a,b,c,d values read from the fpga to the instance, simulated a few
timesteps, retrived the values as x2/y2 from the MyHDL instance and
displayed this result also.  They were the same as x1/y1.

Finally, I converted the MyHDL instances to VHDL, compiled and loaded 
into the FPGA, together with code that transferred the values calculated
in the FPGA also to the PC, as x3/y3.

So, all the values x1/y1, x2/y2, x3/y3 should be the same:  The first
calculated by Python code, the second by the MyHDL simulation, the third
by the hardware.

Unfortunately, most of the time x3/y3 (calculated by the FPGA) were
wrong until I fixed the paranthesis in the MyHDL code.

Thomas