Skip to content
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][IMCP] Overdefine ports of modules with unknown symbol uses #8115

Merged
merged 1 commit into from
Jan 25, 2025

Conversation

fabianschuiki
Copy link
Contributor

If a module is referenced from an unknown top-level operation, i.e. an operation that is not an hw.hierpath, mark the module's inputs as overdefined. IMCP cannot reason about how the module is used by such an unknown operation, and therefore should assume that the operation might instantiate the module and apply arbitrary values to its input.

As an example, the firrtl.formal operation may refer to a private module as to be executed as a formal test, applying symbolic values to the module's inputs. While IMCP could simply special-case the firrtl.formal operation, it feels cleaner to make the pass defensive in the presence of any operation which it does not explicitly know how to deal with.

@fabianschuiki fabianschuiki added bug Something isn't working FIRRTL Involving the `firrtl` dialect labels Jan 23, 2025
@fabianschuiki fabianschuiki requested a review from youngar January 23, 2025 04:13
@fabianschuiki fabianschuiki requested a review from uenoku January 23, 2025 18:12
If a module is referenced from an unknown top-level operation, i.e. an
operation that is not an `hw.hierpath`, mark the module's inputs as
overdefined. IMCP cannot reason about how the module is used by such an
unknown operation, and therefore should assume that the operation might
instantiate the module and apply arbitrary values to its input.

As an example, the `firrtl.formal` operation may refer to a private
module as to be executed as a formal test, applying symbolic values to
the module's inputs. While IMCP could simply special-case the
`firrtl.formal` operation, it feels cleaner to make the pass defensive
in the presence of _any_ operation which it does not explicitly know how
to deal with.
@fabianschuiki fabianschuiki force-pushed the fschuiki/firrtl-imcp-overdefine-unknown-uses branch from 80cd198 to 54dc372 Compare January 25, 2025 01:10
@fabianschuiki
Copy link
Contributor Author

Landing this since Windows build failure is related to 26d80cf.

@fabianschuiki fabianschuiki merged commit 6a54406 into main Jan 25, 2025
4 of 5 checks passed
@fabianschuiki fabianschuiki deleted the fschuiki/firrtl-imcp-overdefine-unknown-uses branch January 25, 2025 01:49
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Something isn't working FIRRTL Involving the `firrtl` dialect
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants