Add Calyx native compiler as an optional dependency

[rachitnigam]

The current Calyx compilation flow involves running the native compiler to lower control operations into pure structure which can be exported back to the MLIR flow. @mikeurbach suggested that one way to encode this is to make the Calyx native compiler an optional dependency that can be installed when building circt tools.

He recommended looking at this integration of the optional julia tools: #2465

[mikeurbach]

Sorry, I must not have been clear, or-tools is a C++ project and those were integrated as an optional CMake dependency: https://github.com/llvm/circt/pull/2465/files#diff-1e7de1ae2d059d21e1dd75d5812d5a34b0222cef273b7c3a2af62eb747f9d20aR310.

Maybe a better example is a command line tool like vivado:

circt/CMakeLists.txt

Line 241 in 1e0fb29

option(VIVADO_DISABLE "Disable the vivado synthesis tests.")

Optional CMake dependency is pretty much the only way CIRCT has been accepting external dependencies, so we'd probably expect the same from a Calyx integration.

I'm curious what the depth of this integration would be.

In the case of or-tools, we depend on it as a library and use it from C++ when enabled:

circt/lib/Scheduling/LPSchedulers.cpp

Line 29 in 1e0fb29

MPSolver::OptimizationProblemType problemType;

In the case of Vivado (and the other commercial simulators), it's so we can write integration tests for IEEE compatible simulators in SV instead of relying on Verilator. These arguably don't need to be in the CIRCT repo at all.

Can you explain more what the Calyx integration would look like? I'd be somewhat hesistant to add an optional Calyx dependency in CIRCT just so we can add tests that use futil. We have gotten by so far by doing that integration in another repo, like circt-hls. Would this be a deeper integration than that (i.e. at the library level, or something else)?

[rachitnigam]

Thanks for the clarification. In the short term, I was expecting to use it to setup integration tests that let us fully lower Calyx programs within the CIRCT repo so an integration like the vivado tools would be appropriate. In the longer term, once we design a shared representation for MLIR and Calyx native programs, maybe we can think of using Calyx native as a library and invoking passes on in-memory representation of Calyx MLIR programs.

The longer term objective of the integration is to also eventually tightly integrate the MLIR and native toolchains so that users can transparently use one or the other. Either way, interested to hear comments!

[rachitnigam]

@sampsyo if you ever feel inclined, this issue requires some specialized knowledge (that I don't yet have) and might be perfect for one of your highly-valuable in-flight plane coding sessions!

This would also make it really useful for people onboarding with CIRCT & Calyx