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

Reset fails to respond when driven from vector containing clock enable #1036

Closed
veripoolbot opened this issue Feb 14, 2016 · 4 comments
Closed
Labels
area: scheduling Issue involves scheduling/ordering of events area: wrong runtime result Issue involves an incorrect runtine result from Verilated model effort: days Expect this issue to require roughly days of invested effort to resolve resolution: fixed Closed; fixed

Comments

@veripoolbot
Copy link
Contributor


Author Name: Neil Turton
Original Redmine Issue: 1036 from https://www.veripool.org
Original Date: 2016-02-14


In the attached test, the active low reset output fails to go high when the active high input goes low.

There are several work-arounds. One is to define the FIXIT macro which modifies the test code. Another is to remove the clock_enable comment. Another is to delete slave_clk.

To reproduce, save the attached files in the current directory and run the commands:
make
./obj_dir/Verror9

@veripoolbot
Copy link
Contributor Author


Original Redmine Comment
Author Name: Neil Turton
Original Date: 2016-02-14T17:37:10Z


There's a formatting problem in the commands to reproduce the issue. There should be two commands (separated by a new line which got removed). So, "make ; ./obj_dir/Verror9" would do.

@veripoolbot
Copy link
Contributor Author


Original Redmine Comment
Author Name: Wilson Snyder (@wsnyder)
Original Date: 2016-02-24T02:22:48Z


Attributes such as the clock enables and clocks themselves are propagated signal-by-signal rather than bit-of-signal. So what's going on here is the clock enable attribute also gets associated with the reset. This is certainly a bug, but fairly fundamental so unfortunately is unlikely to be resolved any time soon, sorry.

@veripoolbot
Copy link
Contributor Author


Original Redmine Comment
Author Name: Todd Strader (@toddstrader)
Original Date: 2016-02-24T14:42:24Z


This looks very similar to a problem we had with vectors of clocks:

http://www.veripool.org/issues/1009-Verilator-Non-cutable-ordering-loop-when-using-an-array-of-clocks

I've been slacking on cleaning this up for pushing back upstream, but the GitHub link has the code that we are currently using to address the issue. I haven't tried your code, however, my suspicion is that it will not work for you. But it should be trivial to apply the same technique for clock enable signals (as opposed to clocks).

@veripoolbot veripoolbot added area: scheduling Issue involves scheduling/ordering of events area: wrong runtime result Issue involves an incorrect runtine result from Verilated model effort: days Expect this issue to require roughly days of invested effort to resolve status: blocked Issue is waiting for another bug, when other bug is fixed, then goes to 'status: assigned' labels Dec 22, 2019
@wsnyder wsnyder added resolution: fixed Closed; fixed and removed status: blocked Issue is waiting for another bug, when other bug is fixed, then goes to 'status: assigned' labels May 15, 2022
@wsnyder
Copy link
Member

wsnyder commented May 15, 2022

Believed fixed in develop-v5 with #3278.

@wsnyder wsnyder closed this as completed May 15, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
area: scheduling Issue involves scheduling/ordering of events area: wrong runtime result Issue involves an incorrect runtine result from Verilated model effort: days Expect this issue to require roughly days of invested effort to resolve resolution: fixed Closed; fixed
Projects
None yet
Development

No branches or pull requests

2 participants