Re: [myhdl-list] Why MyHDL (New MyHDL Wiki)

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

On 04/20/2012 12:33 AM, Christopher Lozinski wrote:
> Here is a web page describing why one should use MyHDL.
>
> http://ejr0.x.rootbsd.net:8080
>
> In the long run, it will be moved to
>
> wiki.myhdlclass.com
>
> It is in moinmoin, implemented in Python.
>
> I once made a mistake, and so am not allowed to edit the MyHDL wiki.
> Jan politely suggested I put up a new page.  Great idea.
>
> Anyhow you are all welcome to make edits to the page or add new pages.
> Let me know if you have any troubles.
>
> Why am I doing this?  I had thought of offering a MyHDL class.  But the
> first thing is to
> get the high level arguments right.    A class is transient, the
> documentation lives longer.
>
> Your comments are most appreciated.

There are a number of errors and inaccuracies.

Verilog is also based on the event-driven paradigm, as is VHDL.
This is what MyHDL, Verilog and VHDL have in common, unlike most
HDLs that have been proposed (and forgotten) historically. It
is the winning solution.

To put things in perspective: my critique on Verilog/VHDL is
incremental, not fundamental. With all three HDLs, it
is possible to do serious HDL-based design. Some language
features in Verilog/VHDL just make it harder (or much harder)
than necessary. But not impossible, like with the HDLs
based on an inferior paradigm.

The blocking/nonblocking issues in Verilog are an example:
they make it harder for some designers to use procedural
techniques as there is no strict separation between
variables and signals.  

The fact that VHDL designers need a lot of casting is not
because it is statically typed, but simply because it uses
an inadequate type system (too low level.) Do integers like
MyHDL does and a lot of the issues go away.

Migen is definitely *not* based on MyHDL, it's not because
someone says that they will fork that they do :-) In fact, it
tries very hard to be the opposite. It dumps the event-driven
paradigm. It has no support for procedural modelling. It
makes no difference between variable/signal semantics, even
less so than Verilog. And instead of following MyHDL's unique
example of how integers should be done in an HDL, it
re-introduces Verilog's broken way of handling unsigned
and signeds.

Migen ignores most of the lessons that MyHDL has to offer.
Their good right of course - but it shows that I was
right in not spending too much time/effort on the requests
of its developer: he did not like (or understand) MyHDL
fundamentally, as I suspected right from the start.

One more issue. What you keep silent about, surprizingly,
is the licensing scheme on your web pages. Before requesting
edits, I think you owe it to all potential editors to
tell them what will happen with their work. Please, let
us avoid the confusion and frustration that happened
the last time around.

I am not asking for a discussion about pro's and con's
of various licensing schemes - it is an endless discussion
with no single good answer. Just tell us what you use
so that every potential editor can decide.

Finally, even it you had editing rights on myhdl.org, I'm
not sure you would agree with its Terms of Use, which
are crystal-clear by now:

http://www.myhdl.org/doku.php/terms_of_use

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