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

Convergence failures, how to debug #1353

Closed
veripoolbot opened this issue Sep 27, 2018 · 5 comments
Closed

Convergence failures, how to debug #1353

veripoolbot opened this issue Sep 27, 2018 · 5 comments
Labels
resolution: no fix needed Closed; no fix required (not a bug)

Comments

@veripoolbot
Copy link
Contributor


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?

@veripoolbot
Copy link
Contributor Author


Original Redmine Comment
Author Name: Wilson Snyder (@wsnyder)
Original Date: 2018-09-27T16:53:18Z


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.

@veripoolbot
Copy link
Contributor Author


Original Redmine Comment
Author Name: Wilson Snyder (@wsnyder)
Original Date: 2018-10-05T00:31:50Z


This seemed a request for assistance which was provided earlier, if I misread it and something needs fixing please reopen.

@veripoolbot
Copy link
Contributor Author


Original Redmine Comment
Author Name: Al Grant
Original Date: 2018-10-05T10:33:04Z


I'm not sure whether it was a bug report or not. It was basically an observation that the FAQ made it
sound like the diagnostics would obviously show the root cause of a failure to converge, but it doesn't
seem like they do. It's a report about the diagnostics not being clear. No doubt the root cause of the
failure to converge is my error and I can diagnose it with gdb or prints, but the issue is whether you
aim for the diagnostics are expected to be more helpful in locating the root cause.

E.g. couldn't it show the source position(s) where the signal is being changed,
rather than the source position of its declaration?

@veripoolbot
Copy link
Contributor Author


Original Redmine Comment
Author Name: Wilson Snyder (@wsnyder)
Original Date: 2018-10-05T10:46:53Z


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.

@veripoolbot
Copy link
Contributor Author


Original Redmine Comment
Author Name: Al Grant
Original Date: 2018-10-05T11:53:23Z


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
#5 clk = ~clk;

It got a STMTDLY warning, but clearly if Verilator is ignoring delays then this will fail to converge.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
resolution: no fix needed Closed; no fix required (not a bug)
Projects
None yet
Development

No branches or pull requests

1 participant