4

I'm writing VHDL code for a d-flip-flop on Modelsim and I get an error when I try to simulate it:

Error: (vsim-3601) Iteration limit reached at time 400 ps.

I'm not sure what it means, but I've looked through much of my source code for errors to no success. Can anyone guess what the problem might be?

Qiu
  • 5,651
  • 10
  • 49
  • 56
user607444
  • 51
  • 1
  • 1
  • 3

6 Answers6

4

This error usually indicates that ModelSim is stuck in an infinite loop. In VHDL, this can happen when a signal is placed in the sensitivity list and this signal is changed in the process. The signal changes, triggering the process, which changes the signal, which again triggers the process and the cycle continues.

The following is a simple example of a process that causes an infinite loop:

PROCESS (count)

BEGIN

count <= not count;

END PROCESS;
askewchan
  • 45,161
  • 17
  • 118
  • 134
Ahmed Soliman
  • 365
  • 1
  • 4
  • 12
2

I just had a similar problem.

the way I fixed it was just to increase delays in the testbench. I changed my delay from 100ps to 1ns and it was fixed! because the latency of the FOR LOOP is more than within the range of PicoSeconds.

Rahimi0151
  • 395
  • 3
  • 11
  • 1
    This can be a big problem if your simulator timing resolution is greater than or equal to your clock period (search modelsim.ini for "Resolution"). In my case, my modelsim.ini had "Resolution = ns", so even my 1 ns clock was too fast, causing it to get stuck forever, incrementing delta cycles but never progressing past 0 ns. – Harry May 20 '19 at 15:12
2

If your iteration limit is reached, that means the system hasn't stabilized. Most likely it is something like:

a <= b;

--- and then later...

b <= a;

Aaron D. Marasco
  • 6,506
  • 3
  • 26
  • 39
  • I think your simplified example is too simple to cause the problem. More like `a <= someFuntionOf(b,c,d,e); b <= someOtherFunctionOf(a,f,g,h)`...... but yes, sounds like the OP has a feedback loop in their code. – Paul S Feb 14 '12 at 08:52
1

One problem most people have with VHDL or any other HDL languages is that they do not understand that this is not a sequential code. EVERYTHING you have inside a process happens in parallel. The example from Ahmed is a good one:

PROCESS (count)

BEGIN

count <= not count;

END PROCESS;

An HDL simulator tries to set the value of the count to "not count" after each simulation tick, and the change will trigger another tick since the value of the count is changed and it keeps going on until it either crashes or gives you the above problem.

For an HDL to work properly you must use delays, either in form of a clock or if it is not for synthesis, to use an actual valued delay.

By changing the above code to 

PROCESS (count)
BEGIN
   count <= not count after 1 ns;
END PROCESS;

The simulation will work and the count will toggle every 1 ns.

FarhadA
  • 853
  • 2
  • 8
  • 19
0

You need to add breakpoints in you code and single step until you see the loop. Another technique, maybe more productive, is a good code review with a close look at you iterations and sensitivity lists.

advaneharshal
  • 23
  • 3
0

As stated the issue is that the signals aren't stabilizing. While the likely issue is two combinational logic signals continually replacing each other there are a couple of other possibilities that I want to highlight for posterity's sake.

As documented by Xilinx in Answer Record #19068 it can also be caused by a process that changes a signal in it's sensitivity list.

Another check to make that finally solved my issue here was to make sure your simulation resolution is small enough. Mine was orders of magnitude too high, and the clock on my test bench was running too many times in a single simulation step.

Voider
  • 454
  • 3
  • 12