The layer sink pass is showing some performance problems, and we want
the ability to turn it off to work around the issue, until we can
properly fix it.
Add an override that, instead of emitting an error, selects the default target
to specialize an instance choice when the option is unspecified. By default a
partially specified instance choice is not allowed. But we can override the
error and select the default target, by using
`--select-default-for-unspecified-instance-choice` with `firtool`.
This enables a user to specialize the instance choice for a particular build
flow, and fall-back to the default for all others.
This PR adds the option to run CSE only on `firrtl.module`, and ignore
other operations. There are some tools, that are not able to handle CSE of
`firrtl.object` in `firrtl.class`. Specifically, the reuse of `firrtl.object`
is not modeled properly.
This is a temporary workaround to disable the CSE of operations inside
`firrtl.class`, which can be removed once the actual issue is fixed.
This legacy system for representing an object model has been replaced
by FIRRTL classes, objects, and properties. This removes the old
system completely.
The main change is removing the EmitOMIR pass completely, but there
are several other things related to OMIR JSON to clean up. This
includes command line options and annotations for specifying input and
output OMIR JSON, as well as support for parsing the JSON and
scattering OMIR tracker annotations. Any tests related to the above
were also removed.
The only remaining legacy OMIR feature is the OMIRTracker annotation,
which is currently used in some canBeDeleted logic on annotations in
folders, IMDCE, etc. This is being separated, and removed in this PR:
https://github.com/llvm/circt/pull/7908.
This adds a conversion pass from AIG dialect to Comb dialect. AndInverterOp can be easily converted into comb.and + comb.xor + hw.constant.
This enables us to utilize core dialects tools for synthesis results without any addition. Primarly use case is running LEC on IR before and after synthesis.
This adds a conversion pass from Comb to AIG. Currently conversion patterns for variadic `comb.or/and`
and binary xor are supported. There will be a follow up to implement conversion patterns for arithmetic ops.
This PR extends compreg's powerOnValue operand to be able to capture more complicated initialization such as firreg's randomized initialization or DPI calls. This change should make register initialization more modular and a step forward towards https://github.com/llvm/circt/issues/7213.
While ASICs might not have explicit initial values, they are crucial for simulation
and FPGA implementation. FPGA designs often require constant initial values, while
simulation allows for more complex initialization using expressions like function calls
`$random`, `$readmem`, and `$fopen`.
seq.compreg has a (optional) powerOn operand that is lowered into inlined assignment in SV which allows users to initialize registers with user-specified values. However this representation is not sufficient for initialization with function calls.
In order to represent various kinds of initialization, `seq.initial` op and `!seq.immutable` type
are introduced. The `seq.initial` operation produces values with types wrapped in `!seq.immutable`.
The `!seq.immutable` type wrapper prevents initial values from depending on time-variant values.
Stateful operations typically require corresponding initial values with the `!seq.immutable` type.
This ensures that the initial state of the operation is well-defined and independent of time-variant factors.
Example Input:
```mlir
%r_init, %u_init = seq.initial {
%rand = sv.macro.ref.se @RANDOM() : () -> i32
%c0_i32 = hw.constant 0 : i32
seq.yield %rand, %c0_i32 : i32, i32
} : !seq.immutable<i32>, !seq.immutable<i32>
%r = seq.compreg %i, %clk initial %r_init : i32
%u = seq.compreg %i, %clk initial %u_init : i32
```
Output Verilog:
```verilog
reg [31:0] r;
initial
r = `RANDOM;
reg [31:0] u = 32'h0;
```
Casting from interface to operation generates these warnings,
as with other instances resolve by casting from Operation* instead.
> llvm/llvm/include/llvm/Support/Casting.h:490:69: warning: returning reference to local temporary object [-Wreturn-stack-address]
This has only been used for probes, but without input probes
this is no longer useful or necessary.
The HW-signal hoisting works well (if limited) and has no
known issues[1] but has yet to be used in practice due
primarily to passthroughs being intentional occasionally
and lacking a mechanism to capture or distill this intent
properly (it must be ""optimized"" yet not).
Since this is unused, and lacking traction on the above,
remove from pipeline and delete this for now instead of
having it bitrot and be a maintenance burden while
adding/completing new features.
Lives on in version control history!
[1] FWIW, see https://github.com/llvm/circt/pull/6115 for
both small example and before/after on chipyard, as well
as testing internally back when this was introduced.
Move the definitions of all array types from C++ land into
`MooreTypes.td`. This removes a significant amount of redundant code and
simplifies the dialect's type system.
Replace packed and unpacked ranges (`T [4:3]` or `T [2:4]`) with a new
type that discards the directionality and offset of the range. This
information is no longer needed at the IR level. Any meaning that the
offsets have can be encoded in the corresponding ops. Both ranges are
now represented as `array<2 x T>` and `array<3 x T>`, respectively.
Combine unpacked ranges (`T foo [6:2]`) and unpacked arrays
(`T foo [42]`) into a single `uarray<N x T>` type.
Coalesce SystemVerilog's `shortreal`, `real`, and `realtime` types into
a single `!moore.real` type understood to be 64 bits wide, and move the
definition from C++ land into `MooreTypes.td`. Once ImportVerilog
actually supports expressions on real values we may want to revisit this
type and either replace it with the standard `f32` and `f64` types, or
create dedicated types for `shortreal`, `real`, and `realtime`.
The core type most SystemVerilog expressions are interested in and
operate on is a "simple bit vector type". These are individual integer
atoms like `bit` or `logic`, integral types like `int`, or packed arrays
with a single dimension and an integer atom inner type, like
`bit [42:0]`. So in a nutshell, simple bit vector types are MLIR's `i42`
in the two-valued (`bit`) case, or the four-valued equivalent (`logic`).
Up until this point, the Moore dialect reflected this pattern by
providing and `IntType` for the integer atoms like `bit` and `int`, and
using the `PackedRangeDim` for single dimension vectors of `bit`. A
`SimpleBitVectorType` helper struct would then summarize the _actual_
bit vector that was expressed by the packed range and integer atom. This
makes working with the types in TableGen files very annoying, since the
thing you are actually interested in -- the simple bit vector -- is not
a propery MLIR type, but more like a helper struct on the side.
This commit rips out the existing `IntType` and its composition with a
packed array dimension, and replaces it with a proper simple bit vector
type that is actually an MLIR type. As a result, SystemVerilog types
like `int unsigned`, `bit [42:0]`, `reg`, `logic signed [31:0]`, or
`integer` are all translated into the same MLIR type. This new simple
bit vector MLIR type retains the `IntType` name, and prints as
`!moore.i42` or `!moore.l42`, depending on whether it is a two-valued or
four-valued integer. Single `bit` and `logic` atoms become `i1` and `l1`
respectively.
This makes the Moore type system a lot easier to work with and removes
a lot of unnecessary noise. Operations can now simply use
`llvm::isa<IntType>` to check if a value is a simple bit vector.
Add a `circt-capi` target that depends on all C API libraries. Introduce
a new `add_circt_public_c_api_library` CMake function that wraps around
the MLIR equivalent, but also adds a dependency from `circt-capi`. Make
at least the short integration tests CI job build the `circt-capi`
target to ensure it has a bit of CI coverage.
* Add lowering for AssertProperty operations
* removed nl at start of file
* sorted cmake and removed unreachable branches
* Removed useless wire in test + removed symbol from hbr compreg
Add option to allow this for compatibility.
Add statistic to count ports added to public modules,
as an interesting bit of information but particularly
to track how many are still being added when updating
a code base to avoid this.
This commits replaces `--emit-chisel-asserts-as-sva` with an option with more fine grained control.
Specifically an option `--verification-flavor={none, if-else-fatal, immediate, sva}` is added. `none` is the option for the current behaviour that uses per-op configuration (which must be deprecated once after `has_been_reset` is properly used for assertions that are expected to be disabled while pre-resets).
Close https://github.com/llvm/circt/issues/6543
Both the upstream MLIR IntegerAttr and OM IntegerAttr are backed by an
arbitrary precision integer. However, the upstream Python bindings
don't have any mechanism to return an integer larger than 64 bits back
to Python, even though Python ints are also arbitrary precision
integers.
To support this, we can handle this where we explicitly convert OM
IntegerAttrs to Python values. The simplest thing is to print a string
representation of the arbitrary precision integer, and parse that to a
Python int. This adds the necessary C API and Python binding for a "to
string" method, and uses it in the attribute_to_var function.
There are smarter ways we can handle the conversion, but the "to
string" API seems generally useful, so I'm using that in the
conversion for now.
In some OM dialect constructs, it is possible to receive
EvaluatorValue::Reference values. In the Python bindings, where we are
converting an EvaluatorValue to a Python value, we need to dereference
the Reference, to get at the underlying EvaluatorValue that was set
during evaluation.
This adds the necessary C APIs, and updates the Python bindings to use
them. If we encounter a Reference, we dereference it and recursively
call the converter function.
A Python test was added using an example IR from the Evaluator unit
tests, which delays evaluation and introduces references.
Add the emit dialect to the C-API and to Python. This is both missing and
is necessary for downstream Python tooling to not break.
Signed-off-by: Schuyler Eldridge <schuyler.eldridge@sifive.com>
The previous fix in https://github.com/llvm/circt/pull/6572 did not
get to the root of the issue. In fact, it didn't even work around the
issue correctly, because the added DEPENDS was on the wrong
target. This attempts to remedy that by changing the DEPENDS to the
actual target that was missing before.
The real issue to this problem is in the CFToHandshake.h header, and
tracked here: https://github.com/llvm/circt/issues/6693.
When the conversion from FSM to SV was added to the CAPI, an include
of the circt/Conversion/Passes.h header was included for the pass
registration function. But nothing guarantees the generated header
that is included by Passes.h actually exists.
We have seen intermittent failures from it not existing, for example:
https://github.com/llvm/circt/actions/runs/7474242994/job/20339994666
This adds a DEPENDS on the target that generates the missing header,
so it will be available.
* Added missing tool in integration test
* Fixed formatting
* Fixed whitespace issue
* Fixed typo in VerilogGeneration.md
* Added skeleton for btor2 lowering pass
* added pattern match skeleton to lowering pass
* Added initial emission of inputs and hw::constant ops
* added constant emission
* added emission for most operations and final assertion
* Added support for muxes, assumptions and wire aliases
* Added support for inputs in btor2
* fixed bug in input generation
* added support for missing comb operations
* Changed input registration to allow for booleans
* Made input type check more robust
* WIP register state transition system generation
* Added support for registers
* refactored hardcoded string
* added names to btor2 states
* Added state initialization support
* Removed state initializer, it should be a firrtl construct and not a btor one
* Removed temporary file emission
* Added back accidentally removed btor2 string printing
* Ran clang-format
* Ran clang-format
* WIP refactored typeswitch
* refactored giant type switch
* Made all string litterals constexpr
* attempting to fix sanity check
* fixed variable name typo
* Attempting to satisfy clang-tidy
* renamed things to make clang happy
* inlined useless helper methods
* Clarified the necessity of important data structures in comments
* fixed formatting
* Changed pass into a Conversion pass
* refactored helper methods
* Checked for case where next is a port when emitted transitions
* Added newline at EOF
* Inherited visitors instead of using a big typeswitch
* Throw an error for unsupported ops and explicitly ignore the rest
* Removed unnecessary functions and refactored runOnOperation
* Fixed formatting
* Attempted to add some test
* Added in ops that weren't covered by visitors
* Added in missing declaration in header
* Included pass in CAPI CmakeLists
* Added infrastructure for btor integration tests
* Revert "Added infrastructure for btor integration tests"
This reverts commit a5ec3da4ec.
* various nitpicking comments accounted for
* used generalized ids for btor2 testcase
* fixed typo in test
* updated test and found small bug
* clang-format
* added support for arbitrary resets
* Updated test to reflect new handling of reset
* Switched to a DFS strategy for emission
* Updated test to align with preemission of register declarations
* Removed gratuitous lookups.
* inlined a bunch of string constatns
* removed certain silent fails and added out of order test
Move firtool pipeline configuration over to the same mechanism the rest of llvm and mlir use. Export this via the CAPI. Add a couple examples of methods to change options to the CAPI. Interested parties are encouraged to finish out the set of functions.
Since the CAPI has no tests, this breaks nothing.
As an aside, the configuration space of the firrtl pipeline is WAY too big.
This PR changes the HW StructExtract, StructInject, UnionCreate and UnionExtract ops to reference their accessed field by the respective aggregate type's field index instead of the field name. This allows us to access the field's FieldInfo struct directly instead of having to traverse the array to find the matching name.
In order to use the types in Python with isinstance, etc., we need to
provide the mlir_type_subclass bindings. This adds the C API
boilerplate and binds the types.
This turned out to be a bad idea. We're still using Cap'nProto for Cosim, just with the message being a blob which is already encoded by the client. This is nearly identical to what happens in hardware, just Cap'nProto/DPI as the transport layer.
Goodbye old frenemy.
This change adds evaluator support for frozen paths.
Two new EvaluatorValues have been added, one for BasePaths, which
represent fragments of paths through the instance hiearchy, and one for
Paths, which represent a full path to a hardware component.
When the evaluator instantiates an OM class, it is expected that it will
usually have to pass in an empty basepath, which signifies that the
class is at the top of the hierarchy. To facilitate this, we exposed the
ability to create an empty basepath value in the python API.
Path values can be transformed in to strings, where in they are printed
as FIRRTL style target paths. In the future, we may want a richer API.
Deleted paths are represented as Path values with the targetKind
attribute nulled out, which is handled specially in the string
serializer.
This PR does an overhaul of how path related operations work in the OM dialect.
When OM classes are created from FIRRTL, a base path is now fed through the
class hieararchy. All paths to hardware objects are now created relative to
the base path. The `path` op has been renamed to `path_create`, and now takes
a basepath SSA parameter, which means that it is impossible to create a path
which is not relative to some base.
A second set of operations to create "frozen paths" have been added. In
FreezePaths, we lower all path operations to hard-coded strings, which allows
us to remove the hardware from the OM IR and still be valid. These operations
have been changed to return `FrozenPathType`, which is to make sure that people
don't try to inter-mix the two kinds of path types. The intention is that the
evaluator will only understand frozen paths.
The PathAttr in OM no longer represents the entire target path, but just the
list of instances which lead up to it.
This also adds an OM utility for parsing FIRRTL style target strings, which is
used in the `frozenpath_create` MLIR assembly format. The existing APIs
contained in FIRRTL were not suitable since these new strings do not include
the circuit name, and we need some restrictions for parsing base paths, which
can not target components. The new parser is a bit more resilient to badly
formed path strings. In the future it may be possible to reunite these two
bodies of code.
The existing python support for paths had to be removed.
This commit adds support for graph regions for evaluator.
`ReferenceValue`, a new subclass of `EvaluatorValue`, is added to behave as pointers. `ReferenceValue` can be used as alias to different values and is created for `class.object.field` operation because `class.object.field` can access fields across class hierarchies and the fields might not be initilized yet. `RefenceValue` is not exposed to outside of evaluator implemenation. `EvaluatorValue::finalize` shrinks intermidiate `RefenceValue` in the evaluator value.
Evaluation algorithm is changed to worklist-based iteration. `instantiae` method first traverses the whole IR including sub-class, and create partially evaluaed values for all values and add these values to the worklist. After that we evaluate values until there is no partially evaluaed value.
Fix https://github.com/llvm/circt/issues/5834
Change the name of the constexpr `latestFIRVersion` to `exportFIRVersion`
as this is not the "latest" version, but the version that is used when
exporting FIRRTL. This will avoid confusion about what this is.
Make the `exportFIRVersion` the same as the `nextFIRVersion`.
Signed-off-by: Schuyler Eldridge <schuyler.eldridge@sifive.com>
Implement the proper `__hash__` and `__eq__` methods for Object, such that it
can be used in dictionaries. This is required to ensure we use mlir object
reference for equality and hashing, rather than the default methods provided
by python.
Hashable::
"In Python, a "hashable" object is an object that has a hash value that remains
constant throughout its lifetime and can be compared to other objects.
User-defined classes need to implement the `__hash__()` and `__eq__()` methods
to be hashable."
In the OM dialect, we want there to be "reference semantics". In other words,
two objects with identical classes and fields should not be "the same" if they
are created from separate instances in the elaborated object graph that the
Evaluator sees. In addition, due to presence of cyclic dependencies, value
equivalence cannot be determined and reference semantics is required.
Remove the now unused global reference operations and attributes. These
have been fully migrated to HierPathOp.
Signed-off-by: Schuyler Eldridge <schuyler.eldridge@sifive.com>
Since AppIDs serve as system identifiers, they classify as a system
construction feature. So they should be in the ESI dialect, which will
be using them shortly.
Discovering AppIDs used to be a pass and only worked on `msft.module`s. Since we're removing them, make AppID discovery an API which creates dynamic instances from AppIDs. Since it'll primarily be used from PyCDE, expose to Python. Test through Python.
Will remove the discover appid pass in a subsequent PR. Progress on #6109.
Implement the python bindings for the `om.integer` attribute. Add support to
create `om::IntegerAttr` from `mlir::IntegerAttr`. Also ensure all tests use
`om::IntegerAttr` instead of `mlir::IntegerAttr`.
`argNames` and `resultNames` attributes were removed from HWModule (https://github.com/llvm/circt/pull/6095) in the presence of ModuleType but downstream python tools are relying these attributes for name look up. However currently there is no CAPI/Python API for ModuleType to query names of ports so this PR adds CAPI and bindings respectively in the same way to port types.
Martin Erhart