Debugging combinational logic loops in Icarus Verilog

Question

I'm using Icarus verilog to simulate a reasonably complex design. I find that in some rare cases my simulation gets "stuck", i.e., the clock doesn't tick any more and none of the signals appear to change. I suspect this is because I have a combinational logic loop somewhere in my design. The problem, of course, is that I have no idea where.

Is there a systematic method debugging this? I'm just staring really hard at the code, but I'm unable to make any progress. Any suggestions on things I could try are much appreciated.

Answer 1

When you run a simulation, dump a VCD file. If you have an infinite loop, you will see the VCD file size continue to grow without a new time being written to the file. Times are indicated by # at the beginning of a line. You will be able to determine which signals are changing without time advancing.

Answer 2

So it turns out Icarus Verilog has a compile flag "-pfileline=1" for this specific. Running vvp with this flag turned on prints out a whole lot of debugging information about exactly what is being executed.

Answer 3

IMO, most of the time infinite loops happen is with clock generation. Especially if you've them set up to generate variable frequencies. For example, if you've a clock set up like this:

`timescale 1ns / 1ns
 real period;
 reg clk;

 initial begin
     period = 5.0;
     clk = 1'b0;
     forever begin
         #(period/2) clk = !clk;
     end
end

If you change period then infinite loops can happen if you change period to 0.0 accidentally.

Even trickier, sometimes period / 2 can fall outside of your timescale precision. For example, if you set period = 1.0, then period / 2 is 0.5, and since your time precision is 1ns, this will snap to 0, causing infinite loops. If I suspect this, I usually put a guard on the time just before I go into the delay (again, careful with precision...) .

...
half_period_ns = period_ns / 2.0; 
if( half_period_ns == 0 )
    half_period_ns = 1;
#(half_period_ns) clk = !clk;
...

Another thing to do is to run the simulation in interactive mode and randomly Ctrl-C, type in the command to ask the simulator where it's at (simulator specific, sadly, but in Incisive it's where I think), and resume the sim. Do this a few times and you'll be able to get an idea of code is taking up all the simulator's time.