myhdl-list

[myhdl-list] [myhdl_hg] toVerilog unittest errors with Icarus Verilog

[Günter D. <dan...@we...>]

Hi,

I ran the unittest test_all.py in the hg repository's 
conversion/toVerilog folder and got a bunch of errors (took out the 
traceback):

======================================================================
ERROR: test1 (test_always_comb.AlwaysCombSimulationTest)
----------------------------------------------------------------------
...
ValueError: Expected boolean value, got intbv(None) (<class
'myhdl._intbv.intbv'>)

======================================================================
ERROR: test2 (test_always_comb.AlwaysCombSimulationTest)
----------------------------------------------------------------------
...
ValueError: Expected boolean value, got intbv(None) (<class
'myhdl._intbv.intbv'>)

======================================================================
ERROR: testIncRefInc2 (test_custom.TestInc)
----------------------------------------------------------------------
...
IndexError: list index out of range

======================================================================
ERROR: testIncRefInc3 (test_custom.TestInc)
----------------------------------------------------------------------
...
IndexError: list index out of range

======================================================================
FAIL: testBinaryOps (test_signed.TestBinaryOps)
----------------------------------------------------------------------
...
AssertionError: Signal(True) != Signal(False)


Comparing that to the latest development snapshot 0.6dev8, there are
only three of these errors. All the indexing errors are new with the
latest revision in the repository.

Is that expected or has it to do that I am using Icarus Verilog the
latest development snapshot for the cosimulation? In the test cver was
used by default.


Guenter

Re: [myhdl-list] [myhdl_hg] toVerilog unittest errors with Icarus Verilog

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

Günter Dannoritzer wrote:
> Hi,
> 
> I ran the unittest test_all.py in the hg repository's 
> conversion/toVerilog folder and got a bunch of errors (took out the 
> traceback):

> 
> Comparing that to the latest development snapshot 0.6dev8, there are
> only three of these errors. All the indexing errors are new with the
> latest revision in the repository.
> 
> Is that expected or has it to do that I am using Icarus Verilog the
> latest development snapshot for the cosimulation? In the test cver was
> used by default.

Ok, a couple of points.

I have found Icarus to be less reliable than cver. I am currently happy when
the tests run without errors with cver. (Perhaps I should define a project
to debug Icarus using the MyHDL tests; having cver I'm not very motivated
to do that myself.)

With cver, I indeed found 2 errors that shouldn't be there. It shows that
we should run all tests for any changes (although that may not be
practical for those who haven't cosimulation installed.)

I used 'hg bisect' to track down the cause. (A nice mercurial feature BTW
for this kind of thing. The culprit is this changeset:

-----------------------------------------------------
changeset:   931:3bcbf3cd752c
user:        cfelton@localhost
date:        Wed Jul 23 21:00:15 2008 -0500
files:       myhdl/_extractHierarchy.py
description:
Change to the conditional check.  The conditional check would error out when numpy arrays were used. 
  Numpy arrays would not resolve to a boolean value when tested.


diff -r 1870cf0064df -r 3bcbf3cd752c myhdl/_extractHierarchy.py
--- a/myhdl/_extractHierarchy.py        Tue Jul 22 14:22:49 2008 +0200
+++ b/myhdl/_extractHierarchy.py        Wed Jul 23 21:00:15 2008 -0500
@@ -126,7 +126,7 @@


  def _isListOfSigs(obj):
-    if obj and isinstance(obj, list):
+    if obj != None and isinstance(obj, list):
          for e in obj:
              if not isinstance(e, Signal):
                  return False
--------------------------------------------------------------------

The _isListOfSigs function is broken. The intention of the function is to
only return True on a *non-empty* list of signals, but as you can see
this is not what currently happens - empty lists are not equal to None.

The original test had  a problem with numpy arrays (you can't really test
these for thruth value - rather strange).

Assuming that numpy arrays are not subtypes of list, the following
should work

     if isinstance(obj, list) and obj:

but I think I'm going to make the intention clearer as follows:

     if isinstance(obj, list) and len(obj) > 0:

Unless someone objects, I'll test this and push the change.

Jan

-- 
Jan Decaluwe - Resources bvba - http://www.jandecaluwe.com
Kaboutermansstraat 97, B-3000 Leuven, Belgium
     From Python to silicon:
     http://myhdl.jandecaluwe.com

Re: [myhdl-list] [myhdl_hg] toVerilog unittest errors with Icarus Verilog

[Christopher F. <cf...@uc...>]

> 
> Unless someone objects, I'll test this and push the change.
> 
> Jan
> 

Do'H one of my first contributions and it was a dud :).  The fix seems 
reasonable no objections here.  I pulled the latest changes (described 
above) from the repository and ran the design that originally failed 
(numpy arrays) everything simulated correctly as one would expect.

I have added all the example code to the wiki page that requires this 
fix.  Since code is posted that requires the change should a new 
development release be made?

Thanks

Re: [myhdl-list] [myhdl_hg] toVerilog unittest errors with Icarus Verilog

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

Christopher Felton wrote:
>> Unless someone objects, I'll test this and push the change.
>>
>> Jan
>>
> 
> Do'H one of my first contributions and it was a dud :).

No worries, we learned a lot :-)

* running the conversion test suite is a good idea even when it
doesn't seem necessary
* tested the mercurial flow, learned about 'hg bisect'
* code has significantly improved in the process

Jan

-- 
Jan Decaluwe - Resources bvba - http://www.jandecaluwe.com
Kaboutermansstraat 97, B-3000 Leuven, Belgium

Re: [myhdl-list] [myhdl_hg] toVerilog unittest errors with Icarus Verilog

[Günter D. <dan...@we...>]

Jan Decaluwe wrote:
...
> 
> I have found Icarus to be less reliable than cver. I am currently happy when
> the tests run without errors with cver. (Perhaps I should define a project
> to debug Icarus using the MyHDL tests; having cver I'm not very motivated
> to do that myself.)

I installed Cver on my x86_64 installation and noticed that
the makefile that comes with MyHDL to compile myhdl_vpi.so for Cver does
not work with an x86_64 installation. I attached a makefile, based on
the makefile.lnx in the cosimulation/cver folder that compiles the
library correct and what is more important, the library is loaded
properly by cver on a x86_64 installation.

The problem is that cver is compiled as a 32-bit application and the
makefile.lnx will compile the library as 64-bit library.

> 
> With cver, I indeed found 2 errors that shouldn't be there. It shows that
> we should run all tests for any changes (although that may not be
> practical for those who haven't cosimulation installed.)

I tried to simplify the installation effort for doing cosimulation with 
  MyHDL by creating RPM packages for openSUSE, but haven't found out a 
good way yet to do that in connection with Cver.

For Icarus Verilog for example I have created a RPM package myhdl-cosim
that contains the myhdl.vpi file in /usr/lib/ivl or on x86_64 in
/usr/lib64/ivl. That is the folder iverilog-vpi --install-dir reports as
the default folder for vpi modules. When installing a vpi module in that
folder, there is no need to specify the path to the module when calling
vvp. So the vvp call simplifies to:

     vvp -m myhdl <sim_file>

By installing the python-myhdl, myhdl-cosim, and verilog RPM packages,
MyHDL can be used in connection with Icarus Verilog for cosimulation.

With Cver the first issue I see is that the pli_incs folder needs to be
in a common place. I have created a rpm package of Cver for openSUSE and
added the folder as /usr/include/pli_incs. However, I haven't figured
out a good way where to put the vpi module. As it is a shared library I
wonder whether Cver can load it from the standard library folders
without specifying the path to the library? That would allow to put it
in /usr/lib and not require to specify the path. The simplified call
would then look like this:

cver -q +loadvpi=myhdl_vpi:vpi_compat_bootstrap + <verilog source>


Guenter

BTW, the Cver package is available from http://software.opensuse.org/search