Simulation time running but test doing nothing -- any tricks you can recommend to figure out where it stopped?

UVM
,
1

Hi All,

Every now and then I encounter a situation where my UVM simulation hits something (e.g. a register access through frontdoor that the slave never acks, and that doesn’t time out) that causes it to stop at a certain line of code and hang there. The simulation time just keeps on increasing indefinitely, but the test doesn’t do anything anymore. Is there any trick you can suggest to figure out which line of code was the one it hanged on, after it did? Once the test has reached the point where it is running and doing nothing, if I just hit break at any time, Questasim will just stop at a random rtl line of code instead of a UVM one.

Until now I solved these kind of issues by restarting the test and adding multiple breakpoints, and iteratively reducing the spacing between two breakpoints. Since my tests are quite heavy and normally take 12+ hours to run, that is not a very productive way of doing it. I use checkpoints (Questasim) to salve the simulation state, but nevertheless…

In fact, right now I have a case where I used that approach, found the last line it seems to execute, and I am still clueless. It is not a register access, the last line it executes is the auto_sync = 1 below, so I guess it may be waiting forever on that fork. OR it may also be hanging on something else entirely after the auto_sync = 1 is executed :/


for (int k = 0; k < 2; k++) begin
   fork
      automatic int i = k;
      if( this.etgs_active_dl[i]) begin
         this.m_env_api.m_xgress_dl_api.m_xgr_etg_api[i].auto_sync = 0;
//       ... --> writing other stuff to the api
         this.m_env_api.m_xgress_dl_api.m_xgr_etg_api[i].sync_dut();
         this.m_env_api.m_xgress_dl_api.m_xgr_etg_api[i].auto_sync = 1;
      end
   join_none
end
wait fork;

I think this question is a bit at the margin of what is Tool related and what is language related. As I said, I am using Questasim. But I am hoping for the kind of smart trick like adding a breakpoint to some UVM code that is inevitably executed for the simulation time to keep running, and using the call stack to see what code is causing the hang to happen.

Thanks in advance!

2

In reply to jprochno:

What you are describing is in most cases an indication your testbench is waiting in an if statement which never becomsed true. You should look into this direction.

3

In reply to chr_sue:

My test was simply waiting forever on that fork. I could not figure out why. It doesn’t make any sense to me, since I saw the code being executed to the last line inside the fork-join_none using breakpoints/steps. I removed the wait fork, because I don’t really need it, and the test now runs fine. Weirdest thing is that this code has been there for over a month and the test was running fine in a daily regression until two days ago…