Re: [myhdl-list] Synopsis of reported issues

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

On 2/24/13 2:47 PM, Jan Decaluwe wrote:
> Chris:
>
> Thanks for the work to summarize all this.
>
> I am definitely using the SourceForge bug tracker to keep
> track of things.
>
> What is most useful for fixing is to enter a bug report with a
> stanalone testcase. For conversion issues, the easiest
> is to use conversion.analyze or conversion.verify, which
> automatically compares MyHDL and generated Verilog/VHDL.

Absolutely, there were a couple issues that prevented me
from achieving this:

1. Currently, on my system with my version of GHDL
    conversion.analyze and conversion.verify does not
    work (0.7 and 0.8dev).  None of the VHDL conversion
    unit tests run successfully.  I have not investigated
    this but randomly noticed I had to remove the *_ghdl
    from the output name (-o %(*)s_ghdl).

2. I was triaging multiple issues and some required
    more than just the analyze and elaborate.  They
    needed to verify VHDL match the MyHDL behavior,
    currently this is more difficult with VHDL than
    Verilog.

Lastly, I ran out of time.  I had to make a decision
to create a ticket for the two issues I felt confident
were bugs, with what I had.

>
> I have solved issue 4 based on Thomas Hellers' example.
> I have used his example and entered it as bug #39 in the
> bug tracker. See the attached file for the test case - this
> will directly be used as a MyHDL unit test.
>
> /Probably/ this is the same as bug #38 that you created,
> however the provided test case didn't fail as indicated.
> I notice that you have other test cases - could you check
> whether the issue is solved and mark the bug as closed-fixed also,
> if so?

Yes, I did a poor job with issue #38 description, sorry about
that.

I did get your latest changes and my tests do not fail (i.e.
they pass).  I will change the ticket to "closed", as soon as
I figure out how to do so :)

Regards,
Chris

>
>
> On 02/02/2013 05:32 AM, Christopher Felton wrote:
>> Ok, there have been a burst of issues reported in the last couple
>> weeks.  I am trying to keep track of them, understand them,
>> and determine how severe the issues might be and possible
>> corrections.  All with the hope, to provide a clear definition
>> of the issues and help move things along.  Jan D. will have the
>> final say on all the issues.  There were two general simulation
>> and modeling issues and the rest were VHDL conversion failures.
>>
>>       1. Mixing /bool/ and /intbv/.  This is a new issues in
>>          0.8dev.  This may simply be a mid-feature collision?  The
>>          fix, I believe makes sense, is to cast (is that the correct
>>          Python terminology) the /val/ in /_SetNextBool/ to a
>>          /bool/ and to an /int/ in /_SetNextInt/.  This will
>>          prevent the /Signal/ type (/val/) from changing.
>>
>>          I can submit a patch for these changes but I will wait
>>          to see if the 0.8dev changes are in a final form [1].
>>
>>
>>       2. The "bound check race condition".  This is the error that
>>          arises from an /intbv/ bound check on a delta cycle,
>>          essentially an *assertion*.  Complex descriptions might
>>          have invalid delta cycle values (everything cannot be
>>          updated simultaneous).  Per K., which I agree, correctly
>>          identified that the bound check should be deferred to the
>>          end of the simulation step (after all delta-cycles).
>>
>>          I have some ideas (I am sure Jan D. has the solution :) )
>>          and I can proposed an enhancement in a seprate thread, it
>>          could get involved.
>>
>>       3. The following fails in VHDL conversion:
>>          x = Signal(intbv(0, min=0, max=8))
>>          y = Signal(intbv(0, min=0, max=8))
>>          z = Signal(bool(0))
>>
>>          @always ...
>>              z.next = x[0] * y[0]
>>
>>          The bit-operation "castings" might need some looking at?
>>          The tests could use some updating to cover lots of these
>>          cases.
>>
>>       4. More than two right hand side operands fail VHDL
>>          conversion if the operands are mixed sizes:
>>             ...
>>             z.next = a + b + c
>>
>>          Thomas Heller, pointed out this issue and reinforced that
>>          MyHDL has the design goal to handle the sizing and typing.
>>
>>       5. Possible enhancment, VHDL conversion fails for an edge
>>          sensitive conditional for the following cases:
>>          It was indicated the following (at least 2) worked in
>>          previous versions.  Need to verify this and determine
>>          what might changed for edge sensitive conditionals.
>>             2. if sig == False
>>             3. if sig == intbv(0)
>>
>>          And I am not convinced that /if not sig/ should not be
>>          supported.  It is acceptable (as shown in the mailing
>>          list) for non edge sensitve signals.  Why the limitation
>>          for edge sensitive signals in VHDL conversion.
>>
>>       6. Older issue that was identified as a bug, for modeling
>>          only, attributes fail to be added to the sensitivty list
>>          in /always_comb/ generators.
>>
>>
>> I have tests for all of these in a bitbucket repo [2].
>>
>> Thanks to everyone for reporting the issues and being patient
>> as we figure them out.  I was mistaken, it looks like Jan D.
>> has been actively using the sourceforge tracking [3] so I will
>> start adding the above to the bug list.
>>
>> Regards,
>> Chris
>>
>> [1]
>> https://bitbucket.org/cfelton/myhdl_dev/src/tip/myhdl/_Signal.py?at=0.8-dev#cl-260
>>
>> [2] https://bitbucket.org/cfelton/myhdl_tests
>>
>> [3] http://sourceforge.net/tracker/?atid=596332&group_id=91207&func=browse
>>
>>
>>
>> ------------------------------------------------------------------------------
>> Everyone hates slow websites. So do we.
>> Make your web apps faster with AppDynamics
>> Download AppDynamics Lite for free today:
>> http://p.sf.net/sfu/appdyn_d2d_jan
>>
>
>