[libre-riscv-dev] nmigen frustrations make me want Rust

[Luke Kenneth Casson Leighton]

On Sunday, March 17, 2019, Jacob Lifshay <programmerjake at gmail.com> wrote:

> All the dynamic typing that nmigen requires for features such as submodules
> and records is messing with autocompletion because I have to use Any
> everywhere.


I did say! All the classes are designed according to python dynamic
principles. It keeps the code much more compact and readable.


>
> This, among other problems, makes me think I should write a much better
> replacement based on Rust. Rust has really powerful procedural macros and
> stuff (see how simple it makes using serde https://serde.rs/ for example)
> and, since it's statically typed, there is much better autocompletion.
> Also, we can detect quite a few errors at compile time and Rust has really
> nice built-in unit test support. In Rust, the static typing generally
> doesn't get in the way because Rust uses really powerful type deduction
> (makes C++11 look wimpy by comparison) so types are usually only needed in
> declarations rather than throughout function bodies. Rust also has a larger
> crate ecosystem and Python level iterator combinators (see the definition
> of Iterator) so we won't have to compromise on those fronts.


It sounds tempting, doesn't it? So, here is a crucial question: if we run
into difficulties, which pre existing community with experience in the use
of the HDL compiler can we go to?

nmigen has a long established community of users, which in turn means that
there is a wealth of existing code and examples out there. I have been in
touch with the author of enjoy-digital and asked for his help with the ECP5
DDR3 for example.

Also attie, whitequark and sb0 on freenode have been amazingly helpful.

Also there are AXI4 classes, wishbone classes and a ton more besides.

It's just not about the compiler, Jacob, it's about the ecosystem.


> Rust is also
> much faster than Python, so running a whole SoC in Rust is feasible, while
> I highly doubt it would be when using nmigen's built-in simulator.


I thought about that a bit, and the first thing is, honestly it doesn't
matter. Speed can be obtained by running in an FPGA, which will give more
realistic confidence anyway.

Second, if it gets really really annoying we can investigate use of cython.

It is however an optimisation.  The priority is correctness, not speed.


> I completely understand that we don't have time to write our own HDL and
> that we already decided to use nmigen, but it's looking more and more
> tempting for me.


Initially it always does. Then it hits home and the committment has already
been made.


>
> If I wrote a Rust-based HDL, it would use Yosys's intermediate language as
> the target language (like nmigen) letting yosys do the heavy work of
> translating to Verilog or other HDLs. I would probably wait until Rust
> properly supports const generics since that would allow me to have rust do
> all the type checking for matching signal widths and stuff.
>
> nmigen is around 10kloc of code, and we wouldn't have to implement any
> complex code transformations (nmigen's IR is quite close to yosys's IR) and
> most of the code seems quite straightforward, so it seems feasible to write
> a working implementation in 3-6 weeks.


We would be entirely isolated and cut off from the ecosystem surrounding
nmigen. The time is not just about the compiler, it's also about the
libraries, examples, and so on.

I was the lead developer of pyjamas, and it took four years to get a
community established, from no usage when James Tauber abandoned it.


L.


-- 
---
crowd-funded eco-conscious hardware: https://www.crowdsupply.com/eoma68