Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

calyx-hls A Calyx-based HLS toolchain #1680

Open
rachitnigam opened this issue Aug 19, 2023 · 7 comments
Open

calyx-hls A Calyx-based HLS toolchain #1680

rachitnigam opened this issue Aug 19, 2023 · 7 comments

Comments

@rachitnigam
Copy link
Contributor

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:

  1. Use Polygeist to transform C++ programs into the affine dialect.
  2. Use the affine to loopschedule or pipeline flow and generate calyx dialect programs out of it.
  3. Use the soon-to-be-added calyx-native pass to compile programs generated from (2) to purely structural Calyx.
  4. 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.

@rachitnigam
Copy link
Contributor Author

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.

@sampsyo
Copy link
Contributor

sampsyo commented Aug 19, 2023

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?

@rachitnigam
Copy link
Contributor Author

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.

@calebmkim
Copy link
Contributor

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.

@evanmwilliams
Copy link

@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?

@rachitnigam
Copy link
Contributor Author

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.

@evanmwilliams
Copy link

That sounds reasonable! I'll do that :)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

4 participants