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.
Now that the Python bindings for ClassType can return a Python object
of the actual ClassType Python class, it would be useful to get the
ClassType's name from such an object. This includes the usual C API
boilerplate to call the accessor in C++, and the usual Python wrapper
to return a string through pybind.
A relatively new feature of MLIR Python bindings allows returned
MlirTypes to automatically be downcast to the actual concrete Python
class for the type. To enable this, a C API to get the type's TypeID
must be provided, and the rest just works. Opt-in for the OM dialect's
ClassType.
This PR add Evaluator support for Map values.
* EvaluatorValue now takes a MLIR context as a member to make it easy to
construct attributes from evaluated values.
* MapValue is added and created from om.map_create.
* CAPIs for MapType and StringType are added.
`llvm_unreachable()` only tells the compiler to assume that can't happen
(in release builds w/default build options), so this doesn't help anyway.
cc #3836.
This is a PR for new representation of Evaluator and list_create support.
`std::variant` has been used as runtime representation of Evaluator but it's difficult to use it as
data structure for more structured values such as list or map. So this PR instead introduces a base class `EvaluatorValue ` and derived classes, `AttributeValue`, `ListValue` and `ObjectValue`, as runtime representation of values.
Also terminology `ObjectValue` is changed to `EvaluatorValue` since runtime values will not be limited to Object.
Python and C bindings are changed accordingly.
This functionality was used primarily wrap handshake modules. Now that
handshake uses ESI channels it's no longer necessary. I don't think
there are any other users.
These binding are very shallow and only support the use case of a single
InnerSymProperties with a fieldID of 0. Current use cases only require this
limited functionality, and in the future we will probably be changing the
underlying attributes, so it doesn't make sense to expose it all now.
Change the FIRRTL emitter to use v3.0.0 of the FIRRTL specification.
Logic for emitting an older version of the spec is still preserved. There
is no option for choosing the spec version from the command line right
now.
Signed-off-by: Schuyler Eldridge <schuyler.eldridge@sifive.com>
This adds custom CAPI wrap and unwrap functionality for Object to
better align with the std::shared_ptr functionality. Object now
enables the shared_from_this functionality, which allows the unwrap
function to more seamlessly create shared pointers to the Object with
the appropriate reference count. Similarly, the wrap functionality is
updated to always allocate new shared pointers, to ensure reference
counts are incremented appropriately. This was done at the instantiate
API previously, but is now handled generically whenever an Object is
wrapped.
These changes are required to avoid double frees of Objects in
general. A test case has been added that demonstrated the faulty
behavior, which now succeeds.
This adds two APIs to the OM dialect, for querying if a Type is a
ClassType and for getting the ClassType from an Object. These simply
wrap the existing C++ functionality directly. A small test is added to
ensure they work as expected.
This adds the usual CAPI structure and dialect registration
boilerplate, as well as CAPIs around the Evaluator library.
The APIs are intended to be as minimal and straightforward as
possible, simply wrapping and unwrapping the C++ structures when
possible.
One slight divergence is in the ObjectValue type, which is a
std::variant between an Object shared pointer or an Attribute. The
normal approach of casting to and from a void pointer does not work
with std::variant, so a different representation of ObjectValue is
used instead. The discriminated union is simply represented as a
struct which only over has one field set. It might be possible to save
some space using a struct with a C union and a flag, but the
simplicity of the current approach seemed reasonable.
Another minor detail worth mentioning is that we must take some care
to ensure the shared pointers to Objects have their reference count
kept up to date. In the CAPI for the instantiate method, if we simply
return the shared pointer, the reference will be lost as the Object
pointer travels to C as a void pointer, so we allocate a new shared
pointer in the CAPI, which ensures the reference count accurately
reflect that we have handed out another reference.
* [SV] Move emitAsComment to SVAttributeAttr; remove SVAttributesAttr
Move the `emitAsComments` flag from `SVAttributesAttr` (plural) to
`SVAttributeAttr` (singular). Then remove `SVAttributesAttr` (plural)
since it only contains a single array field after `emitAsComments` is
gone.
Add add, remove, and read-modify-write functions to deal with SV
attributes on operations more conveniently. Also enforce deduplicated
SV attributes where easily possible. The new functions now allow for
easy addition and removal of individual SV attributes.
Adapt ExportVerilog to handle the fact that emission as comments is now
a per-attribute option. The emission code now can emit multiple
`/*...*/` and `(*...*)` groups if needed, but tries to pack as many
consecutive attributes with the same `emitAsComment` flag into one
group.
* [ExportVerilog] PP-ify SV attribute emission.
* Test pretty-printing of SV attributes on statements.
* Tweak whitespaces between SV attributes
---------
Co-authored-by: Will Dietz <will.dietz@sifive.com>
* LLVM.h: drop mlir::Optional.
It's an alias for std::optional now, just drop
instead of adding the templated using alias here as well
(which we'd have to remember to drop).
* Convert Optional -> std::optional.
Drop some unnecessary initializations, but keep them for fields for now.
Particularly:
StandardToHandshake.h: keep init for field, for omission in {} initializers.
FSMToSV: similarly keep the current initialization.
Motivation:
1. This file is nearing 2000 LOC. I personally find that having a single file per pass helps in quickly navigating to/between implementations of different passes. Bunching everything into one file makes locating things just a bit harder.
2. This is the style used in the remainder of CIRCT.
3. Uses canonical CMake structure for declaring passes.
* Bump LLVM
Bump LLVM to the current top-of-tree.
This requires changing a few `Attribute`s to the new `TypedAttr`
interface, since attributes no longer carry a type by default. We rely
on this type in quite a few places in the CIRCT codebase, which required
a switch over to `TypedAttr`.
See: https://reviews.llvm.org/D130092
Co-authored-by: John Demme <john.demme@microsoft.com>
Enables writing service generators in Python. Also switches to
string-base 'impl_types' (from Attributes) since Attributes are tied to
a context whereas Passes are not. Simplifies things by not having to
create a registry for each context.
This PR adds a `emitAsComments` field to SV attributes.
Unfortunately, some of vendor specific pragmas are not strictly
valid SV attributes. For example, (* cadence map_to_mux *) is not valid
SV attribute hence vendor compilers recognize comments as some sort of
attributes. From that reason, this commit provides fine-grained control of
emission style to users.
```
%0 = sv.wire {sv.attributes = #sv.attributes<[#sv.attribute<"foo bar">], emitAsComments>} : i1
```
should be emitted as
```
/* foo bar */
wire GEN;
```
`PassCommon` contains `getAndSortModules`, which is generally useful. Make it general by implementing `HWModuleLike` and `HWInstanceLike` and targeting those OpInterfaces instead. Involves a bit of ugliness when converting to/from the OpInterfaces to concrete module ops, but hopefully that'll go away as we add more functionality to said OpInterfaces.
An 'AppID' is intended to make browsing the instance hierarchy easier.
Instead of having to reason about instance names, users can specify an
'AppID' consisting of a (name, index) pair and browse the hierarchy that
way. Said browsing also looks through the instance hierarchy (with
several rules about transparency) to mask implementation details at
various levels of the hierarchy.
This commit adds an `AppID` attribute and exposes it through Python.
This is an initial commit for adding a CAPI for FSM as well as PyCDE support for constructing these.
See `test_fsm.py` for usage.
FSMs are constructed in a similar manner to PyCDE modules through a decorator on a class describing the FSM.
The FSM class may contain inputs (no outputs for now) and must provide
- A dictionary containing the states and their transitions
- A default state
State transitions may be either always taken, or taken based on some guard. This guard is defined by a function provided to the transition, which (like `@generator` functions) acts on the ports of the FSM.
The FSM will then be constructed with an output for each state, asserted when that state is active.
One important implementation note is the fact that the `fsm.machine` operation is treated as a PyCDE Module - there was surprisingly little friction slotting it into the current code and everything works as expected wrt. referencing `fsm.machine` in/out arguments through the transition guard functions.
However, modules instantiating the FSM expect a hardware-like interface, this being the ports of the `fsm.machine` operation + clock and reset signals. An `fsm.machine` op does not have these signals at the top level, since these are added during hardware lowering. To me, this is a sensible design choice, seeing that the FSM dialect should be applicable to both software and hardware representations (...eventually).
To get around this, the user will specify the intended name of the `clock` and optional `reset` signal of an FSM. A wrapper module is then created that provides the correct interface to the instantiating module, as well as instantiating the FSM through a `fsm.hw_instance` operation, doing the proper hoop-jumping to attach the clock signal (see `fsm_wrapper_class`).
There's still some work to do on the CIRCT side of the FSM dialect to clean it up a bit + make it a viable target for a front-end, but this commit represents the brunt of work on the PyCDE side.
Lots of boilerplate which should _really_ be autogenerated. Added support for SystemVerilog attributes to the python bindings for the SV and Seq dialects.
Moved the definiton of `Seq` passes to a separate `SeqPasses.h`, similarly to other dialects.
Exposed the `createSeqLowerToSV` function to be used by other clients.
To simplify the ownership model, MLIR core python bindings don't support
building a block before the operation. So we build a dummy operation
first, build the block, construct the array, move the block, then delete
the dummy op. The core MLIR C API doesn't have a region editing API, so
we need to add a specialized one in the MSFT C API.
A first step to have proper support of the Moore types in the C API. This focusses on the functions to create types and some SBV type functions needed to support the already existing moore operations in the external moore frontend compiler.
Since we are generating only pieces of a design (and FPGA resources are
obviously a property of the entire design), the devdb should be
independent of the 'top' module.
Also, since the devdb is supposed to act as an 'alternative view' of the
IR, load the IR's placements by default.
- Use the new dynamic instance op and its children to simplify the PlacementDB.
- Switch to new paradigm wherein all placements are done through the device db and get reflected in the IR. So for the life of PlacementDB, it "owns" all the placements.
- Rename "PhysicalRegionOp" to "DeclPhysicalRegionOp" to be more
descriptive of what it does.
- Rename "PhysLocationOp" to be more consistent with asm name.
- Add "PDPhysRegionOp" to eliminate random attribute from globalRef.
- Ditch old ref attribute since it's no longer necessary.
Keep the PhysLocation attribute for the actual physical location. Create
an op to refer to a global ref with the location attribute and the
subpath. Incremental change towards a new approach to dynamic instances.
This PR breaks tcl placement output in the way the integration test and pycde
enters the placements. Will be fixed shortly with the dynamic instance PR.
These complement the main add* APIs for putting entities into the
database and support moving entities around or removing entities
entirely after any initial placements.
This allows the user to specify a walk order through the placements'
columns and rows. If specified, the order is used to sort the indices
into the placements' maps. Else, the order is undefined as before.
Previously, a sub-path could be specified by encoding it in the name
of the attribute using a certain scheme. This is brittle and
non-standard. To make this more natural and robust, the sub-path is
added as a field of the attribute definition as a StringRef. It is not
required, in which case an empty StringRef can be used. The attribute
name for placement attributes is no longer used in any logic.
This refactors ExportQuartusTcl to use the hw::GlobalRefs and arrays
of hw::InnerRefAttrs directly. This greatly simplifies the
implementation, and removes the need for SwitchInstanceAttr. That
attribute will be fully removed in a follow up.
* [HW] Use StringAttr instead of StringRef in FieldInfo, nfc
This commit changes to use use StringAttr instead of StringRef
in FieldInfo to avoid unnecessary copies of field names.
Changes are mainly about parser/printer and CAPI.
This commit also changes Struct/UnionTypeImpl to use ArrayRefParameter
instead of ArrayRefOfSelfAllocationParameter in their tablegen
definition. And this deletes unnecessary allocators too.
This add the necessary Python binding boilerplate to create
PhysicalBounds and PhysicalRegionRef attributes. A new API is added to
System, which inserts a PhysicalRegion. A wrapper class for
PhysicalRegion allows creating a region, adding bounds, and getting a
reference attribute suitable for use with the add_attribute API.
This is the preferred way to output design collatoral. Closes
https://github.com/llvm/circt/issues/2068.
The ExportQuartusTcl pass is removed, and the functionality is moved
into LowerMSFTToHW. The pass now populates a SymbolCache of the things
we care about in the export, namely instances. It produces verbatim
ops containing the Tcl, which can then be emitted from ExportVerilog.
The old Python API to run the export is removed in favor of the new
approach. PyCDE now exports both System Verilog and Tcl using the
exportSplitVerilog API to output files into a directory.
This keeps the existing functionality based on attributes, and exports
to llvm::outs as part of the pass, in order to keep the existing
tests. Further changes based on the approach in #2068 will follow.
With the new CMake functionality upstream, we need to set the
ENABLE_AGGREGATION option when we call add_mlir_library. The easiest
way to do this is to just rely on the upstream helper
add_mlir_public_c_api_library, which does this and other important
settings for us.
Also, ensure the MSFT dialect's CAPI marks all of the public functions
as being exported.
No functional changes. This PR simply renames DeviceDB to PlacementDB within the MSFT dialect. The "DeviceDB" name may be used in a future PR and live alongside the PlacementDB.
We've switched to Python-based generators. Ping-ponging between IR modifying
C++ and IR modifying Python was a massive mistake for pointer safety reasons.
Mike Urbach