[Libre-soc-dev] nmigen tutorials etc.

[lkcl]

(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.

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.

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 :)

> 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.

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.

> partly due to
> architecture specifics, partly due to nmigen/OOP syntax.
> Covered Const/Signals, fairly straightforward (coming from verilog
> background).

yehyeh.  everything's there.

> 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.

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")

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.

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

done.

congratulations, your lovely python nmigen program got turned into reasonably-readable verilog.

> 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.

l.