[core] Add Wire association support#5251
Conversation
80e2e87 to
4b1cd61
Compare
Extend the current `associate` API to also allow specifying domain
associations on wires. This is necessary for certain libraries that
eschew the existence of ports and use wires everywhere (e.g., diplomacy).
This introduces new FIRRTL syntax like the following to represent this:
wire w: UInt<1> domains [A, B]
This syntax is not currently supported, but an outstanding PR adds support
for it [[1]]. In the interim, this commit includes an XFAIL test that
will start passing once CIRCT support lands.
[1]: llvm/circt#10065
AI-assisted-by: pi.dev (Qwen 3.5)
AI-assisted-by: Claude Code (Claude Sonnet 4.6, Claude Haiku 4.5)
Signed-off-by: Schuyler Eldridge <schuyler.eldridge@sifive.com>
4b1cd61 to
671da0e
Compare
| } | ||
|
|
||
| /** Associate a port or wire of this module with one or more domains. */ | ||
| final def associate(data: Data, domains: domain.Type*)(implicit si: SourceInfo): Unit = { |
There was a problem hiding this comment.
I think changing the name of this argument is right, but note that it is technically a source-incompatible change (since one can use argument names when calling functions). I'm not going to block it here but we should be careful with this generally.
There was a problem hiding this comment.
Do we have any guidance / policy around this?
Generally, source incompatible seems less bad as at least the compilation will error.
Is there a way to do this that wouldn't break source compatibility without going through a multi-stage deprecation process? I.e., I don't think we can have a duplicate definition with the same type signature.
There was a problem hiding this comment.
Generally, source incompatible seems less bad as at least the compilation will error.
I agree they're less bad but still something to avoid, especially on minor versions. This API is new (and in flux generally) enough that I think it's fine but if someone were to try changing the name of the argument to RegNext I would say no.
Is there a way to do this that wouldn't break source compatibility without going through a multi-stage deprecation process? I.e., I don't think we can have a duplicate definition with the same type signature.
You can two-step it with @deprecatedName. Again not necessary here.
Signed-off-by: Schuyler Eldridge <schuyler.eldridge@sifive.com>
Signed-off-by: Schuyler Eldridge <schuyler.eldridge@sifive.com>
Extend the current
associateAPI to also allow specifying domain associations on wires. This is necessary for certain libraries that eschew the existence of ports and use wires everywhere (e.g., diplomacy).This introduces new FIRRTL syntax like the following to represent this:
This syntax is not currently supported, but an outstanding PR adds support for it [1]. In the interim, this commit includes an XFAIL test that will start passing once CIRCT support lands.
AI-assisted-by: pi.dev (Qwen 3.5)
AI-assisted-by: Claude Code (Claude Sonnet 4.6, Claude Haiku 4.5)
Release Notes
Extend
associateAPI to allow adding domain associations to wires.