circt
circt copied to clipboard
[FIRRTL] Add a FIRRTL XMR Op
This is a Draft PR, proposing a new XMROp
and showing its sample usage.
- Add a FIRRTL XMR Op that lowers to the SV XMR Op.
- Update the SV XMR Op to align with the new usage.
- Show how
GrandCentralTaps
can use this new Op for generating Taps, instead ofVerbatimExpr
.
This op is developed based on the proposal to update HierPathOp
to end on a module (https://github.com/llvm/circt/pull/3250).
If HierPathOp
can only be used to specify hierarchichal paths that end on a module, then the FIRRTL::XMROp
can be used to specify a component inside the path specified by HierPathOp
.
For example, firrtl.hierpath @nla_0 [@Top::@foo, @Foo]
specifies the path, and
the XMROp
%1 = firrtl.xmr @nla_0 <@Foo::@f> : !firrtl.uint<1>
uses the InnerRefAttr
to specify the component @f
in the module @Foo
.
We need a different firrtl::XMROp
since the sv::XMROp
has an InOutType
.
Other followup tasks
- How to merge
HW::GlobalRefOp
with this usage ? - How to generate the
FIRRTL::XMROp
directly during annotation lowering ? - Expose the IMCP to the
XMROp
.
The tests will fail, since this is based on the assumption that HierPathOp
ends on a module, which is not yet merged.
This is coming together nicely. It is worthwhile to think about what the semantics of this op should be for FIRRTL. I'm of the opinion that a valid FIRRTL XMR is a downward reference only and must be rooted at the module in which it is used. This is strictly weaker than SV XMRs, but also avoids some problems: the XMR can always be verified (which is not the case for upwards references) and there is no ambiguity around multiple instantiations of a specific XMR path.
For Grand Central passes I anticipate we can actually use this in LowerAnnotations directly and kill a bunch of logic in the GCT passes. I further expect that this will become the new BoringUtils-like API once we enable lowering of specific XMRs to ports.
Any GCT changes should come out into a separate PR (but thank you for showing the demo with this!).
I have a small question to this: would it be possible to directly add the XMROp to HWDialect
, and applies to HWModuleLike
and HWInstanceLike
API, then we can use the XMR API for most of hardware dialect.
Should there be a corresponding change to firrtl spec for this?
Eventually, yes. This PR is, right now, just for CIRCT-internal usage to better model XMR concepts which are currently living in annotations. However, we can use this to guide a spec-XMR which would eventually unify with this.
Is this still relevant?
No longer relevant. Closing this.