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

no STMTDLY warning for always #1 -- blocks #22

Closed
veripoolbot opened this issue Jul 14, 2008 · 3 comments
Closed

no STMTDLY warning for always #1 -- blocks #22

veripoolbot opened this issue Jul 14, 2008 · 3 comments
Assignees
@wsnyder
Labels
resolution: wontfix Closed; work won't continue on an issue or pull request type: feature-IEEE Request to add new feature, described in IEEE 1800

Comments

@veripoolbot
Copy link
Contributor

Author Name: Holger Wächtler
Original Redmine Issue: 22 from https://www.veripool.org
Original Date: 2008-07-14
Original Assignee: Wilson Snyder (@wsnyder)

The STMTDLY warning is not necessairy for 'always # 1'-blocks:

/* verilator lint_off STMTDLY */
always # 1 begin
         clk = ~clk;
end

in both cases the inner block should get evaluated every simulation time step, Verilator does essentially the same as other simulators in this case.

So, could the warning for this construct get disabled? (as soon $fopen & Co. are working, this is the last show-stopper for portable testcases. Other simulators run into infinite loops when using 'always begin ... end' without '#1', which works fine in verilator).
@veripoolbot
Copy link
Contributor Author

Original Redmine Comment
Author Name: Wilson Snyder (@wsnyder)
Original Date: 2008-07-14T20:53:56Z

If you change the #{number} to something other than the number that you happen to increment simulation time by, you'll get different results between Verilator and other simulators, therefore I think it's worth a warning.

Most good code doesn't have any #delays; if you know the code has such things, why not just pass -Wno-STMTDLY?

@veripoolbot
Copy link
Contributor Author

Original Redmine Comment
Author Name: Holger Wächtler
Original Date: 2008-07-14T21:06:21Z

In this case (always-statement delay for one simulation time step) the warning makes no sense. in all other situations one wants to retain it, since simulation results may differ.

@veripoolbot
Copy link
Contributor Author

Original Redmine Comment
Author Name: Wilson Snyder (@wsnyder)
Original Date: 2008-07-14T21:14:28Z

#1 isn't one simulation time step, it's one time unit, they're different things. You're making an assumption about the upper level c file that you shouldn't, and can't be known to Verilator.

Besides, people that are silly enough to put #1 in a real design (versus your tests) will get burnt when they go above 1GHz, and are well deserving of a warning even if it were to simulate the same. (Again, It doesn't always - I can post an example if you want.)

@veripoolbot veripoolbot added resolution: wontfix Closed; work won't continue on an issue or pull request type: feature-IEEE Request to add new feature, described in IEEE 1800 labels Dec 22, 2019
@veripoolbot veripoolbot mentioned this issue Dec 22, 2019
Closed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees

@wsnyder wsnyder

Labels
resolution: wontfix Closed; work won't continue on an issue or pull request type: feature-IEEE Request to add new feature, described in IEEE 1800
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
2 participants
@wsnyder @veripoolbot