However, I got significantly worse QoR from Quartus. By significant I mean that I might ordinarily see a slack that’s in the 0.2ns to -0.2ns rnage, but I have never seen -0.49ns.
Therefore, and based on nothing else, I’m inclined to believe that there is something in the .sv files that’s actually leading Quartus to worse results.
It is of course possible that I got a freak outlier in QoR results from Stratix and that there is in fact no real difference, but that’s not my initial assumption.
We don’t have Quartus configured to explore a number of initial conditions in it’s P&R&S so as to know with confidence whether the .sv files generated by CIRCT are better or worse. There is a feature to do that, but is not what we have set up in our flow.
Requires further study.
What might be useful is for Chisel CIRCT to have default options, or at least document such options, that gets Verilog that’s close to what Chisel does today. The user can then explore one improvement in genrated Verilog at the time…
The first order of the day is of course to identify exactly what those options are…
Upon studying timing, I see a “technial debt margin call”. The failing timing path is a real issue in the design that Quartus is no longer able to sweep under the rug.
The trick with timing failures is that the problem isn’t necessarily the failing path…
The problem can exist somewhere else entirely. P&R&S timing closure, to my mind, is like trying to fit a baloon into a certain shape. Sometimes you can squeeze the baloon in some places and make it fit, but eventually you have to reduce the total amount of air in the baloon to make it fit.
In my case, the solution is to “reduce the amount of air in the baloon” prior to upgrading to LLVM CIRCT.
A lot of this went over my head (one of those “understand the words, not the sentence” situations), but I’m interested in your results. I’d like to use CIRCT for generating Verilog from a slightly higher level HDL.
Just to clarify, is this the workflow you used?
Chisel code (.scala) → .fir → CIRCT (do you know options/dialects you used?) → .sv → Quartus → test that output
I’m interested to know if there’s issues with ExportVerilog in general, issues with it and a specific RTL dialect, or issues with some part of the Chisel import process. I may have outdated information since I’m new to CIRCT, so let me know if that’s wrong.
How much of the features of proper SystemVerilog are you using (as opposed to what Verilog also supports)?
“Just to clarify, is this the workflow you used?
Chisel code (.scala) → .fir → CIRCT (do you know options/dialects you used?) → .sv → Quartus → test that output”
I ran into various issues, but I think it simply a bit too early in CIRCT’s lifecycle to expect that the above flow should work.
I intend to try again in while…
In particular, I’m waiting for this github issue to be resolved. Ideally with these Chisel tests being integrated into the CI of LLVM CIRCT pre-pull request tests…
The goal is to generate Verilog (or SystemVerilog) code that’s friendly to engineers downstream of Chisel(Verification, FPGA developers, etc.). I’m not trying to use as many SystemVerilog features as possible.
Can you elaborate on what’s holding CIRCT back at this point? I’d like to see what needs to be done if it would hold me back from using CIRCT for our HDL.
So do you think that your issues could also derive from the unfinished nature of chisel-circt? I’d imagine it’s a combination of both.
I have a similar goal. I actually just want to make .v Verilog files anyways. If they happen to technically be .sv files, that’s fine with me (as long as my understanding of SystemVerilog’s backwards compatibility is correct).
This will depend entirely on what features of Chisel you are using and if you have custom Scala FIRRTL Compiler (SFC) transforms in use. SiFive is switching to CIRCT for all of our Chisel designs. I.e., we’re running cores through simulation and physical design flows and we very much using CIRCT as a FIRRTL compiler. The SiFive flow is similar to a Rocket Chip build flow where a Chisel generator produces FIRRTL, a FIRRTL compiler compiles this, and then SystemVerilog testbenches are attached to the result.
Your specific use case @emosy sounds like CIRCT may be suitable for your use case.
These are the known Chisel features which I am aware have not been ported:
Enum Annotations (it would be very weird if anybody is actually cares about these)
ForceNameAnnotation on anything that is not a module
These are mostly non-standard things that a new Chisel project will likely not encounter. However, some of these have seen widespread uptake by the community. (Oyvind uses some of these.) The plan is to release a Chisel 3.6 which upstreams chisel-circt to enable running Chisel designs through CIRCT without having to bring in a library. A Chisel 3.7 milestone release will simultaneously drop that switches to CIRCT. These will simultaneously coexist while features that people care about are ported (ideally by the people that care about them, while some of the existing Chisel features not ported will be ported by the core Chisel/CIRCT team).
Any custom (not in-tree) SFC transforms deployed by a user would have to be ported to CIRCT by the user.
As part of this we have ported a large number of internal, custom transforms which may have value to Chisel/CIRCT adopters (though without the accompanying Chisel APIs):
Full Async Reset Transform (ability to add an async reset to every register in a design)
Grand Central (ability to generate SystemVerilog interfaces that XMR into your design to provide a stable “view” of the design to a user)
More aggressive deduplication than what SFC supports
I sincerely hope that there is both a substantive carrot angle (cool new long-asked for features, much faster compilation times/lower memory usage, and the fact that this puts Chisel on rock-solid compiler infrastructure) in addition to an unfortunate stick angle (SFC will eventually go away).