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

signal not generated in state machine #46

Closed
veripoolbot opened this issue Dec 27, 2008 · 1 comment
Closed

signal not generated in state machine #46

veripoolbot opened this issue Dec 27, 2008 · 1 comment
Assignees
@wsnyder
Labels
area: wrong runtime result Issue involves an incorrect runtine result from Verilated model resolution: fixed Closed; fixed

Comments

@veripoolbot
Copy link
Contributor

Author Name: Rodney Sinclair
Original Redmine Issue: 46 from https://www.veripool.org
Original Date: 2008-12-27
Original Assignee: Wilson Snyder (@wsnyder)

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"
@veripoolbot
Copy link
Contributor Author

Original Redmine Comment
Author Name: Wilson Snyder (@wsnyder)
Original Date: 2008-12-30T22:24:03Z

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.

@veripoolbot veripoolbot added area: wrong runtime result Issue involves an incorrect runtine result from Verilated model resolution: fixed Closed; fixed 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
area: wrong runtime result Issue involves an incorrect runtine result from Verilated model resolution: fixed Closed; fixed
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
2 participants
@wsnyder @veripoolbot