[libre-riscv-dev] Why nMigen?

[Cole Poirier]

> On Mar 3, 2020, at 8:29 AM, Luke Kenneth Casson Leighton <lkcl at lkcl.net> wrote:
> 
> On Tue, Mar 3, 2020 at 3:50 PM Cole Poirier <colepoirier at gmail.com> wrote:
> 
>> 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
> 
> i know.  and i repeated the answer (with more detail) that i gave when
> he suggested it back in the original HDL thread around nov 2018.
> 
>> 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.
> 
> for the reasons outlined (which are reiterations of the ones from appx
> nov 2018) although it seems very nice, the complete lack of any
> pre-existing community, when we're doing something that is itself so
> innovative, is extremely risky.
> 
> i explained this in some detail in the latest EOMA68 crowdsupply update:
> https://www.crowdsupply.com/eoma68/micro-desktop/updates/coronavirus-and-a-plan-for-pcb-testing
> 
> one binary unknown, you have two outcomes: you therefore only need to
> make ONE test to know what to do (because if the test "fails" then
> clearly the answer is: "the other one")
> 
> two binary unknowns, you have four outcomes: you therefore need to
> make THREE tests to triage where the problem is (eliminate three out
> of four, the answer has to be "the remaining one".  you don't
> *actually* need to test for it, although it can be a good double-check
> to do so).
> 
> three binary unknowns, you have eight outcomes.  that's *seven*
> permutations just to find out which combination is the "problem" one.
> 
> four binary unknowns, sixteen outcomes, that's fifteen tests.
> 
> you see how that spirals out of control?
> 
Hmm yes, delightfully simple but powerful analysis. 

> by developing an entirely new HDL compiler in an entirely new
> programming language that is nowhere near the top 10 well-known
> programming languages that is under constant rapid development *and*
> developing an entirely new processor, we would absolutely be asking to
> fail, pure and simple.
> 
> *each* of those tasks is massively complex.
> 
> taking on three of them at once is just...  yeah.
> 
> 
Absolutely, makes sense.

> 
>> 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.
> 
> then... why are you not asking for help?  the moment you "fail", that
> should *immediately* be the cue to write a message saying "i did step
> X but step Y failed".

Yes sorry it is my tendency to bang my head against the wall until I can crack the problem, I haven’t had this kind of support and expertise available before, so I’m learning to cpu yer this bad habit.

> 
>> 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.
> 
> this doesn't have anything to do with c or c++ code: it's a mindset
> that you're blocked for some reason in asking for help when you are
> stuck.
> 
> did you notice on the coriolis2 bugreport, how often i asked for help?
> and if i found the answer myself, i said, "i found the answer, i'm
> moving on to the next stage".

I did, and reflecting on it now is helping me to plan better for my future efforts.

> 
>> 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.
> 
> ah that's a pain.
> 
>> I actually have been putting in time and effort, I just have not been able to make any headway.
> 
> then you can ask for help, by explaining precisely and exactly *where*
> you have not been able to make any headway.
> 
> saying "i have not been able to make any headway" is not a useful or
> productive thing to do.  even reading it is not useful.
> 
> if you had said, "i have not been able to make any headway BECAUSE i
> am at line 35 of the page and i am stuck at line 36', *that* is
> something that we can help you with (and subsequently improve the
> instructions).
> 
> but if you don't *tell* us, and expect yourself to continue to
> struggle, that's not helping either yourself or us, is it?
> 
> so take a moment to reflect on that, and write - without hesistation
> or fear - exactly what and where you are stuck, ok?
> 
> best,
> 
> l

Thanks for the encouragement Luke. When I find the time this week, I’ll sit down and make myself document the exact difficulties I’m encountering and ask for help on list, instead of continuing on in my futile attempts at doing it in the silly unaided manner I have been.

Much appreciation for your continuing openness and support,

Cole