[FIRRTL] Add a new FIRRTL XMR Op

[prithayan]

This PR adds a new FIRRTL op for specifying a cross module reference, also known as an XMR. The XMR represents a non-local hierarchical name to a net. The hierarchical path is specified by a reference to the symbol defined by a HierPathOp. Only downward reference is allowed, hence the HierPathOp must be rooted at the module in which it is used. The verifier will fail, if the HierPathOp is not rooted at the current module. It is assumed that the result type of the XMROp matches with the result type of the remote net, but the op verifier doesn't check this property now. This will be lowered to the sv::XMROp. The use of this op was demonstrated in https://github.com/llvm/circt/pull/3290. This XMROp is intended to replace the GrandCentral generated XMR as VerbatimOp.

firrtl.hierpath @nla_1 [@XMRTop::@test,@Aardvark::@test_1, @Zebra::@w]
  firrtl.module @XMRTop() {
    firrtl.instance test  sym @test @Aardvark()
    %1 = firrtl.xmr @nla_1 : !firrtl.uint<3>
  }

  firrtl.module @Aardvark() {
    firrtl.instance test sym @test @Zebra()
    firrtl.instance test1 sym @test_1 @Zebra()
  }

  firrtl.module @Zebra() {
    %w = firrtl.wire sym @w : !firrtl.uint<3>
  }
}

[prithayan]

After a discussion with schuyler, the constraint of only a downward reference XMR is too strong, and cannot be used for the existing GrandCentral XMRs. Even the most common case is that, the root of the XMR is the parent of the module in which the XMR is instantiated. Verifying such a property, that the root of the XMR is some parent in the InstanceGraph can be quite expensive and not practical. So, the next step is to explore the current use cases and come up with a proposal for GrandCentral implementation with a more constrainted XMR, that can be practically verified.

[darthscsi]

Is this still relevant?

[prithayan]

No loner relevant. Closing.