[FIRRTL] Add a FIRRTL XMR Op

[prithayan]

This is a Draft PR, proposing a new XMROp and showing its sample usage.

1. Add a FIRRTL XMR Op that lowers to the SV XMR Op.
2. Update the SV XMR Op to align with the new usage.
3. Show how GrandCentralTaps can use this new Op for generating Taps, instead of VerbatimExpr.

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

1. How to merge HW::GlobalRefOp with this usage ?
2. How to generate the FIRRTL::XMROp directly during annotation lowering ?
3. 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.

[seldridge]

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!).

[sequencer]

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.

[seldridge]

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.

[darthscsi]

Is this still relevant?

[prithayan]

No longer relevant. Closing this.