5 ms·

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

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 https://github.com/newhouseb/onebitbt [1] https://github.com/newhouseb/onebitbt/blob/master/research/Detection.ipynb https://github.com/newhouseb/onebitbt/blob/master/research/D...

victor82 5y ago
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 5y ago
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 https://i.imgur.com/tAQe5Sr.jpg (If that is indeed a bug, I’m curious how that might impact the results!)
- newhouseb 5y ago
  Good eye! That's indeed a typo in the notebook. Somehow in the actual design I have the correct pairing https://github.com/newhouseb/onebitbt/blob/master/onebitbt/radio.py#L75 https://github.com/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 5y ago
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.
- wyager 5y ago
  > 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 5y ago
    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 5y ago
      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.
cushychicken 5y ago
Any idea of how the performance is of nMigen generated Verilog vs, say, Simulink generated Verilog? My understanding is that generated HDL works, but isn't ideal for highly performant for really latency sensitive applications like HFT or EM warfare. Another mark against Simulink is the relative unreadability of its generated HDL. Very challenging to optimize as a result.
- tverbeure 5y ago
  You’re a little bit comparing apples against oranges. When you use Migen, Chisel, SpinalHDL, you’re still writing RTL: you can define what kind of gates are being generated with the same precision as you can with Verilog. You are 100% control of pipelining and low level details. The readability of the generated Verilog will obviously be lower but, unlike Simulink or HLS, there is nothing that is making architectural decisions for you.
  - cushychicken 5y ago
    OK, I'll admit I'm confused here. I thought nMigen was a kind of Python-to-Verilog compiler. (I know Migen was a separate HDL; I'm not exactly sure the relationship between Migen and nMigen.) Something about your comment has me questioning whether that's correct. Is there a tool that does what I'm describing? I assumed that a Python-to-Verilog or VHDL compiler would be useful if you could find ways to map concise Python syntax to slightly more verbose HDL constructs. That'd give you Python's expressiveness, but maintain compatibility with a bunch of vendor toolchains if you could emit something commonly supported like verilog-2001.

victor82 5y ago

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 5y ago

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 https://i.imgur.com/tAQe5Sr.jpg (If that is indeed a bug, I’m curious how that might impact the results!)

newhouseb 5y ago
Good eye! That's indeed a typo in the notebook. Somehow in the actual design I have the correct pairing https://github.com/newhouseb/onebitbt/blob/master/onebitbt/radio.py#L75 https://github.com/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 5y ago

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.

wyager 5y ago
> 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 5y ago
  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 5y ago
    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.

cushychicken 5y ago

Any idea of how the performance is of nMigen generated Verilog vs, say, Simulink generated Verilog? My understanding is that generated HDL works, but isn't ideal for highly performant for really latency sensitive applications like HFT or EM warfare. Another mark against Simulink is the relative unreadability of its generated HDL. Very challenging to optimize as a result.

tverbeure 5y ago
You’re a little bit comparing apples against oranges. When you use Migen, Chisel, SpinalHDL, you’re still writing RTL: you can define what kind of gates are being generated with the same precision as you can with Verilog. You are 100% control of pipelining and low level details. The readability of the generated Verilog will obviously be lower but, unlike Simulink or HLS, there is nothing that is making architectural decisions for you.
- cushychicken 5y ago
  OK, I'll admit I'm confused here. I thought nMigen was a kind of Python-to-Verilog compiler. (I know Migen was a separate HDL; I'm not exactly sure the relationship between Migen and nMigen.) Something about your comment has me questioning whether that's correct. Is there a tool that does what I'm describing? I assumed that a Python-to-Verilog or VHDL compiler would be useful if you could find ways to map concise Python syntax to slightly more verbose HDL constructs. That'd give you Python's expressiveness, but maintain compatibility with a bunch of vendor toolchains if you could emit something commonly supported like verilog-2001.