myhdl-list

[myhdl-list] Style based on decorators

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

Hi:

I have decided to proceed with the introduction of decorators
to create local generators in 0.5.

In addition, I would like to make this the default coding style.
In particular, I would change all documentation and examples to
use decorators, including in tutorials. Note that 3 decorators
are introduced: @always, @always_comb, and @instance.

Also, the possibility to use a parametrizable generator directly
would be de-emphasized (but possible, of course). The equivalent
in VHDL/Verilog would be a process/always block with a port
interface, something which doesn't exist. Therefore, this
can be confusing to new users. Instead, one would use a function
that returns a single generator (as many of you do already).
This makes the overall style more consistent: structure is
always specified using a plain function, behavior using
a local generator (created with a decorator).

Note that all of this has no impact on backwards compatibility.

As always, let me know if you disagree.

Jan

-- 
Jan Decaluwe - Resources bvba - http://www.jandecaluwe.com
Losbergenlaan 16, B-3010 Leuven, Belgium
     From Python to silicon:
     http://myhdl.jandecaluwe.com

Re: [myhdl-list] Style based on decorators

[Matt E. <ma...@et...>]

Jan Decaluwe wrote:
> Hi:
> 
> I have decided to proceed with the introduction of decorators
> to create local generators in 0.5.
> 
> In addition, I would like to make this the default coding style.
> In particular, I would change all documentation and examples to
> use decorators, including in tutorials. Note that 3 decorators
> are introduced: @always, @always_comb, and @instance.
> 
> Also, the possibility to use a parametrizable generator directly
> would be de-emphasized (but possible, of course). The equivalent
> in VHDL/Verilog would be a process/always block with a port
> interface, something which doesn't exist. Therefore, this
> can be confusing to new users. Instead, one would use a function
> that returns a single generator (as many of you do already).
> This makes the overall style more consistent: structure is
> always specified using a plain function, behavior using
> a local generator (created with a decorator).
> 
> Note that all of this has no impact on backwards compatibility.
> 
> As always, let me know if you disagree.

I don't see the advantage of pushing everyone towards the decorators.
Am I correct in my understanding that complex cases may still need the
old syntax?

Also, I love Python and understand the desire to be Pythonic, but making
things as different as possible from preexisting HDLs doesn't seem to
buy anything but a steep learning curve.

Matt

[myhdl-list] Re: Style based on decorators

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

Matt Ettus wrote:

> I don't see the advantage of pushing everyone towards the decorators.
> Am I correct in my understanding that complex cases may still need the
> old syntax?

Generators are the raw material in MyHDL. They can have arguments,
and they can even be used dynamically in yield statements (anyone
ever tried that already?) For such cases (and all others, if you
want) the general syntax is and will always be available.

However, there is an overwhelmingly popular usage pattern: a local
generator function, embedded in a classic function that defines an
interface and structure. Such a generator function has rather special
characteristics. It is not intended to be reusable. Therefore, it
doesn't have parameters. We don't need its name, only its code. It is
intended to be called exactly once, to create a generator.

It is that clearly defined and very popular pattern that decorators
target. Within this pattern, there is always a decorator available,
no matter how complex the generator function. This is because the
@instance decorator is the catch-all decorator.

All decorators create the generator and reuse the name automatically.
This means that they automate the single meaningful way to use the
generator function, and their presence explicitly signals this.
Important advantages, I believe.

> Also, I love Python and understand the desire to be Pythonic, but making
> things as different as possible from preexisting HDLs doesn't seem to
> buy anything but a steep learning curve.

I don't think you can argue that the decorators make things
"as different as possible". On the contrary I would say, although
this is not a design goal either. In fact, there is a close
correspondence with certain Verilog statements:

   @instance    <->  initial
   @always      <=>  always
   @always_comb <=>  always_comb

I guess this may make MyHDL code with decorators easier to
understand by users of other HDLs.

Regards,

Jan

-- 
Jan Decaluwe - Resources bvba - http://www.jandecaluwe.com
Losbergenlaan 16, B-3010 Leuven, Belgium
     From Python to silicon:
     http://myhdl.jandecaluwe.com

Re: [myhdl-list] Style based on decorators

[bedros <be...@ya...>]

I disagree with Matt, and agree with Jan.

This is still an experimental release (sub 1.0)
meaning major changes could happen. I think decorators
are brilliant idea; and make it look like a real HDL
rather than a hacked sequential language as in the old
style.

I would prefer to stay compatible with old style as
long it does not conflict with the new style; but
compatibality is not important.

I believe that the most important advantage with MyHDL
over other HDL's is the ability to express my designs
in the language in the least effort; and the ability
to read and understand the code without trying to
crack the cryptic ways of making it a parallel
language. Decorators simplify things and make coding
in MyHDL more elegant.

to me, MyHDL is to RTL design, is like what FPGA is to
ASIC. It's a way of getting something out quickly.
It's a fast way from concept to a cycle acurate model
of the concept; and run the design in simulation, to
verify the architecture; if things work well, I could
try toVerilog conversion; or replace parts of the
design with their equivalent verilog or VHDL by hand; 

In my work, we do everything in VHDL; I wonder if it's
possible to co-simulate VHDL and MyHDL via VHPI
interface; I don't need it right now, but probably in
a year; I'll try to figure it out.

keep the good work Jan.


-Bedros

--- Matt Ettus <ma...@et...> wrote:

> Jan Decaluwe wrote:
> > Hi:
> > 
> > I have decided to proceed with the introduction of
> decorators
> > to create local generators in 0.5.
> > 
> > In addition, I would like to make this the default
> coding style.
> > In particular, I would change all documentation
> and examples to
> > use decorators, including in tutorials. Note that
> 3 decorators
> > are introduced: @always, @always_comb, and
> @instance.
> > 
> > Also, the possibility to use a parametrizable
> generator directly
> > would be de-emphasized (but possible, of course).
> The equivalent
> > in VHDL/Verilog would be a process/always block
> with a port
> > interface, something which doesn't exist.
> Therefore, this
> > can be confusing to new users. Instead, one would
> use a function
> > that returns a single generator (as many of you do
> already).
> > This makes the overall style more consistent:
> structure is
> > always specified using a plain function, behavior
> using
> > a local generator (created with a decorator).
> > 
> > Note that all of this has no impact on backwards
> compatibility.
> > 
> > As always, let me know if you disagree.
> 
> I don't see the advantage of pushing everyone
> towards the decorators.
> Am I correct in my understanding that complex cases
> may still need the
> old syntax?
> 
> Also, I love Python and understand the desire to be
> Pythonic, but making
> things as different as possible from preexisting
> HDLs doesn't seem to
> buy anything but a steep learning curve.
> 
> Matt
> 
> 
>
-------------------------------------------------------
> This SF.net email is sponsored by: Splunk Inc. Do
> you grep through log files
> for problems?  Stop!  Download the new AJAX search
> engine that makes
> searching your log files as easy as surfing the 
> web.  DOWNLOAD SPLUNK!
>
http://ads.osdn.com/?ad_id=7637&alloc_id=16865&op=click
> _______________________________________________
> myhdl-list mailing list
> myh...@li...
>
https://lists.sourceforge.net/lists/listinfo/myhdl-list
>