[libre-riscv-dev] nmigen frustrations make me want Rust
programmerjake at gmail.com
Sun Mar 17 04:51:19 GMT 2019
All the dynamic typing that nmigen requires for features such as submodules
and records is messing with autocompletion because I have to use Any
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. 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 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.
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.
More information about the libre-riscv-dev