calyx
calyx copied to clipboard
`calyx-hls` A Calyx-based HLS toolchain
I've written been getting my hands dirty with the Calyx CIRCT implementation and have been inspired to design a couple of new tools to drive work on Calyx forward. Specifically, I think we have everything we need to build a calyx-hls
tool that takes C++ programs and generates synthesizable Verilog out of it.
Here is a rough sketch:
- Use Polygeist to transform C++ programs into the
affine
dialect. - Use the
affine
toloopschedule
orpipeline
flow and generatecalyx
dialect programs out of it. - Use the soon-to-be-added
calyx-native
pass to compile programs generated from (2) to purely structural Calyx. - Either use the Calyx compiler to generate Verilog programs from there or use the CIRCT flow (
calyx
->hw
->sv
)
Et voila, you have an HLS tool built using Calyx. There are a couple of good reasons to build this toolchain:
- We're already moving towards HLS flows being an important driver of Calyx development.
- We can start compiling programs from real HLS benchmarks like Rosetta and see where this toolchain fails. This will also start giving us programs we can look at for optimization purposes.
- Marketing wise, things are easier if we have a C++-based HLS compiler.
Another long-term benefit is that folks like @andrewb1999 can potentially design a new frontend DSL for the AMC compiler (which currently uses a lower-level representation) which will really allow calyx-hls
to start beating Vitis.
My proposal is to use the new calyxir organization to house this project because it relies on dependencies from both Calyx land and CIRCT land.
I think @calebmkim and I should sit down and think about how to build this. IIRC, he is already using a Polygiest flow for evaluating the static paper.
Seems like a fun thing to try! Here are a couple of high-level thoughts:
- To state the probably-obvious, the utility here depends strongly on how well Polygeist does. "Plain C++"-to-affine translation will necessarily always be quite limited, and increasing its coverage seems like hard work. So while it doubtless works fine for Polybench, Rosetta may be a drastically different story.
- Hopefully, the thing being built here is "just glue" and contains no actual cleverness. That is, all the hard work happens in places that are more reusable in other contexts: Polygeist, CIRCT, and Calyx per se. With that in mind, maybe we should think about what is not covered by hlstool… perhaps hlstool has no interest in integrating with Polygeist for source-code ingestion, for instance?
Precisely: this is mostly supposed to be a "glue code" exercise to see how far we can get with the tools today. You're right that Polygeist will be the limitation here and so eventually, we'd want to see what other frontends we can use. For example, there are passes to convert the ControlFlow dialect cf
into scf
which could potentially allow us to play with more programs (albeit with none of the pipelining that the affine
flow gives us).
The long-term dream is of course to use @andrewb1999's AMC dialect as the only representation and come up with a frontend that really takes advantage of its abstractions.
Just to give context to this issue, I've already been using the Polygeist flow to go from C++->Affine->SCF->Calyx->Native Calyx->Verilog for the Polybench benchnmarks:
The code is here: https://github.com/cucapra/calyx-resource-eval/tree/main/polybench-affine/blas/gemm. I manually run Polygeist on C++ scripts to get mlir files. Then there's this other script that just runs the circt/mlir command line options: https://github.com/cucapra/calyx-resource-eval/blob/main/polybench-affine/utilities/gen-calyx.sh.
@rachitnigam Sorry for the delay on this - I was wondering how to get involved in the work Andrew referenced for adding support for the static scheduling flow in Calyx HLS. Is there any chance you'd be free for a chat early next week?
Hey @evanmwilliams! I'm unfortunately not super available these days. What do you think about starting a new thread our Zulip channel for calyx and starting a discussion about what to do next? I think the simplest thing to do is look at hlstool in the CIRCT repository and extracting out the Calyx based lowering flow from it. Then we can build upon it.
That sounds reasonable! I'll do that :)