[Libre-soc-dev] nmigen tutorials etc.
luke.leighton at gmail.com
Thu Oct 7 16:51:49 BST 2021
(In reply to andrey from comment #27)
> 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
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
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".
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.
More information about the Libre-soc-dev