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

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

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.

But it cannot - unless all you need is a sophisticated
generator of concurrent statements and a single clock.
That is all Migen really is (and then it added some
horrible design choices despite having a good example).

For serious design work, procedural support alongside
concurrent semantics is essential. Not just for test benches
and high level modeling (of course) but also for synthesizable
code.

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 you (and many Verilog/VHDL designers, and Migen's
designers) miss is the role of RTL/logic synthesis.
It is much more than technology mapping. It can handle
procedural descriptions quite well, including features
such as register inferencing from procedural variables.
It enables you to move the abstraction level a little
higher by thinking about (admittedly low-level) *code*
instead of gates.

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


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
>
>
> ------------------------------------------------------------------------------
>
>
Virtualization&  Cloud Management Using Capacity Planning
> Cloud computing makes use of virtualization - but cloud computing
> also focuses on allowing computing to be delivered as a service.
> http://www.accelacomm.com/jaw/sfnl/114/51521223/


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