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] Allow non-public modules to dedup with public modules #7875

Closed
seldridge opened this issue Nov 22, 2024 · 1 comment
Closed

[FIRRTL] Allow non-public modules to dedup with public modules #7875

seldridge opened this issue Nov 22, 2024 · 1 comment
Labels
enhancement New feature or request FIRRTL Involving the `firrtl` dialect

Comments

@seldridge
Copy link
Member

seldridge commented Nov 22, 2024

The FIRRTL spec allows for an amount of wiggle room on what can be done with deduplication and public modules. Currently, we don't do something as aggressive as we could. Consider the following:

FIRRTL version 4.0.0
circuit Foo:
  module A:
  module B:
  module C:
  public module D:
  public module Foo:
    inst a of A
    inst b of B
    inst c of C
    inst d of D

Currently, only modules A, B, and C dedup. However, it is legal to have these dedup with D.

Modify the dedup pass to dedup A, B, and C into D. In the final Verilog, there should only be two modules.

You can make a call and do anything legal if there are multiple possible dedup targets. E.g., if there is public module D and public module E. This should incorporate the must dedup annotations to do what they say.

@seldridge seldridge added FIRRTL Involving the `firrtl` dialect enhancement New feature or request labels Nov 22, 2024
@youngar
Copy link
Member

youngar commented Nov 27, 2024

The linked PR added the ability to deduplicate a private module in to a public module, but it did not make the change to take in to account the MustDedup annotation when deciding which public module to dedup with. Right now MustDedup is only used to check the results of Dedup were what we were expecting, and using it to inform the deduplication procedure would be a larger change. I think we can close this issue because we don't have any plans on implementing this behaviour, but we can re-open it if we decide to go this route.

@youngar youngar closed this as completed Nov 27, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request FIRRTL Involving the `firrtl` dialect
Projects
None yet
Development

No branches or pull requests

2 participants