myhdl-list — Mailing list for discussions on MyHDL

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

Re: [myhdl-list] MyHDL logic synthesis

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

Newell Jensen wrote:

> So in the end....if I am going to make optimisations and go through the 
> trouble of fine tunning things hopefully there is a direct mapping in 
> the conversion.

There is, for working code.

> Just to see if this was so I went and tried to code up 
> the second example here in MyHDL.  I got it to convert fine, but what I 
> got fails during synthesis for Xilinx ISE 10.1 (service pack is the 
> latest as well).  This is my myhdl module and following it is the 
> conversion:

Newell, here's a golden advice for using conversion.

    http://www.myhdl.org/doc/0.6/manual/conversion.html#simulate-first

Until you are very experienced with MyHDL and conversion, please
simulate first. I agree that the conversion could do a better job of
catching common errors, but due to the nature of Python, it will
never do as good a job as a simulation. Unless simulation works,
all bets are off for the meaningfulness of conversion.

Below you are doing signal assignment on variables. You would get
a run-time error in simulation immediately.

Unlike Verilog, MyHDL makes a distinction between signals and variables.

Signals are used for communication between generators:
    http://www.myhdl.org/doc/0.6/manual/intro.html#signals-ports-and-concurrency

However, you can also use them in a single generator just to get their
parallel semantics, as your example suggests. But you still have to define
them outside the generator as usual. Alternatively, you can use variables
but then you have to control the order carefully.

For example, using your original example:

>     @always(clk.posedge)
>     def logic():
>         XPower1 = intbv(min=0, max=256)
>         XPower2 = intbv(min=0, max=256)
>         X1 = intbv(min=0, max=256)
>         X2 = intbv(min=0, max=256)
>         # Pipeline stage one
>         X1.next = X
>         XPower1.next = X
>         # Pipeline stage two
>         X2.next = X1
>         XPower2.next = XPower1 * X1
>         # Pipeline stage three
>         XPower.next = XPower2 * X2
>            
>     return logic
>    

With signal semantics:

    XPower1 = Signal(intbv(min=0, max=256))
    XPower2 = Signal(intbv(min=0, max=256))
    X1 = Signal(intbv(min=0, max=256))
    X2 = Signal(intbv(min=0, max=256))
 
    @always(clk.posedge)
    def logic():
        # Pipeline stage one
        X1.next = X
        XPower1.next = X        
        # Pipeline stage two
        X2.next = X1
        XPower2.next = XPower1 * X1
        # Pipeline stage three
        XPower.next = XPower2 * X2

With variable semantics:

    @always(clk.posedge)
    def logic():
        XPower1 = intbv(min=0, max=256)
        XPower2 = intbv(min=0, max=256)
        X1 = intbv(min=0, max=256)
        X2 = intbv(min=0, max=256)
        # Pipeline stage three
        XPower[:] = XPower2 * X2
        # Pipeline stage two
        X2[:] = X1
        XPower2[:]= XPower1 * X1
         # Pipeline stage one
        X1[:] = X
        XPower1[:] = X        
    

Both case should simulate, convert, and sythesize similarly.
(Interesting test!)

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] MyHDL logic synthesis

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

On Mon, Mar 23, 2009 at 4:58 AM, Jan Decaluwe <ja...@ja...> wrote:

> Newell Jensen wrote:
> > Jan,
> >
> > Have you ever thought of giving MyHDL synthesis capabilities?
>
> No.
>
> Synthesis, the way I define it, would be a formidable task, certainly
> beyond my capabilities as an open-source developer.
>
> In addition to powerful HDL inference capabilites and logic minimization,
> my definition of synthesis includes timing-driven optimization with an
> integrated timing analyzer and powerful technology mapping, ideally
> including placement info from an integrated P&R tool.
>
> Morever, what would be the value proposition? Today I get these tools
> basically for free from Xilinx and Altera for their architecture.
>
>  > Icarus Verilog can synthesis designs and personally, I would find it a
> huge
> > advantage to not have to go the MyHDL --> Verilog route as there are
> > many things that are not convertable such as delays etc.
>
> I respect Stephen Williams very much and the value of Icarus the simulator
> if very clear to me, including its tremendous value to the MyHDL project.
> However, I don't see this for Icarus the synthesis tool.
> I don't believe it matches my definition of a synthesis tool. It's kind of
> hard to judge, as there is virtually no documentation that I can find,
> but I'm pretty sure we would have heard about it otherwise.
>
> So I suspect that after Icarus "synthesis" some other tool still has
> to perform some tasks (e.g. timing optimization) that I consider part
> of synthesis. In other words, it probably gives you an entry point
> at a somewhat lower level than Verilog RTL, in a tool flow that you
> have to run anyway, and which is basically free anyway.
> Again, what's the point?


There are a couple of points.

                                   As an example, consider the following
piece of
code that would most likely be used in a software implementation for finding
the
third power of X. Note that the term “software” here refers to code that is
targeted
at a set of procedural instructions that will be executed on a
microprocessor.
     XPower = 1;
     for (i=0;i < 3; i++)
        XPower = X * XPower;
Note that the above code is an iterative algorithm. The same variables and
addresses are accessed until the computation is complete. There is no use
for par-
allelism because a microprocessor only executes one instruction at a time
(for the
purpose of argument, just consider a single core processor). A similar
implemen-
tation can be created in hardware. Consider the following Verilog
implementation
of the same algorithm (output scaling not considered):
     module power3(
        output [7:0]      XPower,
        output            finished,
        input [7:0]       X,
        input             clk, start); // the duration of start is a
                                                single clock
        reg      [7:0] ncount;
        reg      [7:0] XPower;
        assign finished = (ncount == 0);
        always@(posedge clk)
           if(start) begin
              XPower <= X;
              ncount <= 2;
           end

           else if(!finished) begin
              ncount <= ncount - 1;
              XPower <= XPower * X;
           end
     endmodule
In the above example, the same register and computational resources are
reused
until the computation is finished as shown in Figure 1.1.
     With this type of iterative implementation, no new computations can
begin
until the previous computation has completed. This iterative scheme is very
similar to a software implementation. Also note that certain handshaking
signals
are required to indicate the beginning and completion of a computation. An
external module must also use the handshaking to pass new data to the module
and receive a completed calculation. The performance of this implementation
is
     Throughput 1⁄4 8/3, or 2.7 bits/clock
     Latency 1⁄4 3 clocks
     Timing 1⁄4 One multiplier delay in the critical path
Contrast this with a pipelined version of the same algorithm:
     module power3(
        output reg [7:0] XPower,
        input                  clk,
        input         [7:0] X
        );
        reg           [7:0] XPower1, XPower2;
        reg           [7:0] X1, X2;
        always @(posedge clk) begin
           // Pipeline stage 1
           X1        <= X;
           XPower1 <= X;
           // Pipeline stage 2
           X2        <= X1;
           XPower2 <= XPower1 * X1;
           // Pipeline stage 3
           XPower <= XPower2 * X2;
        end
     endmodule

In the above implementation, the value of X is passed to both pipeline
stages
where independent resources compute the corresponding multiply operation.
Note
that while X is being used to calculate the final power of 3 in the second
pipeline
stage, the next value of X can be sent to the first pipeline stage as shown
in
Figure 1.2.
     Both the final calculation of X3 (XPower3 resources) and the first
calculation
of the next value of X (XPower2 resources) occur simultaneously. The
perform-
ance of this design is
     Throughput 1⁄4 8/1, or 8 bits/clock
     Latency 1⁄4 3 clocks
     Timing 1⁄4 One multiplier delay in the critical path
The throughput performance increased by a factor of 3 over the iterative
implementation. In general, if an algorithm requiring n iterative loops is
“unrolled,” the pipelined implementation will exhibit a throughput
performance
increase of a factor of n. There was no penalty in terms of latency as the
pipelined
implementation still required 3 clocks to propagate the final computation.
Like-
wise, there was no timing penalty as the critical path still contained only
one
multiplier.

So in the end....if I am going to make optimisations and go through the
trouble of fine tunning things hopefully there is a direct mapping in the
conversion.  Just to see if this was so I went and tried to code up the
second example here in MyHDL.  I got it to convert fine, but what I got
fails during synthesis for Xilinx ISE 10.1 (service pack is the latest as
well).  This is my myhdl module and following it is the conversion:

from myhdl import *

def power3(
    XPower,
    X,
    clk):


    @always(clk.posedge)
    def logic():
        XPower1 = intbv(min=0, max=256)
        XPower2 = intbv(min=0, max=256)
        X1 = intbv(min=0, max=256)
        X2 = intbv(min=0, max=256)
        # Pipeline stage one
        X1.next = X
        XPower1.next = X
        # Pipeline stage two
        X2.next = X1
        XPower2.next = XPower1 * X1
        # Pipeline stage three
        XPower.next = XPower2 * X2

    return logic


def convert():

    XPower, X = [Signal(intbv(0)[8:]) for i in range(2)]
    clk = Signal(bool(0))

    toVerilog(power3, XPower, X, clk)

convert()

#############################################
// File: power3.v
// Generated by MyHDL 0.6
// Date: Mon Mar 23 20:15:45 2009

`timescale 1ns/10ps

module power3 (
    XPower,
    X,
    clk
);

output [7:0] XPower;
reg [7:0] XPower;
input [7:0] X;
input clk;




always @(posedge clk) begin: POWER3_LOGIC
    reg [8-1:0] X2;
    reg [8-1:0] X1;
    reg [8-1:0] XPower2;
    reg [8-1:0] XPower1;
    XPower1 = 0;
    XPower2 = 0;
    X1 = 0;
    X2 = 0;
    X1 <= X;
    XPower1 <= X;
    X2 <= X1;
    XPower2 <= (XPower1 * X1);
    XPower <= (XPower2 * X2);
end

endmodule


The Error that I am getting is --> Cannot mix blocking and non blocking
assignments on signal

So, maybe there is a way to define intermediate registers within the file
outside of the blocks?? I tried using an @instance block as well but got the
same results.

Any ideas??

This is one of the headaches of switching between one HDL and another....




>
>
> If I'm wrong, we can always wrap a synthesize() function around
> the Icarus engine :-)
>
>  From your question I infer that you assume that a direct synthesis
> flow from MyHDL would somehow remove some synthesis-related restrictions
> But that is not true. The restrictions would be just the same as
> today. They are there for Icarus synthesis also, believe me.
>
> However, those "synthesis restrictions" are in fact badly explained in
> text books. So what could be meaningful is to write a guide for
> "Efficient synthesis with MyHDL". (If I would do that, it would be
> totally different from what you read today. I would basically start
> with synchronous processes and flip-flop inferencing from variables.)
>
> > I haven't looked into what would need to happen to make this happen but
> > I wanted to ask you to see what you thought about this.
> >
> > Personaly, writing everything in Python would be a dream come true.
>
> For all practical purposes, for me this dream is true today. After a
> project
> is properly setup, conversion is hidden somewhere in a Makefile right
> before
> synthesis. Verilog is just one of the many back-end formats used by the
> back-end tools needed to go from MyHDL to an implementation. That's how
> I see it, and it works fine.
>
> Jan
>
> --
> Jan Decaluwe - Resources bvba - http://www.jandecaluwe.com
>     From Python to silicon:
>     http://www.myhdl.org
>
>
>
> ------------------------------------------------------------------------------
> Apps built with the Adobe(R) Flex(R) framework and Flex Builder(TM) are
> powering Web 2.0 with engaging, cross-platform capabilities. Quickly and
> easily build your RIAs with Flex Builder, the Eclipse(TM)based development
> software that enables intelligent coding and step-through debugging.
> Download the free 60 day trial. http://p.sf.net/sfu/www-adobe-com
> _______________________________________________
> myhdl-list mailing list
> myh...@li...
> https://lists.sourceforge.net/lists/listinfo/myhdl-list
>



-- 
Newell

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

Re: [myhdl-list] MyHDL logic synthesis

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

Newell Jensen wrote:
> Jan,
> 
> Have you ever thought of giving MyHDL synthesis capabilities?

No.

Synthesis, the way I define it, would be a formidable task, certainly
beyond my capabilities as an open-source developer.

In addition to powerful HDL inference capabilites and logic minimization,
my definition of synthesis includes timing-driven optimization with an
integrated timing analyzer and powerful technology mapping, ideally
including placement info from an integrated P&R tool.

Morever, what would be the value proposition? Today I get these tools
basically for free from Xilinx and Altera for their architecture.

 > Icarus Verilog can synthesis designs and personally, I would find it a huge
> advantage to not have to go the MyHDL --> Verilog route as there are 
> many things that are not convertable such as delays etc.

I respect Stephen Williams very much and the value of Icarus the simulator
if very clear to me, including its tremendous value to the MyHDL project.
However, I don't see this for Icarus the synthesis tool.
I don't believe it matches my definition of a synthesis tool. It's kind of
hard to judge, as there is virtually no documentation that I can find,
but I'm pretty sure we would have heard about it otherwise.

So I suspect that after Icarus "synthesis" some other tool still has
to perform some tasks (e.g. timing optimization) that I consider part
of synthesis. In other words, it probably gives you an entry point
at a somewhat lower level than Verilog RTL, in a tool flow that you
have to run anyway, and which is basically free anyway.
Again, what's the point?

If I'm wrong, we can always wrap a synthesize() function around
the Icarus engine :-)

 From your question I infer that you assume that a direct synthesis
flow from MyHDL would somehow remove some synthesis-related restrictions
But that is not true. The restrictions would be just the same as
today. They are there for Icarus synthesis also, believe me.

However, those "synthesis restrictions" are in fact badly explained in
text books. So what could be meaningful is to write a guide for
"Efficient synthesis with MyHDL". (If I would do that, it would be
totally different from what you read today. I would basically start
with synchronous processes and flip-flop inferencing from variables.)

> I haven't looked into what would need to happen to make this happen but 
> I wanted to ask you to see what you thought about this.
> 
> Personaly, writing everything in Python would be a dream come true.

For all practical purposes, for me this dream is true today. After a project
is properly setup, conversion is hidden somewhere in a Makefile right before
synthesis. Verilog is just one of the many back-end formats used by the
back-end tools needed to go from MyHDL to an implementation. That's how
I see it, and it works fine.

Jan

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

Re: [myhdl-list] MyHDL logic synthesis

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

Yes,
 
I agree with Newell Jensen.  I believe a synthesis capability built within MyHDL would also be a dream come true.  
 
David Blubaugh

--- On Sat, 3/21/09, Newell Jensen <pil...@gm...> wrote:


From: Newell Jensen <pil...@gm...>
Subject: Re: [myhdl-list] MyHDL logic synthesis
To: "General discussions on MyHDL" <myh...@li...>
Date: Saturday, March 21, 2009, 10:16 PM





On Sat, Mar 21, 2009 at 6:37 PM, Newell Jensen <pil...@gm...> wrote:

Jan,

Have you ever thought of giving MyHDL synthesis capabilities?  Icarus Verilog can synthesis designs and personally, I would find it a huge advantage to not have to go the MyHDL --> Verilog route as there are many things that are not convertable such as delays etc.

After re-reading this I realize that using a delays wasn't a good example.
 



I haven't looked into what would need to happen to make this happen but I wanted to ask you to see what you thought about this.

Personaly, writing everything in Python would be a dream come true.

-- 
Newell



-- 
Newell


-----Inline Attachment Follows-----


------------------------------------------------------------------------------
Apps built with the Adobe(R) Flex(R) framework and Flex Builder(TM) are
powering Web 2.0 with engaging, cross-platform capabilities. Quickly and
easily build your RIAs with Flex Builder, the Eclipse(TM)based development
software that enables intelligent coding and step-through debugging.
Download the free 60 day trial. http://p.sf.net/sfu/www-adobe-com
-----Inline Attachment Follows-----


_______________________________________________
myhdl-list mailing list
myh...@li...
https://lists.sourceforge.net/lists/listinfo/myhdl-list