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

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

I still want to take the time to clarify my position
on the many issues raised in this post.

On 03/17/2012 09:20 PM, Bob Cunningham wrote:
> 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?

I am disturbed by the suggestion that my critique on Migen is
based on anything else than a purely technical assessment.

Let me be clear. I don't like Mr. Bourdeauducq's attitude for
one bit. But do you think that would be a reason for me to
ignore any good idea that he might come up with? Of course
not. I am not a masochist.

It is quite simple. During my career, I have found that when
you think you have seen the worst in HDL-based design, it
always gets worse. To date, Migen is the worst that I have
seen. But to understand why I am saying this, you have to
be prepared to follow my technical arguments and to
engage in technical discussions. I have made a few starts,
but I certainly was not done yet. However, I see close to
zero enthousiasm to continue such discussions.

I am therefore frustrated by the fact that I hear all kinds
of opinions and suggestions to "merge" but that whenever things
get a little technical then the "I am a beginner" umbrella opens.

Migen is not my problem. It will disappear in the milky mist
of HDL history, just like the many HDLs based on the same
flawed paradigm. I am addressing it simply because misleading
posts about it appear on this newsgroup.

What I am really targetting instead is the conventional wisdom in
mainstream HDL design, which often has it all wrong.

>  If you'd rather beginners like myself go
> elsewhere, just say so.

MyHDL welcomes beginners. It is the first item on "Why MyHDL":

http://myhdl.org/doku.php/why#you_are_new_to_digital_hardware_design

In fact, I put most of my hopes on beginners, as they have not
yet been brainwashed by the conventional wisdom.

> 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

I am not impressed by "arguments from experience". The conventional
wisdom that I am targetting was created by experienced designers,
mostly Verilog ones. Experience can lead to conservatism and
can become a hindrance to clear thinking.

> simply happened that some things became a bit clearer to me after
> looking at Migen and the problems it was created to address.

Was it because of Migen or simply because you were spending more
time on the problem?

> Whatever Migen leaves out may have been what was getting in my way!

I find that strange. I understand that you have a lot of
experience with embedded software. Therefore, you must know
procedural software techniques very well. That is exactly what
Migen leaves out. What it leaves is low-level concurrency at the
statement level, which must be new to you. And now you suggest
that the obstacle is exactly that what you are most familiar
with. Beats me.

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

No secrets here. The first sentence of "Why MyHDL" warns you:
"There's a lot to learn and it will be hard work". Therefore, if
you are intellectually lazy (not prepared to learn new things even
when they will save you lots of time and effort later on), MyHDL
or HDL-based design is not for you.

MyHDL is for those who are lazy in the good engineering sense,
wanting to accomplish more with less effort eventually.

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

Come on, let's keep some perspective here. It's not *that* difficult
or complex either. And there is a cookbook that shows you the way.

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

I don't understand. Your specification seems very extensive and
ambitious. It would seem that you have a big need for raising the
abstaction level as high as possible, and for an easy path to
strong verification.

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

There is a broad concensus about the "building blocks" paradigm
in hardware design. That is really not the issue. The issue is
what the abstraction level of the building blocks should be.

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

Suppose that  I teach a class to newbies in embedded software design
based on assembler. Would any of the newbies, except for the
rare genius, miss the capabilities of say, C?  Does this prove that
teaching assembler was a good choice?

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

Again, I find this strange. I understand that you have not been
successful with MyHDL. However, as I understand it you have not
been successful with Migen either. So what is your defense based
upon? Of course, we are about 5 weeks further now :-)

More to the point.

Barriers to entry - ok, but what is the task? I told you that I
believe the main problem in HDL-based design is verification, and
how MyHDL (unlike Migen) helps you by the fact that you
can use the same modelling paradigm for high-level models and
test benches as for synthesizable logic.

You seemed surprized, which I found suprizing in turn. Is
it so different in software? Really, getting those gates into
an FPGA is the easy part. The difficult part is getting
them to work properly.

You will have noticed that Mr. Bourdeauducq made an error in
the first simple "one-liner" circuit that I presented to him,
as if he wanted to prove my point. Of course, the reason is
not incompetence, but simply that he did not verify his
design.

There is a pattern however. Mr. Bourdeauducq cried foul because
I didn't accept his "simple patches". What he ignored, and
continued to ignore despite my insistence is that they broke
MyHDL. Perhaps Mr. Bourdeaducq considers verification a "detail".

Well, I don't. Verification is the problem. The reason why I
think the abstraction level of synthesizable logic should
be as high as possible, is because that leaves more time
for verification.

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

Sounds good, but I think it is cheap talk.

Most of Migen's technical choices, starting with its basic paradigm,
are almost the opposite of MyHDL's. As a result, verification is not
addressed, and it forces you to think at an artificially low level
for synthesizable logic. What good can one learn from that?

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

Perhaps you are too ambitious.

In your shoes, I would start as follows:

* isolate a simple function out of your spec
* try to concentrate on what it does, instead of how it should be implemented
* write that behavior in a (clocked) MyHDL process or processes
* also describe it in high-level python, and use that in a unit-test to verify
* experiment with synthesis to see whether it works and the result is acceptable
* iterate with the synthesizable description as necessary


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