[libre-riscv-dev] Why nMigen?

[Luke Kenneth Casson Leighton]

On Mon, Mar 2, 2020 at 8:27 PM Immanuel, Yehowshua U
<yimmanuel3 at gatech.edu> wrote:

> > kinda. https://libre-riscv.org/3d_gpu/tutorial/
> > jacob and i went through this very early on the list.
>
> Ok. I see this.

ultimately, it was, "if you came at this with zero knowledge of
hardware, what would be the probability that you had some working
knowledge of a stable, well-known well-structured programming language
called 'python' at the very least?"

and the answer to that apparently turns out to be "about 30%".

by going with a well-known programming language, we cut "introductory"
time drastically.  just like in the tutorial page, it says, "go learn
python by finding python tutorials online" and that's really all we
need to do.  i learned python i think in about... 2-3 days?

quick search:

top "trending":

1. javascript
2. python
...
....
9. scala

from there, teaching someone "how to use a library" (which happens to
be called "nmigen") - well, the only thing i have to smack them over
the head with a 2-by-four about is that whitequark completely ignores
and disregards very well-known, fundamental and critical python
programming advice by using "import *".  given that nmigen could well
be some peoples' first ever introduction to python, this is quite
irresponsible.  you *do not* use "import *" except under very special
mitigating circumstances.

i did actually do some bsv (bluespec) programming, 2 years ago,
helping the RISE Group out at IIT Madras.  it was... extremely
difficult.  we had to constantly do "workarounds", refer to the PDF
manuals for a whopping 30-40% of our time, and it was continuously
fraught with compile-time errors that i had no idea how to fix and had
to routinely ask - several times a day - on how to deal with.  this
took up a considerable amount of time on the part of the senior
developer, who was really busy with other tasks.

then we also evaluated the communities *behind* the different
languages.  the fact that litex exists was a big deciding factor.
many other python-based HDLs were too small a community (one key
researcher - pyrtl for example).  myhdl has a strong community except
unfortunately it restricts to a *subset* of python due to it being
actually *in* python.  they do an AST tree-walk *of the actual python
code*.  in effect, myhdl is a python *bytecode* language translator.
as such, abstract classes, exceptions, they're all out... because
those are not concepts that can be "translated" to actual hardware.

several others were eliminated as well, including doing our own HDL,
because we would literally be the only people in the world using it.

l.