Port (some of) the AXI wrapper to Calyx

[sampsyo]

This is a somewhat wacky, possibly doomed-to-fail proposal to address some of the pitfalls of our current AXI wrapper code. As mentioned in #1022 (reply in thread), many of the problems we encounter in that code are a direct result of Verilog being kinda bad: unchecked errors, irregular code generation, and so on. And furthermore, the code does some manual state-machine management.

There's a chance this code could be a lot simpler if it were in Calyx instead of Verilog! What if we tried to incrementally port our Xilinx-generating AXI code to generate Calyx code instead? The practical goal would be to make the AXI stuff far more maintainable. There could also be a research goal in here, in showcasing/extending Calyx itself to be good at this kind of timing-sensitive signal manipulation.

I think the first step, if we were to prototype this, would be to replace the top-level component. This is the bit that not only has all the external ports that connect to the host but also does the FSM sequencing to implement data exchange. At an extremely high level, we'd want the top-level's control program to look like:

seq {
  par { read_mem_0; read_mem_1; ... };
  kernel;
  par { write_mem_0; write_mem_1; ... };
}

…which would sure save us a lot of funky Verilog code that essentially does the same thing.

This would go well with #1084, in the sense that the AXI generator would be just another Calyx frontend with a somewhat funky DSL. That DSL would be a description of the target hardware's external interface, and we'd build a compiler that translates that into a Calyx-implemented AXI wrapper for that interface.

[rachitnigam]

@sampsyo Removing the discussion needed tag because I'm not entirely sure what to discuss here but feel free to add it back if you'd like

[rachitnigam]

As usual, I've come to the same conclusion as @sampsyo on this (about one year later) that this is really the right way to do things. My slightly different pitch is that instead of using the builder stuff in Rust, we should try switching to the calyx-py as our primary AXI generator and use that to make a really robust generator in initially and an cool AXI DSL in the long term.