myhdl-list — Mailing list for discussions on MyHDL

[myhdl-list] Named branches in repository

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

As announced, I am now using named branches in the repository.

They implement different development lines with different
policies. Currently I use them to separate "bleeding edge"
development on the default branch from bug fixes for 0.6
in branch 0.6-maint. Merges occur only in one direction,
from 0.6-maint to default.

The alternative would have been different repositories,
which is the principal method advocated in the mercurial
documentation. Named branches are "advanced" but I
prefer them because you can switch development lines
without changes to your python setup.

I have documented this on the website:\

http://www.myhdl.org/doku.php/dev:repo#named_branches


-- 
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
    Analog design automation: http://www.mephisto-da.com
    World-class digital design: http://www.easics.com

[myhdl-list] Development status

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

Those who track the mecurial repo - be careful.

As announced, I am now working with 2 branches, one for maintenances
(0.6-maint) and the default trunk for the bleeding edge.

The trunk is currently UNSTABLE, as I am in the middle of a major
rewrite to replace package compiler by ast. In normal circumstances,
I try to avoid an unstable trunk, but this rewrite is really major.
(Next time I may use another branch.) I didn't want to delay a
push any longer, as I also use the external repo a backup.

When you pull now, you will get changesets for all branches. If you
want to track bug fixes for 0.6, make sure to switch to 0.6-maint
before installing:
   hg update -C 0.6-maint.

I will explain all of this better later on when I have more time.

Jan

-- 
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
    Analog design automation: http://www.mephisto-da.com
    World-class digital design: http://www.easics.com

Re: [myhdl-list] intbv return types and a fixed-point Object

[Felton C. <chr...@gm...>]

On Apr 19, 2009, at 3:08 AM, Jan Decaluwe wrote:

> Christopher L. Felton wrote:
>> Curiosity, what was the rational behind the mathematical operators  
>> for
>> the intbv object returning the integer values and the logic operators
>> (shifts, and, or, xor, etc) returning an intbv object?
>>
>> Example
>> a = intbv(1)
>> b = intbv(2)
>>
>> c = a + b
>> type(c)
>> <type 'int'>
>>
>> c = a ^ b
>> type(c)
>> <class 'myhdl._intbv.intbv'>
>
> If the return value is an intbv, you can slice and index it.
> This probably makes sense for "bit-oriented" operations,
> and perhaps less for "arithmetic" operations.
> Therefore, for the latter case it might be a good idea
> to avoid the overhead of intbv construction.
>
> This is all a little bit arbitrary and speculative -
> for example, I haven't done tests to check how significant
> the intbv construction overhead exactly is.
> We always have the option to change the return type
> to intbv if there's a real need.
>
> Jan
>

In my experience if you have a type (object) and some operations are  
performed the result is the same type.  Also, I think it would simply  
matters some what for users (but could cause other issues) not having  
to use the [:].  There could be more negatives than positives to such  
a change.

I imagine it might be difficult to change at this point because it  
could affect much of the user code.  Also, don't know if it would have  
any implications on conversion, checking, etc.

The reason I had come across this question was because I spend some  
time putting together a fixed-point object that used the intbv as the  
base class.  Hence it would be convertible.  I came across this  
scenario, for the mathematical operations leave the same  
implementation as intbv or return the type.

I have uploaded a draft document I started for the fixed-point  
object.  It is very (very, very, very) rough at this point http://www.myhdl.org/lib/exe/fetch.php/users:cfelton:projects:myhdlfixedpoint.pdf?id=users%3Acfelton%3Aprojects%3Afxintbv&cache=cache

Thanks

Re: [myhdl-list] the path not taken

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

Neal Becker wrote:
> I'm having a problem with this code:
> 
> def rnd (x, bits, output):
>     min_val = x.min
>     max_val = x.max
>     @always_comb
>     def rnd_logic():
>         if (bits < 1):
>             output.next = x
>         else:
>             y1 = intbv (int (x >> (bits-1)), min_val, max_val)
>             #y1 = intbv (int(x), min_val, max_val)
>             y2 = intbv (int (y1 + 1), min_val, max_val)
>             y3 = intbv (int (y2 >> 1), min_val, max_val)
>             output.next = y3
>     return rnd_logic
> 
> When translating to verilog:
> ValueError: negative shift count
> 
> If the commented line #y1 is used, no error.
> 
> So myhdl is complaining about neg shift count if bits < 1, even though I
> tried to eliminate that with the if (bits < 1).
> 
> What can I do?

I think the problem can be solved by making the code much
clearer at the same time. I would separate object contruction
from usage. Also, I would avoid using redundant objects and
constructors - now they look like ugly type conversions.

For example:

def rndn (x, bits, output):
    min_val = x.min
    max_val = x.max
    @always_comb
    def rnd_logic():
        y = intbv(0, min_val, max_val)
        if (bits < 1):
            output.next = x
        else:
            y[:] = x >> bits-1
            y += 1
            output.next = y >> 1
    return rnd_logic




-- 
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
    Analog design automation: http://www.mephisto-da.com
    World-class digital design: http://www.easics.com

[myhdl-list] the path not taken

[Neal B. <ndb...@gm...>]

I'm having a problem with this code:

def rnd (x, bits, output):
    min_val = x.min
    max_val = x.max
    @always_comb
    def rnd_logic():
        if (bits < 1):
            output.next = x
        else:
            y1 = intbv (int (x >> (bits-1)), min_val, max_val)
            #y1 = intbv (int(x), min_val, max_val)
            y2 = intbv (int (y1 + 1), min_val, max_val)
            y3 = intbv (int (y2 >> 1), min_val, max_val)
            output.next = y3
    return rnd_logic

When translating to verilog:
ValueError: negative shift count

If the commented line #y1 is used, no error.

So myhdl is complaining about neg shift count if bits < 1, even though I
tried to eliminate that with the if (bits < 1).

What can I do?

Re: [myhdl-list] Further development setup

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

Günter Dannoritzer wrote:

> When I read the explanation about the compiler package at this page:
> 
> http://docs.python.org/library/compiler.html
> 
> It talks about that the compiler converts the Python code to an abstract
> syntax tree and from there creates the Python bytecode.
> 
> Unfortunately I have not understood that process much deeper yet, but if
> I recall it right, then the MyHDL converter uses the abstract syntax
> tree to create the Verilog or VHDL code from. So the last step, the
> Python bytecode is not really needed.
> 
> This makes me think whether it would make sense to take the compiler
> package as part of myhdl? At least the part that parses Python code and
> create the abstract syntax tree. This would ease the requirement to
> change the conversion software in the time line of Python 2.6.

Both packages, compiler and ast, generate an abstract syntax tree
and support walking through it. None of them is used by the built-in
Python compiler. However, ast starts from the same syntax description
as the built-in compiler, so it is closer to the real thing.

The problem is that these packages have to be adapted whenever the
Python syntax changes by extensions (typical in major releases) or
fundamental changes (3.0).

What will happen with 3.0 is that package compiler simply won't support
that Python syntax. Therefore, we have no choice to move to the
ast package if we want to stay current.

Jan

-- 
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
    Analog design automation: http://www.mephisto-da.com
    World-class digital design: http://www.easics.com

Re: [myhdl-list] Further development setup

[David B. <dav...@ya...>]

Gunter,
 
I believe you might have the correct solution.  By taking this approach it might allow us to circumvent the compatibility problems between python 2.6 and 3.0.  
 
 
David Blubaugh

--- On Sun, 4/19/09, Günter Dannoritzer <dan...@we...> wrote:


From: Günter Dannoritzer <dan...@we...>
Subject: Re: [myhdl-list] Further development setup
To: ja...@ja..., "General discussions on MyHDL" <myh...@li...>
Date: Sunday, April 19, 2009, 2:19 PM


Jan Decaluwe wrote:
...
> MyHDL 0.7
> ---------
> Unfortunately, we're having a kind of a setback. The
> conversion software was written using the "compiler" package.
> This is deprecated in 2.6 and removed in 3.0. Instead,
> the new package to use is "ast". This has the advantage
> that it's closely related to the Python parser, but unfortunately
> it requires a complete rewrite of the conversion code.

When I read the explanation about the compiler package at this page:

http://docs.python.org/library/compiler.html

It talks about that the compiler converts the Python code to an abstract
syntax tree and from there creates the Python bytecode.

Unfortunately I have not understood that process much deeper yet, but if
I recall it right, then the MyHDL converter uses the abstract syntax
tree to create the Verilog or VHDL code from. So the last step, the
Python bytecode is not really needed.

This makes me think whether it would make sense to take the compiler
package as part of myhdl? At least the part that parses Python code and
create the abstract syntax tree. This would ease the requirement to
change the conversion software in the time line of Python 2.6.

Guenter

------------------------------------------------------------------------------
Stay on top of everything new and different, both inside and 
around Java (TM) technology - register by April 22, and save
$200 on the JavaOne (SM) conference, June 2-5, 2009, San Francisco.
300 plus technical and hands-on sessions. Register today. 
Use priority code J9JMT32. http://p.sf.net/sfu/p
_______________________________________________
myhdl-list mailing list
myh...@li...
https://lists.sourceforge.net/lists/listinfo/myhdl-list



      

Re: [myhdl-list] Further development setup

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

Jan Decaluwe wrote:
...
> MyHDL 0.7
> ---------
> Unfortunately, we're having a kind of a setback. The
> conversion software was written using the "compiler" package.
> This is deprecated in 2.6 and removed in 3.0. Instead,
> the new package to use is "ast". This has the advantage
> that it's closely related to the Python parser, but unfortunately
> it requires a complete rewrite of the conversion code.

When I read the explanation about the compiler package at this page:

http://docs.python.org/library/compiler.html

It talks about that the compiler converts the Python code to an abstract
syntax tree and from there creates the Python bytecode.

Unfortunately I have not understood that process much deeper yet, but if
I recall it right, then the MyHDL converter uses the abstract syntax
tree to create the Verilog or VHDL code from. So the last step, the
Python bytecode is not really needed.

This makes me think whether it would make sense to take the compiler
package as part of myhdl? At least the part that parses Python code and
create the abstract syntax tree. This would ease the requirement to
change the conversion software in the time line of Python 2.6.

Guenter

[myhdl-list] Further development setup

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

It's time to set things up for new developments. There
are a number of issues that I'd like to describe.

Python 2.6
----------
I plan to move to Python 2.6. It's becoming the "sweet spot"
now and it's a necessary step to prepare for Python 3.0.

MyHDL 0.7
---------
Unfortunately, we're having a kind of a setback. The
conversion software was written using the "compiler" package.
This is deprecated in 2.6 and removed in 3.0. Instead,
the new package to use is "ast". This has the advantage
that it's closely related to the Python parser, but unfortunately
it requires a complete rewrite of the conversion code.

I have no idea how complicated this is going to be. I have
the tests, and an existing implementation of course, but
I don't expect it to be trivial.

Also, I'm not very motivated to support new things in the
convertor before the rewrite is done.

Mercurial named branches
------------------------
I plan to use named branches for the first time in mercurial,
to support simultaneous maintenance of 0.6 and further
development on the trunk. I believe this will be easier
for me than separate repositories.

It means that if you track the repository, you will have
to make sure to switch to the correct branch depending
on what you want to track.

More about this when it actually starts happening.


Jan

-- 
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
    Analog design automation: http://www.mephisto-da.com
    World-class digital design: http://www.easics.com

[myhdl-list] mailing list usage

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

I received a message from someone who had difficulties
reviewing the mailing list archive on SourceForge.

On this occasion, I'd like to point out that SourceForge
was just used to create a mailing list. To access and
search the info, there is a choice of much more convenient
interfaces via the gmane gateway. There's even no need
to subscribe.

Personally, I prefer the nntp interface so that I can
access the mailing list as a usenet newsgroup. I recommend
that you choose an interface that shows the message
threads explicitly.

I have tried to explain it better than before:

http://www.myhdl.org/doku.php/mailing_list

Jan


-- 
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
    Analog design automation: http://www.mephisto-da.com
    World-class digital design: http://www.easics.com

Re: [myhdl-list] intbv return types

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

Christopher L. Felton wrote:
> Curiosity, what was the rational behind the mathematical operators for 
> the intbv object returning the integer values and the logic operators 
> (shifts, and, or, xor, etc) returning an intbv object?
> 
> Example
> a = intbv(1)
> b = intbv(2)
> 
> c = a + b
> type(c)
> <type 'int'>
> 
> c = a ^ b
> type(c)
> <class 'myhdl._intbv.intbv'>

If the return value is an intbv, you can slice and index it.
This probably makes sense for "bit-oriented" operations,
and perhaps less for "arithmetic" operations.
Therefore, for the latter case it might be a good idea
to avoid the overhead of intbv construction.

This is all a little bit arbitrary and speculative -
for example, I haven't done tests to check how significant
the intbv construction overhead exactly is.
We always have the option to change the return type
to intbv if there's a real need.

Jan


-- 
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
    Analog design automation: http://www.mephisto-da.com
    World-class digital design: http://www.easics.com

Re: [myhdl-list] Need instance name

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

Neal Becker wrote:
> I coded a function that, when synthesized, generates very poor verilog code.  
> So, I hand coded the verilog using __verilog__.  Problem is, that I coded 
> something like:
> 
> always @(%(x)s) begin
>     reg signed [%(inbits)s-1:0] y1;
>  ...
> 
> This gives a syntax error regarding unnamed blocks.  If I let myhdl code the 
> block, it would be a named block, using the instance name.
> 
> How can I get the instance name from my python code, so I could write 
> 
> always @(%(x)s) begin: <instance name>

The hierarchical name generated by MyHDL is internal, but surely you don't
need that one.
Just put a name there in the __verilog__ template. If parameterization
is needed, you can use any name from the surrounding namespace in the
template.

I suspect something else is going on though. I don't think named blocks
are used systematically by Verilog designers.

Jan

-- 
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
    Analog design automation: http://www.mephisto-da.com
    World-class digital design: http://www.easics.com

[myhdl-list] Need instance name

[Neal B. <ndb...@gm...>]

I coded a function that, when synthesized, generates very poor verilog code.  
So, I hand coded the verilog using __verilog__.  Problem is, that I coded 
something like:

always @(%(x)s) begin
    reg signed [%(inbits)s-1:0] y1;
 ...

This gives a syntax error regarding unnamed blocks.  If I let myhdl code the 
block, it would be a named block, using the instance name.

How can I get the instance name from my python code, so I could write 

always @(%(x)s) begin: <instance name>

[myhdl-list] intbv return types

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

Curiosity, what was the rational behind the mathematical operators for 
the intbv object returning the integer values and the logic operators 
(shifts, and, or, xor, etc) returning an intbv object?

Example
a = intbv(1)
b = intbv(2)

c = a + b
type(c)
<type 'int'>

c = a ^ b
type(c)
<class 'myhdl._intbv.intbv'>

Thanks
Chris

[myhdl-list] Cosimulation help

[Newell J. <pil...@gm...>]

Wondering if anyone might be able to help me with a Cosimulation error that
I am getting.
I am using py.test and don't know if this is the reason I am getting the
error.  Any suggestions
are welcome.

Here is the error:

jensen@ubuntu-2012:~/Desktop/python$ py.test simulate
Traceback (most recent call last):
  File "/usr/bin/py.test", line 10, in <module>
    py.test.cmdline.main()
  File "/usr/lib/python2.5/site-packages/py/test/cmdline.py", line 15, in
main
    failures = session.main()
  File "/usr/lib/python2.5/site-packages/py/test/session.py", line 57, in
main
    colitems = self.config.getcolitems()
  File "/usr/lib/python2.5/site-packages/py/test/config.py", line 65, in
getcolitems
    return [self._getcollector(path) for path in (trails or self.args)]
  File "/usr/lib/python2.5/site-packages/py/test/config.py", line 77, in
_getcollector
    return col._getitembynames(names)
  File "/usr/lib/python2.5/site-packages/py/test/collect.py", line 149, in
_getitembynames
    assert next is not None, (cur, name, namelist)
AssertionError: (<Directory 'python'>, 'simulate', ['simulate'])


And here is the script that I am running (simulate):

#! /usr/bin/env python

import os

from myhdl import *

cmd = "iverilog -o simple_bench -cconffile.txt"
WB_PERIOD = 10

# Make a clk generator for pci_clock, wb_clock
# Make a 32 bit signal for listening to the reg AD

def bench():
    """ Practice Unit Test for the opencores PCI project """

    pci_clock = Signal(bool(0))
    wb_clock = Signal(bool(0))
    AD = Signal(intbv(0, min=0, max=2**32))

    dut = simple_bench(pci_clock, wb_clock, AD)

    @always(delay(10))
    def pci_clkgen():
        pci_clock.next = not pci_clock

    @always(delay(WB_PERIOD/2))
    def wb_clkgen():
        wb_clock.next = not wb_clock

    @always(pci_clock.negedge)
    def monitor():
        print AD

    return pci_clkgen, wb_clkgen, monitor, dut

def test_bench():
    sim = Simulation(bench())
    sim.run()

def simple_bench(pci_clock, wb_clock, AD):
    os.system(cmd)
    return Cosimulation("vvp -m ./myhdl.vpi simple_bench",
pci_clock=pci_clock, wb_clock=wb_clock, AD=AD)


-- 
Newell

http://www.gempillar.com
Before enlightenment: chop wood, carry water
After enlightenment: code, build circuits

Re: [myhdl-list] Newbie problem with instances()

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

Georg Acher wrote:
> On Tue, Mar 31, 2009 at 07:18:04PM +0200, Jan Decaluwe wrote:
>> You have hit a backwards incompatibility:
>>
>>     http://www.myhdl.org/doc/0.6/whatsnew/0.6.html#instances-function
> 
> Ouch... That explains everything. I guess I'll have to go over the 20 files
> and look if it's just a sequential function or intended to be an instance...
> :-(

It it worked with earlier versions, it means that every generator
was intended to be a MyHDL instance. If you want to use instances(),
you'll have to adapt all of them to use decorators. That's the bad news.
The good news is that there's no need to consider their specific
functionality :-)
 
>> Only generators produced by MyHDL decorators are now considered by instances().
>> MyHDL decorators are used as a way to discriminate between "MyHDL generators"
>> and regular ones. In particular, this makes it possible to use regular
>> generators in MyHDL models for different purposes. (Users had reported
>> problems when instances() didn't make this difference.)
>>
>> That having said, I personally don't like instances() that much. I tend
>> to return generators explicitly.
> 
> Removing instances() would IMO make MyHDL quite unusable... It's already
> tedious to explicitely return the implicitely instantiated modules. If I
> have to care manually about the correct instantiation of my modules, I can
> just use raw threads and shared variables ;-)

It may be tedious and feel redundant if no conditionals are involved. But
in MyHDL, you can use conditionals to control which generators are returned,
for example to support recursion or simply different implementations dependent
on some condition. In other HDLs this is either not possible (Verilog), or
cumbersome (VHDL configurations.)

Granted, instances() would still work when you use conditional returns,
but it in those cases it probably much clearer to return generators
explicitly.

Jan

-- 
Jan Decaluwe - Resources bvba - http://www.jandecaluwe.com
    Python as an HDL: http://www.myhdl.org
    VHDL development, the modern way: http://www.sigasi.com
    Analog design automation: http://www.mephisto-da.com
    World-class digital design: http://www.easics.com

Re: [myhdl-list] Newbie problem with instances()

[Georg A. <ac...@in...>]

On Tue, Mar 31, 2009 at 07:18:04PM +0200, Jan Decaluwe wrote:
> You have hit a backwards incompatibility:
> 
>     http://www.myhdl.org/doc/0.6/whatsnew/0.6.html#instances-function

Ouch... That explains everything. I guess I'll have to go over the 20 files
and look if it's just a sequential function or intended to be an instance...
:-(
 
> Only generators produced by MyHDL decorators are now considered by instances().
> MyHDL decorators are used as a way to discriminate between "MyHDL generators"
> and regular ones. In particular, this makes it possible to use regular
> generators in MyHDL models for different purposes. (Users had reported
> problems when instances() didn't make this difference.)
> 
> That having said, I personally don't like instances() that much. I tend
> to return generators explicitly.

Removing instances() would IMO make MyHDL quite unusable... It's already
tedious to explicitely return the implicitely instantiated modules. If I
have to care manually about the correct instantiation of my modules, I can
just use raw threads and shared variables ;-)

-- 
         Georg Acher, ac...@in...         
         http://www.lrr.in.tum.de/~acher
         "Oh no, not again !" The bowl of petunias          

Re: [myhdl-list] Newbie problem with instances()

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

Georg Acher wrote:
> Hi,
> I'm trying to run the Turbo-decoder-project from opencores unter MyHDL 0.6
> (on Unbuntu 8.04).
> 
> If I understand the docs correctly, instances() should return a list of all
> generated instances. So in the example I expect [ instance_0 ] to be returned.
> 
> But:
> 
> # python main.py
> instance0 =  <generator object at 0xb7cf9a0c>
> instances  =  []
> subunit =  []
> <class 'myhdl.StopSimulation'>: No more events
> 
> When returning instance_0 in subunit, it works as expected and j/k is
> printed.
> 
> The empty instances()-list seems to be the root cause for the failure of the
> turbo decoder... 
> 
> Am I missing something important here?

You have hit a backwards incompatibility:

    http://www.myhdl.org/doc/0.6/whatsnew/0.6.html#instances-function

Only generators produced by MyHDL decorators are now considered by instances().
MyHDL decorators are used as a way to discriminate between "MyHDL generators"
and regular ones. In particular, this makes it possible to use regular
generators in MyHDL models for different purposes. (Users had reported
problems when instances() didn't make this difference.)

That having said, I personally don't like instances() that much. I tend
to return generators explicitly.

Regards,

Jan

-- 
Jan Decaluwe - Resources bvba - http://www.jandecaluwe.com
    Python as an HDL: http://www.myhdl.org
    VHDL development, the modern way: http://www.sigasi.com
    Analog design automation: http://www.mephisto-da.com
    World-class digital design: http://www.easics.com

[myhdl-list] Newbie problem with instances()

[Georg A. <ac...@in...>]

Hi,
I'm trying to run the Turbo-decoder-project from opencores unter MyHDL 0.6
(on Unbuntu 8.04).

But it simply doesn't produce any data, because all the internal instances
are not running. Although not very familiar with MyHDL (nor Python) I
simplified the code down to this:


from myhdl import *

def clkGen(clk, duration_1 = 10, duration_2 = 10):
    print "clkgen start"
    while 1:
        yield delay(duration_1)
        print "j"
        clk.next = not clk.val
        yield delay(duration_2)
        print "k"
        clk.next = not clk.val

def subunit():
    clk = Signal(bool(0))        
    instance_0=clkGen(clk)
    print "instance0 = ",instance_0
    i=instances()
    print "instances  = ",i
    return i


x=subunit();
print "subunit = ",x
sim = Simulation(x)
sim.run(100)


If I understand the docs correctly, instances() should return a list of all
generated instances. So in the example I expect [ instance_0 ] to be returned.

But:

# python main.py
instance0 =  <generator object at 0xb7cf9a0c>
instances  =  []
subunit =  []
<class 'myhdl.StopSimulation'>: No more events

When returning instance_0 in subunit, it works as expected and j/k is
printed.

The empty instances()-list seems to be the root cause for the failure of the
turbo decoder... 

Am I missing something important here?

-- 
         Georg Acher, ac...@in...
         http://www.lrr.in.tum.de/~acher
         "Oh no, not again !" The bowl of petunias

Re: [myhdl-list] Lists of signals as synthesizable arguments

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

Eric Jonas wrote:
> I'm trying to construct modules that will take in lists of signals and
> gang them together as address lines, where I don't want to manually
> break out those signals or pre-invocation gang them into a single
> signal.

I don't see a solution immediately. It seems that we are hitting
the boundaries here to what can be meaningfully converted and
mapped to Verilog. 


> I can't for the life of me figure out how to do this -- basically, what
> I want is 
> 
> from myhdl import *
> 
> def MyTestObject(listofsigs, myval):
>     totallen = sum(len(x) for x in listofsigs)
> 
>     @always_comb
>     def logic():
>         myval.next = concat(*listofsigs)
> 
>     return logic
> 
> def MyTestObjectTwo(myval):
>     listofsigs = [Signal(intbv(0)[4:]),
>                   Signal(intbv(0)[6:])]
> 
>     to = MyTestObject(listofsigs, myval)
>     return to
> 
> 
> def test_MyTestObject():
> 
>     myval = Signal(intbv(0)[10:])
> 
>     toVerilog(MyTestObjectTwo, myval)
>     
> 
> However, this complains that the signal elements don't have the same
> bitwidth (not sure why?) 

The crucial point is: is the list referenced inside generator
code or not? If it is, it is mapped to a Verilog memory. And for
Verilog memories, all elements have the same bit width. Hence
the restriction.

> When I use only a single signal I get: 
> 
>     Not supported: extra positional arguments
> 
> Which suggests that concat(*listofsigs) isn't going to work.

Correct. This is not supported by the convertor.
> 
> I've looked at the "Conversion of lists of signals" in the 0.6
> documentation, but I'm not entirely clear how its statements relate to
> my problem. 

The point is that, if a list is referenced inside a generator,
there are much more conversion restrictions than if it isn't.

I admit that the kind of modelling problem you bring up is relevant.
But to get it converted, if possible, will need some fresh ideas that
I don't see right now.

Jan

-- 
Jan Decaluwe - Resources bvba - http://www.jandecaluwe.com
    Python as an HDL: http://www.myhdl.org
    VHDL development, the modern way: http://www.sigasi.com
    Analog design automation: http://www.mephisto-da.com
    World-class digital design: http://www.easics.com

[myhdl-list] Lists of signals as synthesizable arguments

[Eric J. <jo...@MI...>]

I'm trying to construct modules that will take in lists of signals and
gang them together as address lines, where I don't want to manually
break out those signals or pre-invocation gang them into a single
signal. 

I can't for the life of me figure out how to do this -- basically, what
I want is 

from myhdl import *

def MyTestObject(listofsigs, myval):
    totallen = sum(len(x) for x in listofsigs)

    @always_comb
    def logic():
        myval.next = concat(*listofsigs)

    return logic

def MyTestObjectTwo(myval):
    listofsigs = [Signal(intbv(0)[4:]),
                  Signal(intbv(0)[6:])]

    to = MyTestObject(listofsigs, myval)
    return to


def test_MyTestObject():

    myval = Signal(intbv(0)[10:])

    toVerilog(MyTestObjectTwo, myval)
    

However, this complains that the signal elements don't have the same
bitwidth (not sure why?) When I use only a single signal I get: 

    Not supported: extra positional arguments

Which suggests that concat(*listofsigs) isn't going to work. 

I've looked at the "Conversion of lists of signals" in the 0.6
documentation, but I'm not entirely clear how its statements relate to
my problem. 

Anywho, this is part of a larger set of questions about what the "Right"
abstractions are for working with myHDL, which I'll leave for another
day. :)  Any help would be greatly appreciated, thanks again, 

		...Eric

Re: [myhdl-list] missing declaration of input?

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

Neal Becker wrote:
> I found that I had to edit the verilog output, adding a signed declaration.  
> Ideas?

If the ranges of x are defined like you did:
  x = Signal (intbv(0)[37:0])

it is always going to be "unsigned" (as in Verilog).

If you want it "signed", you have to use min and max for x also.

Jan

-- 
Jan Decaluwe - Resources bvba - http://www.jandecaluwe.com
    Python as an HDL: http://www.myhdl.org
    VHDL development, the modern way: http://www.sigasi.com
    Analog design automation: http://www.mephisto-da.com
    World-class digital design: http://www.easics.com

[myhdl-list] missing declaration of input?

[Neal B. <ndb...@gm...>]

I found that I had to edit the verilog output, adding a signed declaration.  
Ideas?

--------------------------------------------------
... def's of max_signed, min_signed 

def sat_rnd (x, bits, outbits, out):
    min_val = min_signed (len (x))
    max_val = max_signed (len (x))
    min_out = min_signed (outbits)
    max_out = max_signed (outbits)
    @always_comb
    def sat_rnd_logic():
        y1 = intbv (int (x >> (bits-1)), min_val, max_val)
        y2 = intbv (int (y1 + 1), min_val, max_val)
        y3 = intbv (int (y2 >> 1), min_val, max_val)
        if (y3 > max_out):
            out.next = max_out
        elif (y3 < min_out):
            out.next = min_out
        else:
            out.next = y3

    return sat_rnd_logic

x = Signal (intbv(0)[37:0])
out = Signal (intbv (0)[18:0])

def verilog():
    toVerilog.name = 'sat_rnd_36_18_18'
    toVerilog (sat_rnd, x, 18, 18, out)

if __name__ == "__main__":
    verilog()
------------------------------------------------

generated output:

-----------------------------------------------------
module sat_rnd_36_18_18 (
    x,
    out
);

input [36:0] x;
output [17:0] out;
reg [17:0] out;
   wire signed [36:0] x;  <<<<< NEED TO ADD THIS!!!
   



always @(x) begin: SAT_RND_36_18_18_SAT_RND_LOGIC
    reg signed [37-1:0] y1;
    reg signed [37-1:0] y3;
    reg signed [37-1:0] y2;
    y1 = (x >>> (18 - 1));
    y2 = (y1 + 1);
    y3 = $signed(y2 >>> 1);
    if ((y3 > 131071)) begin
        out <= 131071;
    end
    else if ((y3 < -131072)) begin
        out <= -131072;
    end
    else begin
        out <= y3;
    end
end

endmodule

Re: [myhdl-list] strange problem

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

Neal Becker wrote:

> That worked fine, until I needed to access (read) a variable also in another 
> generator.
> 
> I find that:
> 
> x = Signal (0)
> 
> def gen1...
>   x.next = x + 1
> 
> def gen2...
>   print x
> 
> Works fine, but if x was just a simple variable, say int, we have the 
> referenced before assignment (of course, using x = x+1 instead of x.next = 
> x+1).
> 
> Other than using a Signal, any other solution?  It seems silly to use Signal 
> for something that is just part of my test setup.

You could declare the int x as global inside your generators.

Or you could declare a global intbv and use x[:] = x + 1.

In both cases though, you loose the determinism that signals give
you. In other words, the behavior will depend on the (unspecified)
order in which generators are run by the simulator.

Jan

-- 
Jan Decaluwe - Resources bvba - http://www.jandecaluwe.com
    Python as an HDL: http://www.myhdl.org
    VHDL development, the modern way: http://www.sigasi.com
    Analog design automation: http://www.mephisto-da.com
    World-class digital design: http://www.easics.com

Re: [myhdl-list] strange problem

[Neal B. <ndb...@gm...>]

Jan Decaluwe wrote:

> Neal Becker wrote:
>> I'm still trying to wrap my head around myhdl.  This one is weird.
> 
> It is purely a Python scope issue. Consider:
> 
> def f():
>     n = 0
>     def g():
>             n += 1
>             print n
>     g()
> 
> f()
> 
> Running this gives:
> 
>> python tmp.py
> Traceback (most recent call last):
>   File "tmp.py", line 8, in <module>
>     f()
>   File "tmp.py", line 6, in f
>     g()
>   File "tmp.py", line 4, in g
>     n += 1
> UnboundLocalError: local variable 'n' referenced before assignment
> 
> 
> To understand what happens, consider that 'n += 1' is equivalent to:
>   n = n + 1
> 
> When you *assign* to n somewhere locally, Python considers it a
> local variable. As the n in the rhs as not been locally assigned yet,
> you get the error.
> Note that as long you don't assign to n, you would have read
> access to the n in the enclosing scope.
> 
> For your case, put the initialization in the generator before
> the while loop.
> 
> Jan
That worked fine, until I needed to access (read) a variable also in another 
generator.

I find that:

x = Signal (0)

def gen1...
  x.next = x + 1

def gen2...
  print x

Works fine, but if x was just a simple variable, say int, we have the 
referenced before assignment (of course, using x = x+1 instead of x.next = 
x+1).

Other than using a Signal, any other solution?  It seems silly to use Signal 
for something that is just part of my test setup.