[libre-riscv-dev] Why nMigen?

[Cole Poirier]

> On Mar 3, 2020, at 4:48 AM, Luke Kenneth Casson Leighton <lkcl at lkcl.net> wrote:
> 
> 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

I actually do understand that rust is not a hammer and not everything is a nail, especially something like hardware design and layout. I was responding to *Jacob’s* idea of a nmigen-like language in rust because I don’t have *any* relevant knowledge experience whereas he’s writing on of the core components of the gpu in rust. I would never conceive of rewriting nmigen, but given that Jacob had expressed an interest I suggested it might be something he could do as a very large bug report. Though I do understand better from your above explanations why this might not be a very good idea. Please don’t mistake my enthusiasm for arrogance. I plan on studying the gates and logic once I have the time. Over the past month I’ve been struggling to setup the Coriolis schroot. It’s been incredibly frustrating as this kind of blind searching for the right way to configure things, such that they finally work, was my least favourite thing about trying to work with c and cpp code. But I keep trying because I really want to be able to contribute to the project. This weekend I was also planning to set up my machine with openvpn but unfortunately I have discovered that I had a bad motherboard.

I actually have been putting in time and effort, I just have not been able to make any headway.

Cole