Derive abstract cells in top module during hierarchy #4930
+29
−0
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
What are the reasons/motivation for this change?
Previously if hierarchy had a top module then it would not derive any other abstract cells, this means that
-check
could miss certain kinds of errors that it would normally detect, such as in #4927.Explain how this is achieved.
After finding (and potentially deriving)
top_mod
, find all of the cells included and derive them as well; similarly to how if there is no top module then all abstract modules are derived. I'm just now realising this only works for one level of abstract cells, which means we probably need some kind of recursive approach instead so I'm leaving this as draft for now. Also because it breaks underconnect_rpc
.If applicable, please suggest to reviewers how they can test the change.
Includes
tests/various/hierarchy_reassign_localparam.ys
which fails under previous versions (instead giving the less helpfulERROR: Module name in defparam contains non-constant expressions!
), but works when not usingread_verilog
without-defer
, and/or when usinghierarchy -check
without-top
.