[libre-riscv-dev] Why nMigen?

[Luke Kenneth Casson Leighton]

On Tuesday, March 3, 2020, Cole Poirier <colepoirier at gmail.com> wrote:

>
> helpfulness/readability is inspired by). I think that rust would likely
> solve the bugs that arise from nmigen’s destructive interaction with python
> design/language features,


try not to confuse whitequark's skill in HDL with lack of experience with
python.  not python as a *language*: whitequark is exceptionally competent,
there: it's the lack of respect for python conventions (do not use import
*, do not use "if type(x) == ClassName) that will (and are) causing ongoing
maintenance and useability headaches.

fortunately i am familiar with python (21 years now) to help people avoid
the worst pitfalls.

 be of great benefit. Its entirely possible I completely misunderstand
> nmigen and the problem space but from my current understanding this is my
> perspective.


regardless of the language used, if you do not "grok" hardware as a
concept, no language of any kind is going to help you, no matter what that
language is.

to clarify: if a rust HDL existed, it would need to have data structures
EXACTLY like nmigen.

it would need HDL concepts.. exactly like nmigen.

it would need an Abstract Syntax Tree... exactly like nmigen does.

it would need an "output" phase, converting that AST into something another
tool understands (yosys)... EXACTLY LIKE NMIGEN DOES.


there would literally be no difference, Cole, except that the programming
language in which the abstract hardware concepts (and the conversion
process) were expressed would have changed.

you *need to get that into your head* before thinking "I have a rust
hammer, now i am looking for HDL nails".

you are familiar with the phrase "to someone with a hammer, everything
looks like a nail" :)

so if you *really* want to do a rust HDL, learn HDL first.  and that first
means understanding gates and how hardware is parallel, just like i wrote
in the tutorial.



>  I think this would be a good candidate for a later task in a future
> iteration of Libre-SOC.


only if we are happy to stake the entire future direction of the project on
becoming entirely isolated from absolutely all other libraries and
resources (and other programmers) by being literally the only people in the
world to be not just using an unproven HDL but *developing* that quicksand
at the same time.

you can see from the coriolis2 discussion, that quite critical bugs have
been detected by trying to use it in ways that nobody else has considered.

do we *really* want the entire project to grind to a crashing halt in the
middle of a deadline because a bug is found in a rust-based HDL and
everyone has to stop whilst one or two people on the team switch context,
and are forced to investigate tool bugs?

contrast this with the coriolis2 bugs (or nmigen bugs) where we can report
them, and *other people* with 100% domain expertise and 100% dedicated time
and focus can easily find and fix the issue within hours or days.

programming is not about "programming".  it's about communication,
understanding, resources and, ultimately, people.

*not* code!

l.



-- 
---
crowd-funded eco-conscious hardware: https://www.crowdsupply.com/eoma68