myhdl-list — Mailing list for discussions on MyHDL

Re: [myhdl-list] Block return values (myhdl.BlockError)

[Henry G. <he...@ma...>]

On 10/05/16 13:09, Henry Gomersall wrote:
> On 10/05/16 12:30, Jan Decaluwe wrote:
>> > On 10/05/16 12:02, Henry Gomersall wrote:
>>>> >> > On 10/05/16 10:45, Henry Gomersall wrote:
>>>>>> >>> >> On 10/05/16 10:32, Jan Decaluwe wrote:
>>>>>>>>>> >>>>> >>>> I have considered this issue for some time now
>>>>>>>>>> >>>>> >>>> and I have basically decided to leave the constraints
>>>>>>>>>> >>>>> >>>> as they are, that is, blocks should only return
>>>>>>>>>> >>>>> >>>> block and instantiator objects.
>>>>>> >>> >> I think your reasoning is sound.
>>>>>> >>> >>
>>>>>> >>> >> Do you object to alternative strategies for constructing Block
>>>>>> >>> >> operators? This could leave @block as the default usual case, with more
>>>>>> >>> >> esoteric cases handled by direct access to the construction of the Block
>>>>>> >>> >> object. This could allow the best of both worlds - simple default and
>>>>>> >>> >> arbitrary control if desired.
>>>> >> >
>>>> >> > Actually, a neat solution could be to allow optional decorator arguments
>>>> >> > taking the class constructor and allow subclassing of _Block.
>>>> >> >
>> > Independent of this feature, decorator arguments may be
>> > useful, but as you know a decorator without arguments
>> > behaves completely differently from a decorator with
>> > arguments.
>> > 
>> > Until now, the only way I saw to handle both cases
>> > with a single decorator was with some ad-hoc check
>> > that I didn't find very elegant.
> Yeah this is an issue. There's a somewhat neat way using keyword args
> exclusively, but it does require keyword args (which is not overly
> restrictive since this would be an "advanced" feature).
> 
> In this case it might work reasonably neatly in the simpler case though
> since we can check it's either a callable or a _Block, and reject
> anything else.

To be clear, what is seen by a naive user need not changed.

Both @block and @block(MyCustomBlock) can be made to work.

Speaking of that, another solution is to have something like an
@custom_block() decorator which _must_ take an argument.

Henry

Re: [myhdl-list] Block return values (myhdl.BlockError)

[Henry G. <he...@ma...>]

On 10/05/16 12:30, Jan Decaluwe wrote:
> On 10/05/16 12:02, Henry Gomersall wrote:
>> > On 10/05/16 10:45, Henry Gomersall wrote:
>>> >> On 10/05/16 10:32, Jan Decaluwe wrote:
>>>>> >>>> I have considered this issue for some time now
>>>>> >>>> and I have basically decided to leave the constraints
>>>>> >>>> as they are, that is, blocks should only return
>>>>> >>>> block and instantiator objects.
>>> >> I think your reasoning is sound.
>>> >>
>>> >> Do you object to alternative strategies for constructing Block
>>> >> operators? This could leave @block as the default usual case, with more
>>> >> esoteric cases handled by direct access to the construction of the Block
>>> >> object. This could allow the best of both worlds - simple default and
>>> >> arbitrary control if desired.
>> >
>> > Actually, a neat solution could be to allow optional decorator arguments
>> > taking the class constructor and allow subclassing of _Block.
>> >
> Independent of this feature, decorator arguments may be
> useful, but as you know a decorator without arguments
> behaves completely differently from a decorator with
> arguments.
> 
> Until now, the only way I saw to handle both cases
> with a single decorator was with some ad-hoc check
> that I didn't find very elegant.

Yeah this is an issue. There's a somewhat neat way using keyword args
exclusively, but it does require keyword args (which is not overly
restrictive since this would be an "advanced" feature).

In this case it might work reasonably neatly in the simpler case though
since we can check it's either a callable or a _Block, and reject
anything else.

Henry

Re: [myhdl-list] Block return values (myhdl.BlockError)

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

On 10/05/16 12:02, Henry Gomersall wrote:
> On 10/05/16 10:45, Henry Gomersall wrote:
>> On 10/05/16 10:32, Jan Decaluwe wrote:
>>>> I have considered this issue for some time now
>>>> and I have basically decided to leave the constraints
>>>> as they are, that is, blocks should only return
>>>> block and instantiator objects.
>> I think your reasoning is sound.
>>
>> Do you object to alternative strategies for constructing Block
>> operators? This could leave @block as the default usual case, with more
>> esoteric cases handled by direct access to the construction of the Block
>> object. This could allow the best of both worlds - simple default and
>> arbitrary control if desired.
>
> Actually, a neat solution could be to allow optional decorator arguments
> taking the class constructor and allow subclassing of _Block.
>

Independent of this feature, decorator arguments may be
useful, but as you know a decorator without arguments
behaves completely differently from a decorator with
arguments.

Until now, the only way I saw to handle both cases
with a single decorator was with some ad-hoc check
that I didn't find very elegant.

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
   Urubu, a static website CMS: http://urubu.jandecaluwe.com

Re: [myhdl-list] Block return values (myhdl.BlockError)

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

On 10/05/16 11:45, Henry Gomersall wrote:
> On 10/05/16 10:32, Jan Decaluwe wrote:
>> I have considered this issue for some time now
>> and I have basically decided to leave the constraints
>> as they are, that is, blocks should only return
>> block and instantiator objects.
>
> I think your reasoning is sound.
>
> Do you object to alternative strategies for constructing Block
> operators? This could leave @block as the default usual case, with more
> esoteric cases handled by direct access to the construction of the Block
> object. This could allow the best of both worlds - simple default and
> arbitrary control if desired.

I have nothing against collecting good ideas.

However, for this specific feature, I am unconvinced
that the additional complexity is warranted. I may
change that opinion with future evidence - until
now it has only been brought up once as an alternative
possibility and does not seem enough.

My priority is moving forward with the simplifications
enabled by @block, and I believe there are several
much more relevant new features that these simplifications
will make possible.

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
   Urubu, a static website CMS: http://urubu.jandecaluwe.com

Re: [myhdl-list] Block return values (myhdl.BlockError)

[Henry G. <he...@ma...>]

On 10/05/16 11:02, Henry Gomersall wrote:
> super(self, _Block).__init__(
>             wrapper_func, deco, wrapper_srcfile,
>             wrapper_srcline, *args, **kwargs)

Of course, that should be

super(ExtractExtraArgsBlock, self).__init__(...)

Re: [myhdl-list] Block return values (myhdl.BlockError)

[Henry G. <he...@ma...>]

On 10/05/16 10:45, Henry Gomersall wrote:
> On 10/05/16 10:32, Jan Decaluwe wrote:
>> > I have considered this issue for some time now
>> > and I have basically decided to leave the constraints
>> > as they are, that is, blocks should only return
>> > block and instantiator objects.
> I think your reasoning is sound.
> 
> Do you object to alternative strategies for constructing Block
> operators? This could leave @block as the default usual case, with more
> esoteric cases handled by direct access to the construction of the Block
> object. This could allow the best of both worlds - simple default and
> arbitrary control if desired.

Actually, a neat solution could be to allow optional decorator arguments
taking the class constructor and allow subclassing of _Block.

e.g.

class MyBlock(_Block):

    @property
    def some_exposed_property(self):
        return 20

@block(block_class=MyBlock)
def foo():
    ...

In the case of handling alternative default args, it's simply a case
then of an alternative Block. Something like (untested so may be wrong)...

(it actually doesn't matter whether it is right or easy, it provides an
opportunity to add later).

class ExtractExtraArgsBlock(_Block):
    @property
    def extra_args(self):
        return extra_args

    def __init__(self, func, deco, srcfile, srcline, *args, **kwargs):
        self.extra_args = []
        def wrapper_func(*args, **kwargs):
            inst, output_stuff = func(*args, **kwargs)
            self.extra_args.append(output_stuff)
            return inst

        wrapper_srcfile = inspect.getsourcefile(wrapper_func)
        wrapper_srcline = inspect.getsourcelines(wrapper_func)[0]

        super(self, _Block).__init__(
            wrapper_func, deco, wrapper_srcfile,
            wrapper_srcline, *args, **kwargs)

Re: [myhdl-list] Block return values (myhdl.BlockError)

[Henry G. <he...@ma...>]

On 10/05/16 10:32, Jan Decaluwe wrote:
> I have considered this issue for some time now
> and I have basically decided to leave the constraints
> as they are, that is, blocks should only return
> block and instantiator objects.

I think your reasoning is sound.

Do you object to alternative strategies for constructing Block
operators? This could leave @block as the default usual case, with more
esoteric cases handled by direct access to the construction of the Block
object. This could allow the best of both worlds - simple default and
arbitrary control if desired.

Henry

Re: [myhdl-list] Block return values (myhdl.BlockError)

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

I have considered this issue for some time now
and I have basically decided to leave the constraints
as they are, that is, blocks should only return
block and instantiator objects. So I plan to reject
the requested feature. My rationale follows,
for the record.

The purpose of @block is to make MyHDL usage more
robust (checks and error reporting) and simplify
the code drastically (e.g. by removing the dubious
use of the profiler).

I did not find a good way to keep these advantages
while relaxing the constraints on the type of the
return values.

Here is why I believe the feature to return other
object types will not be missed that much.

First, it is "advanced" usage. People coming
from other HDLs will not think about it initially.
Instead, they will find it intuitive to use the
argument list for the interface, similar to
other HDLs.

Moreover, if we would have had @block early
on, I don't think anyone would have missed the
feature. After all, the intuitive workaround is
simply to use the argument list.

It is true that the feature would permit
parametrization of output ports inside
a block. However, I don't think it is bad
style to enforce to do this externally. After
all, the ports in question are external
signals.

Finally, the requested feature goes in the
opposite direction of other requests, that
is, to find a way to remove the "redundant"
return statement. (We may consider to
support a nonexisting return statement as an
indication to assemble blocks and instantiators
automatically.)

Jan

On 29/03/16 15:54, Jos Huisken wrote:
> Hi,
>
> Sometimes I'm using a block like this:
>
> def tb():
>      m, clk, rst = clkrst()
>      return m, clk, rst
>
> In which 'm' is the list of instantiator objects, and 'clk'/'rst' are
> Signals.
> So this way you can specify a block in general:
>
> def unit(inputports):
>      ...
>      return m, outputports
>
> Note that this could be a preferred way of design. It just happened that I
> created few such examples.
>
> With the new block decorator this is not allowed anymore, raising a
> myhdl.BlockError.
>
> I can imagine that also other return values may be wanted by users.
> Is this something which can be taken into account?
> Or: should 'block's really be constrained in returning just block or
> instantiator objects?
>
> Thanks,
> Jos
>
>
> ------------------------------------------------------------------------------
> Transform Data into Opportunity.
> Accelerate data analysis in your applications with
> Intel Data Analytics Acceleration Library.
> Click to learn more.
> http://pubads.g.doubleclick.net/gampad/clk?id=278785471&iu=/4140
>


-- 
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
   Urubu, a static website CMS: http://urubu.jandecaluwe.com

Re: [myhdl-list] Raun - Intro.

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

On 5/5/16 1:06 PM, Ravi Jain wrote:
> Hey Everyone!!
>
> Its Ravi Jain(Raun) from Surat, India. Pretty excited to work in GSOC
> this year. Will be working on implementing GEMAC core.

Welcome Ravi,

>
> @Guy@Tom@Christopher
> I had a question in mind. What should be our main goal while
> implementing the core using MyHDL? In other words, Why do we do it? The
> best reason i can think of is showoff the capabilities of the MyHDL
> language over other HDLs. (Mail from google recommending to improve the
> Project Abstract made me ask this question).

The reasons why we are doing these projects are: to
create more complex examples; increase the number of
cores implemented in MyHDL.

Often, when designers want to use a new language or
tool they also want to leverage existing cores,
kinda like a standard library.  Having high-quality,
readable, best practice implementations is very
valuable to this project.

> I have already setup the development environment - Eclipse in Windows
> with GTKWave to view wave forms.(Also tried Impulse integration with
> Eclipse). Still using MyHDL - 0.9 dev(Should i move to 1.0 or its fine
> in the beginning?).

During the bonding period it is fine to use 0.9, you
will want to move to 1.0 (dev) by the time of the
official period and make use of the `myhdl.block`
decorator.

> Now going through the manual all over again to brush up my basics for MyHDL.
> Any To Dos to complete before community bonding period is over? Book
> Suggestions if any for GEMAC/HDL?

There probably aren't any books that will discuss the
specifics of a GEMAC, you can review datasheets for
other cores and look and the reference implementation
mentioned in the project description.

Regards,
Chris

Re: [myhdl-list] Variable has same name as a hierarchical Signal

[David J. H. Jr. <da...@ad...>]

Your line is missing .next after r_write_n, no?

Change this:
r_write_n = x_write_n
into this:
r_write_n.next = x_write_n

On May 5, 2016 2:03:21 PM PDT, Edward Vidal <dev...@sb...> wrote:
>Hello All,
>
>Trying to convert the follow Verilog to MyHDL
>
>The Signals creating  the are the following
>reg x_write_n,r_write_n;
>
>    always @(posedge i_clk)
>    begin
>        { x_dstb_n, x_astb_n, x_write_n, x_depp }
>            <= { i_dstb_n, i_astb_n, i_write_n, i_depp };
>        { r_dstb_n, r_astb_n, r_write_n, r_depp }
>            <= { x_dstb_n, x_astb_n, x_write_n, x_depp };
>        { l_dstb_n, l_astb_n } <= { r_dstb_n, r_astb_n };
>    end
>
>    This is what I am doing.
>    @always(i_clk.posedge)
>    def rtl():
>        x_dstb_n.next = i_dstb_n
>        x_astb_n.next = i_astb_n
>        x_write_n.next = i_write_n
>        x_depp.next = i_depp
>       
>    @always(i_clk.posedge)
>    def rtl1():        
>        r_dstb_n.next = x_dstb_n
>        r_astb_n.next = x_astb_n
>        #r_write_n = x_write_n
>        r_depp.next = x_depp
>      
>    @always(i_clk.posedge)
>    def rtl2():        
>        l_dstb_n.next = r_dstb_n
>        l_astb_n.next = r_astb_n
>        
>The above code is adding 1 & 2 bit delays.
> In the simulation is see 1 clk delay between 
>i_dstb_n & x_dstb_ni_astb_n & x_astb_ni_write_n & x_write_ni_depp &
>x_depp
>In the simulation is see 2 clk delay between 
>i_dstb_n & r_dstb_n
>In the simulation is see 3 clk delay betweeni_dstb_n & l_dstb_n    
>The toVerilog goes okay with line  #r_write_n = x_write_n commented
>out.
>
>Uncommenting the line gets the follow error.
>        
>  File
>"/usr/local/lib/python2.7/dist-packages/myhdl-1.0dev-py2.7.egg/myhdl/conversion/_misc.py",
>line 149, in raiseError
>    raise ConversionError(kind, msg, info)
>myhdl.ConversionError: in file my_wbdepp.py, line 104:
>    Variable has same name as a hierarchical Signal 
>
>How do I convert these statements from Verilog to MyHDL.
>I recall reading the initial values was currently disabled.    
>    initial    x_dstb_n = 1'b1;
>    initial    r_dstb_n = 1'b1;
>    initial    l_dstb_n = 1'b1;
>    initial    x_astb_n = 1'b1;
>    initial    r_astb_n = 1'b1;
>    initial    l_astb_n = 1'b1;
>    
>Any and all help is appreciated.
>Thanks in advance. Edward Vidal Jr. e-mail dev...@sb...
>915-595-1613
>
>------------------------------------------------------------------------
>
>------------------------------------------------------------------------------
>Find and fix application performance issues faster with Applications
>Manager
>Applications Manager provides deep performance insights into multiple
>tiers of
>your business applications. It resolves application problems quickly
>and
>reduces your MTTR. Get your free trial!
>https://ad.doubleclick.net/ddm/clk/302982198;130105516;z
>
>------------------------------------------------------------------------
>
>_______________________________________________
>myhdl-list mailing list
>myh...@li...
>https://lists.sourceforge.net/lists/listinfo/myhdl-list

[myhdl-list] Variable has same name as a hierarchical Signal

[Edward V. <dev...@sb...>]

Hello All,

Trying to convert the follow Verilog to MyHDL

The Signals creating  the are the following
reg x_write_n,r_write_n;

    always @(posedge i_clk)
    begin
        { x_dstb_n, x_astb_n, x_write_n, x_depp }
            <= { i_dstb_n, i_astb_n, i_write_n, i_depp };
        { r_dstb_n, r_astb_n, r_write_n, r_depp }
            <= { x_dstb_n, x_astb_n, x_write_n, x_depp };
        { l_dstb_n, l_astb_n } <= { r_dstb_n, r_astb_n };
    end

    This is what I am doing.
    @always(i_clk.posedge)
    def rtl():
        x_dstb_n.next = i_dstb_n
        x_astb_n.next = i_astb_n
        x_write_n.next = i_write_n
        x_depp.next = i_depp
       
    @always(i_clk.posedge)
    def rtl1():        
        r_dstb_n.next = x_dstb_n
        r_astb_n.next = x_astb_n
        #r_write_n = x_write_n
        r_depp.next = x_depp
      
    @always(i_clk.posedge)
    def rtl2():        
        l_dstb_n.next = r_dstb_n
        l_astb_n.next = r_astb_n
        
The above code is adding 1 & 2 bit delays.
 In the simulation is see 1 clk delay between 
i_dstb_n & x_dstb_ni_astb_n & x_astb_ni_write_n & x_write_ni_depp & x_depp
In the simulation is see 2 clk delay between 
i_dstb_n & r_dstb_n
In the simulation is see 3 clk delay betweeni_dstb_n & l_dstb_n    
The toVerilog goes okay with line  #r_write_n = x_write_n commented out.

Uncommenting the line gets the follow error.
        
  File "/usr/local/lib/python2.7/dist-packages/myhdl-1.0dev-py2.7.egg/myhdl/conversion/_misc.py", line 149, in raiseError
    raise ConversionError(kind, msg, info)
myhdl.ConversionError: in file my_wbdepp.py, line 104:
    Variable has same name as a hierarchical Signal 

How do I convert these statements from Verilog to MyHDL.
I recall reading the initial values was currently disabled.    
    initial    x_dstb_n = 1'b1;
    initial    r_dstb_n = 1'b1;
    initial    l_dstb_n = 1'b1;
    initial    x_astb_n = 1'b1;
    initial    r_astb_n = 1'b1;
    initial    l_astb_n = 1'b1;
    
Any and all help is appreciated.
Thanks in advance. Edward Vidal Jr. e-mail dev...@sb... 915-595-1613

Re: [myhdl-list] Howto model a 16MHz clock?

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

Cristian,

The MyHDL simulator is a discrete simulator,
each time-step can only be an integer.  This
time-step is arbitrary it can map to any absolute
unit or none.  The MyHDL doesn't force a
time-unit on the simulation.

Absolute time doesn't mean much is the simulator,
if your design only has one clock you can use
what every integer number of simulation time-ticks
for your clock.  Example, I could  simply say
my 16MHz clock is 8 simulation  time-steps:

    @always(delay(4))
    def clock_generation():
        clock.next = not clock

If I do this, each simulation step will be 1/16e6/8
which is 7.8125ns.

Personally, I would simply make my "16MHz"
clock in simulation 16.1290323MHz (62 ns
period) and keep the 1 sim step == 1 ns mapping.


Regards,
Chris

On Wed, May 4, 2016 at 4:30 AM, Cristian Ramos <ram...@gm...>
wrote:

> Hi,
>
> The delay constructor only accepts integers:
>
> File "~/lib/python/myhdl-0.9.0-py2.7.egg/myhdl/_delay.py", line 39, in
> __init__ raise TypeError(_errmsg) TypeError: arg of delay constructor
> should be a natural integeer
>
> Also the Simulator object doesn't seem to accept a time resolution, like
> in Verilog, where you have a "timescale 1ns/100ps".
>
> So for a simple clock generator:
>
> def DRIVE_CLK():
> while True:
> yield delay(LOW)
> CLK_OUT.next = 1
> yield delay(HIGH)
> CLK_OUT.next = 0
>
>
> Where LOW and HIGH must be integers (ns), doesn't allow me to create an
> arbitrary clock frequency (like in 16MHz).
>
> Any ideas are very welcome!
>
> Thanks,
>
> Regards
> Cristian
>
> ------------------------------------------------------------------------------
> Find and fix application performance issues faster with Applications
> Manager
> Applications Manager provides deep performance insights into multiple
> tiers of
> your business applications. It resolves application problems quickly and
> reduces your MTTR. Get your free trial!
> https://ad.doubleclick.net/ddm/clk/302982198;130105516;z
> _______________________________________________
> myhdl-list mailing list
> myh...@li...
> https://lists.sourceforge.net/lists/listinfo/myhdl-list
>
>

[myhdl-list] Howto model a 16MHz clock?

[Cristian R. <ram...@gm...>]

Hi,

The delay constructor only accepts integers:

File "~/lib/python/myhdl-0.9.0-py2.7.egg/myhdl/_delay.py", line 39, in
__init__ raise TypeError(_errmsg) TypeError: arg of delay constructor
should be a natural integeer

Also the Simulator object doesn't seem to accept a time resolution, like in
Verilog, where you have a "timescale 1ns/100ps".

So for a simple clock generator:

def DRIVE_CLK():
while True:
yield delay(LOW)
CLK_OUT.next = 1
yield delay(HIGH)
CLK_OUT.next = 0


Where LOW and HIGH must be integers (ns), doesn't allow me to create an
arbitrary clock frequency (like in 16MHz).

Any ideas are very welcome!

Thanks,

Regards
Cristian

Re: [myhdl-list] myhdl & co-simulation

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

On Sun, May 1, 2016 at 12:53 PM, Edward Vidal <dev...@sb...>
wrote:

> <snip>
>
> Should I create both a myhdl instance and instance in file
> tb_wbdeppsimple.v?
>

It depends on what you want to do.  If you want to create
the testbench in MyHDL then you want to connect the
MyHDL simulation to the Verilog simulation (Cosimulation).
If you want to do Verilog simulation only, you can do as you
have done and include the converted MyHDL blocks into
the Verilog.

Hope that helps,
Chris

Re: [myhdl-list] problem compile myhdl.vpi in windows

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

Which version of icarus are you using?

Regards,
Chris

On Mon, May 2, 2016 at 10:02 PM, <chr...@si...> wrote:

> Hi,  when I compile myhdl for iverilog in cygwin, it report error
>
> iverilog-vpi myhdl.c myhdl_table.c
> gcc: fatal error: input file ‘myhdl.c’ is the same as output file
>
> Is there any hint how to solve the problem. Oh there is binary myhdl.vpi
> for use?
>
> Thanks!
> chriss
>
> ------------------------------------------------------------------------------
> Find and fix application performance issues faster with Applications
> Manager
> Applications Manager provides deep performance insights into multiple
> tiers of
> your business applications. It resolves application problems quickly and
> reduces your MTTR. Get your free trial!
> https://ad.doubleclick.net/ddm/clk/302982198;130105516;z
> _______________________________________________
> myhdl-list mailing list
> myh...@li...
> https://lists.sourceforge.net/lists/listinfo/myhdl-list
>

[myhdl-list] problem compile myhdl.vpi in windows

[<chr...@si...>]

Hi,  when I compile myhdl for iverilog in cygwin, it report error

iverilog-vpi myhdl.c myhdl_table.c
gcc: fatal error: input file ‘myhdl.c’ is the same as output file

Is there any hint how to solve the problem. Oh there is binary myhdl.vpi for use?

Thanks!
chriss

Re: [myhdl-list] More thoughts and code towards dynamic code generation

[Henry G. <he...@ma...>]

On 02/05/16 22:00, Henry Gomersall wrote:
> Essentially it seems like a fairly easy operation to have an extra layer
> of elaboration to expand python stuff into convertible stuff.

Sorry, *more arbitrary* python stuff into convertible *python* stuff.

Henry

Re: [myhdl-list] More thoughts and code towards dynamic code generation

[Henry G. <he...@ma...>]

On 02/05/16 13:12, Henry Gomersall wrote:
> On 02/05/16 12:50, Jan Decaluwe wrote:
>> > Is the generated code convertible? Then we have an automated path
>> > from initial code to silicon, and the problem is solved as
>> > far as I am concerned.
> :)
> 
> I think this could a be a really powerful technique. I'm going to have a
> play with it now - looking at e.g. auto loop unrolling.

Whoa! This is really powerful.

I've not yet done anything to show it off (more than Samuele has done
anyway), but it looks like it fits really neatly with the block operator
- inspecting and dynamically twiddling the code therein.

Essentially it seems like a fairly easy operation to have an extra layer
of elaboration to expand python stuff into convertible stuff.

Bear with me, I'll have something soonish to talk about.

Samuele, I'm keen to interact on this, but I need to have a play by
myself a bit I think first (to thoroughly understand it).

Henry

Re: [myhdl-list] More thoughts and code towards dynamic code generation

[Samuele D. <sm...@gm...>]

Yes it is!
it is a fairly simple approach but we might need some clever thoughts about
what the user expect to get from it and how we want to get resulting
generated code:
-should it generate a new parsed file (as my example)?
-should it replace the function instance at runtime while simulating?

The nice thing of this approach is that it is orthogonal to MyHDL
development because it aims to refactor the source code to a MyHDL
compatible one.

If someone has some code that needs this I can look at it and start to
investigate all the different approaches.
Or I can look at VHDL and other modern languages and try to reach feature
parity with them (first case is better because as you said we have much
many capabilities in MyHDL, and therefore we can do better)

Henry G., let me know how we can interact if you are interested!

:),
  Samuele

On Mon, May 2, 2016 at 1:50 PM, Jan Decaluwe <ja...@ja...> wrote:

> Is the generated code convertible? Then we have an automated path
> from initial code to silicon, and the problem is solved as
> far as I am concerned.
>
> On 02/05/16 13:10, Samuele Disegna wrote:
> >
> > How would you use current MyHDL features to produce something like this
> that is convertible? I am  dynamically replicating the elif template inside
> this always block:
> >
> >      bi_redbaron = [i for i in range(2,6)]
> >      @always(clk.posedge)
> >      @redBaronGenerate(i_redbaron)
> >      def feedback_address_generator():
> >          if count[n-1] == 0:
> >              feedback_address.next =
> concat(count[n:n-1],count[n-2:1],count[n-2],count[0])
> >          elif count[n-i_redbaron] == 0:
> >              feedback_address.next =
> concat(count[n:n-i_redbaron],count[n-i_redbaron-1:1],
> >
>  count[n-i_redbaron-1],count[0])
> >          else:
> >              feedback_address.next = count
> >
> >
> > Generated code is:
> >
> >      @always(clk.posedge)
> >      def feedback_address_generator():
> >          if count[n-1] == 0:
> >              feedback_address.next =
> concat(count[n:n-1],count[n-2:1],count[n-2],count[0])
> >          elif count[n-2] == 0:
> >              feedback_address.next = concat(count[n:n-2],count[n-2-1:1],
> count[n-2-1],count[0])
> >          elif count[n-3] == 0:
> >              feedback_address.next =
> concat(count[n:n-3],count[n-3-1:1],count[n-3-1],count[0])
> >          elif count[n-4] == 0:
> >              feedback_address.next =
> concat(count[n:n-4],count[n-4-1:1],count[n-4-1],count[0])
> >          elif count[n-5] == 0:
> >              feedback_address.next =
> concat(count[n:n-5],count[n-5-1:1],count[n-5-1],count[0])
> >          else:
> >              feedback_address.next = count
> >
> > On Mon, May 2, 2016 at 12:04 PM, Jan Decaluwe <ja...@ja...
> <mailto:ja...@ja...>> wrote:
> >
> >     On 01/05/16 23:22, Samuele Disegna wrote:
> >     > Hello,
> >     >
> >     > Finally I have some contributions to the project:
> >     > After seeing some questions about  VHDL "generate" like
> capabilities for MyHDL I started thinking about a solution.
> >
> >     I am not following. MyHDL "generate" is much more
> >     powerful than VHDL can offer, including for conversion
> >     because you can use the Python interpreter to elaborate
> >     your code you first.
> >
> >
> >      > It is only a proof of concept, let me know your thoughts!
> >      > The following code uses RedBaron to inspect and refactor itself
> in order to generate an elif statement list.
> >      > A decorator is used for targeting the function to analyze:
> >      >
> >      > from myhdl import *
> >      > from functools import wraps
> >      > import inspect
> >      > from redbaron import RedBaron
> >      >
> >      > i_redbaron = [i for i in range(2,6)]
> >      > def redBaronGenerate(i_redbaron):
> >      >      def real_redBaronGenerate(func):
> >      >          with open(inspect.getsourcefile(func), "r") as
> source_file:
> >      >              red = RedBaron(source_file.read())
> >      >              #find the decoratornode and the definition node
> (parent of the former)
> >      >              node = red.find("decorator", lambda x:
> x.value.value.name.value == "redBaronGenerate")
> >      >              defnode = node.parent
> >      >              #delete the decorator
> >      >              del defnode.decorators[node.index_on_parent]
> >      >              #search elif
> >      >              elifnode = defnode.find("elif")
> >      >              #iterate for elif insertions as desired
> >      >              start =elifnode.index_on_parent
> >      >              for i,elifindex in zip(i_redbaron ,
> range(start,start+len(i_redbaron))):
> >      >                  # prepare the elif template
> >      >                  elifnodetemplate = elifnode.copy()
> >      >                  for node in
> elifnodetemplate.findAll("name","i_redbaron"):
> >      >                      node.replace(str(i))
> >      >                  #insert the node
> >      >
> elifnode.parent.value.insert(elifindex,elifnodetemplate)
> >      >              #delete the template
> >      >              del elifnode.parent.value[elifnode.index_on_parent]
> >      >              #we dump the result to a file as a demonstration
> purpose
> >      >              #we could try also to substitute the function with
> the newer at runtime
> >      >              with open("address_gens_redbaron.py", "w") as
> source_file:
> >      >                  source_file.write(red.dumps())
> >      >          @wraps(func)
> >      >          def wrapper(*args, **kwds):
> >      >              return func(*args, **kwds)
> >      >          return wrapper
> >      >      return real_redBaronGenerate
> >      >
> >      > @block
> >      > def address_gens(clk,count,datain_address,feedback_address):
> >      >      n = len(count)
> >      >
> >      >      @always(clk.posedge)
> >      >      def address_counter():
> >      >          count.next = count +1
> >      >
> >      >      @always(clk.posedge)
> >      >      def datain_address_generator():
> >      >          datain_address.next =
> concat(count[n-2:0],count[n-2],count[n-1])
> >      >
> >      >      @always(clk.posedge)
> >      >      @redBaronGenerate(i_redbaron)
> >      >      def feedback_address_generator():
> >      >          #REDBARON for i_redbaron in range(1,5)
> >      >          if count[n-1] == 0:
> >      >              feedback_address.next =
> concat(count[n:n-1],count[n-2:1],count[n-2],count[0])
> >      >          elif count[n-i_redbaron] == 0:
> >      >              feedback_address.next =
> concat(count[n:n-i_redbaron],count[n-i_redbaron-1:1],
> >      >
>  count[n-i_redbaron-1],count[0])
> >      >          else:
> >      >              feedback_address.next = count #and last 2 values are
> not important (actually one could be used to do half of the last butterfly)
> >      >
> >      >      return
> address_counter,datain_address_generator,feedback_address_generator
> >      >
> >      >
> >      > if __name__ == "__main__":
> >      >      @block
> >      >      def ClkDriver(clk,halfperiod):
> >      >          @always(delay(halfperiod))
> >      >          def driveClk():
> >      >              clk.next = not clk
> >      >          return driveClk
> >      >      @block
> >      >      def tb(clk,count,dina,fa):
> >      >          clk_driver = ClkDriver(clk,5)
> >      >          a_gen = address_gens(clk,count,dina,fa)
> >      >          return clk_driver,a_gen
> >      >
> >      >      clk = Signal(False)
> >      >      count = Signal(modbv(0,_nrbits=8))
> >      >      dina = Signal(intbv(0,_nrbits=8))
> >      >      fa = Signal(intbv(0,_nrbits=8))
> >      >
> >      >      #address_gens(clk,count,fa).convert(hdl='Verilog')
> >      >
> >      >      tb1 = tb(clk,count,dina,fa)
> >      >      tb1.config_sim(trace=True)
> >      >
> >      >
> >      >
> >      >
> ------------------------------------------------------------------------------
> >      > Find and fix application performance issues faster with
> Applications Manager
> >      > Applications Manager provides deep performance insights into
> multiple tiers of
> >      > your business applications. It resolves application problems
> quickly and
> >      > reduces your MTTR. Get your free trial!
> >      > https://ad.doubleclick.net/ddm/clk/302982198;130105516;z
> >      >
> >      >
> >      >
> >      > _______________________________________________
> >      > myhdl-list mailing list
> >      > myh...@li... <mailto:
> myh...@li...>
> >      > https://lists.sourceforge.net/lists/listinfo/myhdl-list
> >      >
> >
> >
> >     --
> >     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
> >         Urubu, a static website CMS: http://urubu.jandecaluwe.com
> >
> >
> >
>  ------------------------------------------------------------------------------
> >     Find and fix application performance issues faster with Applications
> Manager
> >     Applications Manager provides deep performance insights into
> multiple tiers of
> >     your business applications. It resolves application problems quickly
> and
> >     reduces your MTTR. Get your free trial!
> >     https://ad.doubleclick.net/ddm/clk/302982198;130105516;z
> >     _______________________________________________
> >     myhdl-list mailing list
> >     myh...@li... <mailto:
> myh...@li...>
> >     https://lists.sourceforge.net/lists/listinfo/myhdl-list
> >
> >
> >
> >
> >
> ------------------------------------------------------------------------------
> > Find and fix application performance issues faster with Applications
> Manager
> > Applications Manager provides deep performance insights into multiple
> tiers of
> > your business applications. It resolves application problems quickly and
> > reduces your MTTR. Get your free trial!
> > https://ad.doubleclick.net/ddm/clk/302982198;130105516;z
> >
> >
> >
> > _______________________________________________
> > myhdl-list mailing list
> > myh...@li...
> > https://lists.sourceforge.net/lists/listinfo/myhdl-list
> >
>
>
> --
> 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
>    Urubu, a static website CMS: http://urubu.jandecaluwe.com
>
>
>
> ------------------------------------------------------------------------------
> Find and fix application performance issues faster with Applications
> Manager
> Applications Manager provides deep performance insights into multiple
> tiers of
> your business applications. It resolves application problems quickly and
> reduces your MTTR. Get your free trial!
> https://ad.doubleclick.net/ddm/clk/302982198;130105516;z
> _______________________________________________
> myhdl-list mailing list
> myh...@li...
> https://lists.sourceforge.net/lists/listinfo/myhdl-list
>

Re: [myhdl-list] More thoughts and code towards dynamic code generation

[Henry G. <he...@ma...>]

On 02/05/16 12:50, Jan Decaluwe wrote:
> Is the generated code convertible? Then we have an automated path
> from initial code to silicon, and the problem is solved as
> far as I am concerned.

:)

I think this could a be a really powerful technique. I'm going to have a
play with it now - looking at e.g. auto loop unrolling.

There is potentially a really neat tool flow here:

Python -> High level translation library -> convertible code -> V*

Currently, the convertible code has to be hand crafted, but it would be
really cool if we could have an interim library that takes a MyHDL
hierarchy and translates the functions into convertible code. It means
complex cases can be handled through the translation library without it
making the converter code unwieldy.

I looked at PyPy for this a little while ago, but it was hard to
penetrate (not least because of the rather dismissive response from the
pypy developers) - Redbaron looks like it might be better suited to the
problem (largely because it looks like it doesn't require any backend
changes to the MyHDL converter code).

Henry

Re: [myhdl-list] More thoughts and code towards dynamic code generation

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

Is the generated code convertible? Then we have an automated path
from initial code to silicon, and the problem is solved as
far as I am concerned.

On 02/05/16 13:10, Samuele Disegna wrote:
>
> How would you use current MyHDL features to produce something like this that is convertible? I am  dynamically replicating the elif template inside this always block:
>
>      bi_redbaron = [i for i in range(2,6)]
>      @always(clk.posedge)
>      @redBaronGenerate(i_redbaron)
>      def feedback_address_generator():
>          if count[n-1] == 0:
>              feedback_address.next = concat(count[n:n-1],count[n-2:1],count[n-2],count[0])
>          elif count[n-i_redbaron] == 0:
>              feedback_address.next = concat(count[n:n-i_redbaron],count[n-i_redbaron-1:1],
>                                             count[n-i_redbaron-1],count[0])
>          else:
>              feedback_address.next = count
>
>
> Generated code is:
>
>      @always(clk.posedge)
>      def feedback_address_generator():
>          if count[n-1] == 0:
>              feedback_address.next = concat(count[n:n-1],count[n-2:1],count[n-2],count[0])
>          elif count[n-2] == 0:
>              feedback_address.next = concat(count[n:n-2],count[n-2-1:1], count[n-2-1],count[0])
>          elif count[n-3] == 0:
>              feedback_address.next = concat(count[n:n-3],count[n-3-1:1],count[n-3-1],count[0])
>          elif count[n-4] == 0:
>              feedback_address.next = concat(count[n:n-4],count[n-4-1:1],count[n-4-1],count[0])
>          elif count[n-5] == 0:
>              feedback_address.next = concat(count[n:n-5],count[n-5-1:1],count[n-5-1],count[0])
>          else:
>              feedback_address.next = count
>
> On Mon, May 2, 2016 at 12:04 PM, Jan Decaluwe <ja...@ja... <mailto:ja...@ja...>> wrote:
>
>     On 01/05/16 23:22, Samuele Disegna wrote:
>     > Hello,
>     >
>     > Finally I have some contributions to the project:
>     > After seeing some questions about  VHDL "generate" like capabilities for MyHDL I started thinking about a solution.
>
>     I am not following. MyHDL "generate" is much more
>     powerful than VHDL can offer, including for conversion
>     because you can use the Python interpreter to elaborate
>     your code you first.
>
>
>      > It is only a proof of concept, let me know your thoughts!
>      > The following code uses RedBaron to inspect and refactor itself in order to generate an elif statement list.
>      > A decorator is used for targeting the function to analyze:
>      >
>      > from myhdl import *
>      > from functools import wraps
>      > import inspect
>      > from redbaron import RedBaron
>      >
>      > i_redbaron = [i for i in range(2,6)]
>      > def redBaronGenerate(i_redbaron):
>      >      def real_redBaronGenerate(func):
>      >          with open(inspect.getsourcefile(func), "r") as source_file:
>      >              red = RedBaron(source_file.read())
>      >              #find the decoratornode and the definition node (parent of the former)
>      >              node = red.find("decorator", lambda x: x.value.value.name.value == "redBaronGenerate")
>      >              defnode = node.parent
>      >              #delete the decorator
>      >              del defnode.decorators[node.index_on_parent]
>      >              #search elif
>      >              elifnode = defnode.find("elif")
>      >              #iterate for elif insertions as desired
>      >              start =elifnode.index_on_parent
>      >              for i,elifindex in zip(i_redbaron , range(start,start+len(i_redbaron))):
>      >                  # prepare the elif template
>      >                  elifnodetemplate = elifnode.copy()
>      >                  for node in elifnodetemplate.findAll("name","i_redbaron"):
>      >                      node.replace(str(i))
>      >                  #insert the node
>      >                  elifnode.parent.value.insert(elifindex,elifnodetemplate)
>      >              #delete the template
>      >              del elifnode.parent.value[elifnode.index_on_parent]
>      >              #we dump the result to a file as a demonstration purpose
>      >              #we could try also to substitute the function with the newer at runtime
>      >              with open("address_gens_redbaron.py", "w") as source_file:
>      >                  source_file.write(red.dumps())
>      >          @wraps(func)
>      >          def wrapper(*args, **kwds):
>      >              return func(*args, **kwds)
>      >          return wrapper
>      >      return real_redBaronGenerate
>      >
>      > @block
>      > def address_gens(clk,count,datain_address,feedback_address):
>      >      n = len(count)
>      >
>      >      @always(clk.posedge)
>      >      def address_counter():
>      >          count.next = count +1
>      >
>      >      @always(clk.posedge)
>      >      def datain_address_generator():
>      >          datain_address.next = concat(count[n-2:0],count[n-2],count[n-1])
>      >
>      >      @always(clk.posedge)
>      >      @redBaronGenerate(i_redbaron)
>      >      def feedback_address_generator():
>      >          #REDBARON for i_redbaron in range(1,5)
>      >          if count[n-1] == 0:
>      >              feedback_address.next = concat(count[n:n-1],count[n-2:1],count[n-2],count[0])
>      >          elif count[n-i_redbaron] == 0:
>      >              feedback_address.next = concat(count[n:n-i_redbaron],count[n-i_redbaron-1:1],
>      >                                             count[n-i_redbaron-1],count[0])
>      >          else:
>      >              feedback_address.next = count #and last 2 values are not important (actually one could be used to do half of the last butterfly)
>      >
>      >      return address_counter,datain_address_generator,feedback_address_generator
>      >
>      >
>      > if __name__ == "__main__":
>      >      @block
>      >      def ClkDriver(clk,halfperiod):
>      >          @always(delay(halfperiod))
>      >          def driveClk():
>      >              clk.next = not clk
>      >          return driveClk
>      >      @block
>      >      def tb(clk,count,dina,fa):
>      >          clk_driver = ClkDriver(clk,5)
>      >          a_gen = address_gens(clk,count,dina,fa)
>      >          return clk_driver,a_gen
>      >
>      >      clk = Signal(False)
>      >      count = Signal(modbv(0,_nrbits=8))
>      >      dina = Signal(intbv(0,_nrbits=8))
>      >      fa = Signal(intbv(0,_nrbits=8))
>      >
>      >      #address_gens(clk,count,fa).convert(hdl='Verilog')
>      >
>      >      tb1 = tb(clk,count,dina,fa)
>      >      tb1.config_sim(trace=True)
>      >
>      >
>      >
>      > ------------------------------------------------------------------------------
>      > Find and fix application performance issues faster with Applications Manager
>      > Applications Manager provides deep performance insights into multiple tiers of
>      > your business applications. It resolves application problems quickly and
>      > reduces your MTTR. Get your free trial!
>      > https://ad.doubleclick.net/ddm/clk/302982198;130105516;z
>      >
>      >
>      >
>      > _______________________________________________
>      > myhdl-list mailing list
>      > myh...@li... <mailto:myh...@li...>
>      > https://lists.sourceforge.net/lists/listinfo/myhdl-list
>      >
>
>
>     --
>     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
>         Urubu, a static website CMS: http://urubu.jandecaluwe.com
>
>
>     ------------------------------------------------------------------------------
>     Find and fix application performance issues faster with Applications Manager
>     Applications Manager provides deep performance insights into multiple tiers of
>     your business applications. It resolves application problems quickly and
>     reduces your MTTR. Get your free trial!
>     https://ad.doubleclick.net/ddm/clk/302982198;130105516;z
>     _______________________________________________
>     myhdl-list mailing list
>     myh...@li... <mailto:myh...@li...>
>     https://lists.sourceforge.net/lists/listinfo/myhdl-list
>
>
>
>
> ------------------------------------------------------------------------------
> Find and fix application performance issues faster with Applications Manager
> Applications Manager provides deep performance insights into multiple tiers of
> your business applications. It resolves application problems quickly and
> reduces your MTTR. Get your free trial!
> https://ad.doubleclick.net/ddm/clk/302982198;130105516;z
>
>
>
> _______________________________________________
> myhdl-list mailing list
> myh...@li...
> https://lists.sourceforge.net/lists/listinfo/myhdl-list
>


-- 
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
   Urubu, a static website CMS: http://urubu.jandecaluwe.com

Re: [myhdl-list] More thoughts and code towards dynamic code generation

[Samuele D. <sm...@gm...>]

How would you use current MyHDL features to produce something like this
that is convertible? I am  dynamically replicating the elif template inside
this always block:

    bi_redbaron = [i for i in range(2,6)]
    @always(clk.posedge)
    @redBaronGenerate(i_redbaron)
    def feedback_address_generator():
        if count[n-1] == 0:
            feedback_address.next =
concat(count[n:n-1],count[n-2:1],count[n-2],count[0])
        elif count[n-i_redbaron] == 0:
            feedback_address.next =
concat(count[n:n-i_redbaron],count[n-i_redbaron-1:1],
                                           count[n-i_redbaron-1],count[0])
        else:
            feedback_address.next = count


Generated code is:

    @always(clk.posedge)
    def feedback_address_generator():
        if count[n-1] == 0:
            feedback_address.next =
concat(count[n:n-1],count[n-2:1],count[n-2],count[0])
        elif count[n-2] == 0:
            feedback_address.next = concat(count[n:n-2],count[n-2-1:1],
count[n-2-1],count[0])
        elif count[n-3] == 0:
            feedback_address.next = concat(count[n:n-3],count[n-3-1:1],
count[n-3-1],count[0])
        elif count[n-4] == 0:
            feedback_address.next = concat(count[n:n-4],count[n-4-1:1],
count[n-4-1],count[0])
        elif count[n-5] == 0:
            feedback_address.next = concat(count[n:n-5],count[n-5-1:1],
count[n-5-1],count[0])
        else:
            feedback_address.next = count

On Mon, May 2, 2016 at 12:04 PM, Jan Decaluwe <ja...@ja...> wrote:

> On 01/05/16 23:22, Samuele Disegna wrote:
> > Hello,
> >
> > Finally I have some contributions to the project:
> > After seeing some questions about  VHDL "generate" like capabilities for
> MyHDL I started thinking about a solution.
>
> I am not following. MyHDL "generate" is much more
> powerful than VHDL can offer, including for conversion
> because you can use the Python interpreter to elaborate
> your code you first.
>
>
> > It is only a proof of concept, let me know your thoughts!
> > The following code uses RedBaron to inspect and refactor itself in order
> to generate an elif statement list.
> > A decorator is used for targeting the function to analyze:
> >
> > from myhdl import *
> > from functools import wraps
> > import inspect
> > from redbaron import RedBaron
> >
> > i_redbaron = [i for i in range(2,6)]
> > def redBaronGenerate(i_redbaron):
> >      def real_redBaronGenerate(func):
> >          with open(inspect.getsourcefile(func), "r") as source_file:
> >              red = RedBaron(source_file.read())
> >              #find the decoratornode and the definition node (parent of
> the former)
> >              node = red.find("decorator", lambda x:
> x.value.value.name.value == "redBaronGenerate")
> >              defnode = node.parent
> >              #delete the decorator
> >              del defnode.decorators[node.index_on_parent]
> >              #search elif
> >              elifnode = defnode.find("elif")
> >              #iterate for elif insertions as desired
> >              start =elifnode.index_on_parent
> >              for i,elifindex in zip(i_redbaron ,
> range(start,start+len(i_redbaron))):
> >                  # prepare the elif template
> >                  elifnodetemplate = elifnode.copy()
> >                  for node in
> elifnodetemplate.findAll("name","i_redbaron"):
> >                      node.replace(str(i))
> >                  #insert the node
> >                  elifnode.parent.value.insert(elifindex,elifnodetemplate)
> >              #delete the template
> >              del elifnode.parent.value[elifnode.index_on_parent]
> >              #we dump the result to a file as a demonstration purpose
> >              #we could try also to substitute the function with the
> newer at runtime
> >              with open("address_gens_redbaron.py", "w") as source_file:
> >                  source_file.write(red.dumps())
> >          @wraps(func)
> >          def wrapper(*args, **kwds):
> >              return func(*args, **kwds)
> >          return wrapper
> >      return real_redBaronGenerate
> >
> > @block
> > def address_gens(clk,count,datain_address,feedback_address):
> >      n = len(count)
> >
> >      @always(clk.posedge)
> >      def address_counter():
> >          count.next = count +1
> >
> >      @always(clk.posedge)
> >      def datain_address_generator():
> >          datain_address.next = concat(count[n-2:0],count[n-2],count[n-1])
> >
> >      @always(clk.posedge)
> >      @redBaronGenerate(i_redbaron)
> >      def feedback_address_generator():
> >          #REDBARON for i_redbaron in range(1,5)
> >          if count[n-1] == 0:
> >              feedback_address.next =
> concat(count[n:n-1],count[n-2:1],count[n-2],count[0])
> >          elif count[n-i_redbaron] == 0:
> >              feedback_address.next =
> concat(count[n:n-i_redbaron],count[n-i_redbaron-1:1],
> >
>  count[n-i_redbaron-1],count[0])
> >          else:
> >              feedback_address.next = count #and last 2 values are not
> important (actually one could be used to do half of the last butterfly)
> >
> >      return
> address_counter,datain_address_generator,feedback_address_generator
> >
> >
> > if __name__ == "__main__":
> >      @block
> >      def ClkDriver(clk,halfperiod):
> >          @always(delay(halfperiod))
> >          def driveClk():
> >              clk.next = not clk
> >          return driveClk
> >      @block
> >      def tb(clk,count,dina,fa):
> >          clk_driver = ClkDriver(clk,5)
> >          a_gen = address_gens(clk,count,dina,fa)
> >          return clk_driver,a_gen
> >
> >      clk = Signal(False)
> >      count = Signal(modbv(0,_nrbits=8))
> >      dina = Signal(intbv(0,_nrbits=8))
> >      fa = Signal(intbv(0,_nrbits=8))
> >
> >      #address_gens(clk,count,fa).convert(hdl='Verilog')
> >
> >      tb1 = tb(clk,count,dina,fa)
> >      tb1.config_sim(trace=True)
> >
> >
> >
> >
> ------------------------------------------------------------------------------
> > Find and fix application performance issues faster with Applications
> Manager
> > Applications Manager provides deep performance insights into multiple
> tiers of
> > your business applications. It resolves application problems quickly and
> > reduces your MTTR. Get your free trial!
> > https://ad.doubleclick.net/ddm/clk/302982198;130105516;z
> >
> >
> >
> > _______________________________________________
> > myhdl-list mailing list
> > myh...@li...
> > https://lists.sourceforge.net/lists/listinfo/myhdl-list
> >
>
>
> --
> 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
>    Urubu, a static website CMS: http://urubu.jandecaluwe.com
>
>
>
> ------------------------------------------------------------------------------
> Find and fix application performance issues faster with Applications
> Manager
> Applications Manager provides deep performance insights into multiple
> tiers of
> your business applications. It resolves application problems quickly and
> reduces your MTTR. Get your free trial!
> https://ad.doubleclick.net/ddm/clk/302982198;130105516;z
> _______________________________________________
> myhdl-list mailing list
> myh...@li...
> https://lists.sourceforge.net/lists/listinfo/myhdl-list
>

Re: [myhdl-list] More thoughts and code towards dynamic code generation

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

On 01/05/16 23:22, Samuele Disegna wrote:
> Hello,
>
> Finally I have some contributions to the project:
> After seeing some questions about  VHDL "generate" like capabilities for MyHDL I started thinking about a solution.

I am not following. MyHDL "generate" is much more
powerful than VHDL can offer, including for conversion
because you can use the Python interpreter to elaborate
your code you first.


> It is only a proof of concept, let me know your thoughts!
> The following code uses RedBaron to inspect and refactor itself in order to generate an elif statement list.
> A decorator is used for targeting the function to analyze:
>
> from myhdl import *
> from functools import wraps
> import inspect
> from redbaron import RedBaron
>
> i_redbaron = [i for i in range(2,6)]
> def redBaronGenerate(i_redbaron):
>      def real_redBaronGenerate(func):
>          with open(inspect.getsourcefile(func), "r") as source_file:
>              red = RedBaron(source_file.read())
>              #find the decoratornode and the definition node (parent of the former)
>              node = red.find("decorator", lambda x: x.value.value.name.value == "redBaronGenerate")
>              defnode = node.parent
>              #delete the decorator
>              del defnode.decorators[node.index_on_parent]
>              #search elif
>              elifnode = defnode.find("elif")
>              #iterate for elif insertions as desired
>              start =elifnode.index_on_parent
>              for i,elifindex in zip(i_redbaron , range(start,start+len(i_redbaron))):
>                  # prepare the elif template
>                  elifnodetemplate = elifnode.copy()
>                  for node in elifnodetemplate.findAll("name","i_redbaron"):
>                      node.replace(str(i))
>                  #insert the node
>                  elifnode.parent.value.insert(elifindex,elifnodetemplate)
>              #delete the template
>              del elifnode.parent.value[elifnode.index_on_parent]
>              #we dump the result to a file as a demonstration purpose
>              #we could try also to substitute the function with the newer at runtime
>              with open("address_gens_redbaron.py", "w") as source_file:
>                  source_file.write(red.dumps())
>          @wraps(func)
>          def wrapper(*args, **kwds):
>              return func(*args, **kwds)
>          return wrapper
>      return real_redBaronGenerate
>
> @block
> def address_gens(clk,count,datain_address,feedback_address):
>      n = len(count)
>
>      @always(clk.posedge)
>      def address_counter():
>          count.next = count +1
>
>      @always(clk.posedge)
>      def datain_address_generator():
>          datain_address.next = concat(count[n-2:0],count[n-2],count[n-1])
>
>      @always(clk.posedge)
>      @redBaronGenerate(i_redbaron)
>      def feedback_address_generator():
>          #REDBARON for i_redbaron in range(1,5)
>          if count[n-1] == 0:
>              feedback_address.next = concat(count[n:n-1],count[n-2:1],count[n-2],count[0])
>          elif count[n-i_redbaron] == 0:
>              feedback_address.next = concat(count[n:n-i_redbaron],count[n-i_redbaron-1:1],
>                                             count[n-i_redbaron-1],count[0])
>          else:
>              feedback_address.next = count #and last 2 values are not important (actually one could be used to do half of the last butterfly)
>
>      return address_counter,datain_address_generator,feedback_address_generator
>
>
> if __name__ == "__main__":
>      @block
>      def ClkDriver(clk,halfperiod):
>          @always(delay(halfperiod))
>          def driveClk():
>              clk.next = not clk
>          return driveClk
>      @block
>      def tb(clk,count,dina,fa):
>          clk_driver = ClkDriver(clk,5)
>          a_gen = address_gens(clk,count,dina,fa)
>          return clk_driver,a_gen
>
>      clk = Signal(False)
>      count = Signal(modbv(0,_nrbits=8))
>      dina = Signal(intbv(0,_nrbits=8))
>      fa = Signal(intbv(0,_nrbits=8))
>
>      #address_gens(clk,count,fa).convert(hdl='Verilog')
>
>      tb1 = tb(clk,count,dina,fa)
>      tb1.config_sim(trace=True)
>
>
>
> ------------------------------------------------------------------------------
> Find and fix application performance issues faster with Applications Manager
> Applications Manager provides deep performance insights into multiple tiers of
> your business applications. It resolves application problems quickly and
> reduces your MTTR. Get your free trial!
> https://ad.doubleclick.net/ddm/clk/302982198;130105516;z
>
>
>
> _______________________________________________
> myhdl-list mailing list
> myh...@li...
> https://lists.sourceforge.net/lists/listinfo/myhdl-list
>


-- 
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
   Urubu, a static website CMS: http://urubu.jandecaluwe.com

[myhdl-list] More thoughts and code towards dynamic code generation

[Samuele D. <sm...@gm...>]

Hello,

Finally I have some contributions to the project:
After seeing some questions about  VHDL "generate" like capabilities for
MyHDL I started thinking about a solution.

It is only a proof of concept, let me know your thoughts!
The following code uses RedBaron to inspect and refactor itself in order to
generate an elif statement list.
A decorator is used for targeting the function to analyze:

from myhdl import *
from functools import wraps
import inspect
from redbaron import RedBaron

i_redbaron = [i for i in range(2,6)]
def redBaronGenerate(i_redbaron):
    def real_redBaronGenerate(func):
        with open(inspect.getsourcefile(func), "r") as source_file:
            red = RedBaron(source_file.read())

            #find the decoratornode and the definition node (parent of the
former)
            node = red.find("decorator", lambda x: x.value.value.name.value
== "redBaronGenerate")
            defnode = node.parent
            #delete the decorator
            del defnode.decorators[node.index_on_parent]
            #search elif
            elifnode = defnode.find("elif")
            #iterate for elif insertions as desired
            start =elifnode.index_on_parent
            for i,elifindex in zip(i_redbaron ,
range(start,start+len(i_redbaron))):
                # prepare the elif template
                elifnodetemplate = elifnode.copy()
                for node in elifnodetemplate.findAll("name","i_redbaron"):
                    node.replace(str(i))
                #insert the node
                elifnode.parent.value.insert(elifindex,elifnodetemplate)
            #delete the template
            del elifnode.parent.value[elifnode.index_on_parent]
            #we dump the result to a file as a demonstration purpose
            #we could try also to substitute the function with the newer at
runtime
            with open("address_gens_redbaron.py", "w") as source_file:
                source_file.write(red.dumps())
        @wraps(func)
        def wrapper(*args, **kwds):
            return func(*args, **kwds)
        return wrapper
    return real_redBaronGenerate

@block
def address_gens(clk,count,datain_address,feedback_address):
    n = len(count)

    @always(clk.posedge)
    def address_counter():
        count.next = count +1

    @always(clk.posedge)
    def datain_address_generator():
        datain_address.next = concat(count[n-2:0],count[n-2],count[n-1])

    @always(clk.posedge)
    @redBaronGenerate(i_redbaron)
    def feedback_address_generator():
        #REDBARON for i_redbaron in range(1,5)
        if count[n-1] == 0:
            feedback_address.next =
concat(count[n:n-1],count[n-2:1],count[n-2],count[0])
        elif count[n-i_redbaron] == 0:
            feedback_address.next =
concat(count[n:n-i_redbaron],count[n-i_redbaron-1:1],
                                           count[n-i_redbaron-1],count[0])
        else:
            feedback_address.next = count #and last 2 values are not
important (actually one could be used to do half of the last butterfly)

    return
address_counter,datain_address_generator,feedback_address_generator


if __name__ == "__main__":
    @block
    def ClkDriver(clk,halfperiod):
        @always(delay(halfperiod))
        def driveClk():
            clk.next = not clk
        return driveClk
    @block
    def tb(clk,count,dina,fa):
        clk_driver = ClkDriver(clk,5)
        a_gen = address_gens(clk,count,dina,fa)
        return clk_driver,a_gen

    clk = Signal(False)
    count = Signal(modbv(0,_nrbits=8))
    dina = Signal(intbv(0,_nrbits=8))
    fa = Signal(intbv(0,_nrbits=8))

    #address_gens(clk,count,fa).convert(hdl='Verilog')

    tb1 = tb(clk,count,dina,fa)
    tb1.config_sim(trace=True)

Re: [myhdl-list] Block return values (myhdl.BlockError)

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

It's not so much an implementation problem as an
expectations problem.

Previously, one could do

    return m, sig1, sig2

and make a "contract" with oneself that m should be a list
of instances.

The problem I have is that this kind of decision would now
become part of the @block specification, valid for all, instead
simply being a local decision.

For example, what if one uses:
  
    return m1, m2, sig1, sig2

should that fail? And on what ground? And if it doesn't
fail, should the decorator than modify the return values
into something like:

    return Block(m1, m2), sig1, sig2

changing the argument aspect completely?

And what about

    return sig1, sig2, m


Or

    return m, siglist

And so on.

Jan


On 01/05/16 16:57, Samuele Disegna wrote:
> Hi! I am not getting the problem completely so I will try to give a
> probably wrong solution, I would like to hear some feedback on it in
> order to rise a more practical discussion:
>
> Block connections are usually indicated as arguments of the block
> functions, can we stick to this phylosophy and pass an empty list for
> signals defined inside the block itself? (the block will fill the
> list)
>
> Hardware Instances are usually passed through the return statement as
> single object, lists or tuples (Is this the maintenance problem?) and
> we are not capable of return anything else with the current
> implementation without getting errors (Have I got it right?). Can we
> decide to use a list for hardware instances embedded as the first
> element of a tuple (or in a dictionary)? The other elements will
> contain all kinds of return objects.
>
> Jan, could you list your thoughts about the problems you are getting
> on the implementation side :)? I am definitely interested.
>
> Samuele
>
> On Sun, May 1, 2016 at 12:46 PM, Henry Gomersall <he...@ma...
> <mailto:he...@ma...>> wrote:
>
> On 01/05/16 11:40, Jan Decaluwe wrote:
>> Feedback is more than welcome.
>
> Another potential option is to make the Block class part of the user
> API, or perhaps an alternative Block factory, to allow these more
> esoteric use cases.
>
> So, the @block decorator is used in the simple/common case. If you
> want to do something more complicated, you can use the alternative
> tools to extract the block object. Exactly how this would be realised
> I'm not sure, but I'm sure there would be a neat way.
>
> It touches on my comments in issue #162, which is another
> manifestation of the limitations of the decorator implementation.
>
> Henry
>
> ------------------------------------------------------------------------------
>
>
Find and fix application performance issues faster with Applications Manager
> Applications Manager provides deep performance insights into multiple
> tiers of your business applications. It resolves application problems
> quickly and reduces your MTTR. Get your free trial!
> https://ad.doubleclick.net/ddm/clk/302982198;130105516;z
> _______________________________________________ myhdl-list mailing
> list myh...@li...
> <mailto:myh...@li...>
> https://lists.sourceforge.net/lists/listinfo/myhdl-list
>
>
>
>
> ------------------------------------------------------------------------------
>
>
Find and fix application performance issues faster with Applications Manager
> Applications Manager provides deep performance insights into multiple
> tiers of your business applications. It resolves application problems
> quickly and reduces your MTTR. Get your free trial!
> https://ad.doubleclick.net/ddm/clk/302982198;130105516;z
>
>
>
> _______________________________________________ myhdl-list mailing
> list myh...@li...
> https://lists.sourceforge.net/lists/listinfo/myhdl-list
>


-- 
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
   Urubu, a static website CMS: http://urubu.jandecaluwe.com