![[logo]](/img/veripool_small.png)
Issue #46
signal not generated in state machine
| Status: | Closed | Start date: | 12/27/2008 | |
|---|---|---|---|---|
| Priority: | Normal | Due date: | ||
| Assignee: | Wilson Snyder | % Done: | 0% |
|
| Category: | WrongRuntimeResult | |||
| Target version: | - | Estimated time: | 3.00 hours |
Description
The attached code demonstrates a problem with state machines using Verilator 3.681.
After the strobe "myevent", the signal "myevent_pending" should go high for at least one clock cycle, after which STATE_ONE should be entered. The code in tb1.v should have this behavior but it does not -- STATE_ONE is entered immediately after the strobe "myevent". The work around in tb2.v does not have this problem.
To demonstrate:
make -f tb1.mk
obj_dir/Vtb
-- examine "myevent_pending"
make -f tb2.mk
obj_dir/Vtb
-- examine "myevent_pending"
History
Updated by Wilson Snyder over 3 years ago
- Category set to WrongRuntimeResult
- Status changed from New to Closed
- Assignee set to Wilson Snyder
- Estimated time set to 3.00
Thanks for the good testcase; one thing that confused me up front was your second example shouldn't have the same behavior as the first; the always block you added should have instead used "if (state==STATE_ZERO && myevent_pending)" to match the cycle-by-cycle behavior of example 1. It would probably help next time to use the t/t_EXAMPLE base that is described in the manual as then it could be insured the outputs would be the same with both cases.
Anyhow the bug was a problem in the table optimizer which converts FSM, ROMs and case statements into lookup tables, caused by reading a variable that was just delayed assigned to above.
You can work around it by using "-Oa", for only a small performance loss unless you have a lot of ROMs.
This is in git and will be in the next release in a few weeks. I can post a patch if you wish.
Also available in: Atom