circt
circt copied to clipboard
[FIRRTL] Add a new FIRRTL XMR Op
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>
}
}
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.
Is this still relevant?
No loner relevant. Closing.