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
Support bind statements within generate blocks #1501
Comments
Original Redmine Comment Thanks for the test. This is a bug due to Bind being expanded up front before parameters are resolved. Note to self/fixer: there's a minor complication in fixing this in that Verilator currently computes the possible hierarchy before parameter resolution, probably the bind needs to be considered then backed out if parameters rip it out; similar to AstNotFoundModule's. |
Original Redmine Comment Haven't forgotten about this. Got the exact case provided working, but based on where in the tree the bind is there's other problems, and unfortunately can't yet detect when it goes wrong to throw an unsupported error. |
Original Redmine Comment Thanks!! It's not a show-stopper for us. Our workaround for anyone watching is to clock-gate based on the bind parameter.
|
We ran into this bug again recently. Because this was filed with the old bug tracker, I don't see the test case. Would it help to provide one again? |
I have the test case - if you or someone would like to take the patch as far as it got, debug and provide a pull request that would be the next steps. |
Hi @wsnyder, could you post the testcase and a link to the WIP patch on this issue? Not sure if we’ll be able to take a look for a bit, but it would help! |
Author Name: Dan Petrisko (@dpetrisko)
Original Redmine Issue: 1501 from https://www.veripool.org
A bind statement within a generate if, if the generate if evaluates to false, should not bind.
I've attached a complete testcase. If you set do_bind to 1, the module is bound. If you set do_bind to 0, the module is still bound! The code works as expected in Synopsys VCS.
Tested on Verilator 4.017 devel rev UNKNOWN_REV on CENTOS 7
The text was updated successfully, but these errors were encountered: