myhdl-list — Mailing list for discussions on MyHDL

Re: [myhdl-list] Wait within @always()

[Ben <ben...@gm...>]

On Wed, Aug 3, 2011 at 09:50, Uri Nix <ur...@gm...> wrote:
> Hi,
>
> I'm using MyHDL to model a FSM, and would like to wait/delay the state
> transitions, something like this:
>
> @always(clk.posedge)
>  def logic():
>     if state == t_State.ONE:
>         state.next = t_State.TWO
>         # wait for something comparable to myhdl.delay(x)
>     ...
>
> If I understand correctly, this would require changing the function's
> sensitivity list dynamically - is it possible?
> I'd prefer to keep using the @always() pattern instead of yielding
> explicitly.
>

You can achieve something similar by using a DelayedSignal instead of
a standard Signal. The drawback is that every next on this signal will
be delayed. You just have to specify a "delay" value while defining
your signal. I'm not sure this is documented, look at the code if in
doubt.

Regards,
Benoit

[myhdl-list] Wait within @always()

[Uri N. <ur...@gm...>]

Hi,

I'm using MyHDL to model a FSM, and would like to wait/delay the state
transitions, something like this:

@always(clk.posedge)
 def logic():
    if state == t_State.ONE:
        state.next = t_State.TWO
        # wait for something comparable to myhdl.delay(x)
    ...

If I understand correctly, this would require changing the function's
sensitivity list dynamically - is it possible?
I'd prefer to keep using the @always() pattern instead of yielding
explicitly.

Cheers,
Uri

Re: [myhdl-list] A Reviewers Thoughts ...

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

On 7/25/11 3:28 AM, Angel Ezquerra wrote:
> On Fri, Jul 22, 2011 at 10:36 PM, Christopher Felton
> <chr...@gm...>  wrote:
>> <snip>
>>>
>>> Again, I am not trying to argue if in-system debugging is useful or not
>>> but instead arguing that including in-system debugging in the design is
>>> a better approach.  Which removes the need to add probes to the
>>> post-P&R.  And such, minimizes the argument that the flat file
>>> conversion is a negative.
>>>
>>>
>>> Chris
>>>
>>
>> Thinking about this a little more, one possible downside, I can think
>> of, is how a flat hierarchy might effect floor-planning.  Some FPGA and
>> IC designs might want (require) floor-planning*.  But I am not really
>> sure of this either because the blocks are named blocks and the tools
>> might be able to handle this as well.
>>
>> Chris
>>
>> * Floor-planning is a "flow" to guide the P&R (place-and-route) tools by
>> defining physical constraints.  Often this is done by indicating a
>> region for placement of a block, often a major block.
>
> Actually that is one of the things taht I meant to say on my first
> email on this thread, when I said that keeping the hierarchy "can lead
> to more predictable synthesis", but I should have said floor planning
> rather than synthesis.
>
> Angel
>

I should have said *manual* floor-planning.  I my experience I don't 
think it effects auto P&R, much.

Chris

Re: [myhdl-list] A Reviewers Thoughts ...

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

On Fri, Jul 22, 2011 at 10:36 PM, Christopher Felton
<chr...@gm...> wrote:
> <snip>
>>
>> Again, I am not trying to argue if in-system debugging is useful or not
>> but instead arguing that including in-system debugging in the design is
>> a better approach.  Which removes the need to add probes to the
>> post-P&R.  And such, minimizes the argument that the flat file
>> conversion is a negative.
>>
>>
>> Chris
>>
>
> Thinking about this a little more, one possible downside, I can think
> of, is how a flat hierarchy might effect floor-planning.  Some FPGA and
> IC designs might want (require) floor-planning*.  But I am not really
> sure of this either because the blocks are named blocks and the tools
> might be able to handle this as well.
>
> Chris
>
> * Floor-planning is a "flow" to guide the P&R (place-and-route) tools by
> defining physical constraints.  Often this is done by indicating a
> region for placement of a block, often a major block.

Actually that is one of the things taht I meant to say on my first
email on this thread, when I said that keeping the hierarchy "can lead
to more predictable synthesis", but I should have said floor planning
rather than synthesis.

Angel

[myhdl-list] Jan Decaluwe's Blog @ Sigasi

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

Be sure to check out Jan's blog, good stuff.

http://www.sigasi.com/content/wasting-real-time-zero-time

Chris

Re: [myhdl-list] A Reviewers Thoughts ...

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

<snip>
>
> Again, I am not trying to argue if in-system debugging is useful or not
> but instead arguing that including in-system debugging in the design is
> a better approach.  Which removes the need to add probes to the
> post-P&R.  And such, minimizes the argument that the flat file
> conversion is a negative.
>
>
> Chris
>

Thinking about this a little more, one possible downside, I can think 
of, is how a flat hierarchy might effect floor-planning.  Some FPGA and 
IC designs might want (require) floor-planning*.  But I am not really 
sure of this either because the blocks are named blocks and the tools 
might be able to handle this as well.

Chris

* Floor-planning is a "flow" to guide the P&R (place-and-route) tools by 
defining physical constraints.  Often this is done by indicating a 
region for placement of a block, often a major block.

Re: [myhdl-list] MyHDL / ModelSim cosim

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

Many months later ...

Attached is the patch for the modelsim memory leak issues.  Created a 
separate directory and Makefile for modelsim.

General modelsim items:
   When (if) running the cosimulation unittests make sure to
   first build the shared library and copy to the test directory.
   Then execute the following two modelsim commands

   >> vlib work
   >> vmap work work

If the above are not executed errors will ensue.

{plug for my friends, I have been transitioning to CVC instead of 
modelsim and all is working well and faster (thus far).  But I had these 
changes laying around so I thought I would share them for other modelsim 
users}.

Regards,
Chris Felton

On 5/6/11 2:37 PM, Jan Decaluwe wrote:
> On 05/05/2011 02:48 PM, Christopher Felton wrote:
>> There was an old thread (last post 31 May 2005, same subject line) that
>> addressed a memory leak in Modelsim which also occurred in cver and
>> Icarus.  I don't know if this was resolved but the issue still exists in
>> the current releases with Modelsim.
>>
>> In a cosimulations that I was running a simulation would exceed 10GB of
>> resident memory usage.  And the simulation would crawl along when this
>> occurred.
>>
>> The fix was to release the handles created by vpi_scan, example
>>
>> ~~~~~~~~~~~ Code Snip ~~~~~~~~~~~~~~~~~~
>> // ~line 416 of myhdl_vpi.c
>> while ((value_s.value.str = strtok(NULL, " ")) != NULL) {
>>        reg_handle = vpi_scan(reg_iter);
>>        vpi_put_value(reg_handle,&value_s, NULL, vpiNoDelay);
>>        vpi_free_object(reg_handle);  // **<-- Added line
>> }
>> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
>>
>> This had to be added in four spots (~line 125, 198, 301, 416).  The
>> reg_handle and net_handle in the reg and net iterator loops had to be
>> released for each object retrieved (at least for modelsim).  After this
>> change my memory usage top out at 222MB (no more leak).
>>
>> I did not create a patch because I didn't have time to regression test
>> cver and Icarus.
>>
>> I can provide a patch if desired.  Should a separate directory and
>> myhdl_vpi.c and Makefile be created for mti in the Cosimulation directory?
>
> Yes, that's the right way, and thanks for debugging this.
>
>
>

Re: [myhdl-list] A Reviewers Thoughts ...

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

On 7/11/11 3:29 AM, Angel Ezquerra Moreu wrote:
> On Sun, Jul 10, 2011 at 8:54 PM, Christopher Felton
> <chr...@gm...>  wrote:
>> On 7/8/11 12:41 AM, Angel Ezquerra wrote:
>>> On Fri, Jul 8, 2011 at 6:54 AM, Christopher Felton
>>> <chr...@gm...>    wrote:
>>>> I have stumbled upon this presentation a couple times;
>>>>
>>>> http://seti.berkeley.edu/sites/default/files/gordon_casper_myhdl_presentation.pdf.
>>>>
>>>> The last slide is interesting, it is the brief summary of the author's
>>>> concluding strengths and weaknesses of MyHDL.
>>>>
>>>> Strengths
>>>> -----------
>>>>    * The power of Python
>>>>      * Supporting Libraries
>>>>      * Flexibility
>>>>
>>>>    * Fast accurate functional simulations
>>>>
>>>> Weaknesses
>>>> ------------
>>>>    * Flat Conversion
>>>>
>>>>    * Limited Datatypes
>>>>
>>>>    * Manual Process
>>>>
>>>>
>>>> I am surprised to see the "Flat Conversion" protested frequently.  I
>>>> have not found this to be a weakness of any kind.  Have others found
>>>> this to be a weakness?
>>>
>>> Well, I am definitely not a power user of MyHDL, but I recently
>>> attended a training course for Xilinx tools and one thing that we
>>> learned is that it is possible to tell the synthesizer to "keep the
>>> hierarchy" for a given (or all) module(s). Apparently this can lead to
>>> more predictable synthesis. Also this makes sure that the module
>>> interface signals are not lost during the synthesis/traslate/map
>>> process, which makes it easier to add probes (e.g. a ChipScope) that
>>> peek on those signals.
>>>
>>> Angel
>>>
>>
>> Thanks for for the comments!  I am curious because this "item" seems to
>> appear from time to time.  The following is my rebuttal to the case you
>> mentioned.
>>
>> At least so far, the main argument is that minimal signal/variable/net
>> obfuscation is desired for downstream debugging.  In other-words the
>> Designers want to identify "things" from the original design entry in
>> the targeted implementation (in a FPGA the synthesized-P&R circuit).  To
>> me this is really a bigger question.  What is the most efficient
>> verification (debug) method.
>>
>> I think others would agree, in MyHDL with all the power of Python,
>> building a robust verification environment is reasonable.  This would
>> minimize the requirement to do in system debugging.  The need to
>> identify a net in a post P&R circuit to attach debug probes shouldn't be
>> required (chip-scope or signal-tap).  Or at least, the in-circuit
>> "probing", avoided because it is a more difficult method to debug.  Not
>> because of net obfusction but because less is available at run time:
>> less visibility, limited number of probes, can be harder to inject error
>> scenarios, etc.
>>
>> In some cases (in my opinion they are rare) you may want to do in system
>> debugging / verification.  In this scenario, it is usually because some
>> interface is poorly defined and you need to see how it is acting.  But
>> in my mind, this is something that is designed in (DFM approach) and not
>> an after-thought.  Meaning that you don't realize you need to attach
>> probes until it doesn't work and don't want to re-P&R.
>>
>> I guess, in my mind this isn't an issue of flat design versus a
>> preserved hierarchy design.  But rather the difference between the best
>> verification/debug approach
>>
>> Regards,
>> Chris
>
> Chris,
>
> this is certainly a very good point, but even if rare, there are still
> occasions in which even with a very robust verification system you may
> still need to do "downstream debugging".
>
> For example, we work with systems whose inputs are non deterministic.
> It is quite hard to create a reasonable number of test vectors that
> cover all scenarios. So sometimes you must peek at the system as it is
> running in order to understand why it is not working as expected.
>
> Angel

I think my point was missed, it wasn't the fact that downstream / 
in-system debugging is beneficial or not but rather that the need for 
*unexpected* downstream debugging can be adverted.  And how this relates 
to the generated "flat" file.

Again, I am not trying to argue if in-system debugging is useful or not 
but instead arguing that including in-system debugging in the design is 
a better approach.  Which removes the need to add probes to the 
post-P&R.  And such, minimizes the argument that the flat file 
conversion is a negative.


Chris

Re: [myhdl-list] A Reviewers Thoughts ...

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

On Sun, Jul 10, 2011 at 8:54 PM, Christopher Felton
<chr...@gm...> wrote:
> On 7/8/11 12:41 AM, Angel Ezquerra wrote:
>> On Fri, Jul 8, 2011 at 6:54 AM, Christopher Felton
>> <chr...@gm...>  wrote:
>>> I have stumbled upon this presentation a couple times;
>>>
>>> http://seti.berkeley.edu/sites/default/files/gordon_casper_myhdl_presentation.pdf.
>>>
>>> The last slide is interesting, it is the brief summary of the author's
>>> concluding strengths and weaknesses of MyHDL.
>>>
>>> Strengths
>>> -----------
>>>   * The power of Python
>>>     * Supporting Libraries
>>>     * Flexibility
>>>
>>>   * Fast accurate functional simulations
>>>
>>> Weaknesses
>>> ------------
>>>   * Flat Conversion
>>>
>>>   * Limited Datatypes
>>>
>>>   * Manual Process
>>>
>>>
>>> I am surprised to see the "Flat Conversion" protested frequently.  I
>>> have not found this to be a weakness of any kind.  Have others found
>>> this to be a weakness?
>>
>> Well, I am definitely not a power user of MyHDL, but I recently
>> attended a training course for Xilinx tools and one thing that we
>> learned is that it is possible to tell the synthesizer to "keep the
>> hierarchy" for a given (or all) module(s). Apparently this can lead to
>> more predictable synthesis. Also this makes sure that the module
>> interface signals are not lost during the synthesis/traslate/map
>> process, which makes it easier to add probes (e.g. a ChipScope) that
>> peek on those signals.
>>
>> Angel
>>
>
> Thanks for for the comments!  I am curious because this "item" seems to
> appear from time to time.  The following is my rebuttal to the case you
> mentioned.
>
> At least so far, the main argument is that minimal signal/variable/net
> obfuscation is desired for downstream debugging.  In other-words the
> Designers want to identify "things" from the original design entry in
> the targeted implementation (in a FPGA the synthesized-P&R circuit).  To
> me this is really a bigger question.  What is the most efficient
> verification (debug) method.
>
> I think others would agree, in MyHDL with all the power of Python,
> building a robust verification environment is reasonable.  This would
> minimize the requirement to do in system debugging.  The need to
> identify a net in a post P&R circuit to attach debug probes shouldn't be
> required (chip-scope or signal-tap).  Or at least, the in-circuit
> "probing", avoided because it is a more difficult method to debug.  Not
> because of net obfusction but because less is available at run time:
> less visibility, limited number of probes, can be harder to inject error
> scenarios, etc.
>
> In some cases (in my opinion they are rare) you may want to do in system
> debugging / verification.  In this scenario, it is usually because some
> interface is poorly defined and you need to see how it is acting.  But
> in my mind, this is something that is designed in (DFM approach) and not
> an after-thought.  Meaning that you don't realize you need to attach
> probes until it doesn't work and don't want to re-P&R.
>
> I guess, in my mind this isn't an issue of flat design versus a
> preserved hierarchy design.  But rather the difference between the best
> verification/debug approach
>
> Regards,
> Chris

Chris,

this is certainly a very good point, but even if rare, there are still
occasions in which even with a very robust verification system you may
still need to do "downstream debugging".

For example, we work with systems whose inputs are non deterministic.
It is quite hard to create a reasonable number of test vectors that
cover all scenarios. So sometimes you must peek at the system as it is
running in order to understand why it is not working as expected.

Angel

Re: [myhdl-list] A Reviewers Thoughts ...

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

On 7/8/11 12:41 AM, Angel Ezquerra wrote:
> On Fri, Jul 8, 2011 at 6:54 AM, Christopher Felton
> <chr...@gm...>  wrote:
>> I have stumbled upon this presentation a couple times;
>>
>> http://seti.berkeley.edu/sites/default/files/gordon_casper_myhdl_presentation.pdf.
>>
>> The last slide is interesting, it is the brief summary of the author's
>> concluding strengths and weaknesses of MyHDL.
>>
>> Strengths
>> -----------
>>   * The power of Python
>>     * Supporting Libraries
>>     * Flexibility
>>
>>   * Fast accurate functional simulations
>>
>> Weaknesses
>> ------------
>>   * Flat Conversion
>>
>>   * Limited Datatypes
>>
>>   * Manual Process
>>
>>
>> I am surprised to see the "Flat Conversion" protested frequently.  I
>> have not found this to be a weakness of any kind.  Have others found
>> this to be a weakness?
>
> Well, I am definitely not a power user of MyHDL, but I recently
> attended a training course for Xilinx tools and one thing that we
> learned is that it is possible to tell the synthesizer to "keep the
> hierarchy" for a given (or all) module(s). Apparently this can lead to
> more predictable synthesis. Also this makes sure that the module
> interface signals are not lost during the synthesis/traslate/map
> process, which makes it easier to add probes (e.g. a ChipScope) that
> peek on those signals.
>
> Angel
>

Thanks for for the comments!  I am curious because this "item" seems to 
appear from time to time.  The following is my rebuttal to the case you 
mentioned.

At least so far, the main argument is that minimal signal/variable/net 
obfuscation is desired for downstream debugging.  In other-words the 
Designers want to identify "things" from the original design entry in 
the targeted implementation (in a FPGA the synthesized-P&R circuit).  To 
me this is really a bigger question.  What is the most efficient 
verification (debug) method.

I think others would agree, in MyHDL with all the power of Python, 
building a robust verification environment is reasonable.  This would 
minimize the requirement to do in system debugging.  The need to 
identify a net in a post P&R circuit to attach debug probes shouldn't be 
required (chip-scope or signal-tap).  Or at least, the in-circuit 
"probing", avoided because it is a more difficult method to debug.  Not 
because of net obfusction but because less is available at run time: 
less visibility, limited number of probes, can be harder to inject error 
scenarios, etc.

In some cases (in my opinion they are rare) you may want to do in system 
debugging / verification.  In this scenario, it is usually because some 
interface is poorly defined and you need to see how it is acting.  But 
in my mind, this is something that is designed in (DFM approach) and not 
an after-thought.  Meaning that you don't realize you need to attach 
probes until it doesn't work and don't want to re-P&R.

I guess, in my mind this isn't an issue of flat design versus a 
preserved hierarchy design.  But rather the difference between the best 
verification/debug approach

Regards,
Chris

Re: [myhdl-list] A Reviewers Thoughts ...

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

On Fri, Jul 8, 2011 at 6:54 AM, Christopher Felton
<chr...@gm...> wrote:
> I have stumbled upon this presentation a couple times;
>
> http://seti.berkeley.edu/sites/default/files/gordon_casper_myhdl_presentation.pdf.
>
> The last slide is interesting, it is the brief summary of the author's
> concluding strengths and weaknesses of MyHDL.
>
> Strengths
> -----------
>  * The power of Python
>    * Supporting Libraries
>    * Flexibility
>
>  * Fast accurate functional simulations
>
> Weaknesses
> ------------
>  * Flat Conversion
>
>  * Limited Datatypes
>
>  * Manual Process
>
>
> I am surprised to see the "Flat Conversion" protested frequently.  I
> have not found this to be a weakness of any kind.  Have others found
> this to be a weakness?

Well, I am definitely not a power user of MyHDL, but I recently
attended a training course for Xilinx tools and one thing that we
learned is that it is possible to tell the synthesizer to "keep the
hierarchy" for a given (or all) module(s). Apparently this can lead to
more predictable synthesis. Also this makes sure that the module
interface signals are not lost during the synthesis/traslate/map
process, which makes it easier to add probes (e.g. a ChipScope) that
peek on those signals.

Angel

Re: [myhdl-list] pypy test_all.py

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

On 7/5/11 5:22 AM, Bob Cunningham wrote:
>
>
> On 07/05/2011 01:26 AM, Bob Cunningham wrote:
>> On 07/05/2011 01:00 AM, Jan Decaluwe wrote:
>>> On 07/05/2011 07:06 AM, Bob Cunningham wrote:
>>>> I just downloaded and installed MyHDL 0.7 and pypy under Fedora 15.
>>>>
>>>> I first did the install using python, and "python test_all.py" ran without correctly.
>>>>
>>>> I repeated the install using pypy, and "pypy test_all.py" ran with 4 errors and 1 fail.
>>>> Are these failures expected for the current versions of MyHDL and pypy?
>>> http://myhdl.org/doku.php/performance#installation_hints_and_known_issues
>>>
>> Is there a known pypy nightly build that passes test_all.py
>
> I just cloned the pypy repository and built the pypy tip (and found a new love for the ASCII Mandelbrot).  Though there were a gazillion warnings, the build completed.  I ran the following:
>
>       $ ./pypy-c
>       Python 2.7.1 (2630c86662b4, Jul 05 2011, 08:25:11)
>       [PyPy 1.5.0-alpha0 with GCC 4.6.0] on linux2
>       Type "help", "copyright", "credits" or "license" for more information.
>       And now for something completely different: ``- how will the fact that they are
>       used in our repl change our topics?''
>   >>>>  46 - 4
>       42
>   >>>>  from test import pystone
>   >>>>  pystone.main()
>       Pystone(1.1) time for 50000 passes = 0.381942
>       This machine benchmarks at 130910 pystones/second
>
> So the new pypy-c is at least minimally functional.
>
> Next, I manually installed myhdl for the new pypy-c executable, without error.
>
> Then I ran "pypy-c test_all.py".  The pypy-c executable itself died during the first test, so the current pypy tip appears to be broken.  (Of course, I could be doing something wrong...)
>
> -BobC
>

I think you would need a pypy 1.5.1 variant (I could be wrong) that 
would include the fix for the conversion and traceSignal functions.

I believe most have used the version (binaries supplied) that Jan D. 
mentions in his write-up.  And simply avoid using the conversion 
(toVerilog, toVHDL) and the traceSignal functions.  If you have both 
cpython and pypy you can work around the issue till the next pypy 
release.  Use pypy for the simulations and cpython for conversion.

Hope that helps,
Chris

[myhdl-list] A Reviewers Thoughts ...

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

I have stumbled upon this presentation a couple times;

http://seti.berkeley.edu/sites/default/files/gordon_casper_myhdl_presentation.pdf.

The last slide is interesting, it is the brief summary of the author's 
concluding strengths and weaknesses of MyHDL.

Strengths
-----------
  * The power of Python
    * Supporting Libraries
    * Flexibility

  * Fast accurate functional simulations

Weaknesses
------------
  * Flat Conversion

  * Limited Datatypes

  * Manual Process


I am surprised to see the "Flat Conversion" protested frequently.  I 
have not found this to be a weakness of any kind.  Have others found 
this to be a weakness?

Just curious,
Chris

Re: [myhdl-list] pypy test_all.py

[Bob C. <Fl...@gm...>]

On 07/05/2011 01:26 AM, Bob Cunningham wrote:
> On 07/05/2011 01:00 AM, Jan Decaluwe wrote:
>> On 07/05/2011 07:06 AM, Bob Cunningham wrote:
>>> I just downloaded and installed MyHDL 0.7 and pypy under Fedora 15.
>>>
>>> I first did the install using python, and "python test_all.py" ran without correctly.
>>>
>>> I repeated the install using pypy, and "pypy test_all.py" ran with 4 errors and 1 fail.
>>> Are these failures expected for the current versions of MyHDL and pypy?
>> http://myhdl.org/doku.php/performance#installation_hints_and_known_issues
>>
> Is there a known pypy nightly build that passes test_all.py

I just cloned the pypy repository and built the pypy tip (and found a new love for the ASCII Mandelbrot).  Though there were a gazillion warnings, the build completed.  I ran the following:

     $ ./pypy-c
     Python 2.7.1 (2630c86662b4, Jul 05 2011, 08:25:11)
     [PyPy 1.5.0-alpha0 with GCC 4.6.0] on linux2
     Type "help", "copyright", "credits" or "license" for more information.
     And now for something completely different: ``- how will the fact that they are
     used in our repl change our topics?''
 >>>> 46 - 4
     42
 >>>> from test import pystone
 >>>> pystone.main()
     Pystone(1.1) time for 50000 passes = 0.381942
     This machine benchmarks at 130910 pystones/second

So the new pypy-c is at least minimally functional.

Next, I manually installed myhdl for the new pypy-c executable, without error.

Then I ran "pypy-c test_all.py".  The pypy-c executable itself died during the first test, so the current pypy tip appears to be broken.  (Of course, I could be doing something wrong...)

-BobC

Re: [myhdl-list] pypy test_all.py

[Shakthi K. <sha...@gm...>]

Hi,

--- On Tue, Jul 5, 2011 at 1:30 PM, Jan Decaluwe <ja...@ja...> wrote:
| http://myhdl.org/doku.php/performance#installation_hints_and_known_issues
\--

So, I shall wait for PyPy 1.5.1 to be pushed to Fedora. At present
PyPy 1.5 is available from Fedora 15 onwards. But, python-myhdl is
available in Fedora 14 as well.

SK

-- 
Shakthi Kannan
http://www.shakthimaan.com

Re: [myhdl-list] pypy test_all.py

[Bob C. <Fl...@gm...>]

On 07/05/2011 01:00 AM, Jan Decaluwe wrote:
> On 07/05/2011 07:06 AM, Bob Cunningham wrote:
>> I just downloaded and installed MyHDL 0.7 and pypy under Fedora 15.
>>
>> I first did the install using python, and "python test_all.py" ran without correctly.
>>
>> I repeated the install using pypy, and "pypy test_all.py" ran with 4 errors and 1 fail.
>> Are these failures expected for the current versions of MyHDL and pypy?
> http://myhdl.org/doku.php/performance#installation_hints_and_known_issues
>

Is there a known pypy nightly build that passes test_all.py?

-BobC

Re: [myhdl-list] pypy test_all.py

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

On 07/05/2011 07:06 AM, Bob Cunningham wrote:
> I just downloaded and installed MyHDL 0.7 and pypy under Fedora 15.
>
> I first did the install using python, and "python test_all.py" ran without correctly.
>
> I repeated the install using pypy, and "pypy test_all.py" ran with 4 errors and 1 fail.

> Are these failures expected for the current versions of MyHDL and pypy?

http://myhdl.org/doku.php/performance#installation_hints_and_known_issues

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

Re: [myhdl-list] pypy test_all.py

[Bob C. <Fl...@gm...>]

On 07/05/2011 12:11 AM, Bob Cunningham wrote:
> On 07/04/2011 11:57 PM, Shakthi Kannan wrote:
>> Hi,
>>
>> --- On Tue, Jul 5, 2011 at 12:23 PM, Bob Cunningham<Fl...@gm...>   wrote:
>> | I did a manual install because I assumed the package would not install MyHDL
>> | for pypy, and I want python and pypy to be the same.
>> \--
>>
>> Okay.
>>
>> ---
>> | Plus, I assumed the download from the MyHDL site would be the latest&
>> | greatest.
>> \--
>>
>> I packed and pushed MyHDL to Fedora/RHEL repos recently. I will try to
>> push the latest and greatest as they are released.
>>
>> SK
>>
> Great!  Thank-you for being a package maintainer!
>
> Any problem with simply soft-linking the python-myhdl install over to pypy?
>
> -BobC
I removed my manual install and installed the python-myhdl package, then soft-linked it to pypy.

I noticed that the package install did not include all the files present in the download from the MyHDL site: The test directory is omitted.  Perhaps those files could be installed in /opt?

I reran test_all.py and got the same results: No python errors, 4 pypy errors.

So, back to the original question:  Does anyone know why these errors occur with pypy, and are they expected?

-BobC

Re: [myhdl-list] pypy test_all.py

[Bob C. <Fl...@gm...>]

On 07/04/2011 11:57 PM, Shakthi Kannan wrote:
> Hi,
>
> --- On Tue, Jul 5, 2011 at 12:23 PM, Bob Cunningham<Fl...@gm...>  wrote:
> | I did a manual install because I assumed the package would not install MyHDL
> | for pypy, and I want python and pypy to be the same.
> \--
>
> Okay.
>
> ---
> | Plus, I assumed the download from the MyHDL site would be the latest&
> | greatest.
> \--
>
> I packed and pushed MyHDL to Fedora/RHEL repos recently. I will try to
> push the latest and greatest as they are released.
>
> SK
>
Great!  Thank-you for being a package maintainer!

Any problem with simply soft-linking the python-myhdl install over to pypy?

-BobC

Re: [myhdl-list] pypy test_all.py

[Shakthi K. <sha...@gm...>]

Hi,

--- On Tue, Jul 5, 2011 at 12:23 PM, Bob Cunningham <Fl...@gm...> wrote:
| I did a manual install because I assumed the package would not install MyHDL
| for pypy, and I want python and pypy to be the same.
\--

Okay.

---
| Plus, I assumed the download from the MyHDL site would be the latest &
| greatest.
\--

I packed and pushed MyHDL to Fedora/RHEL repos recently. I will try to
push the latest and greatest as they are released.

SK

-- 
Shakthi Kannan
http://www.shakthimaan.com

Re: [myhdl-list] pypy test_all.py

[Bob C. <Fl...@gm...>]

On 07/04/2011 11:05 PM, Shakthi Kannan wrote:
> Hi,
>
> --- On Tue, Jul 5, 2011 at 10:36 AM, Bob Cunningham<rcu...@ac...>  wrote:
> | I just downloaded and installed MyHDL 0.7 and pypy under Fedora 15.
> |
> | I first did the install using python,
> \--
>
> A manual installation using setup.py? MyHDL is available in Fedora as
> python-myhdl:
>
>    $ sudo yum install python-myhdl
>
> SK

I did a manual install because I assumed the package would not install MyHDL for pypy, and I want python and pypy to be the same.

Plus, I assumed the download from the MyHDL site would be the latest & greatest.

Were my assumptions wrong?

-BobC

Re: [myhdl-list] pypy test_all.py

[Shakthi K. <sha...@gm...>]

Hi,

--- On Tue, Jul 5, 2011 at 10:36 AM, Bob Cunningham <rcu...@ac...> wrote:
| I just downloaded and installed MyHDL 0.7 and pypy under Fedora 15.
|
| I first did the install using python,
\--

A manual installation using setup.py? MyHDL is available in Fedora as
python-myhdl:

  $ sudo yum install python-myhdl

SK

-- 
Shakthi Kannan
http://www.shakthimaan.com

[myhdl-list] pypy test_all.py

[Bob C. <rcu...@ac...>]

I just downloaded and installed MyHDL 0.7 and pypy under Fedora 15.

I first did the install using python, and "python test_all.py" ran without correctly.

I repeated the install using pypy, and "pypy test_all.py" ran with 4 errors and 1 fail.

The diff of the two runs is:

> $ diff python_test_all.out pypy_test_all.out
> 284,288c284,288
> < testBackupOutputFile (test_traceSignals.TestTraceSigs) ... ok
> < testHierarchicalTrace1 (test_traceSignals.TestTraceSigs) ... ok
> < testHierarchicalTrace2 (test_traceSignals.TestTraceSigs) ... ok
> < testMultipleTraces (test_traceSignals.TestTraceSigs) ... ok
> < testReturnVal (test_traceSignals.TestTraceSigs) ... ok
> ---
>> testBackupOutputFile (test_traceSignals.TestTraceSigs) ... ERROR
>> testHierarchicalTrace1 (test_traceSignals.TestTraceSigs) ... ERROR
>> testHierarchicalTrace2 (test_traceSignals.TestTraceSigs) ... ERROR
>> testMultipleTraces (test_traceSignals.TestTraceSigs) ... ERROR
>> testReturnVal (test_traceSignals.TestTraceSigs) ... FAIL
> 349a350,351
>> ======================================================================
>> ERROR: testBackupOutputFile (test_traceSignals.TestTraceSigs)
> 351c353,360
> < Ran 285 tests in 32.085s
> ---
>> Traceback (most recent call last):
>>   File "/home/bobc/Download/AlienCortex/HDL/MyHDL/myhdl-0.7/myhdl/test/core/test_traceSignals.py", line 143, in testBackupOutputFile
>>     dut = traceSignals(fun)
>>   File "/usr/lib/pypy-1.5/site-packages/myhdl/_traceSignals.py", line 76, in __call__
>>     h = _HierExtr(name, dut, *args, **kwargs)
>>   File "/usr/lib/pypy-1.5/site-packages/myhdl/_extractHierarchy.py", line 231, in __init__
>>     raise ExtractHierarchyError(_error.NoInstances)
>> ExtractHierarchyError: No instances found
> 353c362,413
> < OK
> ---
>> ======================================================================
>> ERROR: testHierarchicalTrace1 (test_traceSignals.TestTraceSigs)
>> ----------------------------------------------------------------------
>> Traceback (most recent call last):
>>   File "/home/bobc/Download/AlienCortex/HDL/MyHDL/myhdl-0.7/myhdl/test/core/test_traceSignals.py", line 131, in testHierarchicalTrace1
>>     top()
>>   File "/home/bobc/Download/AlienCortex/HDL/MyHDL/myhdl-0.7/myhdl/test/core/test_traceSignals.py", line 59, in top
>>     inst = traceSignals(fun)
>>   File "/usr/lib/pypy-1.5/site-packages/myhdl/_traceSignals.py", line 76, in __call__
>>     h = _HierExtr(name, dut, *args, **kwargs)
>>   File "/usr/lib/pypy-1.5/site-packages/myhdl/_extractHierarchy.py", line 231, in __init__
>>     raise ExtractHierarchyError(_error.NoInstances)
>> ExtractHierarchyError: No instances found
>>
>> ======================================================================
>> ERROR: testHierarchicalTrace2 (test_traceSignals.TestTraceSigs)
>> ----------------------------------------------------------------------
>> Traceback (most recent call last):
>>   File "/home/bobc/Download/AlienCortex/HDL/MyHDL/myhdl-0.7/myhdl/test/core/test_traceSignals.py", line 137, in testHierarchicalTrace2
>>     dut = traceSignals(top)
>>   File "/usr/lib/pypy-1.5/site-packages/myhdl/_traceSignals.py", line 76, in __call__
>>     h = _HierExtr(name, dut, *args, **kwargs)
>>   File "/usr/lib/pypy-1.5/site-packages/myhdl/_extractHierarchy.py", line 231, in __init__
>>     raise ExtractHierarchyError(_error.NoInstances)
>> ExtractHierarchyError: No instances found
>>
>> ======================================================================
>> ERROR: testMultipleTraces (test_traceSignals.TestTraceSigs)
>> ----------------------------------------------------------------------
>> Traceback (most recent call last):
>>   File "/home/bobc/Download/AlienCortex/HDL/MyHDL/myhdl-0.7/myhdl/test/core/test_traceSignals.py", line 105, in testMultipleTraces
>>     dut = top3()
>>   File "/home/bobc/Download/AlienCortex/HDL/MyHDL/myhdl-0.7/myhdl/test/core/test_traceSignals.py", line 69, in top3
>>     inst_1 = traceSignals(fun)
>>   File "/usr/lib/pypy-1.5/site-packages/myhdl/_traceSignals.py", line 76, in __call__
>>     h = _HierExtr(name, dut, *args, **kwargs)
>>   File "/usr/lib/pypy-1.5/site-packages/myhdl/_extractHierarchy.py", line 231, in __init__
>>     raise ExtractHierarchyError(_error.NoInstances)
>> ExtractHierarchyError: No instances found
>>
>> ======================================================================
>> FAIL: testReturnVal (test_traceSignals.TestTraceSigs)
>> ----------------------------------------------------------------------
>> Traceback (most recent call last):
>>   File "/home/bobc/Download/AlienCortex/HDL/MyHDL/myhdl-0.7/myhdl/test/core/test_traceSignals.py", line 125, in testReturnVal
>>     self.assertEqual(e.kind, _error.InconsistentToplevel % (2, "dummy"))
>> AssertionError: 'No instances found' != 'Inconsistent top level 2 for dummy - should be 1'
>>
>> ----------------------------------------------------------------------
>> Ran 285 tests in 23.302s
>>
>> FAILED (failures=1, errors=4)

Are these failures expected for the current versions of MyHDL and pypy?

Some more info:

> $ python --version
> Python 2.7.1
>
> $ pypy --version
> Python 2.7.1 (?, May 02 2011, 19:05:27)
> [PyPy 1.5.0-alpha0 with GCC 4.6.0]
>
> $ lsb_release -a
> LSB Version:	:core-4.0-ia32:core-4.0-noarch
> Distributor ID:	Fedora
> Description:	Fedora release 15 (Lovelock)
> Release:	15
> Codename:	Lovelock
>
> $ uname -a
> Linux snafu 2.6.38.8-32.fc15.i686.PAE #1 SMP Mon Jun 13 19:55:27 UTC 2011 i686 i686 i386 GNU/Linux


TIA,

-BobC

[myhdl-list] modbv example and another pypy data point

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

I just pushed a modbv example,
   https://bitbucket.org/cfelton/examples/src
if anyone is interested.

I also took the opportunity to measure the execution speed CPython vs 
PYPY with this example.  Again it was about an 8x improvement, updated 
table below.

+---------+----------+----------+
|         | CPython  | PYPY     |
+---------+==========+==========+
| USBP    | 4m.50s   | 2m.28s   |
+---------+----------+----------+
| LED     | 16m.13s  | 1m.59s   |
+---------+----------+----------+
| RWA     | 178m.89s | 21m.71s  |
+---------+----------+----------+

System configurations
Ubu  - AMD Athlon LE1620 1.7GiB RAM, Ubuntu (natty)


Question, has anyone ran a performance test with a design that has many 
generators?  The examples I have run so far are all small number of 
generators.

Chris

Re: [myhdl-list] cpython, pypy, and py.test

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

Thanks to all for the suggestions, things learned thus far:

  1. Installed tox and created the example tox.ini file.  It complained 
about a missing setup.py file in the directory that I was trying to run 
the tests.  Not sure what this error is, will need to investigate later.

  2.  My case, using pytest as a module (-m) appeared straight-forward. 
  But I couldn't resolve how to install pytest for different installed 
interpreters.  This might be something very basic that I am overlooking.

Thanks again for the comments.
Chris