[HN Gopher] nMigen - A refreshed Python toolbox for building com...
___________________________________________________________________
nMigen - A refreshed Python toolbox for building complex digital
hardware
Author : olvy0
Score : 87 points
Date : 2021-10-22 10:00 UTC (1 days ago)
(HTM) web link (github.com)
(TXT) w3m dump (github.com)
| newhouseb wrote:
| In addition to the (likely) obvious benefit of Python versus a
| traditional HDL that hacks in really janky scripting features for
| testbenches (read Verilog), one of the main draws for nMigen is
| that you can combine things like Jupyter notebooks and Numpy into
| a REPL like development approach for developing and testing
| digital logic [1].
|
| I can't speak to the quality of my nmigen code, but earlier in
| the year I managed to pull together a (basic) bluetooth radio
| using exclusively nmigen which should demonstrate that you can
| build "real" things with it:
| https://github.com/newhouseb/onebitbt
|
| [1]
| https://github.com/newhouseb/onebitbt/blob/master/research/D...
| victor82 wrote:
| Thank you for sharing you all digital radio project!
|
| It is a nice example of nMigen usage, sadly there are not many
| ultra-cheap FPGA boards with 5GHz SerDes to try it.
| jmgrosen wrote:
| Very cool!
|
| Just a random thing I noticed reading through [1]: you might
| have a bug in how you calculate the magnitudes of the signals?
| When you assign the output of the low-pass filters on the high
| frequency to the input of the magnitude approximator, you
| assign the imaginary LPF to the imaginary input but the real
| LPF to also the imaginary input, which I think is incorrect?
| Since I'm on mobile, it's easiest for me to show sign a
| screenshot: https://i.imgur.com/tAQe5Sr.jpg (If that is indeed
| a bug, I'm curious how that might impact the results!)
| newhouseb wrote:
| Good eye! That's indeed a typo in the notebook. Somehow in
| the actual design I have the correct pairing https://github.c
| om/newhouseb/onebitbt/blob/master/onebitbt/r....
|
| Since writing this particular notebook I've actually built
| out a proper CORDIC module, so once I get back to the
| environment where I was writing all this (I am nomadic right
| now w/ anemic compute) I can fix this and rerun things (and
| add in my CORDIC implementation).
| thrtythreeforty wrote:
| Your tooling for interactive hardware development should be
| standard issue.
|
| However, I would actually make the other claim - nMigen et al
| don't improve the readability of a hardware block versus
| Verilog. Verilog does indeed suck for any parametric design
| though, so the Python metaprogrammability is an obvious win. A
| dedicated, strongly typed language where the hardware is a
| first class language feature (or at least appears to be via
| syntactic sugar/new grammar) would give the best of both worlds
| in my opinion.
|
| The difficult part is (still) polyglot programs - say, if I
| have a module written in Silice, which includes a vendor's
| Verilog block ram model, which is all instantiated by an nMigen
| harness. LiteX makes this _possible_ (although difficult) to
| simulate with Verilator, but the quick interactivity of the
| Jupyter workbench is lost.
| newhouseb wrote:
| Totally agree, I've been doing a ton of DSLs using
| Typescript's (super) expressive type system and am holding
| myself back from writing a full on HDL that compiles down to
| FIRRTL.
| wyager wrote:
| > A dedicated, strongly typed language where the hardware is
| a first class language feature
|
| Have you seen clash? It sounds like what you want. It really
| kicks ass - by far the most productivity-boosting and error-
| reducing HDL strategy I've seen. It's also a subset of
| Haskell, so you can run your hardware code from a compiled
| binary or REPL before compiling it to VHDL/Verilog.
|
| I like nmigen, but I have the same preference that hardware
| should be a first-class component of the language, and strong
| types are desirable.
| thrtythreeforty wrote:
| Thanks for the recommendation! I've run across it in the
| past, but I still find Haskell syntax to be absolutely
| baffling so I was put off by the learning curve. (There's
| something to be said for sticking to syntax familiar to
| users of the incumbent - Rust vs C++ springs to mind.)
|
| Perhaps I'll give Clash a shot - the homepage describes
| basically all the features I'm looking for. The
| documentation appears to be excellent.
| wyager wrote:
| There's definitely a learning curve, but since you're
| using a relatively restricted subset of Haskell, you can
| basically skip learning about things like IO and also
| most of the Haskell ecosystem, so it's very manageable.
|
| The learning curve is sort of inherent to the fact that
| the _reason_ Clash works so well is that semantics of a
| pure lazy functional language with algebraic data types
| (very different from what most people learn) _almost
| exactly_ matches the standard 01XZ semantics of digital
| circuitry. There's one very small difference that I'm
| aware of. The nearly-ideal correspondence is honestly
| kind of surprising.
| melony wrote:
| What is the small difference?
| wyager wrote:
| Zero-bit busses cannot have an indeterminate value in
| hardware. However, zero-bit values (Unit) can have
| indeterminate value in software.
|
| If you have the circuit
|
| f :: () -> Int
|
| f () = 3
|
| Vs
|
| g :: () -> Int
|
| g _ = 3
|
| Are the exact same thing in hardware but different in
| software.
|
| "f undefined" is undefined in software but "g undefined"
| is not. Neither is undefined in hardware.
|
| This distinction comes up very rarely. Only if you have a
| parametric circuit that sometimes takes zero-bit inputs
| (I.e. if the input is unused in some instantiations).
| melony wrote:
| Try Chisel, it is production ready and is built on Scala.
| fouric wrote:
| Chisel builds with sbt, which is _extraordinarily_
| slow[1][2][3], and extremely difficult for newcomers to
| use[1], if not outright poorly-designed.
|
| [1] https://www.lihaoyi.com/post/SowhatswrongwithSBT.html
|
| [2] http://overwatering.org/blog/2013/12/scala-1-star-
| would-not-...
|
| [3] https://duckduckgo.com/?q=sbt+slow
___________________________________________________________________
(page generated 2021-10-23 23:01 UTC)