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

Sensitivity lists with boolean expressions #1425

Closed
veripoolbot opened this issue May 1, 2019 · 1 comment
Closed

Sensitivity lists with boolean expressions #1425

veripoolbot opened this issue May 1, 2019 · 1 comment
Labels
resolution: wontfix Closed; work won't continue on an issue or pull request

Comments

@veripoolbot
Copy link
Contributor


Author Name: Al Grant
Original Redmine Issue: 1425 from https://www.veripool.org


Items in sensitivity lists can be expressions:

always @(&vec) ..

This is legal, as long as you remember that "always @(a|b)" isn't the same as "always @(a or b)".

This came up before in Bug #934 but was not resolved. It sounded like this would need deep changes to Verilator. But would it not be possible to do it by a simple transformation? I.e. any time you see

always @(expr1 or ...) ..

and an expression is not simple, just introduce an assign:

assign tmp1234 = expr1;
always @(tmp1234 ...)

This is exactly the transformation you would do at the source level if working around this Verilator limitation. So there would be no impact on Verilator's simulation engine. Unless I'm missing something?

@veripoolbot
Copy link
Contributor Author


Original Redmine Comment
Author Name: Wilson Snyder (@wsnyder)
Original Date: 2019-05-01T22:32:34Z


Verilator doesn't really do anything with sensitivity lists except posedge/negedge handling; it basically is following synthesis rules, not event simulator rules. If you add the wire as you suggest it will act just as if it's in an "always @*", which is unlikely to be what you want.

@veripoolbot veripoolbot added the resolution: wontfix Closed; work won't continue on an issue or pull request label Dec 22, 2019
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
resolution: wontfix Closed; work won't continue on an issue or pull request
Projects
None yet
Development

No branches or pull requests

1 participant