1. 22
  1.  

  2. 5

    That was a remarkably readable research paper for such an advanced topic! I really appreciate that in papers like this; they could easily have crowded it with Greek letters and math notation for explaining stuff like their IR or other pieces, but instead they explained the complex technical topic elegantly with just words. I was able to grasp the core pieces of the toolchain they built even though my knowledge of the domain is rough at best.

    Also, I was super impressed at how much they accomplished with such a small amount of code:

    We implemented a Reticle compiler in 8662 LoC in Rust, together with a Verilog AST library (2486 LoC).

    1. 2

      So if I understand what I’m reading - the advantage of using something like Reticle over Verilog is better support for custom features of a particular FPGA?

      1. 8

        [Co-author here.] Yep, that’s the main advantage. And our argument is maximally using those custom features (e.g., the poorly-named “DSP blocks” that are actually richly programmable SIMD math functional units) is critical for good performance when you’re using FPGAs as algorithmic accelerators. It’s less important if you’re blinking LEDs or hacking up a GameBoy emulator, but pretty important if you’re trying to offload computations from a CPU/GPU for speed.

        1. 2

          Thanks very much! I must admit I’m a bit mystified by that whole space but it seems like it could be a fascinating rabbit hole to explore :)

      2. 1

        I wonder how this relates to recent work on higher level alternatives to Verilog & VHDL like nmigen and chisel. Could those be enhanced to back-end to reticle rather than Verilog for superior expressiveness, predictability and performance?

        1. 4

          It’s something we’ve explored! But our main goal is actually to be backend for more accelerator-focused languages/compilers. Stuff like Aetherling, Spatial, and Dahlia more so than nMigen and Chisel.