This is quite invasive. This converts from the functiontype printer to the moduletype printer.
---------
Co-authored-by: Mike Urbach <mikeurbach@gmail.com>
This commit adds a version of the Calyx remove-groups pass tailored for
the FSM flow. Specifically, it will perform FSM outlining alongside group
rewriting - which interacts with the FSM I/O (group go/done signals).
Technically, we now (finally) have an end-to-end flow for SCF->Calyx->FSM->SV.
The usability of the end-to-end flow is still fairly restricted, mainly
due to:
1. the lack of support for lowering Calyx memory ops
2. The lack of support for lowering `calyx.par` ops in the FSM lowering
(this shouldn't be too difficult).
A fair amount of state is stored in attributes in between `materialize-calyx-to-fsm`
and `calyx-remove-groups-fsm`. I'm debating with myself whether that's code
smell or just a necessary evil given the approach taken. Nevertheless, I
did this work because of being frustrated with the disconnection of Calyx
from the rest of CIRCT, which renders it unuseable. Since I was the author
of the FSM flow, I figured that i'd might aswell finish the end-to-end
prototype before stepping somewhat away from Calyx-related development.
I'm hoping that given this end-to-end prototype, there's enough existing
infrastructure for others to pick up the torch and flesh out the
missing pieces.
Some additional notes:
* Also makes `calyx.component` contain a graph region to make it a bit less
of a pain to specify SSA dependencies between cells.
* Also fixes various small bugs highlighted by this conversion.
This was essentially enforcing unintended behavior and making it weird to target FSM as a front-end. Previously, `SingleBlockImplicitTerminator<"OutputOp">` required an OutputOp to be in both the output and transition regions, where it really only made sense for the output region.
It's a similar story for the TransitionOp and `SingleBlockImplicitTerminator<"ReturnOp">`.
This, and other small fixes, have been moved to FSMOps.cpp
There is currently no rationale for explicitly annotating the type that states (a state register) should be inferred as for a machine op. Annotating it upon constructing the machine op is therefore just an extra burden on the front-end, and may also be a premature constraint.
As i see it, default behaviour should just be to infer a state type via. e.g. ceil_log2(# states) when lowering to hardware. If some other behaviour is needed, then this should be lowering specific.
Blameless revert of e1cf64ad00. This is
done because there are some issues with the approach around
canonicalization that can cause intermittent failures in tests. This
will be fixed up in #3131.
Signed-off-by: Schuyler Eldridge <schuyler.eldridge@sifive.com>
Initial implementation of LLVM graph traits for an FSM machine operation. This will most likely be a useful piece of code for building further transformations, visualizations, ... upon.
* LLVM bump (as we know it)
* minor format fix
* DCMAKE_BUILD_TYPE=?
* Update lib/Dialect/MSFT/MSFTOps.cpp
Co-authored-by: Andrew Young <youngar17@gmail.com>
* Update lib/Dialect/FIRRTL/FIRRTLOps.cpp
Co-authored-by: Andrew Young <youngar17@gmail.com>
* Update lib/Dialect/Calyx/CalyxOps.cpp
Co-authored-by: Andrew Young <youngar17@gmail.com>
* removed anon module test
Co-authored-by: Andrew Young <youngar17@gmail.com>
Since we currently only allow a single initial state for the state machine, it is a reasonable assumption that any unreasonable states may be pruned as part of canonicalization.
Previously, the first state in the machine was assumed to be the initial state - I believe being explicit here is important to ensure the machine behaves as intended. Also modified "default" state to "initial" state (seems to be more consistent with litterature).
Andrew Lenharth