Calyx passes within CIRCT

[mikeurbach]

There was previously some effort to implement the core Calyx compilation passes in CIRCT. Unfortunately, those do not seem complete, and are already bit-rotting (they implemented the old version of compile control, before top down compile control, and the newer attempt at a top down static timing).

I think it would be great to revive the Calyx passes, on two fronts:

1. Lowering from the lowest form of Calyx (i.e. after the core compilation passes and post-optimization) into CIRCT's core dialects (HW/Comb/Seq).
2. Re-implementing the core compilation passes in CIRCT, using CIRCT-native representations to make this easier.

For 1., this will unlock CIRCT's low-level optimizations and System Verilog emitter for Calyx pipelines. Any integration between CIRCT and Calyx can take advantage of this pass.

For 2., this is more experimental, and may help push the boundaries of how Calyx is transformed as well as what CIRCT can represent in "mid-level" IRs. For example, the top down compile control and top down static timing passes may benefit from having an explicit FSM representation in the IR, which CIRCT provides.

My approach for 2. would be to start at the high-level end of the pass pipeline (i.e. compile control or static timing), and work down the pipeline to get to the low level form that 1. could consume. Tactically, I'd personally start with top down static timing, since the Calyx emitted from the StaticLogic dialect in CIRCT will abide by that pass' requirements. This is a narrow slice of Calyx that we could plumb through CIRCT all the way to System Verilog!

[sampsyo]

Both of these seem useful, but I wanted to throw extra enthusiasm behind item 1… it would enable a super exciting end-to-end CIRCT use case that goes from high-level languages, through the current Calyx (Rust) compiler, and the rest of the way down to hardware within the CIRCT ecosystem. It would also crystallize the problem of replacing parts of the Calyx compiler with "MLIR-native" versions (item 2), bit by bit, if we want to do that. (By "crystallize" I mean it would (a) intellectually clarify the work to be done and (b) enable convenient differential testing between the two implementations.)

[mikeurbach]

I mentioned this in the meeting today, but for the record, I think working on 1. first is the higher priority thing here. Out of all the discussion issues I opened today, I might go so far to say it's the highest priority thing. If we have that flow connected, everything else can be measured as an incremental improvement (better resulting Verilog, better compile times, etc...).