![[logo]](/img/veripool_small.gif)
Issue #22
no STMTDLY warning for always #1 -- blocks
| Status : | Rejected | Start : | 07/14/2008 | |
| Priority : | Normal | Due date : | ||
| Assigned to : | Wilson Snyder | % Done : | 0% |
|
| Category : | Unsupported | |||
| Target version : | - | |||
Description
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).
History
07/14/2008 08:53 PM - Wilson Snyder
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?
07/14/2008 09:06 PM - Holger Wächtler
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.
07/14/2008 09:14 PM - Wilson Snyder
- Category set to Unsupported
- Status changed from New to Rejected
- Assigned to set to Wilson Snyder
#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.)