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
Convergence failures, how to debug #1353
Comments
Original Redmine Comment Sorry, this isn't usually a problem and when it is it usually is "obvious" from the signal involved what is the problem. If many signals are getting printed then most likely each are oscillating (or there is a bug), of course signal e.g. "A" may be oscillating, then "A" feeds signal "B" which then is also reported as oscillating. I would suggest debugging it like a "C" program now; either going into gdb and tracing, or editing the generated C++ code to add appropriate prints to see what is going on. |
Original Redmine Comment This seemed a request for assistance which was provided earlier, if I misread it and something needs fixing please reopen. |
Original Redmine Comment I'm not sure whether it was a bug report or not. It was basically an observation that the FAQ made it E.g. couldn't it show the source position(s) where the signal is being changed, |
Original Redmine Comment Fair point, added more words to the documentation. Unfortunately verilator at this stage doesn't have any knowledge of what logic might be causing the issue. Also it's worth reviewing any UNOPTFLAT messages you suppressed, those do indicate the logic involved. |
Original Redmine Comment I had hundreds of UNOPTFLAT but they were all paths from one part of a vector to another rather than genuine combinational loops. The problem turned out to be always It got a STMTDLY warning, but clearly if Verilator is ignoring delays then this will fail to converge. |
Author Name: Al Grant
Original Redmine Issue: 1353 from https://www.veripool.org
I'm using 4.002 with a design that has simulated successfully with other compilers.
It is failing with "model didn't converge". The FAQ directs me to use debugging
options and look at the CHANGE messages. Naively I was expecting to see repeated
CHANGE messages for one or more signals showing they were failing to converge.
In fact what I see is around 30 CHANGE messages, all for different signals, referencing
the line of the signal declaration. This leaves me with no clue as to which assignment
is occuring repeatedly and causing the value to oscillate. Increasing --converge-limit
has no effect either.
Is there some better way to debug this? Or would it be possible to give a more
specific message about which assignments were causing the failure?
The text was updated successfully, but these errors were encountered: