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

Status and getting started #8099

Open
ecstrema opened this issue Jan 20, 2025 · 2 comments
Open

Status and getting started #8099

ecstrema opened this issue Jan 20, 2025 · 2 comments

Comments

@ecstrema
Copy link

Hello,

I just arrived here, looking for what I heard was "the LLVM of FPGA/ASIC".

After heading to the front page, and trying to find some instructions to get started, I had a hard way finding about the status of this. I got to multiple dead links, then found some sparse documentation, or links saying that it was similar to MLIR and directing towards MLIR tutorials.

Since all was so sparse and quite in-digest, I ended up thinking that the project was largely abandoned (the articles stated in the website all date from 2020 or 2021).

However, the activity in this repo led me to realize that no, the project is in fact not dead at all.

So. What can currently be done with this? Is there a way to get a bitstream or equivalent from Verilog/VHDL/other?

How is it/can it be used in its current state? Would it be a working language backend?

@seldridge
Copy link
Member

"The reports of my death are greatly exaggerated."

No, the project is in no way dead, though the project may not align entirely with what you are expecting. The primary, load-bearing use of the project is as a compiler middle-end and back-end for generating Verilog. New hardware language development is fraught with common problems which all languages have to solve: namely a common IR, common optimizations, and Verilog generation. CIRCT provides all of this, so new language development only needs to get to the core CIRCT representations. The diagram on the main website should help explain this: https://circt.llvm.org/ There are a number of core dialects (MLIR lingo for "separate IRs which can be composed") which are the target of multiple language front-ends (potentially through supporting front-end dialects): Chisel, PyCDE (a Python front end), Kanagawa (a not-yet open source Microsoft design language [1]), Calyx, Verilog (through Slang), and some high-level synthesis front-ends.

There is simulation support through the ARC dialect and arcillator tool.

There is preliminary support for synthesis-like activities through the AIG (and-inverter graph) dialect and work-in-progress support for technology-focused dialects and actual synthesis (see: #8018 and #8031). What you are asking for is a path from Verilog, through the core dialects, and then into the work-in-progress synthesis tooling.

The project is intended to be hardware compiler infrastructure. If you have a problem which looks like a hardware compiler problem, it may be a good fit. However, this main goal is somewhat orthogonal from the tools that the project provides, e.g., a Chisel compiler (firtool) or an FPGA synthesis and bitstream generation tool, though the project does provide a number of tools and intends to provide more.

@ecstrema
Copy link
Author

ecstrema commented Jan 21, 2025

Thank you for your thourough answer. It does clarify it quite a bit.

The primary, load-bearing use of the project is as a compiler middle-end and back-end for generating Verilog.

...

There are a number of core dialects [...] which are the target of multiple language front-ends [...]: Chisel, [...], Verilog (through Slang), and some high-level synthesis front-ends.

So there currently is a way from verilog to verilog, with the only difference between input and output being the optimization passes applied? Interesting.

I really like this arcillator project. Seems like it could replace most of the -mixedsvvh issues people currently have, provided that at some point we have a vhdl to arc transform.

Having found about neither arcillator or the (in-progress) HLsynthesis in the docs, I do think that a "current state of the project" should be put in the readme and in the docs. It could list the current subprojects, and state what is currently possible with it.

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

2 participants