[Libre-soc-dev] nmigen tutorials etc.

[Andrey Miroshnikov]

On 07/10/2021 16:51, lkcl wrote:
> (In reply to andrey from comment #27)
>   https://bugs.libre-soc.org/show_bug.cgi?id=714
> 
>> In the meantime I'll continue looking at Robert's nmigen tutorials.
> 
> i strongly, strongly recommend that you augment anything you do by outputting every single time to an ilang or verilog file, and use yosys commands
> 
> read_ilang / read_verilog
> show top
> 
> then also (because you know verilog) open up the verilog output in a 2nd window.
> 3
> this will give you a gate-level overview by which you can look at *all 3* - nmigen, graphviz and verilog, side-by-side, and see, "oh look, i added X, and X appeared in the gate level diagram, and oh look, X is in the verilog too. amazing".
> 
> do that *every* time including even just adding one line of nmigen code.
Thanks, great idea! It'll be a good excuse to run the hdl-dev-repos 
script as well.

Waited on writing this reply until I tested ilang/verilog generation. 
Today I was able to figure out the process (because some tutorials are 
out of date, some don't include everything I needed).

What came out of my exploration is a new tutorial section:
https://libre-soc.org/docs/learning_nmigen/

Have a look, see if it makes sense.

Also some of the nmigen tutorial links have been taken down, so I 
replaced them with equivalent (although they haven't helped me with what 
you suggested).


> keep doing it for a minimum of 4 months, because it will help you avoid some very costly errors, which will emerge over time.  i won't spoil the surprise :)
Oh good, I better make sure to triple check my work then ;)

>> So far
>> the ParallelSignal conversations you had go over my head,
> 
> yeah, i can only even think about them because i've been doing 22 years now with python, and 2 years with nmigen.
> 
> the idea is however that you will basically not need to know *at all* except in an ancillary indirect way that PartitionedSignal is even being used.
Fair enough.

> one of the requirements is that the SoC compiler actually have a compile-time switch "create scalar ALUs" or "create SIMD ALUs" and the nmigen code for both be EXACTLY the same.
> 
> to do otherwise is flat-out insane, we might as well stop the entire project, right now, if going the route of maintaining 2 different disparate ALU codebases, one scalar, one SIMD.
That's beautiful. Computers were made to automate menial/manual tasks, 
so this only makes sense.

Also, when you mention SIMD, are talking specifically about vector 
instructions? Or is it in relation to executing instructions in parallel 
(with multiple CD6600-like FUs)?


>> Modules (at least initially) seem a bit more involved.
> 
> they're basically conceptually identical to verilog "module". in fact, if you get nmigen to compile to verilog, you actually *end up* with a verilog module named after the class *containing* the nmigen Module.

> dsl.Module is a convenience.  it provides high-level language constructs like "if" and "switch".
> 
> whilst verilog provides these "as part of its syntax", python doesn't have "switch" and it would be a totally different HDL to try and even *use* actual python syntax to create actual HDL.
> 
> such a project does in fact exist: it is called MyHDL. we evaluated it and found it places severe limitations on what can be done because it is, underneath, actual verilog.  as in: you write in python but it is *directly* expressing solely and exclusively verilog concepts.
What's even the point of Verilog with a Python coat? Doesn't make sense 
why MyHDL devs would choose such a path. Maybe it's how certain 
programming languages are made with slightly different 
keywords/terminals/syntax, but express the same thing in the end.

With my limited knowledge, it seems nmigen has more powerful 
abstractions, as well as better integration with formal verification, 
thus making your job easier (and more maintainable).

> nmigen you have an "object" (a Module) to which you add "stuff" using python function calls and that "stuff" accumulates an in-memory Abstract Syntax Tree (look up the concept, under "compilers")
Oh yeah ASTs are pretty cool, the Pascal interpreter Python tutorial 
uses ASTs.

> that in-memory AST then gets handed to a function whose job it is, just like any compiler, to syntax-check it and do other assurances, followed by walking the entire tree and spitting out a yosys-compatible ilang (aka RTLIL) file.
You know, after I studied basic compiler design, and you mentioned ASTs 
now, it makes perfect sense to have an AST of your RTL. For 
visualisation, redundancy checking, errors, etc.

Shame such a concept isn't discussed much on the hardware side of 
things. We have Karnaugh maps, KCL/KVL, which you can use to construct 
diagrams and expressions to optimise.

> if you want verilog instead then nmigen simply reads that ilang file back in witb yosys ("read_ilang") and runs the command "write_verilog".
Very convenient.

>> Sometimes all the object instantiations just seem a little too verbose.
>> However worth learning anyhow.
> 
> yes.  it is software engineering, applied to hardware.
> 
> as a software engineer i am absolutely astounded and shocked that hardware engineers have no idea about git, continuous integration, or any of the standard techniques we take for granted.  the entire industry is about 15-20 years behind.  no wonder they charge so much money.
I'm just as astounded as you are. So much is still manual in the ASIC 
design process that progress is slow, thus limiting the time spent on 
fixing bugs (which soon become generational bugs) to focus on cramming 
more features. Funny thing that most of the time there's always a 
shortage of programmers, plenty of hardware engineers though.