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

Jump to bottom

Support bind statements within generate blocks #1501

Open
veripoolbot opened this issue Sep 6, 2019 · 6 comments
Open

Support bind statements within generate blocks #1501

veripoolbot opened this issue Sep 6, 2019 · 6 comments
Labels
area: elaboration Issue involves elaboration phase effort: days Expect this issue to require roughly days of invested effort to resolve type: feature-IEEE Request to add new feature, described in IEEE 1800

Comments

@veripoolbot
Copy link
Contributor

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.

// Should not bind
localparam do_bind  = 0;
if (do_bind)
  bind ....

// Should bind
localparam do_bind  = 1;
if (do_bind)
  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
@veripoolbot
Copy link
Contributor Author

Original Redmine Comment
Author Name: Wilson Snyder (@wsnyder)
Original Date: 2019-09-06T11:10:43Z

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.

@veripoolbot
Copy link
Contributor Author

Original Redmine Comment
Author Name: Wilson Snyder (@wsnyder)
Original Date: 2019-10-02T01:59:58Z

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.

@veripoolbot
Copy link
Contributor Author

Original Redmine Comment
Author Name: Dan Petrisko (@dpetrisko)
Original Date: 2019-10-02T02:04:07Z

Thanks!! It's not a show-stopper for us. Our workaround for anyone watching is to clock-gate based on the bind parameter.

localparam do_bind  = 0;
if (do_bind)
  foo (.clk_i(clk_i & do_bind));

@veripoolbot veripoolbot added area: elaboration Issue involves elaboration phase effort: days Expect this issue to require roughly days of invested effort to resolve type: feature-IEEE Request to add new feature, described in IEEE 1800 labels Dec 22, 2019
@dpetrisko dpetrisko mentioned this issue Mar 28, 2022
Open
@drichmond drichmond mentioned this issue Mar 28, 2022
Merged
@drichmond
Copy link

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?

@wsnyder
Copy link
Member

wsnyder commented Apr 9, 2022

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.

@dpetrisko
Copy link
Contributor

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!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
area: elaboration Issue involves elaboration phase effort: days Expect this issue to require roughly days of invested effort to resolve type: feature-IEEE Request to add new feature, described in IEEE 1800
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
4 participants
@wsnyder @dpetrisko @drichmond @veripoolbot