myhdl-list — Mailing list for discussions on MyHDL

[myhdl-list] Q: should I activate myhdl.org now?

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

With webfaction, my current host, I can very easily map
and remap applications to domain names.

Also, I own the myhdl.org domain. The idea was to have it
available once we find the "ultimate" cms for our needs.

However, why shouldn't we make the move now already with
what we have, before releasing 0.6?

I think that decoupling the project from my name would help
its credibility by stressing its openness, and its
cooperative nature.

I would remain site owner and admin as before.

If we do find a better system than dokuwiki at one point,
it would be easy to prepare a new site at some temporary
domain and make the switch when appropriate.

Tecnhically, I would move myhdl.jandecaluwe.com with a
'redirect 301' to www.myhdl.org - meaning a permanent move.
Accessing the old domain would transparently move you to the
new domain. This also seems to be search-engine friendly.

Basically, everything would continue to work as before,
including passwords to access the site, with only one
inconvenience: if you rely on the stored password in your
browser, you may have to enter it again.

What do you think?


-- 
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] Name generation RTL components

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

Jos Huisken wrote:
> Suppose you have an n-input xor gate described like:
> 
> def xor(a, z, width):
>     ....
> 
> in which 'width' specifies the number of input (length of 'a').
> Suppose you want to generate both a 3-input and 4-input xor.
> How to generate unique names? Now you can execute:
>     toVerilog,name = 'xor_3'
>     toVerilog(xor, a, z, 3)
>     toVerilog,name = 'xor_4'
>     toVerilog(xor, a, z, 4)
> 
> Maybe it is a suggestion (as opposed to toVerilog.name = 'myName') with
> verilog and/or VHDL generation to insert a name giving function in the
> definition of 'xor' itself:
> 
> def xor(a, z, width):
>     set_my_name("xor_%d" % width) # or whatever...
>     ....
> 
> This would make the name attribute superflous, I think.

A couple of comments:

As the parameter list of toVerilog/toVHDL is used for ports and
parameters, we can't use it for HDL conversion configuration.
The idea to use function attributes such as 'name' is to have
a "second level" of parametrization for this purpose. I see
this as a general, extensible mechanism, and I expect more
attributes may be added in the future. BTW, for toVHDL I
have already added another one called 'configuration_declarations'.
(See the recent what's new document for 0.6).

In general I think I prefer to keep HDL conversion configuration
options as much as possible out of the design code itself, and
this mechanism achieves that.

BTW, if you wanted to generate a series of components,
you'd probably write a for loop that sets up the desired
name in a parametrized way in the loop, so this can be
done in a quite compact way also.

Jan

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

[myhdl-list] Name generation RTL components

[Jos H. <jos...@gm...>]

Suppose you have an n-input xor gate described like:

def xor(a, z, width):
    ....

in which 'width' specifies the number of input (length of 'a').
Suppose you want to generate both a 3-input and 4-input xor.
How to generate unique names? Now you can execute:
    toVerilog,name = 'xor_3'
    toVerilog(xor, a, z, 3)
    toVerilog,name = 'xor_4'
    toVerilog(xor, a, z, 4)

Maybe it is a suggestion (as opposed to toVerilog.name = 'myName') with
verilog and/or VHDL generation to insert a name giving function in the
definition of 'xor' itself:

def xor(a, z, width):
    set_my_name("xor_%d" % width) # or whatever...
    ....

This would make the name attribute superflous, I think.

-- Jos

[myhdl-list] What's New document of 0.6

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

I have completely rewritten and updated the whatsnew document
for MyHDL 0.6. It's now also in restructured text and integrated
with the rest of the documentation:

     http://myhdl.jandecaluwe.com/doc/dev/0.6/whatsnew/0.6.html

Please review, and if required, give feedback or improve.

I will leave it untouched for a week; afterwards I'll start
integrating the new things in the manual.

Jan

-- 
Jan Decaluwe - Resources bvba - http://www.jandecaluwe.com
     Using Python as a hardware description language:
     http://jandecaluwe.com/Tools/MyHDL/Overview.html

Re: [myhdl-list] New repository location

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

Jan Decaluwe wrote:
> Jan Decaluwe wrote:
>> I have moved the MyHDL repository to a place where I have more
>> control. Look on the web site for the new location.
> 
> The new location is:
> 
>      http://hg.myhdl.org/myhdl

This puts the myhdl.org domain to good use for the first time.

If you track development, there's no need to take a fresh clone. You
just have to modify the default repo location to the url above.
This can be done in the hgrc file of your local repo. Look
into myhdl/.hg/hgrc under [paths].

-- 
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] New repository location

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

Jan Decaluwe wrote:
> I have moved the MyHDL repository to a place where I have more
> control. Look on the web site for the new location.

The new location is:

     http://hg.myhdl.org/myhdl


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

[myhdl-list] New repository location

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

I have moved the MyHDL repository to a place where I have more
control. Look on the web site for the new location.

If you track development, there's no need to take a fresh clone. You
just have to modify the default repo location.
This can be done in the hgrc file of your local repo.

(I have tried to send/resend a similar message for the past 5 days,
for some reason it didn't seem to work so far.)

-- 
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] 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

[myhdl-list] bitarray (maybe useful)

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

http://pypi.python.org/pypi/bitarray/0.2.5

[myhdl-list] mailing list problems

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

Sourceforge has also migrated the mailing list, and I'm
seeing some problems.

It seems to be working again now, but it seems it still has
to work through some older messages. I got a permanent error
on one, and I had to resend it. Another one is still missing
and resending hasn't helped yet.

-- 
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] Updating images on the wiki

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

Günter Dannoritzer wrote:
> Hi,
> 
> I tried to update an uploaded image on the wiki, but it seems like that
> is not possible. The way I worked around it is to upload it under a
> different name, but now the not needed image is still there.
> 
> Is there another way to update or delete not needed images?

Because of dokuwiki acl restrictions, it's too dangerous to
enable this in general. Unlike data pages, media files are not
versioned or stored in an attic when removed; so any registered
user could permanently delete any media file.

The are 3 options, depending on the level of inconvenience:
- just use a workaround as you did now
- mail me and ask to remove a certain file
- ask me to set up a special namespace (e.g. users:username) for
   you and to give you full permissions there.

Jan

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

[myhdl-list] Updating images on the wiki

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

Hi,

I tried to update an uploaded image on the wiki, but it seems like that
is not possible. The way I worked around it is to upload it under a
different name, but now the not needed image is still there.

Is there another way to update or delete not needed images?

Thanks for the help.

Cheers,

Guenter

Re: [myhdl-list] Sourceforge repo down

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

Andrew Lentvorski wrote:
> Jan Decaluwe wrote:
>> It seems Sourceforge is migrating to another data center;
>> currently web access to the MyHDL repo is unaccessible.
>>
>>  From what I'm read I'm not really confident that this
>> will be restored as before (e.g. with ssh access for me).
>> I'm therefore currently investigating whether I can put
>> the repo on another server.
>>
>> Jan
>>
> 
> Some people have been saying good things about bitbucket for mercurial 
> projects.
> 
> http://www.bitbucket.org/

Thanks for the suggestion.

I decided to try to use available resources better: I'm paying webfaction
for my websites (including the MyHDL site) and I'm also paying for
the myhdl.org domain (currently not put to use). So I'll give it a
try to put the repo on a subdomain of myhdl.org.

Jan

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

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

Re: [myhdl-list] Sourceforge repo down

[Andrew L. <bs...@al...>]

Jan Decaluwe wrote:
> It seems Sourceforge is migrating to another data center;
> currently web access to the MyHDL repo is unaccessible.
> 
>  From what I'm read I'm not really confident that this
> will be restored as before (e.g. with ssh access for me).
> I'm therefore currently investigating whether I can put
> the repo on another server.
> 
> Jan
> 

Some people have been saying good things about bitbucket for mercurial 
projects.

http://www.bitbucket.org/

-a

[myhdl-list] Sourceforge repo down

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

It seems Sourceforge is migrating to another data center;
currently web access to the MyHDL repo is unaccessible.

 From what I'm read I'm not really confident that this
will be restored as before (e.g. with ssh access for me).
I'm therefore currently investigating whether I can put
the repo on another server.

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] Small buglet

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

Jan Decaluwe wrote:
> Thomas Heller wrote:
>> While working with Python generators in a testbench to supply test data to my instances,
>> I found that the myhdl.instances() function not only returns MyHDL instances but also
>> these generators.
> 
> Right. Sometimes I think that myhdl.instances() is a result
> of me trying to be too clever, and therefore not really a good
> idea. Suppose it would be required to always return instances
> explicitly, would anyone have missed it?
> 
> Anyway. I think that you expect that the function only finds
> instances created by the MyHDL decorators @instance, @always
> and @always_comb (and also the "hierarchical" instances of
> course.) 

In development the behavior of instances() has been changed.
It now works as suggested above.

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] Completely cryptic assertion failure

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

Jan Decaluwe wrote:
> Andrew Lentvorski wrote:
>> I eventually figured out what was wrong, but could somebody explain to
>> me how I should debug this?
> 
> First of all, AssertionError's like this are indeed not very nice
> and can be considered a bug.
> 
> However, it's not necessarily possible to turn this into an
> error message that directly points to the problem. Something
> like "Inconsistent hierachy definition - check if all instances
> are returned." may be the best that can be done. Ok, that
> would perhaps be much better already.

I have pushed a changeset that should do something like the above.

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

[myhdl-list] Good progress with lists of signals

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

I think I made some good progress with lists of signals
recently. I'm quite excited about this, because I believe it
will make the VHDL/Verilog convertor much more usable.

 From user feedback it had become clear that lists of signals
conversion support was confusing and not powerful enough.
I believe that all issues have now been addressed in the
development code.

In particular:

- you an now use list (of signal) index syntax freely in generators.
If used in a generator, a Verilog memory or VHDL array will be
declared. Previously, you couldn't refer to a list member in
another generator with plain signal syntax (resulting in a confusing
"Signal not unique..." error message.) Now this should be
possible.

- in an always_comb block, lists of signals are now detected and
added to the sensitivity list. (This is not necessarily "efficient":
as soon as a list member is referred to, the whole list is added
to the sensitivity list.)

The changes have been pushed to the development repo.
Look into test/conversion/general/test_listofsigs.py for unit
tests that illustrate the functionally (trivially.)

There have been some important changes, so there may be issues.
You can help by digging out old examples that you had expected to
work, but that didn't. Also, it would be interesting to know if
you find limitations with simulators and synthesis tools. I
believe the resulting Verilog code is 2001-compliant and it
works with Icarus in my unit tests. However, cver apparently
doesn't support wire memories.

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] 0.6dev9

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

Christopher L. Felton wrote:
> I agree the repository works for development snapshots.
> 
> The only thought would be for new users.  Is it as easy to pull from  
> the repository (new users not familiar with hg etc) as downloading a  
> zip.

Once a tracking repo is setup, it's easier to stay current: "hg pull -u".

 > I think there are enough instructions etc on the wiki and hg is
> python based for easy to install.  The cost of entry is slightly more  
> than downloading zip files.

Yes, the initial setup is more difficult. However, for truly new users
there should be a stable release on sourceforge. I realize that there
should be stable releases more often - once the VHDL hurdle has
been taken ... (mainly a question of documentation)

Given all this, let's make development snapshots obsolete and use the
hg approach instead. I may still tag from time to time. This should
also make the development loop more efficient and productive.

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] debugging Cosimulation with Icarus Verilog

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

Jan Decaluwe wrote:
...
> 
> Maybe with the bug fix you can use the assignment that was commented out,
> and perhaps that fixes it?
> 
>    // icarus stops on the following line but shouldn't
>    // cb_data_s.value = &value_s;
>    cb_data_s.value = NULL;
> 

Yes, that part works now. But unfortunately does not fix the toVerilog
test errors.

Some of the toVerilog tests failures are caused by the callback at
simulation time 0. The problem is that the callback at time 0 returns a
value 'x' for the signal. The Cosimulation class does not like that and
due to the exception in the Cosimulation._get(self) function an
intbv(None) instance is returned.

So the solution specific to Icarus would be to register the first
cbValueChange call back at simulation time 1. That could actually be
used for all simulators, as the others do it anyway that way.

BTW, I noticed the change is already part of the latest Icarus Verilog
development snapshot 2008-08-30.

Guenter

Re: [myhdl-list] debugging Cosimulation with Icarus Verilog

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

Günter Dannoritzer wrote:
> Jan Decaluwe wrote:
>> Excellent, looks like we're getting somewhere here!
> 
> Some update on the Icarus Verilog bug report #2048463 concerning the
> cbValueChange issues. The bug is fixed in the git repository, however,
> the difference in the call back behavior at time 0 remains. In the bug
> tracker there is some explanation about this behavior:
> 
> http://sourceforge.net/tracker/index.php?func=detail&aid=2048463&group_id=149850&atid=775997
> 
> I also posted a question about this on comp.lang.verilog and got a reply
> from someone at Cadence. The Icarus Verilog developer Steve Williams
> replied now to that subject as well. Will see what comes out of that
> discussion.
> 
> Here is a link to the comp.lang.Verilog discussion:
> 
> http://groups.google.com/group/comp.lang.verilog/browse_frm/thread/58628e26e5294c58#
> 
> I will look into adjusting the current myhdl.c for Icarus to work with
> the t0 behavior.

Maybe with the bug fix you can use the assignment that was commented out,
and perhaps that fixes it?

   // icarus stops on the following line but shouldn't
   // cb_data_s.value = &value_s;
   cb_data_s.value = NULL;

-- 
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] debugging Cosimulation with Icarus Verilog

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

Jan Decaluwe wrote:
> Excellent, looks like we're getting somewhere here!

Some update on the Icarus Verilog bug report #2048463 concerning the
cbValueChange issues. The bug is fixed in the git repository, however,
the difference in the call back behavior at time 0 remains. In the bug
tracker there is some explanation about this behavior:

http://sourceforge.net/tracker/index.php?func=detail&aid=2048463&group_id=149850&atid=775997

I also posted a question about this on comp.lang.verilog and got a reply
from someone at Cadence. The Icarus Verilog developer Steve Williams
replied now to that subject as well. Will see what comes out of that
discussion.

Here is a link to the comp.lang.Verilog discussion:

http://groups.google.com/group/comp.lang.verilog/browse_frm/thread/58628e26e5294c58#

I will look into adjusting the current myhdl.c for Icarus to work with
the t0 behavior.

Guenter