Re: [myhdl-list] Migen logic design toolbox - now with simulator

[Bob C. <fl...@gm...>]

On 03/16/2012 02:03 PM, Jan Decaluwe wrote:
> My conclusion is that Migen found an easy target in
> you, as a newbie, to confuse you. It made you think it
> can be used for serious design work.

Sorry, Jan.  If I have to be "confused" to play with my FPGA, then so be it.  I'm very "serious" about being able to play with my FPGA!

Your statement has an obvious implicit context: To me, you are shouting, "MyHDL is for Serious Designers Only!  Newbies and Pragmatists should Go Away!"

If that's what you are saying, then please be direct: Don't attack Migen for being what it was intentionally created to be, or for being something MyHDL is not intended to be.  Are you upset about Migen existing, or that there is an audience MyHDL can't help as well as Migen may be able to?  If you'd rather beginners like myself go elsewhere, just say so.

Remember, Migen wasn't created to be useful to beginners: It was created by an experienced FPGA designer concerned about practicality and productivity for a specific Open Source hardware project.  It simply happened that some things became a bit clearer to me after looking at Migen and the problems it was created to address.  Whatever Migen leaves out may have been what was getting in my way!

I'm actually quite lazy: What is the *least* I need to know to make useful digital designs *now*?

I'm a beginner:  Though I'd love to someday be able to design circuits like Shakespeare wrote sonnets, I'd be more than happy today if I were able to work at the level of "Green Eggs and Ham", a true masterpiece written with an absolute minimum of linguistic complexity.

> When Migen claims that the "event-driven" paradigm is
> too general, what it really dumps is procedural support
> in your HDL descriptions - the interesting stuff.

What's "interesting" to you can be a frustrating block for a newbie.  I hope to one day also be very interested in those aspects of MyHDL, but it seems to have little to do with what I want to get done today, which is to find the simplest path to get basic circuits out of my mind and in to my FPGA.  Then use them as building-blocks in my hobby projects.

> Unfortunately, I cannot direct you to a good introductory
> text explaining all this in a decent way, even though those
> techniques are more than 20 years old. I will eventually
> get to this in my blog, in which I already discussed some
> background.
>
> http://www.sigasi.com/janhdl

I *love* the way you write!  I've read every word of yours I could find, and I will very gladly read every new thing you share.  If you provide a new example, I will faithfully follow it.  If you direct me to a helpful reference, I will study it.

Most importantly, if you ever write an introductory digital design text that uses MyHDL both as an instructional language and as an implementation language, then I promise to be first in line to buy a copy. I will volunteer in any way I can to help create that book, from proofreading (for grammar and flow, not technical content) to working the examples and attempting the exercises.

I am *totally* behind MyHDL!  You may recall that I was first to post here about using the updated PyPy to pass 100% of the MyHDL test suite.  It was a simple thing, but I do try to help where I can.  I also greatly respect every bit of the work you're doing: When I wanted to talk to other EEs about MyHDL, I first asked you about the correct pronunciation of your name.  I believe you have made an important contribution by creating MyHDL, and I want others to know about it.

I am a MyHDL fan.  Unfortunately, I simply remain unable to use MyHDL to accomplish my own immediate hobby needs.  That does not indicate any flaw in MyHDL, merely the extent my own limitations.  Do not be surprised that I am interested in any tool that helps me circumvent those limitations!

I actually *like* how Migen slices and dices the process of FPGA design: The parts that are left out are ones I doubt newbies like me would notice, much less care about, until confronted with unusually challenging designs.  I suspect Sebastien would agree with much of your analysis, the proper response being: "So What?"

It's not about theoretical power or completeness: It's about barriers to entry.  It's not about what I can do in 5 years, but about what I can do in 5 weeks.  Migen is primarily about pragmatism and productivity, making powerful circuits quickly and easily, and far less about expert capabilities, theoretical purity or even consistency.

I seek tools that will help me do what I want to get done today, and so far Migen seems like it will be most useful.  Tomorrow will likely require additional tools, and I *absolutely* expect (and want) MyHDL to the first of those tools.  It is not an either-or proposition: I want Migen *and* MyHDL.  I realize MyHDL will take more time to master, and I'm willing to commit that time.  But I also want to create something sooner, rather than later.  And I believe that 100% of what I learn using Migen will later prove useful with MyHDL.  I believe using Migen will keep me motivated toward learning MyHDL.

Right next to me I have a Spartan 3E-500 that contains nothing of my own design.  That must change!


-BobC

> On 03/14/2012 05:07 AM, Bob Cunningham wrote:
>> On 03/13/2012 02:19 AM, Jan Decaluwe wrote:
>>> On 03/13/2012 02:07 AM, Bob Cunningham wrote:
>>>
>>>>  From my perspective as an HDL newbie (but a 30+ year engineering
>>>> veteran otherwise), major feature development in MyHDL appears
>>>> to have stalled, and Migen provides important capabilities MyHDL
>>>> either lacks or can implement only with cumbersome and fragile
>>>> kluges or work-arounds.  (At least, that's what they look like to
>>>> me, with my newbie eyes and brain.)
>>> Could you please provide a list of those important capabilities
>>> that MyHDL lacks in your opinion?
>> I must admit I set MyHDL aside a few months ago after having daunting
>> problems getting my 'simple' systems to work (mainly trying to glue
>> together components from Open Cores).  I had trouble writing useful
>> MyHDL, and I found that one of my 'glue' problems, a Wishbone
>> interface, had a simpler solution (from my perspective) in Migen.  It
>> could have been a unique or special case, I don't know enough yet to
>> tell: I haven't solved all my other problems with this project.
>>
>> Another project idea, a dataflow signal processor for a 'flying
>> pixel' camera, had me spending all my initial design time working on
>> the interface between the dataflow stages (simple in software, harder
>> in hardware) rather than on the content of each stage.  Though I
>> haven't implemented anything yet, it seems to me that Migen may make
>> such interfaces easier.
>>
>> However, the sum of my difficulties showed me that I lacked the
>> perspective and depth needed to make proper use of MyHDL, so I'm
>> taking some time to extend my hardware skills, to design some
>> circuits and boards.  Back to schematic capture, device specs, board
>> layout, and using an o'scope and logic analyzer.
>>
>> I understand using gates (bits), and I understand using chips
>> (interfaces).  It's the stuff in between that I'm having problems
>> with.  From my limited perspective, it seems to me that Migen does
>> particularly well with interfaces, and the distinct separation
>> between sequential and combinatorial logic seems to fit my current
>> thought processes.
>>
>> I have no idea how far I can go with Migen compared to MyHDL.  But
>> the initial learning curve, with the goal of making my Spartan 3E
>> board do fun and useful things, for the moment seems to favor Migen
>> over MyHDL.
>>
>> But I am well aware that situation may not persist as my knowledge
>> and experience grow.  I have no intention of abandoning MyHDL: I
>> closely monitor this list, and I periodically review the MyHDL
>> documentation (especially the examples) to see if my comprehension
>> has grown.
>>
>> Perhaps Migen makes FPGA development feel more like building with
>> Legos:  It makes it easy(er) to create parts and click them together.
>> I suspect MyHDL may more like a machine shop: More skill is required
>> to make use of it, but there may be no limit to what can be built,
>> such as a Lego factory.
>>
>> Migen feels more newbie-friendly, while MyHDL may be more attractive
>> to battle-weary V*HDL veterans.  Migen is FPGA-centric, while MyHDL
>> is fully ASIC-capable.  Migen sometimes implements features
>> inelegantly, while MyHDL excludes inelegant features.  Practicality
>> vs purity.  High-level abstractions vs low-level power.
>>
>> Bottom line, I suspect both tools have their place, and share enough
>> common premises that it is a mistake to view one as competing with or
>> detracting from the other: Both agree the V*HDLs have limitations,
>> both agree Python is a great tool for implementing HDLs.  Each
>> chooses a different approach, provides differing capabilities,
>> targets a slightly different domain, and may attract different groups
>> of users, all of which appears to me to be more complimentary than
>> competitive.
>>
>> I don't see how there can be any need to push Migen and MyHDL apart:
>> I think they should stand back-to-back and show the V*HDLs better
>> ways to fill FPGAs.  More like siblings who occasionally argue, than
>> any kind of enemy.
>>
>>
>> -BobC
>>