myhdl-list — Mailing list for discussions on MyHDL

Re: [myhdl-list] Reflections on a MyHDL IP library

[Brendan R. <bre...@gm...>]

Jan Decaluwe <jan <at> jandecaluwe.com> writes:

> 
> George Pantazopoulos wrote:

> > After doing some explorations, I highly recommend looking at Zope for
> > myhdl.org. I've been looking at content management systems, including
> > MediaWiki, phpBB, Drupal, Wordpress, and Zope. So far, I think Zope offers
> > the most potential.
> 
> Mm, but have you ever used it  Several year ago, I have a number of times,
> and never really liked it. I found if very complicated and full of jargon.
> Also, it has something unpythonic: it's large, not orthogonal and complex.
> It was supposed to become the Python killer app, but from what I hear
> many pythonistas simply don't like it.
> 
> I never used Plone, but I imagine it has been invented to take away
> some complexity from the underlying Zope to make a more usable system.
> Still, I fear that the underlying complexity still shines through.
> Tom is using it for his site, so he may give good advice here.
> 
> In any case, with the migration to myhdl.org we now have the opportunity
> to re-assess the CMS software issue. I think it's wise to take some
> time to consider the options carefully, based on a specific list
> of must-have and desirable features.
> 
> Jan
> 

I'm definitely not a fan of Zope and, through relation, Plone.  It's just too
complex.  There are a few new python-based CMSs, however, and of these I think
that skeletonz (http://orangoo.com/skeletonz/) looks pretty promising, though
there's bound to be one for Turbogears or Django as well.

Just my $0.02.

- Brendan

Re: [myhdl-list] Reflections on a MyHDL IP library

[dannoritzer <dan...@we...>]

Joachim König-Baltes wrote:

> I'm working with Plone (CMS based on Zope) as my day job, so in case 
> that some
> help and support is needed, I can contribute (e.g. if a MyHDL skin is 
> needed). Be aware
> that the learning curve is rather steep, but Plone and Zope are mature 
> and worth the
> efforts IMO.
> 
> Joachim
> 

That sounds good to have an experienced Plone user/developer.

I had some frustrating experience with adding Products to Plone that
caused a lot of maintenance when doing a site update. -- Products are
add ons to the basic installation that add functions like issue tracking
for example. http://plone.org/products --

One I had problems with was PloneCollectorNG, an issue tracking system.
Another was a Product with some additional  file types -- forgot its
name -- that could be added and had nicer icons and better indexing
support for PDF documents for example.

I think before committing to Plone it would be good to make a list of
what features should be provided by the page and then look how much is
provided by Plone and what can be added through Products.

Cheers,

Guenter

Re: [myhdl-list] Reflections on a MyHDL IP library

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

George Pantazopoulos wrote:
> On Fri, November 17, 2006 5:40 pm, Günter Dannoritzer wrote:
> 
>>Jan Decaluwe wrote:
>>[...]
>>
>>>>Trac looks more like it is suited for one project group. I think the
>>>>mix
>>>>of having different users that can participate in different projects
>>>>requires quite some tweaking of trac.
>>>
>>>I'm not convinced this is what we need first. Trac seems to be a
>>>sourceforge done better, in other words, a development management
>>>system. But this is a general problem, well suited to large scale
>>>dedicated hosted solutions such as sourceforge itself, or Google Code
>>>(both with subversion support), or opencores.org.
>>>
>>>I think what we need first is a content management system, well suited
>>>to
>>>create great documentation rapidly, and distribute releases by the
>>>good old method of tar files.
>>>
>>
>>I see what you are saying and I agree, with a small community as it is
>>now, there is no need to have a full fledged project management system.
>>That just adds to the administrative overhead and also can create a lot
>>of junk.
>>
>>Now what features do you see that a content management system would add,
>>that cannot be done with the docuwiki as it is now?
>>
>>
>>Guenter
>>
> 
> 
> After doing some explorations, I highly recommend looking at Zope for
> myhdl.org. I've been looking at content management systems, including
> MediaWiki, phpBB, Drupal, Wordpress, and Zope. So far, I think Zope offers
> the most potential.

Mm, but have you ever used it :-) Several year ago, I have a number of times,
and never really liked it. I found if very complicated and full of jargon.
Also, it has something unpythonic: it's large, not orthogonal and complex.
It was supposed to become the Python killer app, but from what I hear
many pythonistas simply don't like it.

I never used Plone, but I imagine it has been invented to take away
some complexity from the underlying Zope to make a more usable system.
Still, I fear that the underlying complexity still shines through.
Tom is using it for his site, so he may give good advice here.

In any case, with the migration to myhdl.org we now have the opportunity
to re-assess the CMS software issue. I think it's wise to take some
time to consider the options carefully, based on a specific list
of must-have and desirable features.

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] Reflections on a MyHDL IP library

[George P. <ge...@ga...>]

On Wed, December 13, 2006 10:15 am, Joachim K=F6nig-Baltes wrote:
> George Pantazopoulos schrieb:
>> After doing some explorations, I highly recommend looking at Zope for
>> myhdl.org. I've been looking at content management systems, including
>> MediaWiki, phpBB, Drupal, Wordpress, and Zope. So far, I think Zope
>> offers
>> the most potential.
>>
>> Zope seems more fundamental than all the others. Since modules can be
>> downloaded and/or created for it, it can incorporate all their
>> functionality.
>>
>> In fact, my friend told me a Zope-based site could even run all those
>> other pre-existing components under one umbrella. Last, but certainly
>> not
>> least, Zope is based on Python, and not nasty, C-like PHP.
>>

> I'm working with Plone (CMS based on Zope) as my day job, so in case
> that some
> help and support is needed, I can contribute (e.g. if a MyHDL skin is
> needed). Be aware
> that the learning curve is rather steep, but Plone and Zope are mature
> and worth the
> efforts IMO.
>
> Joachim
>

Plone looks like exactly what I've wanted all along! Thanks Joachim!

I was very impressed with their website and demostration videos. I think
experiencing something like this as a lot better than reading about it.

Plone demonstration videos:
http://plone.org/about/movies

Rock on,
George


> -----------------------------------------------------------------------=
--
> Take Surveys. Earn Cash. Influence the Future of IT
> Join SourceForge.net's Techsay panel and you'll get the chance to share
> your
> opinions on IT & business topics through brief surveys - and earn cash
> http://www.techsay.com/default.php?page=3Djoin.php&p=3Dsourceforge&CID=3D=
DEVDEV
> _______________________________________________
> myhdl-list mailing list
> myh...@li...
> https://lists.sourceforge.net/lists/listinfo/myhdl-list
>


--=20
George Pantazopoulos
http://www.gammaburst.net

Re: [myhdl-list] Reflections on a MyHDL IP library

[Tom D. <TD...@di...>]

> I'm working with Plone (CMS based on Zope) as my day job, so in case
> that some
> help and support is needed, I can contribute (e.g. if a MyHDL skin is
> needed). Be aware
> that the learning curve is rather steep, but Plone and Zope are mature
> and worth the
> efforts IMO.
>

We use plone to host our website and since we have offered to host the 
myhdl.org site, that may be a good option.  We are by no means plone experts, 
but can do enough to get a site setup so it is easy to add content.

Tom

Re: [myhdl-list] Reflections on a MyHDL IP library

[<joa...@em...>]

George Pantazopoulos schrieb:
> After doing some explorations, I highly recommend looking at Zope for
> myhdl.org. I've been looking at content management systems, including
> MediaWiki, phpBB, Drupal, Wordpress, and Zope. So far, I think Zope offers
> the most potential.
>
> Zope seems more fundamental than all the others. Since modules can be
> downloaded and/or created for it, it can incorporate all their
> functionality.
>
> In fact, my friend told me a Zope-based site could even run all those
> other pre-existing components under one umbrella. Last, but certainly not
> least, Zope is based on Python, and not nasty, C-like PHP.
>   
I'm working with Plone (CMS based on Zope) as my day job, so in case 
that some
help and support is needed, I can contribute (e.g. if a MyHDL skin is 
needed). Be aware
that the learning curve is rather steep, but Plone and Zope are mature 
and worth the
efforts IMO.

Joachim

Re: [myhdl-list] Reflections on a MyHDL IP library

[George P. <ge...@ga...>]

On Fri, November 17, 2006 5:40 pm, G=FCnter Dannoritzer wrote:
> Jan Decaluwe wrote:
> [...]
>>> Trac looks more like it is suited for one project group. I think the
>>> mix
>>> of having different users that can participate in different projects
>>> requires quite some tweaking of trac.
>>
>> I'm not convinced this is what we need first. Trac seems to be a
>> sourceforge done better, in other words, a development management
>> system. But this is a general problem, well suited to large scale
>> dedicated hosted solutions such as sourceforge itself, or Google Code
>> (both with subversion support), or opencores.org.
>>
>> I think what we need first is a content management system, well suited
>> to
>> create great documentation rapidly, and distribute releases by the
>> good old method of tar files.
>>
>
> I see what you are saying and I agree, with a small community as it is
> now, there is no need to have a full fledged project management system.
> That just adds to the administrative overhead and also can create a lot
> of junk.
>
> Now what features do you see that a content management system would add=
,
> that cannot be done with the docuwiki as it is now?
>
>
> Guenter
>

After doing some explorations, I highly recommend looking at Zope for
myhdl.org. I've been looking at content management systems, including
MediaWiki, phpBB, Drupal, Wordpress, and Zope. So far, I think Zope offer=
s
the most potential.

Zope seems more fundamental than all the others. Since modules can be
downloaded and/or created for it, it can incorporate all their
functionality.

In fact, my friend told me a Zope-based site could even run all those
other pre-existing components under one umbrella. Last, but certainly not
least, Zope is based on Python, and not nasty, C-like PHP.

Here's but one site someone did using Zope as a backend:
http://www.issuetrackerproduct.com/

His main site:
http://www.peterbe.com/

Zope webpage:
http://www.zope.org/

Rock on,
George

http://www.gammaburst.net

Re: [myhdl-list] Tristate bus to external SRAM

[George P. <ge...@ga...>]

On Wed, December 13, 2006 9:16 am, Jan Decaluwe wrote:
> George Pantazopoulos wrote:
>>>At some point I would like to take some time to think thorougly
>>>about tristates and inouts and come up with a satisfactory
>>>solution, hopefully based on user inputs and feedback.
>>>Currently, I'm focussed on getting toVHDL on track
>>>and right - which offers more than enough brain teasers :-)
>>>
>>>
>>
>> Hi Jan,
>>
>> Looks like you've been on a roll with toVHDL! I'm looking forward to
>> trying out 0.6dev3 with its signed support.
>
> It's available now.
>
>>
>> I'm planning a HD44780-based LCD interface for the growing MyHDL IP
>> library. I think this is a necessary and useful addition with a lot of
>> popular appeal. To achieve my design goals, I'll need some
>> bidirectional/tristate support. How's that coming along? :-) Can I hel=
p
>> somehow?
>
> I'll no longer try to release 0.6 before the year-end. Instead,
> with 0.6dev3 out I now want to make some progress with myhdl.org,
> so that it is up and running and stable before 0.6. After that,
> I promise I'll look into the bidir/tristate functionality. I'm
> sure you'll be able to help but I want to do it right and it
> will take some time. I may decide to include it in 0.6.
>
> Jan
>

Thanks Jan, I appreciate your effort, as always. No rush on the Tristate
support. I've been busy, but I plan on getting back into my electronic
design stuff between xmas and new years. Feel free to ask for
help/feedback.

Regards,
George

http://www.gammaburst.net

Re: [myhdl-list] Tristate bus to external SRAM

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

George Pantazopoulos wrote:
>>At some point I would like to take some time to think thorougly
>>about tristates and inouts and come up with a satisfactory
>>solution, hopefully based on user inputs and feedback.
>>Currently, I'm focussed on getting toVHDL on track
>>and right - which offers more than enough brain teasers :-)
>>
>>  
> 
> Hi Jan,
> 
> Looks like you've been on a roll with toVHDL! I'm looking forward to 
> trying out 0.6dev3 with its signed support.

It's available now.

> 
> I'm planning a HD44780-based LCD interface for the growing MyHDL IP 
> library. I think this is a necessary and useful addition with a lot of 
> popular appeal. To achieve my design goals, I'll need some 
> bidirectional/tristate support. How's that coming along? :-) Can I help 
> somehow?

I'll no longer try to release 0.6 before the year-end. Instead,
with 0.6dev3 out I now want to make some progress with myhdl.org,
so that it is up and running and stable before 0.6. After that,
I promise I'll look into the bidir/tristate functionality. I'm
sure you'll be able to help but I want to do it right and it
will take some time. I may decide to include it in 0.6.

Jan

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

[myhdl-list] 0.6dev3

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

Hi all:

0.6dev3 has been released.

I have addressed operator handling, including signed and
augmented operators. This can be done cleanly, but it has
taken me some time to figure out how :-) VHDL is much more
complicated than Verilog in this respect, but the code
is now actually cleaner.

I've become an expert in resizings, type conversions and
castings and I'm now convinced that VHDL designers must
be masochists (that includes myself) :-) When 0.6 is released,
I really must write a paper on how great the intbv type is!

Status info:
http://myhdl.jandecaluwe.com/doku.php/dev:todo:0.6

-- 
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] MyHDL and synthesize to non HDL

[<joa...@em...>]

Jan Decaluwe wrote:
> I've looked at some AVR examples very briefly.
>
> As I understand it, you can use C to program the AVR
> architecture by referring to symbols representing registers
> and hardware primitives. So it's a "low-level" kind of C code
> in the sense that you couldn't use it for anything else than
> to program AVR controllers. We are therefore not really
> talking about MyHDL to C, but MyHDL to AVR.
>   
Yes.
> Integrating generic C code based on a functional interface
> in Python code would be trivial. But again, this doesn't seem
> our case here. The hardware interface is embedded in the AVR C
> code in the way the register symbols are set up and used.
>   
Yes, exactly.
> In short, while I don't exclude that meaningful things could be
> done, I don't immediately see what and how (and in a reasonable
> development time)
O.k., thanks for clearing things up. So MyHDL is very valuable for me 
for describing
the connection from the wire into the AVR via UART, Port or USI (simple 
shiftregister
base serial communication hardware) and simulating a 1-wire network 
based on that.

For the final coding however I'll have to derive C manually. It's o.k. 
this way, I just did not
want to spend time on things that would be to difficult to achieve. But 
MyHDL is still useful
here too because of the easy simulation of modification to the algorithms.

Joachim

Re: [myhdl-list] MyHDL and synthesize to non HDL

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

Joachim König-Baltes wrote:
> I've used MyHDL to model the 1-wire protocol from dallas
> between a master and a slave, and it was really easy to
> do so although I was a bit skeptical concerning the
> restrictions of standard generators.
> 
> I was even able to write it as an OO model based on classes.
> 
> As the protocol is rather stable now I'd like to use the
> model for synthesizing it, but not into hardware but:
> 
> I'd like to use AVR microcontrollers for doing some home automation
> with the 1-wire protocol for the communication between them
> (because it's simple and electrically uncritical over "long"
> distances). I'd like to map it onto different resources inside
> the AVRs depending on their capabilities (UART, port, USI) and
> have written models for these resources.
> 
> The AVRs can be programmed in C rather easily.
> 
> Now to my question:
> 
> Is MyHDL suited to synthesize C from the python code?
> 
> My idea would be as follows: A class instance could model a particular
> AVR microcontroller and I could assign ports or an UART to be
> used for 1-wire communication (and other purposes). I would then
> like to simulate the combination of instances connected to form
> a 1-wire network and then synthesize one of the instances to C in
> order to generate the program for the flash of the AVR.

I've looked at some AVR examples very briefly.

As I understand it, you can use C to program the AVR
architecture by referring to symbols representing registers
and hardware primitives. So it's a "low-level" kind of C code
in the sense that you couldn't use it for anything else than
to program AVR controllers. We are therefore not really
talking about MyHDL to C, but MyHDL to AVR.

> Is this somehow possible (I'm willing to dig deep into MyHDL). If
> not, what else can I do with the model? If I still have to hand-code
> the AVR in C, how can I at least have some advantage of MyHDL in
> relation to the C-program?

Integrating generic C code based on a functional interface
in Python code would be trivial. But again, this doesn't seem
our case here. The hardware interface is embedded in the AVR C
code in the way the register symbols are set up and used.

In short, while I don't exclude that meaningful things could be
done, I don't immediately see what and how (and in a reasonable
development time).

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] MyHDL and synthesize to non HDL

[<joa...@em...>]

dannoritzer schrieb:
> Have you looked into the toVerilog function?
no, not yet, will have a look at it.
>  I know you don't want to gothat way, just a thought here.
I do not mind going that way, seems natural to me.
>  If you code complies to the restrictions
> for toVerilog, I wonder how difficult it would be create a toC function,
> based on the existing toVerilog code.
>   
I read a similar question from George Pantazopoulos (on 2006/09/26) 
about synthesizability of classes
and Jan did not give much hope for that. In my case, the classes are 
somehow essential
for me. The individual activities would be handled by ISRs triggered by 
interrupt on the
port pin or by a timer. But I'll have a look at toVerilog and see if I 
have a chance.

Joachim

Re: [myhdl-list] MyHDL and synthesize to non HDL

[dannoritzer <dan...@we...>]

Joachim König-Baltes wrote:
> I've used MyHDL to model the 1-wire protocol from dallas
> between a master and a slave, and it was really easy to
> do so although I was a bit skeptical concerning the
> restrictions of standard generators.
> 
> I was even able to write it as an OO model based on classes.
> 
[...]
> 
> Now to my question:
> 
> Is MyHDL suited to synthesize C from the python code?
> 

Have you looked into the toVerilog function? I know you don't want to go
that way, just a thought here. If you code complies to the restrictions
for toVerilog, I wonder how difficult it would be create a toC function,
based on the existing toVerilog code.

Guenter

[myhdl-list] MyHDL and synthesize to non HDL

[<joa...@em...>]

I've used MyHDL to model the 1-wire protocol from dallas
between a master and a slave, and it was really easy to
do so although I was a bit skeptical concerning the
restrictions of standard generators.

I was even able to write it as an OO model based on classes.

As the protocol is rather stable now I'd like to use the
model for synthesizing it, but not into hardware but:

I'd like to use AVR microcontrollers for doing some home automation
with the 1-wire protocol for the communication between them
(because it's simple and electrically uncritical over "long"
distances). I'd like to map it onto different resources inside
the AVRs depending on their capabilities (UART, port, USI) and
have written models for these resources.

The AVRs can be programmed in C rather easily.

Now to my question:

Is MyHDL suited to synthesize C from the python code?

My idea would be as follows: A class instance could model a particular
AVR microcontroller and I could assign ports or an UART to be
used for 1-wire communication (and other purposes). I would then
like to simulate the combination of instances connected to form
a 1-wire network and then synthesize one of the instances to C in
order to generate the program for the flash of the AVR.

Is this somehow possible (I'm willing to dig deep into MyHDL). If
not, what else can I do with the model? If I still have to hand-code
the AVR in C, how can I at least have some advantage of MyHDL in
relation to the C-program?


Joachim

Re: [myhdl-list] MyHDL performance

[David B. <da...@we...>]

Martin d Anjou wrote:
> Hi,
> 
> I still hesitate to use MyHDL because of performance concerns for doing 
> ASIC verification (I have close to zero interest in design). I have been 
> using "a proprietary verification language" for quite some time now. 
> Recognizing limitations of this proprietary solution, I've been exploring 
> alternatives like C++ trusster.com, Digital Mars D StackThreads 
> (assertfalse.com), Java Jove, and of course MyHDL for its ease of use.
> 
> For example I have run a benchmark using the MyHDL producer-consumer and 
> the gray encoder in the documentation. The producer-consumer example is as 
> fast as an equivalent implementation in "the proprietary language". The 
> gray encoder is 10x slower, but I think the intbv is the bottleneck.
> 
> For code size, MyHDL producer-consumer beats the proprietary solution by a 
> great margin, and for gray coding the code sizes are almost equal. I have 
> not looked at memory footprint.
> 
> Do you think it is worth converting intbv or other aspects of MyHDL to C? 
> Have you explored ways to speed up MyHDL (greenlet, stackless python - 
> which is still active)?
> 
> Thanks,
> Martin
> 

As a general point for speeding up python, have you used psyco?  It 
doesn't work for all kinds of code, but for some things it can make a 
big difference.  Another point is that some operations are significantly 
faster in python 2.5.  If you haven't tried these two, then they will 
maybe give you an easy speed up.

Re: [myhdl-list] MyHDL performance

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

Martin d Anjou wrote:
> Hi,
> 
> I still hesitate to use MyHDL because of performance concerns for doing 
> ASIC verification (I have close to zero interest in design). I have been 
> using "a proprietary verification language" for quite some time now. 
> Recognizing limitations of this proprietary solution, I've been exploring 
> alternatives like C++ trusster.com, Digital Mars D StackThreads 
> (assertfalse.com), Java Jove, and of course MyHDL for its ease of use.
> 
> For example I have run a benchmark using the MyHDL producer-consumer and 
> the gray encoder in the documentation. The producer-consumer example is as 
> fast as an equivalent implementation in "the proprietary language". The 
> gray encoder is 10x slower, but I think the intbv is the bottleneck.

I wouldn't be suprized if some intbv operations such as indexing turn
out to be quite slow.

> For code size, MyHDL producer-consumer beats the proprietary solution by a 
> great margin, and for gray coding the code sizes are almost equal. I have 
> not looked at memory footprint.
> 
> Do you think it is worth converting intbv or other aspects of MyHDL to C?

Converting the intbv class and possibly the Signal class to C may make
a lot of sense. It wouldn't be a small task, so this should be confirmed
by experiments. Perhaps it's possible to start with those functions
that are really slow, instead of the whole class at once.

> Have you explored ways to speed up MyHDL (greenlet, stackless python - 
> which is still active)?

Yes - some comments:

Greenlets, stackless python and generators have in common that they can
model light-weight, massive parallelism. Greenlets and stackless are
more powerful, but I believe generators are good enough for HDL purposes.

The big advantage of generators is that they are standard Python, unlike
stackless; so I can develop myhdl as a conventional python package that
works with the standard interpreter.

I wouldn't anticipate a performance advantage from using greenlets
or stackless. In all cases, we also need a rather strict scheduler
with a significant overhead: that is, we have to implement the delta
cycle algorithm and signals on top of the parallelization method.

At one time I experimented with converting the main simulator loop
to C. Basically I had replaced Python access to high-level data
structures with C API access to high-level data structures. That
doesn't help a lot. Rather, performance advantages can be expected
when you can use low-level C types instead of Python types.

Another approach has been more succesful. Observe that MyHDL generators
can be sensitive to a number of different objects (edge, tuple of edges,
signal, tuple of signals, delay ...). In general, the scheduler has to
take all possibilities into account each time a generator yields.
This is inefficient because many generators will be sensitive to a single
kind of object only. So what has been done is that the code of each
generator is inspected (yes!) before the simulation starts. Based on
that, the generator gets a dedicated scheduler which is efficient
for its sensitivity purposes. This technique removes a lot of
simulation overhead for typical usage cases.

What next? A meaningful next step could be to migrate some
functionality to C, as you suggested.

Finally, there is PyPy. I once saw a demo by Armin Rigo showing
a massive speedup by using psyco. Unfortunately, psyco cannot
handle generators. Instead, Armin and others started the PyPy
project that at one time may bring psyco-like advantages to
general Python code. It would seem to me that MyHDL is a good
candidate, because a lot of code is run over and over again
during simulation.

So perhaps one day I'll be able to report a massive speedup
without having to do anything myself :-) That will be the day!

Jan

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

[myhdl-list] MyHDL performance

[Martin d A. <po...@ma...>]

Hi,

I still hesitate to use MyHDL because of performance concerns for doing 
ASIC verification (I have close to zero interest in design). I have been 
using "a proprietary verification language" for quite some time now. 
Recognizing limitations of this proprietary solution, I've been exploring 
alternatives like C++ trusster.com, Digital Mars D StackThreads 
(assertfalse.com), Java Jove, and of course MyHDL for its ease of use.

For example I have run a benchmark using the MyHDL producer-consumer and 
the gray encoder in the documentation. The producer-consumer example is as 
fast as an equivalent implementation in "the proprietary language". The 
gray encoder is 10x slower, but I think the intbv is the bottleneck.

For code size, MyHDL producer-consumer beats the proprietary solution by a 
great margin, and for gray coding the code sizes are almost equal. I have 
not looked at memory footprint.

Do you think it is worth converting intbv or other aspects of MyHDL to C? 
Have you explored ways to speed up MyHDL (greenlet, stackless python - 
which is still active)?

Thanks,
Martin

Re: [myhdl-list] Licenses and expectations

[George P. <ge...@ga...>]

Martin d Anjou wrote:
> On Tue, 28 Nov 2006, Jan Decaluwe wrote:
>   
>> with things like darcs, git, mercurial ... and sometimes I feel like
>> those distributed systems would be more suited to things like myhdl.
>>     
>
> I am just a quiet watcher on this mailing list, so I don't plan on 
> interrupting your discussion. I simply have run into this problem 
> yesterday at my company, and I just want to share a few links:
>
> http://www.bitkeeper.com/Comparisons.Subversion.html
> http://keithp.com/blog/Repository_Formats_Matter.html
> http://www.jukie.net/~bart/blog/git-vs-hg
>
> And some more:
> http://kerneltrap.org/node/5557
> http://www.kernel.org/pub/software/scm/git/docs/tutorial.html
>
> Git vs Subversion:
> http://git.or.cz/gitwiki/GitSvnComparsion
>
> Martin
>   
Thanks a lot for your links, Martin! I'll be taking a closer look, but I 
really like the sound of Git because it's used by the linux kernel 
developers. This tells me that it's well-tested by a rabid bunch of 
developers who are all over the planet.

Rock on,
George
http://www.gammaburst.net

Re: [myhdl-list] Licenses and expectations

[Martin d A. <po...@ma...>]

On Tue, 28 Nov 2006, Jan Decaluwe wrote:
> with things like darcs, git, mercurial ... and sometimes I feel like
> those distributed systems would be more suited to things like myhdl.

I am just a quiet watcher on this mailing list, so I don't plan on 
interrupting your discussion. I simply have run into this problem 
yesterday at my company, and I just want to share a few links:

http://www.bitkeeper.com/Comparisons.Subversion.html
http://keithp.com/blog/Repository_Formats_Matter.html
http://www.jukie.net/~bart/blog/git-vs-hg

And some more:
http://kerneltrap.org/node/5557
http://www.kernel.org/pub/software/scm/git/docs/tutorial.html

Git vs Subversion:
http://git.or.cz/gitwiki/GitSvnComparsion

Martin

Re: [myhdl-list] Licenses and expectations; was Re: DSX1000 Open-source Delta-Sigma DAC IP Core (MyHDL)

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

George Pantazopoulos wrote:

> 
> I like the distinction made between promotional cores and other cores. I 
> agree that we'll eventually need a version-controlled repository, and I 
> would want subversion to be the tool of choice.

I'm using subversion locally (in particular for myhdl) and I have been
promoting it in the companies that I work with as a consultant. It
seems to be emerging as a real winner. So I agree it's a good choice.
But, there is so much interesting development going on in this field
with things like darcs, git, mercurial ... and sometimes I feel like
those distributed systems would be more suited to things like myhdl.

Anyway, I think the more important question is: should we host
a repository ourselves, or use a hosted service? (The question can
be extended to bug trackers, feature trackers, file release pages, etc.)
My personal feeling is that there is no conceptual difference between
MyHDL IP and any other open-source project, with respect to development
support tools. Therefore, we can save time and effort by using a
hosted service.

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] MyHDL graphic logo - work in progress

[Jens P. A. <je...@if...>]

How about something like this?

(logo is attached, but I don't know if attachments are allowed on the list)

On Thu, 16 Nov 2006 18:44:32 +0100, Jan Decaluwe <ja...@ja...>  
wrote:

> George Pantazopoulos wrote:
>> Hey guys,
>>
>>     I'm in the process of creating a logo that puts a friendly face on
>> MyHDL and I could use some constructive feedback. I'm really a fan of
>> this project and it's time we gave it some teeth! ;-)
>>
>> See here (bottom of my page):
>> http://myhdl.jandecaluwe.com/doku.php/users:george_pantazopoulos#myhdl_logo_work_in_progress
>
> I have zero talent for graphical design, so I'm reluctant to comment  :-)
>
> I like the idea of the snake and the chip but probably a more
> "abstracted" design is better for a logo. And perhaps a chip package
> is more recognizable than a die (it shouldn't resemble a bug though :-))
> The new python logo has such an abstract snake, although I don't  
> particularly
> think it's a very strong logo.
>
> Jan
>



-- 
Using Opera's revolutionary e-mail client: http://www.opera.com/mail/

Re: [myhdl-list] Licenses and expectations; was Re: DSX1000 Open-source Delta-Sigma DAC IP Core (MyHDL)

[George P. <ge...@ga...>]

>
>> I want to make it very clear that I think that nobody should
>> feel any pressure to publish his source code.
>> I would encourage a data sheet section on myhdl.org where people
>> advertise their work under any conditions they want.
>>
>> My proposal to "standardize" on the LGPL is something else - just
>> a practical matter. On sourceforge, you can use any OSI license you
>> want, but sometimes it seems the innovation is in inventing new license
>> schemes instead of in real work. Google Code thinks so too:
>>
>>      http://code.google.com/hosting/faq.html#limitedlicenses
>>
>> as does opencores.org:
>>
>>     http://www.opencores.org/projects.cgi/web/opencores/mission
>>     
>
> OK, I see your point and I agree. I remember endless discussions on the
> opencores mailing list about licenses issues. Even between using GPL vs.
> LGPL. Sticking to one might be a good way to limit that.
>
>
>   

I think the LGPL is a reasonable choice for the IP cores I've been 
releasing.

> >From that difference I think there should be some structuring.
>
> One example could be:
>
> * tools
> * promotional cores
> * other cores
>
> Tools and promotional cores should be something agreed on. Otherwise
> this becomes too much of a bazaar type collection. For that it has some
> structure its code could come along with a distutils installer. Maybe as
> a library to myhdl.
>
> The other cores could be something everybody is doing on its own preference.
>
>
>   
I like the distinction made between promotional cores and other cores. I 
agree that we'll eventually need a version-controlled repository, and I 
would want subversion to be the tool of choice.

I'm not quite sure where stuff like the Ascii Timing Spec that I've been 
working on will fit in just yet.

Another thing I would like to see is that contributors are free to put 
up a link so people can willingly donate money to their projects. 
Additionally, MyHDL itself could have such a button. I use cygwin 
extensively, and I've felt good about donating to their contributors. I 
think their donations link is appropriate and unobtrusive.

See:
http://cygwin.com

Regards,
George

[myhdl-list] Licenses and expectations; was Re: DSX1000 Open-source Delta-Sigma DAC IP Core (MyHDL)

[<dan...@we...>]

Jan Decaluwe wrote:
> Günter Dannoritzer wrote:
>> Jan Decaluwe wrote:
>> [...]
[...]
>>> But what's worse, bona fide companies will simply avoid
>>> looking at the info. They don't want to be exposed to
>>> things that are not legally crystal-clear. And this
>>> bad effect may extend to the whole project.
>>
>> I am not sure. I think if there is a really great project available, a
>> company will take the time to talk about the issues.
> 
> Of course, and I'd love to see such "star IP" developed in MyHDL. But
> there's no need to publish source code for that. Just publish a datasheet
> and the conditions.
> 

OK, I agree. I did not consider that option.

[...]
> 
> I want to make it very clear that I think that nobody should
> feel any pressure to publish his source code.
> I would encourage a data sheet section on myhdl.org where people
> advertise their work under any conditions they want.
> 
> My proposal to "standardize" on the LGPL is something else - just
> a practical matter. On sourceforge, you can use any OSI license you
> want, but sometimes it seems the innovation is in inventing new license
> schemes instead of in real work. Google Code thinks so too:
> 
>      http://code.google.com/hosting/faq.html#limitedlicenses
> 
> as does opencores.org:
> 
>     http://www.opencores.org/projects.cgi/web/opencores/mission

OK, I see your point and I agree. I remember endless discussions on the
opencores mailing list about licenses issues. Even between using GPL vs.
LGPL. Sticking to one might be a good way to limit that.

[...]
> 
> Now, the general point you raise on expectations is very relevant
> and I have many doubts myself. We should have an open discussion
> about this before continuing.

The big difference between for example opencores and myhdl is that the
objective of opencores is to host open logic core projects. In contrast
the object of the new myhdl page should be to promote the use of myhdl
through available logic cores or other tools. Those tools or logic cores
should help lower the hesitation of logic developers to use myhdl.

>From that difference I think there should be some structuring.

One example could be:

* tools
* promotional cores
* other cores

Tools and promotional cores should be something agreed on. Otherwise
this becomes too much of a bazaar type collection. For that it has some
structure its code could come along with a distutils installer. Maybe as
a library to myhdl.

The other cores could be something everybody is doing on its own preference.


Guenter

Re: [myhdl-list] DSX1000 Open-source Delta-Sigma DAC IP Core (MyHDL)

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

George Pantazopoulos wrote:

> 
> Hi Jan, you raise some great points and I too want wide adoption.
> 
>      I didn't put a lot of thought into the license and am open to 
> changing it. I don't mind opening it up for free commercial use as well. 
> How would the LGPL license work in terms of hardware IP cores?

As far as I'm concerned, it's the best option that I'm aware of.

First of all, the GPL family of licenses is widely used, time tested,
and, most importantly, whenever I put some serious thought in it,
its features are exactly what I personally want.

I assume the GPL-like features are familiar, so there's no need to
discuss them further here.

However, the full GPL license itself is not what I want for MyHDL or for
IP cores that I would write. When someone uses MyHDL or an IP core of
mine, I want the GPL conditions to apply only to the code that I
originally wrote, not to the user's own code. That's enough for me.
In this way, a user can keep his own code private if he wants to.
I think that otherwise, commercial users won't touch it.

With the GPL itself, my requirements cannot be fulfilled, because
the license would extend to all code that uses MyHDL or the IP
core. But with the LGPL, I get exactly what I want.

If you look on opencores.org, you'll see that they would like
everyone to use the LGPL as much as possible. So apparently
they came to the same conclusion.

Jan

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