myhdl-list

[myhdl-list] MyHDL code clean-up - please review

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

I think the introduction of decorators in MyHDL 0.5 has been
a success, and by now everybody uses them.

For pure modelling, you can construct generators in any way,
including directly without decorators, and that will always
remain so.

However, some more implementation-oriented features, such
as hierarchy extraction, signal tracing and conversion also
contain support for non-decorator generators. This complicates
the code considerably, and in my opinion, unnecessarily.
Before adding new features, I would like to remove this
support to simplify the code.

Again, if you use decorators, everything should continue to
work as before. Below I will describe the proposed changes
in detail. Please review and give feedback about any objection.

* remove 'processes' function
This (undocumented) function is obsolete if you use decorators. It
was deprecated in 0.5.

* change 'instances' function to only return generators from decorators
Currently 'instances' returns any kind of generator. Sometimes people
may want to use a generator for other purposes than hardware description:
currently you can't use 'instances' in that case. By only returning
generators from decorators, this would become possible.

* remove support for "top-level" generators

Consider the degenerated case where the top-level is a generator:

def top():
    <generator_body>

Hierarchy extraction, signal tracing and conversion have some special
support for this, which I would like to remove. Note that the
above is equivalent to:

def top():
     @instance
     def logic():
         <generator_body>
     return logic

* in general, assume that for hierarchy extraction, signal tracing
and conversion, only generators from decorators need to be considered.
There may be some more places in the code where this assumption can help
to simplify things.


Jan

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

Re: [myhdl-list] MyHDL code clean-up - please review

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

I have just pushed the latest changes that implement everything
as described below.

Every leaf block in the structure should now use a decorator,
if you want to do things like tracing signals and conversion.
This introduces a small backwards incompatibility (probably
mostly for my own older unit tests) but simplifies the
implementation tremendously. Code using decorators is also
clearer as to its purpose.

If you see a problem (e.g. "no instances found") with older
code, the workaround should be easy: use a @instance decorator.

Regards,

Jan

Jan Decaluwe wrote:
> I think the introduction of decorators in MyHDL 0.5 has been
> a success, and by now everybody uses them.
> 
> For pure modelling, you can construct generators in any way,
> including directly without decorators, and that will always
> remain so.
> 
> However, some more implementation-oriented features, such
> as hierarchy extraction, signal tracing and conversion also
> contain support for non-decorator generators. This complicates
> the code considerably, and in my opinion, unnecessarily.
> Before adding new features, I would like to remove this
> support to simplify the code.
> 
> Again, if you use decorators, everything should continue to
> work as before. Below I will describe the proposed changes
> in detail. Please review and give feedback about any objection.
> 
> * remove 'processes' function
> This (undocumented) function is obsolete if you use decorators. It
> was deprecated in 0.5.
> 
> * change 'instances' function to only return generators from decorators
> Currently 'instances' returns any kind of generator. Sometimes people
> may want to use a generator for other purposes than hardware description:
> currently you can't use 'instances' in that case. By only returning
> generators from decorators, this would become possible.
> 
> * remove support for "top-level" generators
> 
> Consider the degenerated case where the top-level is a generator:
> 
> def top():
>     <generator_body>
> 
> Hierarchy extraction, signal tracing and conversion have some special
> support for this, which I would like to remove. Note that the
> above is equivalent to:
> 
> def top():
>      @instance
>      def logic():
>          <generator_body>
>      return logic
> 
> * in general, assume that for hierarchy extraction, signal tracing
> and conversion, only generators from decorators need to be considered.
> There may be some more places in the code where this assumption can help
> to simplify things.
> 
> 
> Jan
> 


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

Re: [myhdl-list] MyHDL code clean-up - please review

[Christopher F. <cf...@uc...>]

> I have just pushed the latest changes that implement everything
> as described below.

Wow, you have been busy with these changes and the list of signal 
changes.  That is impressive.  I have been reviewing the code some and 
from my perspective I haven't come up with any questions yet.  I 
pulled the code before sourceforge went down.


Thanks

[myhdl-list] Manual Update

[Blubaugh, D. A. <dbl...@be...>]

To All,
 
 
I was wondering as to if the user manual for the MyHDL has been updated to 0.6dev9 specs??  It appears as though there has been a great deal of imporvements made to MyHDL, since I last utilized this development environment.
 
Thanks,
 
David Blubaugh
 

________________________________

From: myh...@li... on behalf of Christopher Felton
Sent: Thu 9/18/2008 1:55 PM
To: General discussions on MyHDL; Jan Decaluwe
Subject: Re: [myhdl-list] MyHDL code clean-up - please review




> I have just pushed the latest changes that implement everything
> as described below.

Wow, you have been busy with these changes and the list of signal
changes.  That is impressive.  I have been reviewing the code some and
from my perspective I haven't come up with any questions yet.  I
pulled the code before sourceforge went down.


Thanks

-------------------------------------------------------------------------
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
_______________________________________________
myhdl-list mailing list
myh...@li...
https://lists.sourceforge.net/lists/listinfo/myhdl-list



This e-mail transmission contains information that is confidential and may be 
privileged. It is intended only for the addressee(s) named above. If you receive 
this e-mail in error, please do not read, copy or disseminate it in any manner. 
If you are not the intended recipient, any disclosure, copying, distribution or 
use of the contents of this information is prohibited. Please reply to the 
message immediately by informing the sender that the message was misdirected. 
After replying, please erase it from your computer system. Your assistance in 
correcting this error is appreciated.

Re: [myhdl-list] Manual Update

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

Blubaugh, David A. wrote:
> To All,
>  
>  
> I was wondering as to if the user manual for the MyHDL has been updated to 0.6dev9 specs??  It appears as though there has been a great deal of imporvements made to MyHDL, since I last utilized this development environment.

Not yet, but as I'm now basically done with 0.6 development I'm working
on it - the whatsnew document will be first.

Jan

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