myhdl-list — Mailing list for discussions on MyHDL

Re: [myhdl-list] Unable to get a counter working

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

Andrew Lentvorski wrote:
> Could someone please explain to me what I'm doing wrong?  

pcTemp is a signal. When you assign to a signal you need to use the 
.next property.

See my modification below.

...

> 
> def PCStage(gclk, pc):
> 
>     pcTemp = Signal(intbv(0)[32:])
>     flgPCValidTemp = Signal(bool(0))
> 
>     @always_comb
>     def pc_logic():
>         # WTF?  If you uncomment the next line, you get an unbound
>         # local error.  Why not in pc_flops(), too?
>         # print "pc:pcTemp: 0x%08x:0x%08x" % (int(pc), int(pcTemp))
>         pcTemp = pc + 4
	  pcTemp.next = pc + 4
>         print "pc:pcTemp: 0x%08x:0x%08x" % (int(pc), int(pcTemp))

I tried that an was able to comment out the print line above.

Guenter

[myhdl-list] Unable to get a counter working

[Andrew L. <bs...@al...>]

Could someone please explain to me what I'm doing wrong?  I'm trying to
implement what would be a basic PC counter in a microprocessor.  The
stage has two def's: pc_logic which should basically just be a
combinatorial adder and pc_flops which captures the state of the
combinatorial logic on an edge.

Why doesn't this work?  Worse, why does the one commented line throw a
UboundLocalError error?

Thanks,
-a

Here is the code:

#!/usr/bin/env python

from myhdl import Signal, delay, always, instance, StopSimulation, now, traceSignals, \
    Simulation, intbv, concat, enum, now, always_comb, toVerilog, instances

PCSTARTADDRESS = 0x10000000

def PCStage(gclk, pc):

    pcTemp = Signal(intbv(0)[32:])
    flgPCValidTemp = Signal(bool(0))

    @always_comb
    def pc_logic():
        # WTF?  If you uncomment the next line, you get an unbound
        # local error.  Why not in pc_flops(), too?
        # print "pc:pcTemp: 0x%08x:0x%08x" % (int(pc), int(pcTemp))
        pcTemp = pc + 4
        print "pc:pcTemp: 0x%08x:0x%08x" % (int(pc), int(pcTemp))

    @always(gclk.posedge)
    def pc_flops():
        print "Capturing:", now(), hex(int(pcTemp))
        pc.next = pcTemp

    return instances()

def test_PCStage_basic_0001():
    gclk = Signal(bool(0))
    halfPeriod = delay(50)
    @always(halfPeriod)
    def drive_clock():
        gclk.next = not gclk

    gclk = Signal(bool(0))
    pc = Signal(intbv(PCSTARTADDRESS)[32:])

    pc_stage = PCStage(gclk, pc)
    
    @instance
    def stimulus():
        yield delay(1000)
        print "Stopping...", now()
        raise StopSimulation

    return instances()

def main():
    tb = traceSignals(test_PCStage_basic_0001)
    sim = Simulation(tb)
    sim.run()

if __name__ == "__main__":
    main()

Re: [myhdl-list] debugging Cosimulation with Icarus Verilog

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

Jan Decaluwe wrote:
...

> 
> Based on previous experience, I'm quite reluctant to make big
> changes. Given that cver works with the method as implemented,
> I'm inclined to think that in principle Icarus should behave the
> same it Icarus vpi is done properly.

I have filed a bug report (#2048463) for the cbValueChange issue on the 
Icarus bug tracker.

http://sourceforge.net/tracker/index.php?func=detail&aid=2048463&group_id=149850&atid=775997

One of the developers already confirmed some issues and also named the 
vpiSuppressTime, which is the reason for the necessary change below:

> 
> I do see a difference that may be significant between the two
> files:
> 
>    // icarus stops on the following line but shouldn't
>    // cb_data_s.value = &value_s;
>    cb_data_s.value = NULL;
> 

In the bug report I also mentioned the time 0 issue, which is, that I 
see a call back happening at time 0, when no signal assignment happens. 
I got a reply that the Icarus developers discussed that before and if I 
think that this is a wrong behavior I should file another bug report.

I compared the Cver behavior with Riviera and both behave the same way. 
If no signal assignment happens at time 0, there is no callback. I will 
investigate that some more and then also file it as bug report.

Guenter

Re: [myhdl-list] Wraparound addition?

[Thomas T. <tho...@de...>]

Andrew Lentvorski wrote:
> How do I add two unsigned intbv() objects such that the addition wraps 
> around?
> 
> Obviously, I can do the addition and then mask it and reassign like so:
> 
> new = (old0 + old1) & 0xffff

> However, I doubt that is going to translate to verilog properly.


The following short test code can be used to try the mask approach and
the modulo approach (suggested by Jan some weeks ago).

BTW: Some german websites say that the Verilog arithmetic is defined as
wrap around arithmetic. Therefore the implementation of the wrapping
behaviour I suggested last year and again some weeks ago, is a quite
simple simulator code modification only.

--------------------------------------
from myhdl import *


def wrap(inp,out):

    @always_comb
    def w():
        #out.next = (inp +1) & 0xffff
        out.next = (inp +1)%2**16
    return instances()

i = Signal(intbv(0)[16:])
o = Signal(intbv(0)[16:])

toVerilog(wrap,i,o)
-----------------------------------------

The results (not tested):
-----------------------------------------
// File: wrap.v
// Generated by MyHDL 0.6dev8
// Date: Mon Aug 11 09:13:15 2008

`timescale 1ns/10ps

module wrap (
    inp,
    out
);

input [15:0] inp;
output [15:0] out;
wire [15:0] out;

assign out = ((inp + 1) & 65535);

endmodule
-----------------------------------------
/ File: wrap.v
// Generated by MyHDL 0.6dev8
// Date: Mon Aug 11 09:10:13 2008

`timescale 1ns/10ps

module wrap (
    inp,
    out
);

input [15:0] inp;
output [15:0] out;
wire [15:0] out;

assign out = ((inp + 1) % (2 ** 16));

endmodule
-----------------------------------------

Re: [myhdl-list] Wraparound addition?

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

Andrew Lentvorski wrote:
> How do I add two unsigned intbv() objects such that the addition wraps 
> around?
> 
> Obviously, I can do the addition and then mask it and reassign like so:
> 
> new = (old0 + old1) & 0xffff
> 
> However, I doubt that is going to translate to verilog properly.

There had been a discussion about that feature back in June of last year 
  on this mailing list. Here is a link to the achieve of that:

http://sourceforge.net/mailarchive/forum.php?forum_name=myhdl-list&max_rows=25&style=ultimate&viewmonth=200706

Jan had written some background information about the intention of intbv 
there in connection with the wrap around functionality.

This might be a good question to be answered on the FAQ page.

Cheers,

Guenter

[myhdl-list] Wraparound addition?

[Andrew L. <bs...@al...>]

How do I add two unsigned intbv() objects such that the addition wraps 
around?

Obviously, I can do the addition and then mask it and reassign like so:

new = (old0 + old1) & 0xffff

However, I doubt that is going to translate to verilog properly.

-a

Re: [myhdl-list] debugging Cosimulation with Icarus Verilog

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

Günter Dannoritzer wrote:
> Hi Jan,
> 
> I took some time to look into the error I am getting when doing
> cosimulation with Icarus Verilog. The first test that fails in the 
> myhdl/test/conversion/toVerilog folder is test1 in the 
> test_always_comb.py file.
> 
> The design is the following:
> 
> def design1(a, b, p):
>      def logic():
>          p.next = a | b
>      return always_comb(logic)
> 
> 
> What causes the exception, which stops the simulation is that p returns 
> the value 'x'. I traced the problem down and it has to do with the 
> change_callback() function in the myhdl.c file. It fires too early, 
> already at time step 0. Comparing that with Cver, the change_callback() 
> function only fires at time step 2.
> 
> Now, the change_callback() function is registered in the 
> to_myhdl_calltf() function. To avoid having the change_callback() 
> function trigger already in time step 0, wouldn't it make sense to 
> register it in the first readonly_callback() function. That way it would 
> make sure that it does not fire in time step 0?

Guenter:

I won't have time in the coming weeks to look at this in much
detail. However, some quick comments:

Based on previous experience, I'm quite reluctant to make big
changes. Given that cver works with the method as implemented,
I'm inclined to think that in principle Icarus should behave the
same it Icarus vpi is done properly.

I do see a difference that may be significant between the two
files:

   // icarus stops on the following line but shouldn't
   // cb_data_s.value = &value_s;
   cb_data_s.value = NULL;

while setting up the callback you mention.

Apparently I had an unexpected problem with Icarus here that
I didn't have with cver. This may explain the issue,
I'm not sure.

As a first attempt, I would try if the original line still
breaks things with recent Icarus releases. If it does, I would
contact the Icarus developer to check whether this qualifies
as a bug.

Jan

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

[myhdl-list] debugging Cosimulation with Icarus Verilog

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

Hi Jan,

I took some time to look into the error I am getting when doing
cosimulation with Icarus Verilog. The first test that fails in the 
myhdl/test/conversion/toVerilog folder is test1 in the 
test_always_comb.py file.

The design is the following:

def design1(a, b, p):
     def logic():
         p.next = a | b
     return always_comb(logic)


What causes the exception, which stops the simulation is that p returns 
the value 'x'. I traced the problem down and it has to do with the 
change_callback() function in the myhdl.c file. It fires too early, 
already at time step 0. Comparing that with Cver, the change_callback() 
function only fires at time step 2.

Now, the change_callback() function is registered in the 
to_myhdl_calltf() function. To avoid having the change_callback() 
function trigger already in time step 0, wouldn't it make sense to 
register it in the first readonly_callback() function. That way it would 
make sure that it does not fire in time step 0?

Guenter

Re: [myhdl-list] Completely cryptic assertion failure

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

Andrew Lentvorski wrote:
> I eventually figured out what was wrong, but could somebody explain to
> me how I should debug this?

First of all, AssertionError's like this are indeed not very nice
and can be considered a bug.

However, it's not necessarily possible to turn this into an
error message that directly points to the problem. Something
like "Inconsistent hierachy definition - check if all instances
are returned." may be the best that can be done. Ok, that
would perhaps be much better already.

There is a fundamental issue: it is possible with MyHDL currently
to forget to return instances defined previously. When you are
*not* using things like traceSignals that extract hierarchy,
there is no way currently to warn about this - it's all valid Python.
The "correct" way for hierarchy extraction could be to ignore
unfound instances (perhaps after issuing a warning).

Alternatively, we may think about a fundamental solution, e.g.
by defining a @module decorator that would gather and return
the instances automatically. I'm just thinking aloud, don't
know if it's possible. I'm also not keen on too much magic,
so I'm not sure it would be a good idea.

Jan


 > Here was the error I got:
> 
> $ python memory.py
> Traceback (most recent call last):
>   File "memory.py", line 81, in <module>
>     main()
>   File "memory.py", line 77, in main
>     tb = traceSignals(basic_testbench)
>   File "/home/andrewl/local/lib/python/myhdl/_traceSignals.py", line 82, in __call__
>     h = _HierExtr(name, dut, *args, **kwargs)
>   File "/home/andrewl/local/lib/python/myhdl/_extractHierarchy.py", line 191, in __init__
>     assert id(obj) in names
> AssertionError
> 
> Thanks,
> -a
> 
> And here was the code that caused it:
> 
> #!/usr/bin/env python
> 
> from myhdl import Signal, delay, always, Simulation, instance, StopSimulation, now, traceSignals, intbv
> 
> def StaticRAM(gclk,
>               stall, readData, readByteEnable, # Outputs
>               read, write, address, byteEnable, writeData, #Inputs
>               memoryMap):
> 
>     @always(gclk.posedge)
>     def access():
>         assert read == 0 or write == 0
>         assert byteEnable == 0 or (not byteEnable) == 0
>         assert readByteEnable == 0 or (not readByteEnable) == 0
> 
>         if read == 1 and write == 0:
>             # Initiate RAM read cycle
>             stall.next = 0 # This signals that transaction completed
>             readData.next = address
>             readByteEnable.next = byteEnable
>         elif read == 0 and write == 1:
>             # Initiate RAM write cycle
>             stall.next = 0 # This signals that transaction completed
>             # Place values into sparse RAM
>         elif read == 0 and write == 0:
>             stall.next = 1 # Not required, but makes debugging easier
>         else:
>             raise Exception("Bus Error: Simultaneous read and write transaction requested")
> 
>     return access
> 
> def basic_testbench():
>     memoryMap = []
> 
>     gclk = Signal(bool(0))
>     
>     stall = Signal(bool(0))
>     readData = Signal(intbv(0)[32:])
>     readByteEnable = Signal(intbv(0)[4:])
>     read = Signal(bool(0))
>     write = Signal(bool(0))
>     address = Signal(intbv(0)[32:])
>     byteEnable = Signal(intbv(0)[4:])
>     writeData = Signal(intbv(0)[32:])
>     
> 
>     ram_1 = StaticRAM(gclk,
>                       stall, readData, readByteEnable,
>                       read, write, address, byteEnable, writeData,
>                       memoryMap)
>     
>     halfPeriod = delay(50)
>     @always(halfPeriod)
>     def drive_clock():
>         gclk.next = not gclk
> 
>     @instance
>     def stimulus():
>         yield delay(25)
>         address.next = 0xf036
>         readByteEnable.next = 0xf
>         read.next = 1
>         yield delay(100)
>         read.next = 0
> 
>         yield delay(200)
>         print "Stopping...", now()
>         raise StopSimulation
> 
>     # !!! This is the error !!!
>     return drive_clock, stimulus
> 
>     # It should be
>     return ram_1, drive_clock, stimulus
> 
> def main():
>     tb = traceSignals(basic_testbench)
>     Simulation(tb).run()
> 
> if __name__ == "__main__":
>     main()
> 
> -------------------------------------------------------------------------
> This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
> Build the coolest Linux based applications with Moblin SDK & win great prizes
> Grand prize is a trip for two to an Open Source event anywhere in the world
> http://moblin-contest.org/redirect.php?banner_id=100&url=/


-- 
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] odd website behavior

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

Jan Decaluwe wrote:
> At this moment some things like fetching pdf files and
> displaying images don't seem to work anymore on the web site.
> 
> I'm quite sure it's not something I did :-) I suspect
> webfaction changed something to their apache configuration.
> 
> I'm trying to find out what happened.

Update: it turns out that webfaction changes its php configuration.
The effect is that "media" files are served statically instead
of through php by default. As dokuwiki does everything through
php, such urls are not found anymore.

Webfaction tells me I have to use rewriting rules as a
workaround, and they provided an example. And indeed, with my first
quick attempt many problems seem to be solved.

There is on exception I see: when image files are resized with
wiki syntax, the workaround still doesn't work. I'm working
on this to find out why.

If you see still other problems, let me know.

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] Completely cryptic assertion failure

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

Andrew Lentvorski wrote:
...
> 
>     # !!! This is the error !!!
>     return drive_clock, stimulus
> 
>     # It should be
>     return ram_1, drive_clock, stimulus

Instead of listing all instances by hand you can use the instances() 
function:

http://www.jandecaluwe.com/Tools/MyHDL/manual/ref-model-misc.html#l2h-59

It collects all instances and returns them as a list.

Cheers,

Guenter

[myhdl-list] Completely cryptic assertion failure

[Andrew L. <bs...@al...>]

I eventually figured out what was wrong, but could somebody explain to
me how I should debug this?  Here was the error I got:

$ python memory.py
Traceback (most recent call last):
  File "memory.py", line 81, in <module>
    main()
  File "memory.py", line 77, in main
    tb = traceSignals(basic_testbench)
  File "/home/andrewl/local/lib/python/myhdl/_traceSignals.py", line 82, in __call__
    h = _HierExtr(name, dut, *args, **kwargs)
  File "/home/andrewl/local/lib/python/myhdl/_extractHierarchy.py", line 191, in __init__
    assert id(obj) in names
AssertionError

Thanks,
-a

And here was the code that caused it:

#!/usr/bin/env python

from myhdl import Signal, delay, always, Simulation, instance, StopSimulation, now, traceSignals, intbv

def StaticRAM(gclk,
              stall, readData, readByteEnable, # Outputs
              read, write, address, byteEnable, writeData, #Inputs
              memoryMap):

    @always(gclk.posedge)
    def access():
        assert read == 0 or write == 0
        assert byteEnable == 0 or (not byteEnable) == 0
        assert readByteEnable == 0 or (not readByteEnable) == 0

        if read == 1 and write == 0:
            # Initiate RAM read cycle
            stall.next = 0 # This signals that transaction completed
            readData.next = address
            readByteEnable.next = byteEnable
        elif read == 0 and write == 1:
            # Initiate RAM write cycle
            stall.next = 0 # This signals that transaction completed
            # Place values into sparse RAM
        elif read == 0 and write == 0:
            stall.next = 1 # Not required, but makes debugging easier
        else:
            raise Exception("Bus Error: Simultaneous read and write transaction requested")

    return access

def basic_testbench():
    memoryMap = []

    gclk = Signal(bool(0))
    
    stall = Signal(bool(0))
    readData = Signal(intbv(0)[32:])
    readByteEnable = Signal(intbv(0)[4:])
    read = Signal(bool(0))
    write = Signal(bool(0))
    address = Signal(intbv(0)[32:])
    byteEnable = Signal(intbv(0)[4:])
    writeData = Signal(intbv(0)[32:])
    

    ram_1 = StaticRAM(gclk,
                      stall, readData, readByteEnable,
                      read, write, address, byteEnable, writeData,
                      memoryMap)
    
    halfPeriod = delay(50)
    @always(halfPeriod)
    def drive_clock():
        gclk.next = not gclk

    @instance
    def stimulus():
        yield delay(25)
        address.next = 0xf036
        readByteEnable.next = 0xf
        read.next = 1
        yield delay(100)
        read.next = 0

        yield delay(200)
        print "Stopping...", now()
        raise StopSimulation

    # !!! This is the error !!!
    return drive_clock, stimulus

    # It should be
    return ram_1, drive_clock, stimulus

def main():
    tb = traceSignals(basic_testbench)
    Simulation(tb).run()

if __name__ == "__main__":
    main()

[myhdl-list] odd website behavior

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

At this moment some things like fetching pdf files and
displaying images don't seem to work anymore on the web site.

I'm quite sure it's not something I did :-) I suspect
webfaction changed something to their apache configuration.

I'm trying to find out what happened.

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

[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

Re: [myhdl-list] intbv.signed()

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

Jan Decaluwe wrote:
> Günter Dannoritzer wrote:
>> Jan Decaluwe wrote:
>> ...
>>> Sounds all very logical to me.
>> Would that change already qualify for a bundle
> 
> Yes, but ideally we should also have a test for it,
> perhaps we need to discuss this further.
> 

I have a test case with three tests.

The first test verifies the behavior of the signed() function in
connection with intbv instances having various parameters and values.
The test is divided in two parts. The first part contains cases that
make the signed() function classify the value as unsigned and consider
the bits based on _nrbits as a 2's complement value. The second part
triggers cases were the value is classified as signed and the value
returned as is.

The second test verifies the behavior of the signed() function in
connection with slices. This test can actually be simplified, as the
return of a sliced intbv is always an intbv with min=0 and max>min, 
which is always classified by the signed() function as unsigned. So I 
only did two verifications here, one with a slice and the sign bit set 
and one with a slice with the sign bit not set.

The third test verifies the behavior in connection with the concat()
function. Using the signed() function in connection with concat() only
makes sense, if the concat() function will return an intbv instance. If
I understand the concat() function right, there are cases when it only 
returns an integer value. So here I limited the test to two verifies. In 
one I concat() three bool values, with the msb set and I expect the bit
pattern to be returned as 2's complement value by the signed() function.
In the second test I take an intbv instance that would be classified as
unsigned and concatenate two bool values. Again, expecting the value to
be returned as 2's complement value.

Guenter

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

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] intbv.signed()

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

Günter Dannoritzer wrote:
> Jan Decaluwe wrote:
> ...
>> Sounds all very logical to me.
> 
> Would that change already qualify for a bundle

Yes, but ideally we should also have a test for it,
perhaps we need to discuss this further.

> or does it make more 
> sense first to also add the changes so that toVerilog and toVHDL will 
> convert this function?

I would keep this separate, let's get the desired behavior
right first.

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

[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] installing myhdl stable and development package in parallel

[Brendan <bre...@gm...>]

Günter Dannoritzer <dannoritzer@...> writes:

> I decided to go with the script way as proposed by Jan. Putting it into 
> a central place I can source it from the current shell and by that use 
> the development snapshot in the current shell.
> 
> Cheers,
> 
> Guenter
> 

You could also use Ian Bicking's excellent virtualenv.  It's especially handy
for determining how you would deploy customized Python on production machines.

- Brendan

Re: [myhdl-list] installing myhdl stable and development package in parallel

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

Jan Decaluwe wrote:

> 
> PYTHONPATH="$HOME/dev/myhdl:${PYTHONPATH}"
> export PYTHONPATH
> 
> 

Thanks to all the replies. They helped me to figure out a better way to 
do it.

I decided to go with the script way as proposed by Jan. Putting it into 
a central place I can source it from the current shell and by that use 
the development snapshot in the current shell.

Cheers,

Guenter

Re: [myhdl-list] intbv.signed()

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

Jan Decaluwe wrote:
...
> 
> Sounds all very logical to me.

Would that change already qualify for a bundle or does it make more 
sense first to also add the changes so that toVerilog and toVHDL will 
convert this function?

Guenter

Re: [myhdl-list] intbv.signed()

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

Günter Dannoritzer wrote:
> Jan Decaluwe wrote:
> ...
>> I would go for an integer to start with. That is what MyHDL does now for
>> many operators. It is more efficient than constructing intbv's (although
>> I dont' know how much more) and seems sufficient in many cases.
> 
> I was thinking about the processing of the signed() function and
> basically need to do a categorization when the value of an intbv
> instance is considered unsigned. In that case the the signed() function 
> will change the value based on the msb bit, which is considered the sign 
> bit. In the other case the value is considered signed and the function 
> will return it just as is.
> 
> When considering intbv instances there are several combinations of
> min/max values possible. The following diagram shows them:
> 
> 
>      ----+----+----+----+----+----+----+----
>         -3   -2   -1    0    1    2    3
> 
> 1                     min  max
> 2                          min  max
> 3                min       max
> 4                min            max
> 5           min            max
> 6           min       max
> 7           min  max
> 8   neither min nor max is set
> 9   only max is set
> 10  only min is set
> 
> 
> The horizontal line shows a number range from -3 to 3. Then each line 
> shows different cases of min/max values of an intbv instance.
> 
> As an example, in the first case min=0 and max > 0. The second case min 
>  > 0 and max > min, etc.
> 
>  From all those cases I think only two cases, namely 1 and 2, are where
> the value is considered unsigned and the signed() function will return a
> modified value.
> 
> In all other cases either there is no range specified or the min value
> is < 0, which makes that intbv instance already considered signed and
> the signed() function will just return the value as is.
> 
> So the test will be for min >= 0 and _nrbits > 0. That case will 
> classify the intbv instance as unsigned and the signed() function will 
> return the value as signed, with the sign being determined based on the 
> msb. The msb is bit # _nrbits-1.
> 
> Note that case #10 (only min is set) could fulfill the requirement min 
>  >=0, but as no max is set, _nrbits is 0 and hence the second test will 
> not be True.

Sounds all very logical to me.

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] installing myhdl stable and development package in parallel

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

Günter Dannoritzer wrote:
> Hello,
> 
> Has somebody figured out a good way to install the stable version and 
> the code from the repository in parallel without the packages 
> interfering with each other?
> 
> I did check out the mercurial code as myhdl_hg and then set the 
> PYTHONPATH to it. My idea was to decide by the way of doing the import 
> to take either of the packages. So instead of doing 'from myhdl' do 
> 'from myhdl_hg.myhdl'. Unfortunately there are imports inside the myhdl 
> package that do the 'from myhdl' type import. So I end up mixing 
> packages when doing the import from the repository.
> 
> Are there any better ways of doing that?

I wouldn't try to use the python namespace to control version selection.

I think the cleanest way is to control $PYTHONPATH. Suppose the stable
version is selected by default, then you could have a shell script
to select the development version instead, by doing something like:

PYTHONPATH="$HOME/dev/myhdl:${PYTHONPATH}"
export PYTHONPATH


-- 
Jan Decaluwe - Resources bvba - http://www.jandecaluwe.com
     From Python to silicon:
     http://myhdl.jandecaluwe.com