I envision CIRCT as having a library of commonly used functionalities and the stream dialect sounds like a very common use case. My little SiDi board lacks capacity to go too fancy but with my mostly software background (BS in Computer Science) and little bit of hardware background (AAS in Electronic Engineering Technology) I have some learning to do.
Can someone here tell me how much CIRCT can speed up development of a custom core? My use case is trying to make an open core (possibly CERN OHL) to compete with the Apollo Core AC68080 (a continuation of the Motorola 680x0 series). Among its features are opcode fusion (combining combinations of 2 opcodes into one, such as 3 operand math functions fused from a register move followed by a math operation on the same destination register), opcode bonding (forwarding the contents of 2 operations having the same source so superscalarism isn’t hindered) and more.
Of course I realise the CIRCT software isn’t in full form yet but I want to improve my chances at success in the distant future, after I’ve upgraded from a small Cyclone 4 to a larger FPGA. Am I correct in my assumptions that CIRCT functions like a shorthand for common uses? I want something that’ll help me improve my skill more quickly and do more than Gunnar von Boehn has done in VHDL. I realize this won’t happen overnight.
I have other questions on a legal tangent regarding instruction cracking patents and the Linux related Open Source Initiative but I think you get the idea.
After following the Sticky header topic and seeing the meeting notes link, I see that my questions are way farther ahead of where this project has gotten established. I’ll have to wait for my hobby to get established before I charge in and try something fancy.
1 Like
Hi @SamuraiCrow,
I will take a crack at answering this.
CIRCT is compiler infrastructure. So, it wouldn’t directly help you develop a custom core, but it would help a compiler author construct a compiler, and that compiler could help speed up your development.
For example, the Chisel compiler uses an intermediate representation called FIRRTL, and a FIRRTL compiler is implemented in CIRCT. By switching to the CIRCT-based FIRRTL compiler, Chisel users enjoy a compiler that runs in less wall clock time and consumes less memory. For example, see this keynote talk from last fall’s LLVM Dev Meeting, especially slide 51.
It’s important to remember that the building blocks users combine to construct a core (counters, memories, etc.) are from Chisel, not CIRCT. Those building blocks are lowered into a compiler intermediate representation, which CIRCT transforms and ultimately exports as System Verilog.
Yes and no, I think. CIRCT has some shared constructs, but again, these are meant to capture common uses in a compiler for hardware. You won’t find constructs for “core with opcode fusion”. You will find constructs that would be useful to a compiler writer for a new HDL (like Chisel, et al), and that HDL is where you would define your “core with opcode fusion”.
Does that help position CIRCT? From what I gather, if you want to “use CIRCT”, you’d actually want to use a new HDL that is built with CIRCT under the hood. Chisel is probably the most established, but there is also PyCDE, as well as other projects like ROHD and Magma, which are starting to target CIRCT.
2 Likes
Thanks for the links! That’s just what I needed! The patent I need doesn’t expire until September 2023 anyway. I need to start reading up.
1 Like