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
Properly specify and reimplement opt_clean/clean #2165
Comments
Some elements that come to mind:
|
This would very much help CXXRTL! |
See #2003 and #2076 (comment) -- the latter a case where private wires with |
I don't think that a wire without For single bit wires:
In some cases there's a "race between" 2. and 3., depending of if we first const fold the driver or first optimize away the user we may or may not keep the wire. I don't quite know if there's a good way to resolve that. For multi-bit wires: For SBY / |
Would it be? The reason I want that in synthesis flows as well is so that I can insert scan cells and have the retrieved data mapped back to all levels of hierarchy in a flattened design, not just to one (random, or topmost) level. |
I'm fairly sure we should just have flags that let you specify the behavior you need in a certain situation, as clearly the objectives are contradictory depending on how you intend to use the design. The more interesting question is how granular they should be. Can you think of a use case where it is critical that you do keep wires driven by constants but do not keep other public wires? For maximum flexibility we could of course just have separate arguments for every decision, |
Discussed this with @mwkmwkmwk and we came up with the following proposal: Expected behavior:
Options:
Behavior changes vs. current:
Other points:
Larger discussions that reach beyond opt_clean:
|
Two additions from @clairexen:
|
The behavior of
opt_clean
is frequently adjusted to fix some issues, which then causes other issues, etc. In the latest iteration, unused wires with public names are now retained, but their driving circuit is removed, which leads to wrong behavior displayed in traces.@clairexen suggested that we need to write an actual specification of what
opt_clean
is supposed to do, and then write a new implementation that complies with that specification.The text was updated successfully, but these errors were encountered: