-
Notifications
You must be signed in to change notification settings - Fork 299
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[FIRRTL] Analog Module Connection Generates Unnecessary Alias/Assign #4112
Comments
What's the status of this issue? Is this potentially going to be worked on sometime in the future? |
This isn't currently prioritized. There's currently special casing inside the Do you all have any bandwidth to help out? |
Unfortunately not at the moment. Do you expect the work to be hard (any estimates of effort v.s. time)(subjectively, how hard is the ramp-up time to learn CIRCT FIRTOOL internals)? |
I looked at this before and it's a tiny bit tedious, but not bad. The place where this should get handled is in the Generally, ramping up on CIRCT internals is not bad, especially if you're doing something compartmentalized, e.g., modifications to an existing pass up to writing a single pass. Anything more broad reaching requires more context. Having C++ experience helps, though LLVM/MLIR/CIRCT development is closer to "C++ on rails". You are heavily following LLVM coding conventions (e.g., resource-allocation-is-initialization (RAII) is used everywhere / you will almost never manually heap allocate something), you use LLVM internal libraries in place of normal ones ( |
Just looked into this a bit, and it looks like the function that's generating this circuit Foo:
extmodule Bar:
output a: Analog<1>
extmodule Baz:
input a: Analog<1>
module Foo:
output a: Analog<1>
inst bar of Bar
inst baz of Baz
attach(baz.a, bar.a)
attach(a, bar.a) Produces module Foo(
inout a);
Bar bar (
.a (a)
);
Baz baz (
.a (a)
);
endmodule But once the analog signal is an internal-only wire, then we fall through to the I've got a question about that function: what are the cases where we want that auto v0 = inoutValues.front();
for (auto v : inoutValues) {
if (v == v0) {
continue;
}
v.replaceAllUsesWith(v0);
} I'm quite early in my writing-code-for-CIRCT education, so I recognize I might be way off-base on this solution. Also, if it's easier to discuss there, I'm on the LLVM discord (tynan-nb#2561). Thanks for any feedback! |
We want to only generate the
Anything else is okay. If it is a u-turn from an instance port to one or more other instance ports, then that's just a dummy wire. If this is used by exactly one module port, then the module port name is used instead of the dummy wire. |
Understood, and I see the SFC emits the same code in that case. Is this more what you had in mind? // If all operands of the attach are internal to this module (none of them
// are ports), then they can all be replaced with a single wire, and we can
// delete the attach op.
bool isAttachInternalOnly = true;
for (auto v : inoutValues) {
if (isa<BlockArgument>(v)) {
isAttachInternalOnly = false;
break;
}
}
if (isAttachInternalOnly) {
auto v0 = inoutValues.front();
for (auto v : inoutValues) {
if (v == v0) {
continue;
}
v.replaceAllUsesWith(v0);
}
return success();
}
// If the attach operands contain a port, then we can't do anything to
// simplify the attach operation.
addToIfDefBlock(
... |
The following circuit generates an alias/attach for an analog connection from an instance to another instance. However, anytime we can avoid generating an alias/attach means that more tools will accept it. This should just generate a wire.
This produces with the MFC:
SFC produces:
The text was updated successfully, but these errors were encountered: