myhdl-list — Mailing list for discussions on MyHDL

Re: [myhdl-list] Performance Solution #3, Getting Silicon Valley behind it, Class, LGPL, Video

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

On 04/04/2011 06:11 PM, Christopher Lozinski wrote:

> *LGPL*
>
> It would be great if you could add the common sense description to the front of the LGPG.
>
> "Our intent is that you can you own the designs, and test harnesses, but changes you make to the core MyHDL world get shared. "
>
> Of course LGPL does not allow for edits. Which is a pity, because the license should refer to the application domain in order to be clearer.

Second best option is to add such an explanation
on myhdl.org and in the manual (if we agree that
the principle is OK.) Actually I think that would
be a very good idea, because many (corporate) users
may have similar concerns, and may not appreciate
the difference between GPL and LGPL.

Content and patches welcome :-)

-- 
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
     Analog design automation: http://www.mephisto-da.com
     World-class digital design: http://www.easics.com

[myhdl-list] MyHDL Course

[Christopher L. <loz...@fr...>]

I have started a Google Doc for the MyHDL course.

https://docs.google.com/document/d/1Vo7bMRoc_KOM0bt7XDmV62IqCXweeK9WlhdeUv-nbes/edit?hl=en#

We expect to make money off offering this course, so whoever wants to 
contribute to it, we are happy to compensate you out of the revenue 
made.  More than that, we hope you will also be one of the teachers, for 
those students who live near you.   There are not enough experienced 
MyHDL people for the number of python developers who will want to use it.

I do not expect to make much money off this, mostly I am doing this 
because it is way easier than trying to figure out everything myself.  
In particular there are a bunch of class libraries that I hope someone 
else writes.

If you want edit permission on the course material, please let me 
know.   You can either volunteer, or enter into a business relationship 
for the work you provide.

-- 
Regards
Christopher Lozinski

Check out my iPhone apps TextFaster and EmailFaster
http://textfaster.com

Re: [myhdl-list] Performance Solution #3, Getting Silicon Valley behind it, Class, LGPL, Video

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

On 4/4/2011 11:11 AM, Christopher Lozinski wrote:
> *Performance Solution #3*
>
> For my entire life people have criticized object-oriented software as
> too slow. They want to prematurely optimize all the function calls,
> rather than work at the level of optimizing the application.
>
> My standard answer is give me the fastest development environment
> possible to bring up my application. Once that is done, I can find out
> what is really slow, and what can be done about it. Then I can optimize
> that small part that is slow. In 30 years of practice I have never
> needed to actually do that!
>
> In my design, the slowest part will be my hugely complicated
> communication channels. In python, I can simplify that with a simplified
> model that anything can talk to anything. I can have two versions of the
> communication channels. One that simulates the details, and another one
> that does the exact same thing at a higher level of abstraction but runs
> much faster. In this case, I may need to do this.
>
> And since this is python, it will take me very little time to build both
> models. If I am really lucky the two models will be perfectly
> interchangeable, and provide an additional test harness, but even if
> they are not, I will be fine.

In addition to a OO it is also a scripting language.  The largest 
performance penalty is no native compilation.  This has all kinds of 
benefits but purely speaking performance it is a hindrance.

>
> *Getting Silicon Valley Behind it. *
>
> Jan made an excellent comment about the need to get Silicon Valley
> behind this. I had been expecting to have very interesting conversations
> with the hardware and tool vendors. If anybody has an insight into how
> those conversations would go, I would be very interested in hearing it.
> Here is my naive suggestion.
>
> Let us have a bunch of people behind the scenes with different
> responsibilities. Create a sense of structure. One person in charge of
> interfacing with 3rd party tools. One person in charge of class
> libraries, specifically libraries to support custom hardware features.
> For example someone mentioned that some FPGA's now have FIFO hardware
> modules. So we need FIFO software modules. Maybe another person
> responsible for open source ip cores. And maybe a third person in charge
> of conferences. And a fourth person in charge of offering a class.
> Ideally, those individuals would ideally be available by cell phone
> during the conference. That would totally destroy the one-man image. It
> is what is missing from managed by mailing list.
>
> Any volunteers?

Unfortunately I will not be available, Wednesday is a bad day for me.

>
> *Class*
>
> Which brings us to the Class.
>
> Thank you very much for the class docs Christopher Felton. Forgive me if
> I take a different path. Jan Coombs and I are putting together a simple
> blink the lights class. Anyone else who wants to work with us, we would
> be delighted to have you participate. More on this later.

No problemo

>
> *LGPL*
>
> It would be great if you could add the common sense description to the
> front of the LGPG.
>
> "Our intent is that you can you own the designs, and test harnesses, but
> changes you make to the core MyHDL world get shared. "
>
> Of course LGPL does not allow for edits. Which is a pity, because the
> license should refer to the application domain in order to be clearer.
>
> Anyhow I am pleased that this mailing list has come to life. I have had
> a great time this last week, and learned a lot.
>
> --
> Regards
> Christopher Lozinski

Re: [myhdl-list] My take on MyHDL weaknesses - and solutions

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

On 4/4/2011 9:22 AM, Ben wrote:
> On Mon, Apr 4, 2011 at 15:20, Christopher Felton<chr...@gm...>  wrote:
>> On 4/4/2011 4:10 AM, Ben wrote:
>>> On Mon, Apr 4, 2011 at 11:00, Jan Decaluwe<ja...@ja...>    wrote:
>>>> Lack of killer features
>>>> -----------------------
>>>> The benefits of MyHDL are real but they remain somewhat
>>>> abstract, e.g. "managing complexity".
>>>>
>>>> Solution: a strong value proposition would be concrete
>>>> features that many hardware designers want but that are not
>>>> offered by their current tools. I have two things in mind
>>>> currently: a good fixed-point class with transparent support
>>>> by the convertor, and SystemVerilog-style interfaces in
>>>> MyHDL that could be converted to VHDL and Verilog, that don't
>>>> have something similar.
>>>>
>>>
>>> For the records, I have another one for this list: native (as in
>>> "integrated in the language") support for asynchronous communication
>>> channels. I'm quite certain, this would have its place in MyHDL,
>>> however, my way of tackling this beast down is not established yet ...
>>> I'd be glad to hear your views on this !
>>>
>>
>> Are you thinking something similar to Balsa or CSP type language?  Like
>> many of the other topics (fixed-point, floating-point, etc) I believe
>> this can be an add-on module, just like MyHDL is an add-on to Python.
>> Or at least these additional "features" should be separated so that the
>> focus/goals of MyHDL is crystal clear.  The goals of the add-on features
>> is crystal clear.
>>
>> If you use the MyHDL framework and follow the Python/MyHDL design
>> philosophy I think ASYNC decorators can be created.  But it would
>> require someone interested in this topic to spearhead the efforts.
>>
>> Given my limited understanding of ASYNC communication channels, you
>> could implemented the standard 2 or 4 rail channels in MyHDL today (as
>> you could with Verilog/VHDL).  But to make it a little easier on a ASYNC
>> designer you would want to make this transparent.  Using the decorator
>> approach you could construct something like
>>
>> @always_async(ch1)
>> ...
>>
>> I am completely sticking my neck out here.  But I think this is the type
>> of support you would be looking for?
>>
>
> That's pretty much what I thought of, yes. I would't include it inside
> MyHDL core, even if we need some way to advertise those modules (like
> the fixed-point or floating-point one, ...). Hidden on a page of the
> wiki doesn't sounds enough to me ... Maybe add a chapter about them in
> the tutorial so that everyone reading it get an idea of how those
> modules work and know where to come back when he fells that he needs
> them ...
>
> My interface is pretty much defined: I would introduce a `Channel`
> type, call my decorator `@receive` that would take a channel as
> parameter and it would wait for the sender to be ready, execute the
> function and indicate to the sender that the processing is done. My
> channel type would also have a `send` method that would wait for the
> receiver to be ready, send the value and wait for the receiver to be
> done. The channel value could only be read inside a receive block and
> so on ...
>
> As of today, all kinds of tools exists for that, they are pretty much
> new languages developed for this purpose. The advantage of using
> Python (MyHDL) for such a design is self explanatory !
>
> Regards
> Benoit

I like the @receive decorator.  Why would you need a "Channel" 
object/type versus the "Signal" in MyHDL?  From a simplistic point of 
view, adding support for ASYNC fits the MyHDL simulation model.

Chris

[myhdl-list] Performance Solution #3, Getting Silicon Valley behind it, Class, LGPL, Video

[Christopher L. <loz...@fr...>]

*Performance Solution #3*

For my entire life people have criticized object-oriented software as 
too slow.  They want to prematurely optimize all the function calls, 
rather than work at the level of optimizing the application.

My standard answer is give me the fastest development environment 
possible to bring up my application.  Once that is done, I can find out 
what is really slow, and what can be done about it.  Then I can optimize 
that small part that is slow.  In 30 years of practice I have never 
needed to actually do that!

In my design, the slowest part will be my hugely complicated 
communication channels.  In python, I can simplify that with a 
simplified model that anything can talk to anything.  I can have two 
versions of the communication channels.  One that simulates the details, 
and another one that does the exact same thing at a higher level of 
abstraction but runs much faster.   In this case, I may need to do this.

And since this is python, it will take me very little time to build both 
models.  If I am really lucky the two models will be perfectly 
interchangeable, and provide an additional test harness, but even if 
they are not, I will be fine.

*Getting Silicon Valley Behind it. *

Jan made an excellent comment about the need to get Silicon Valley 
behind this.  I had been expecting to have very interesting 
conversations with the hardware and tool vendors.   If anybody has an 
insight into how those conversations would go, I would be very 
interested in hearing it.  Here is my naive suggestion.

Let us have a bunch of people behind the scenes with different 
responsibilities.  Create a sense of structure.  One person in charge of 
interfacing with 3rd party tools.  One person in charge of class 
libraries, specifically libraries to support custom hardware features.  
For example someone mentioned that some FPGA's now have FIFO hardware 
modules.  So we need FIFO software modules.  Maybe another person 
responsible for open source ip cores.    And maybe a third person in 
charge of conferences.   And a fourth person in charge of offering a 
class.  Ideally,  those individuals would ideally be available by cell 
phone during the conference.  That would totally destroy the one-man 
image.  It is what is missing from managed by mailing list.

Any volunteers?

*Class*

Which brings us to the Class.

Thank you very much for the class docs Christopher Felton.  Forgive me 
if I take a different path.  Jan Coombs and I are putting together a 
simple blink the lights class.  Anyone else who wants to work with us, 
we would be delighted to have you participate.  More on this later.

*LGPL*

It would be great if you could add the common sense description to the 
front of the LGPG.

"Our intent is that you can you own the designs, and test harnesses, but 
changes you make to the core MyHDL world get shared.  "

Of course LGPL does not allow for edits.  Which is a pity, because the 
license should refer to the application domain in order to be clearer.

Anyhow I am pleased that this mailing list has come to life.   I have 
had a great time this last week, and learned a lot.

-- 
Regards
Christopher Lozinski

Check out my iPhone apps TextFaster and EmailFaster
http://textfaster.com

Re: [myhdl-list] GPL License

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

On 4/4/2011 9:26 AM, Jan Decaluwe wrote:
> On 04/04/2011 02:39 PM, Christopher Felton wrote:
>> <snip>
>>>
>>> In short, I believe the LGPL is exactly what I need.
>>
>> Lost me a little.  Is MyHDL currently under GPL but you believe LGPL
>> would be a better option moving forward?  Or is it currently unlicensed
>> and you would like to adopt LGPL.
>
> MyHDL, the implementation, is, and has always been,
> under the LGPL. See the distribution.
>
> This is a gnu license like GPL, but fundamentally different,
> because it only affects the myhdl library itself. (Note  that
> the gnu project recommends against using LGPL as
> a first choice.)
>
> Before everybody start recommending new licenses, please
> review my goals carefully:
>
> 1) I want changes (bug fixes, improvements, new features) to
> the myhdl package to be shared with you and me.
> 2) I want to avoid that using myhdl poses any restrictions on
> whatever someone does with it (as opposed to: "to it").
>
> I believe the LGPL fits that bill.
>
> Therefore:
>
> Either, another license should be a better/cleaner way
> to achieve those goals;
> Or, you have to convince me that there are very good
> reason to change those goals.
>
> For the record: I have no intention to be as generous as
> for example the Python license. If MyHDL is a good idea,
> big EDA may agree one day. I have no intention to compete
> with a closed-source MyHDL clone backed by some big
> EDA company that reuses our ideas and code without
> giving anything back.
>
> Jan
>

Those sound like good goals to me.  Thanks for the clarification which 
license is being used.

Believe it was already stated but to reiterate, LGPL does not have the 
"infected" property.  It is not a "touch" transmittable disease.  The 
DNA has be be modified :)

Chris Felton

Re: [myhdl-list] My take on MyHDL weaknesses - and solutions

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

Thanks for the write-up Jan!

On 4/4/2011 4:00 AM, Jan Decaluwe wrote:
<snip>
>
> Performance
> -----------
> Compared to compiled VHDL and Verilog simulators, MyHDL is
> slow as a dog. MyHDL's implementation tries to limit the
> overhead, but performance will always be limited by the
> underlying Python interpreter.
>
> Solution 1: Education. Raw performance doesn't necessarily
> translate directly into designer's performance, especially
> in the initial exploratory phases of a project. Otherwise
> no one would be using Python, Perl, php or tcl.
>
> Solution 2: The PyPy project (future). Python doesn't have
> to be slow: by employing clever JIT techniques, performance
> can be improved drastically e.g. 5-10x. I believe that MyHDL
> is a good candidate for this type of optimization. The day
> this happens would be one of the most important ones in
> MyHDL's history: the performance limitations would for a
> large part go away, and it would be the ultimate validation
> of the concept: benefitting from advances without having to
> do anything yourself :-)

I think one point to take away is that there are many efforts on-going 
to dramatically increase the speed of Python.  Personally, I think 
US-Python has a little better chance at getting there than PyPy.  But 
regardless of the technology used there are many others interested in 
this subject, which MyHDL will directly benefit!

If resident MyHDL simulation seems to be a bottle neck, co-simulation 
can be utilized.  I frequently use MyHDL co-simulation at work. 
Although, not quantified I don't see any performance penalties for my 
test-benches running in Python and my design simulating in <name your 
favorite simulator>.

I do *not* use the test-bench conversion methods.  The test-bench 
conversions are too limited.  I have been successful creating models and 
transactors in MyHDL and co-simulating with Verilog/VHDL.  Arguably, it 
would be difficult to quantify this because the test-benches (and 
supporting code) are much more advanced than I could ever implemented in 
SystemVerilog/Verilog/VHDL alone.  I could create a small sandbox, 
implement a Python test-bench and an equivalent Verilog testbench and 
compare.  But I don't think it would be a fair comparison because the 
test-benches would be constrained.

>
> Perception
> ----------
> MyHDL is sometimes perceived as a "one man show". Moreover,
> I'm long enough in this business to understand that no new
> EDA technology has a chance of truly succeeding without a
> strong backing from Silicon Valley. For the record: I have
> no plans of moving, it's too much fun living in a
> non-country :-)
>
> Solution: exactly the kind of initiatives that are being
> taken right now.

This is also why the FPGA world is a good target.  There is much less to 
overcome and many more people "playing" with the technology.

What's a non-country?

>
> Audience mismatch
> -----------------
> MyHDL is strongly in the "digital hardware design is a
> special kind of software development" camp. However, the
> vast majority of hardware designers doesn't see things this
> way. Schematic entry may be dead in practice, but not yet in
> the minds.
>
> Solution: Patience. It's a waste of time to argue with
> people who only use irrational arguments, which is how I
> would characterize the arguing skills of many hardware
> designers - they just don't *really* understand HDL-based
> design and synthesis. We have to keep our ideas alive until
> the new generation takes over. Moreover, there is another
> reason for hope: software designers who realize that FPGAs
> can be seen as "just" another computing platform. (Warning:
> we will then face the opposite problem of people wondering
> why things have to be done at such a "low level". It's
> lonely in the middle :-))

I agree, I have mentioned MyHDL countlessy to many of my peers.  And 
this is exactly the case.  Either a peer is doing higher-level system / 
verification or lower-level implementation (HDL) and neither is 
interested.  Most will not even give it look, not even pull up the 
webpage and review.  That could simply be because the suggestion is 
coming from me :)

 From my perspective this is where you can get a little traction, is 
starting with the high-level folks and letting them interface with the 
low-level (assuming a non one person effort).  System simulation, 
verification, model design all done in Python/MyHDL.

>
> Lack of killer features
> -----------------------
> The benefits of MyHDL are real but they remain somewhat
> abstract, e.g. "managing complexity".
>
> Solution: a strong value proposition would be concrete
> features that many hardware designers want but that are not
> offered by their current tools. I have two things in mind
> currently: a good fixed-point class with transparent support
> by the convertor, and SystemVerilog-style interfaces in
> MyHDL that could be converted to VHDL and Verilog, that don't
> have something similar.

If you need any help / input on the fixed-point I will be glad to help. 
  I think these features would be more effective than a "star" IP.  And 
I think the fixed-point would be a good starting point for these 
additional features.

As stated in another post, If possible I think it would be nice for 
these additional features to be treated as modules to MyHDL.  Simply so 
that the scope and goals of MyHDL are precise and the same with the 
modules.  The inclusion of these modules in MyHDL package makes sense 
but I believe there should be clear delineation between the core MyHDL 
and the additional features.

>
> Lack of star IP
> ---------------
> Open source star IP could make MyHDL very attractive. I am
> referring to projects such as Leon SPARC in VHDL. Ideally,
> someone would implement some hot new technology as an IP
> core in MyHDL. The problem is that such a project may need
> more effort than the MyHDL project itself.

As mentioned, I believe the "killer features" (frameworks) are where 
MyHDL can make a name for itself vs. the traditional IP development like 
the LEON processor.  If MyHDL community wants IP like LEON we should 
have signed up for Google's summer of code.  Recreating a large IP 
project is fairly straight forward but takes a substantial amount of 
development / coding time.

Creating support for "features" liked fixed-point, floating-point, 
ASYNC, etc.  These niches might be the area where Python/MyHDL can 
standout.  What I don't have a feel for is if a "star" IP built off the 
"killer features" would be needed to get attention.

There does seem to be a trend that each language requires a "star", ruby 
on rails comes to mind.  But I wonder what Python's "star" application 
was?  Or did it simply catch on as a useful language?

Getting the right "star" can be tricky?  A commercial tool, BlueSpec, 
created an OFDM module, presumably to showcase features and be a "star" 
IP (ah BlueSpec is a dialect of SV).  It isn't clear to me if this was 
successful or not as a "star" IP.  And it is assumed that this took 
considerable effort.  Also, BlueSpec was able to have graduate students 
do the work for them.

An OFDM core is the type of IP that would be great in Python/MyHDL vs 
HDL only language.  You can generate all the signal processing analysis, 
plots, performance analysis (OFDM performance) all in Python/MyHDL.  You 
can verify system-level models vs. the HDL descriptions, etc.  I think a 
core like this would be a great candidate.  But development of this 
would take a lot-o-bit of time, even with the existing reference design.

Another "star" IP option would be the GnuRadio USRP.  GnuRadio is 
heavily into Python!  One of the hardware platforms for GnuRadio is 
USRP.  The USRP has some basic down and up converters and flow control 
in an FPGA implemented in Verilog.  If the design was implemented in 
MyHDL we might be able to persuade the GnuRadio folks to adopt the MyHDL 
version and drop the Verilog version.  A couple years ago I started this 
effort ...  If there is interest in this IP module I can *give a best 
effort* to update the wiki page with the latest and add some explanations.

Yet another approach, is not to create the core IP but create the 
verification environments.  Most of the IP on open-cores lacks decent 
test environments.  If someone is using an open-cores module they might 
want to generate test environment in Python/MyHDL, give an explanation 
on the wiki, and post test environment on open-cores.  I find most are 
not interested in this type of development (at least not on our free 
time).  Most people want to create something and not verify someones 
work.  Optionally, the core could be recreated in MyHDL once the test 
environment is completed.  Many would argue this is the correct 
approach, test environment then the IP creation.

Chris Felton

Re: [myhdl-list] GPL License

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

On 04/04/2011 02:39 PM, Christopher Felton wrote:
> <snip>
>>
>> In short, I believe the LGPL is exactly what I need.
>
> Lost me a little.  Is MyHDL currently under GPL but you believe LGPL
> would be a better option moving forward?  Or is it currently unlicensed
> and you would like to adopt LGPL.

MyHDL, the implementation, is, and has always been,
under the LGPL. See the distribution.

This is a gnu license like GPL, but fundamentally different,
because it only affects the myhdl library itself. (Note  that
the gnu project recommends against using LGPL as
a first choice.)

Before everybody start recommending new licenses, please
review my goals carefully:

1) I want changes (bug fixes, improvements, new features) to
the myhdl package to be shared with you and me.
2) I want to avoid that using myhdl poses any restrictions on
whatever someone does with it (as opposed to: "to it").

I believe the LGPL fits that bill.

Therefore:

Either, another license should be a better/cleaner way
to achieve those goals;
Or, you have to convince me that there are very good
reason to change those goals.

For the record: I have no intention to be as generous as
for example the Python license. If MyHDL is a good idea,
big EDA may agree one day. I have no intention to compete
with a closed-source MyHDL clone backed by some big
EDA company that reuses our ideas and code without
giving anything back.

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
     Analog design automation: http://www.mephisto-da.com
     World-class digital design: http://www.easics.com

Re: [myhdl-list] My take on MyHDL weaknesses - and solutions

[Ben <ben...@gm...>]

On Mon, Apr 4, 2011 at 15:20, Christopher Felton <chr...@gm...> wrote:
> On 4/4/2011 4:10 AM, Ben wrote:
>> On Mon, Apr 4, 2011 at 11:00, Jan Decaluwe<ja...@ja...>  wrote:
>>> Lack of killer features
>>> -----------------------
>>> The benefits of MyHDL are real but they remain somewhat
>>> abstract, e.g. "managing complexity".
>>>
>>> Solution: a strong value proposition would be concrete
>>> features that many hardware designers want but that are not
>>> offered by their current tools. I have two things in mind
>>> currently: a good fixed-point class with transparent support
>>> by the convertor, and SystemVerilog-style interfaces in
>>> MyHDL that could be converted to VHDL and Verilog, that don't
>>> have something similar.
>>>
>>
>> For the records, I have another one for this list: native (as in
>> "integrated in the language") support for asynchronous communication
>> channels. I'm quite certain, this would have its place in MyHDL,
>> however, my way of tackling this beast down is not established yet ...
>> I'd be glad to hear your views on this !
>>
>
> Are you thinking something similar to Balsa or CSP type language?  Like
> many of the other topics (fixed-point, floating-point, etc) I believe
> this can be an add-on module, just like MyHDL is an add-on to Python.
> Or at least these additional "features" should be separated so that the
> focus/goals of MyHDL is crystal clear.  The goals of the add-on features
> is crystal clear.
>
> If you use the MyHDL framework and follow the Python/MyHDL design
> philosophy I think ASYNC decorators can be created.  But it would
> require someone interested in this topic to spearhead the efforts.
>
> Given my limited understanding of ASYNC communication channels, you
> could implemented the standard 2 or 4 rail channels in MyHDL today (as
> you could with Verilog/VHDL).  But to make it a little easier on a ASYNC
> designer you would want to make this transparent.  Using the decorator
> approach you could construct something like
>
> @always_async(ch1)
> ...
>
> I am completely sticking my neck out here.  But I think this is the type
> of support you would be looking for?
>

That's pretty much what I thought of, yes. I would't include it inside
MyHDL core, even if we need some way to advertise those modules (like
the fixed-point or floating-point one, ...). Hidden on a page of the
wiki doesn't sounds enough to me ... Maybe add a chapter about them in
the tutorial so that everyone reading it get an idea of how those
modules work and know where to come back when he fells that he needs
them ...

My interface is pretty much defined: I would introduce a `Channel`
type, call my decorator `@receive` that would take a channel as
parameter and it would wait for the sender to be ready, execute the
function and indicate to the sender that the processing is done. My
channel type would also have a `send` method that would wait for the
receiver to be ready, send the value and wait for the receiver to be
done. The channel value could only be read inside a receive block and
so on ...

As of today, all kinds of tools exists for that, they are pretty much
new languages developed for this purpose. The advantage of using
Python (MyHDL) for such a design is self explanatory !

Regards
Benoit

Re: [myhdl-list] My take on MyHDL weaknesses - and solutions

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

On 4/4/2011 4:10 AM, Ben wrote:
> On Mon, Apr 4, 2011 at 11:00, Jan Decaluwe<ja...@ja...>  wrote:
>> Lack of killer features
>> -----------------------
>> The benefits of MyHDL are real but they remain somewhat
>> abstract, e.g. "managing complexity".
>>
>> Solution: a strong value proposition would be concrete
>> features that many hardware designers want but that are not
>> offered by their current tools. I have two things in mind
>> currently: a good fixed-point class with transparent support
>> by the convertor, and SystemVerilog-style interfaces in
>> MyHDL that could be converted to VHDL and Verilog, that don't
>> have something similar.
>>
>
> For the records, I have another one for this list: native (as in
> "integrated in the language") support for asynchronous communication
> channels. I'm quite certain, this would have its place in MyHDL,
> however, my way of tackling this beast down is not established yet ...
> I'd be glad to hear your views on this !
>

Are you thinking something similar to Balsa or CSP type language?  Like 
many of the other topics (fixed-point, floating-point, etc) I believe 
this can be an add-on module, just like MyHDL is an add-on to Python. 
Or at least these additional "features" should be separated so that the 
focus/goals of MyHDL is crystal clear.  The goals of the add-on features 
is crystal clear.

If you use the MyHDL framework and follow the Python/MyHDL design 
philosophy I think ASYNC decorators can be created.  But it would 
require someone interested in this topic to spearhead the efforts.

Given my limited understanding of ASYNC communication channels, you 
could implemented the standard 2 or 4 rail channels in MyHDL today (as 
you could with Verilog/VHDL).  But to make it a little easier on a ASYNC 
designer you would want to make this transparent.  Using the decorator 
approach you could construct something like

@always_async(ch1)
...

I am completely sticking my neck out here.  But I think this is the type 
of support you would be looking for?

Chris Felton

> Regards
> Benoit
>
> ------------------------------------------------------------------------------
> Create and publish websites with WebMatrix
> Use the most popular FREE web apps or write code yourself;
> WebMatrix provides all the features you need to develop and
> publish your website. http://p.sf.net/sfu/ms-webmatrix-sf

Re: [myhdl-list] GPL License

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

<snip>
>
> In short, I believe the LGPL is exactly what I need.

Lost me a little.  Is MyHDL currently under GPL but you believe LGPL 
would be a better option moving forward?  Or is it currently unlicensed 
and you would like to adopt LGPL.

For other items I have thrown into the world of open-source I have used 
MIT or BSD license, mainly the MIT.

Could MyHDL use the PSF license?  The same which the core Python 
language uses?

Chris Felton

Re: [myhdl-list] Conference: Software demo

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

On 4/3/2011 11:16 PM, Christopher Lozinski wrote:
> Thanks for the support.
>
> I was a bit conflicted because part of me does not want to bother people
> on the mailing list.
>
> And on the other hand people want to support my demo.
>
> And I am sure I do not want to wat
>
> So I did not quite document it correctly. Here are the two files I am
> trying to see. can you see them?
>
> XQuartz 2.3.6 (xorg-server 1.4.2-apple56)
>
> mac 10.6.6 Build 10j567
>
> GTKWave 3.0.2 Ah maybe that is the problem, I will try the older version.
>
> Can someone check if these files work on your system?
>

With GTKWave you first open the VCD file.  Then you need to add the 
signals to the viewer.

Search -> Signal Search Hierarchy

 From here you can add the signals you want to view to the waveform 
viewer.  You can also save the configurations.  The next time you load a 
VCD (from the command line) use

$ gtkwave -A dff.sav dff.vcd &

Hope that helps
Chris Felton

Re: [myhdl-list] Commercial support / training classes

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

On 04/02/2011 09:01 PM, Christopher Lozinski wrote:
>
>> As for training, the biggest issue is probably that
>> there is no ready-to-use  material yet.
> I totally agree.  Chris Felton has a hardware project that generates a
> sound that we could
> use as the basis for the project.   I think a number of us could try to
> duplicate it, edit up the training
> materials in some shared environment, like Google Docs, and before you
> know it we would have a
> training class.
>
>> And before that,
>> the first issue is probably to determine what public we
>> would be targetting and what kind of prelimary knowledge
>> we should/can assume.
> I think we should target the mass market of python developers who want
> to tinker with FPGA's.
> People like me.  For us, meaning experienced python developers, it is
> obvious this is the way to go.  Trying to sell a hardware engineer on
> dynamic binding is going against the flow.

Ok, agreed.

>
> Chris Felton recommends that we do a distributed class.  We would like
> you Jan to do a general presentation on the software and theory, and
> then dive into hands on application. I think we should be done in a
> day.  I think the Silicon Valley standard is do it on a weekend.
> Better yet, you might want to do a video presentation one Saturday,
> people can read the web site during the week, and then come back the
> following Saturday for a class room class, where the "experts" look over
> your shoulder to help you.
>
> Next question can we use the content from the website for the flyers?
> Since the back side of the flyer will sell the class, this is commercial
> use, and needs your approval.

I notice that the content licensing on the website is confusing -
my idea was  to use the GNU free documentation license but the
create commons license is still there, apprarenlty I forgot to
remove it from the wiki template.

I have not yet studied the details of these licenses.

Note that the wiki content is contributed by several people.
We probably should discuss the license we should use, so that
everyone knows what he/she gives way. I think I would be in favour of
license that requires honouring copyright notices (refering to the
myhdl.org contributors) and that lets one use the content
for any type of use. For the texts that I have written, you
can use it along those lines.

> And would you be willing to introduce the class?  How many hours of
> presentation would you like to do?

If someone drives the development of a class in a shared
environment, I'm prepared to review and offer suggestions.
After the material is ready, we can see for what part
my involvement could be useful, and I certainly would
be willing to contribute.

My availability until April 24 is very limited though (milestone)
and it will be on best effort basis.

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
     Analog design automation: http://www.mephisto-da.com
     World-class digital design: http://www.easics.com

Re: [myhdl-list] My take on MyHDL weaknesses - and solutions

[Ben <ben...@gm...>]

On Mon, Apr 4, 2011 at 11:00, Jan Decaluwe <ja...@ja...> wrote:
> Lack of killer features
> -----------------------
> The benefits of MyHDL are real but they remain somewhat
> abstract, e.g. "managing complexity".
>
> Solution: a strong value proposition would be concrete
> features that many hardware designers want but that are not
> offered by their current tools. I have two things in mind
> currently: a good fixed-point class with transparent support
> by the convertor, and SystemVerilog-style interfaces in
> MyHDL that could be converted to VHDL and Verilog, that don't
> have something similar.
>

For the records, I have another one for this list: native (as in
"integrated in the language") support for asynchronous communication
channels. I'm quite certain, this would have its place in MyHDL,
however, my way of tackling this beast down is not established yet ...
I'd be glad to hear your views on this !

Regards
Benoit

[myhdl-list] My take on MyHDL weaknesses - and solutions

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

Hereby my take on current weaknesses, and possible
solutions. In preparation of marketing actions!

If useful we can of course move this type of info
to the website also.

Performance
-----------
Compared to compiled VHDL and Verilog simulators, MyHDL is
slow as a dog. MyHDL's implementation tries to limit the
overhead, but performance will always be limited by the
underlying Python interpreter.

Solution 1: Education. Raw performance doesn't necessarily
translate directly into designer's performance, especially
in the initial exploratory phases of a project. Otherwise
no one would be using Python, Perl, php or tcl.

Solution 2: The PyPy project (future). Python doesn't have
to be slow: by employing clever JIT techniques, performance
can be improved drastically e.g. 5-10x. I believe that MyHDL
is a good candidate for this type of optimization. The day
this happens would be one of the most important ones in
MyHDL's history: the performance limitations would for a
large part go away, and it would be the ultimate validation
of the concept: benefitting from advances without having to
do anything yourself :-)

Perception
----------
MyHDL is sometimes perceived as a "one man show". Moreover,
I'm long enough in this business to understand that no new
EDA technology has a chance of truly succeeding without a
strong backing from Silicon Valley. For the record: I have
no plans of moving, it's too much fun living in a
non-country :-)

Solution: exactly the kind of initiatives that are being
taken right now.

Audience mismatch
-----------------
MyHDL is strongly in the "digital hardware design is a
special kind of software development" camp. However, the
vast majority of hardware designers doesn't see things this
way. Schematic entry may be dead in practice, but not yet in
the minds.

Solution: Patience. It's a waste of time to argue with
people who only use irrational arguments, which is how I
would characterize the arguing skills of many hardware
designers - they just don't *really* understand HDL-based
design and synthesis. We have to keep our ideas alive until
the new generation takes over. Moreover, there is another
reason for hope: software designers who realize that FPGAs
can be seen as "just" another computing platform. (Warning:
we will then face the opposite problem of people wondering
why things have to be done at such a "low level". It's
lonely in the middle :-))

Lack of killer features
-----------------------
The benefits of MyHDL are real but they remain somewhat
abstract, e.g. "managing complexity".

Solution: a strong value proposition would be concrete
features that many hardware designers want but that are not
offered by their current tools. I have two things in mind
currently: a good fixed-point class with transparent support
by the convertor, and SystemVerilog-style interfaces in
MyHDL that could be converted to VHDL and Verilog, that don't
have something similar.

Lack of star IP
---------------
Open source star IP could make MyHDL very attractive. I am
referring to projects such as Leon SPARC in VHDL. Ideally,
someone would implement some hot new technology as an IP
core in MyHDL. The problem is that such a project may need
more effort than the MyHDL project itself.

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
     Analog design automation: http://www.mephisto-da.com
     World-class digital design: http://www.easics.com

Re: [myhdl-list] Conference Plans: Perspective, Flyer, Sign, Classroom classes, Python Classes, Success Stories, Hardware Demo

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

On 04/01/2011 06:07 PM, Christopher Lozinski wrote:
>         I have been reading the myhdl.org website.  It is superbly done.
> Very carefully written.  Looks great.  It is not even his native
> language, but I could not tell.  It makes me expect the software will be
> as carefully done.   It looks like a labor of love.
>
>        My perspective on this is that it is an obvious way to rapidly
> design and thoroughly test new hardware designs. But somehow the rest of
> the world does not see it this way.  It needs some marketing push.

I absolutely agree.

Now I feel a little guilty because apparently I did a good job
on selling you MyHDL's advantages - but of course there are weaknesses
also. As you may face some sceptical people shortly, I think
I should tell you about my take on those also. Obviously not to
discredit the project, I think those weaknesses can all be overcome,
but to complete the picture.

I will write a separate post on this shortly.

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
     Analog design automation: http://www.mephisto-da.com
     World-class digital design: http://www.easics.com

Re: [myhdl-list] GPL License

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

On 04/04/2011 05:36 AM, Christopher Lozinski wrote:
> So it turns out that this is the GNU lesser public license.   That is
> different from the GPL.
>
> I presume the intent is that the code that we create, and the part we
> design is not infected.

Yes, the intent is that changes to MyHDL itself are shared and
nothing else. The only difficulty to understand is that "Library"
refers to the myhdl package in a Python system, but I believe that
is a reasonable and can be clarified explicitly if necessary.

> But that is not at all clear to me.  If we generate the verilog code
> with this toolset, that may well be considered including the gnu code.

I wouldn't know why, not even under the GPL. The convertor
is a compiler. It's not because its output is readable that
it becomes "source code" that someone has written. Otherwise,
anybody using a gnu compiler would have to license their
compiled programs under the GPL.

The difficulty is with the MyHDL design code you write. With
the GPL, the myhdl package would probably infect that. With
the LGPL for the package, you can do with your code whatever
you want.

> Confusion is not good for customers.  I am confused.

I fear that licensing issues are always confusing. The starting
point is that I want changes/improvements to MyHDL itself to
be shared with me and anybody else for that matter, but
I also want to make sure that MyHDL imposes not a single
additional restriction. So I need a license that makes this
distiction with almost opposite requirements in a
clean way.

In short, I believe the LGPL is exactly what I need.

> A quick search of the email archives did not find anything addressing
> this issue.
>
> Regards
> Chris
>
> On 4/3/11 7:17 PM, Christopher Lozinski wrote:
>> I think I just read that MyHDL is under a GPL license.
>>
>> If I understand this correctly, that means if somone implements a design
>> in MyHDL it is "infected" by the GPL,
>> and they have to release that design to the public.
>>
>> I think that would be a problem for most potential users of this tool,
>> myself included.
>>
>> Can anything be done about this?
>>
>
>


-- 
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
     Analog design automation: http://www.mephisto-da.com
     World-class digital design: http://www.easics.com

Re: [myhdl-list] Conference: Software demo

[Christopher L. <loz...@fr...>]

Thanks for the support.

I was a bit conflicted because part of me does not want to bother people 
on the mailing list.

And on the other hand people want to support my demo.

And I am sure I do not want to wat

So I did not quite document it correctly. Here are the two files I am 
trying to see.  can you see them?

XQuartz 2.3.6 (xorg-server 1.4.2-apple56)

mac 10.6.6  Build 10j567

GTKWave 3.0.2  Ah maybe that is the problem, I will try the older version.

Can someone check if these files work on your system?

-- 
Regards
Christopher Lozinski

Check out my iPhone apps TextFaster and EmailFaster
http://textfaster.com

Re: [myhdl-list] Conference: Software demo

[Kevin S. <sta...@gm...>]

Hmm. Not sure what to tell you, sorry :-/. Maybe someone else can help?

Perhaps we start off with which version of OS X you've got and which version if gtkwave?

X11 comes with OS X by default, you haven't installed a different version?


On Apr 3, 2011, at 10:29 PM, Christopher Lozinski <loz...@fr...> wrote:

> So X11 was on my machine.
> 
> I downloaded and ran GTKWave.
> 
> The file looks like it has data.  The window says:
> VCD loaded successfully.
> [6] facilities found.
> [313] regions found.
> 
> So it looks like there is data.
> 
> But nothing shows on the screen.
> 
> I went through the help, clicked on all the buttons.  Still nothing.
> 
> That is why a class is so needed.
> 
> Thanks
> Chris
> 
> 
> On 4/3/11 7:37 PM, Kevin Stanton wrote:
>> Chris,
>> 
>> You should be able to install gtkwave for OS X:
>> 
>> http://eng-osx.sourceforge.net/GTKwave.html
>> 
>> The simulation can output a VCD (Value Change Dump) that you can open in gtkwave.
>> 
>> Take a closer look at the flipflop example:
>> 
>> http://www.myhdl.org/doku.php/cookbook:ff
>> 
>> And you can see that it explains how to get a VCD file output during simulation.
>> 
>> Hope that helps,
>> 
>> Kevin
>> 
>> OS X has X11 by default so you shouldn't have too much trouble getting it set up.
>> On Apr 3, 2011, at 9:03 PM, Christopher Lozinski wrote:
> 
> -- 
> Regards
> Christopher Lozinski
> 
> Check out my iPhone apps TextFaster and EmailFaster
> http://textfaster.com
> 
> 
> ------------------------------------------------------------------------------
> Create and publish websites with WebMatrix
> Use the most popular FREE web apps or write code yourself; 
> WebMatrix provides all the features you need to develop and 
> publish your website. http://p.sf.net/sfu/ms-webmatrix-sf
> _______________________________________________
> myhdl-list mailing list
> myh...@li...
> https://lists.sourceforge.net/lists/listinfo/myhdl-list

Re: [myhdl-list] GPL License

[Christopher L. <loz...@fr...>]

So it turns out that this is the GNU lesser public license.   That is 
different from the GPL.

I presume the intent is that the code that we create, and the part we 
design is not infected.

But that is not at all clear to me.  If we generate the verilog code 
with this toolset, that may well be considered including the gnu code.

Confusion is not good for customers.  I am confused.

A quick search of the email archives did not find anything addressing 
this issue.

Regards
Chris

On 4/3/11 7:17 PM, Christopher Lozinski wrote:
> I think I just read that MyHDL is under a GPL license.
>
> If I understand this correctly, that means if somone implements a design
> in MyHDL it is "infected" by the GPL,
> and they have to release that design to the public.
>
> I think that would be a problem for most potential users of this tool,
> myself included.
>
> Can anything be done about this?
>


-- 
Regards
Christopher Lozinski

Check out my iPhone apps TextFaster and EmailFaster
http://textfaster.com

Re: [myhdl-list] Conference: Software demo

[Christopher L. <loz...@fr...>]

So X11 was on my machine.

I downloaded and ran GTKWave.

The file looks like it has data.  The window says:
VCD loaded successfully.
[6] facilities found.
[313] regions found.

So it looks like there is data.

But nothing shows on the screen.

I went through the help, clicked on all the buttons.  Still nothing.

That is why a class is so needed.

Thanks
Chris


On 4/3/11 7:37 PM, Kevin Stanton wrote:
> Chris,
>
> You should be able to install gtkwave for OS X:
>
> http://eng-osx.sourceforge.net/GTKwave.html
>
> The simulation can output a VCD (Value Change Dump) that you can open in gtkwave.
>
> Take a closer look at the flipflop example:
>
> http://www.myhdl.org/doku.php/cookbook:ff
>
> And you can see that it explains how to get a VCD file output during simulation.
>
> Hope that helps,
>
> Kevin
>
> OS X has X11 by default so you shouldn't have too much trouble getting it set up.
> On Apr 3, 2011, at 9:03 PM, Christopher Lozinski wrote:

-- 
Regards
Christopher Lozinski

Check out my iPhone apps TextFaster and EmailFaster
http://textfaster.com

Re: [myhdl-list] Conference: Software demo

[Kevin S. <sta...@gm...>]

Chris,

You should be able to install gtkwave for OS X:

http://eng-osx.sourceforge.net/GTKwave.html

The simulation can output a VCD (Value Change Dump) that you can open in gtkwave.

Take a closer look at the flipflop example:

http://www.myhdl.org/doku.php/cookbook:ff

And you can see that it explains how to get a VCD file output during simulation.

Hope that helps,

Kevin

OS X has X11 by default so you shouldn't have too much trouble getting it set up.
On Apr 3, 2011, at 9:03 PM, Christopher Lozinski wrote:

> So I took a look at the examples.  There is an example of the flip 
> flop.  Perfect.  If we are targeting
> python developers, they will know what a flip flop is.
> 
> So I downloaded MyHDL, installed it. It said I needed a new python.  Did 
> that.  Had trouble finding the directory, then ran the easy examples 
> from the manual.
> 
> Then I tried the flip flop example.  It is missing an import statement, 
> but then when I got it loaded and tried to call simulate(2000)
> 
>>>> simulate(2000)
> <class 'myhdl._SuspendSimulation'>: Simulated 2000 timesteps
> 
> Great.  But no graphics display.   I still do not know if the graphics 
> will display on my iMac or not.  But I hope this is useful feedback.  
> What do I need to do to get it to display?  I think it would be great to 
> demo the software working!  I could not find a section in the manual on 
> graphics displays.
> 
> Anyhow I am very impressed with all the testing functions.
> 
> Also my hats off to Jan Coombs who said the best thing is to just dive 
> right in.  Be grounded in reality.
> So I did.
> 
> Oh, and I am pleased to say that my second iPhone app is done!
> 
> -- 
> Regards
> Christopher Lozinski
> 
> Check out my iPhone apps TextFaster and EmailFaster
> http://textfaster.com
> 
> 
> ------------------------------------------------------------------------------
> Create and publish websites with WebMatrix
> Use the most popular FREE web apps or write code yourself; 
> WebMatrix provides all the features you need to develop and 
> publish your website. http://p.sf.net/sfu/ms-webmatrix-sf
> _______________________________________________
> myhdl-list mailing list
> myh...@li...
> https://lists.sourceforge.net/lists/listinfo/myhdl-list

[myhdl-list] GPL License

[Christopher L. <loz...@fr...>]

I think I just read that MyHDL is under a GPL license.

If I understand this correctly, that means if somone implements a design 
in MyHDL it is "infected" by the GPL,
and they have to release that design to the public.

I think that would be a problem for most potential users of this tool, 
myself included.

Can anything be done about this?

-- 
Regards
Christopher Lozinski

Check out my iPhone apps TextFaster and EmailFaster
http://textfaster.com

Re: [myhdl-list] Conference: Software demo

[Christopher L. <loz...@fr...>]

So I took a look at the examples.  There is an example of the flip 
flop.  Perfect.  If we are targeting
python developers, they will know what a flip flop is.

So I downloaded MyHDL, installed it. It said I needed a new python.  Did 
that.  Had trouble finding the directory, then ran the easy examples 
from the manual.

Then I tried the flip flop example.  It is missing an import statement, 
but then when I got it loaded and tried to call simulate(2000)

 >>> simulate(2000)
<class 'myhdl._SuspendSimulation'>: Simulated 2000 timesteps

Great.  But no graphics display.   I still do not know if the graphics 
will display on my iMac or not.  But I hope this is useful feedback.  
What do I need to do to get it to display?  I think it would be great to 
demo the software working!  I could not find a section in the manual on 
graphics displays.

Anyhow I am very impressed with all the testing functions.

Also my hats off to Jan Coombs who said the best thing is to just dive 
right in.  Be grounded in reality.
So I did.

Oh, and I am pleased to say that my second iPhone app is done!

-- 
Regards
Christopher Lozinski

Check out my iPhone apps TextFaster and EmailFaster
http://textfaster.com

[myhdl-list] Conference: Software demo

[Christopher L. <loz...@fr...>]

I am amazed at how much we have gotten done in just a few days.

Now my mind is turning to the software demo.  I have a mac mini, I want 
to load the newest release of python, and myHDL.  But then I am not sure 
what to do with it.  What makes for a good demo?  The banner
poster had all those graphics.  Maybe I could show something happening.  
Not sure what.

Will MyHDL run on a Mac?   What should I demonstrate?  Remember I am 
targeting python developers.  I would love to show a chip laid out by 
MyHDL.  Of course that is not what it does.

I am open to your advice.

-- 
Regards
Christopher Lozinski

Check out my iPhone apps TextFaster and EmailFaster
http://textfaster.com