调试 VHDL Modelsim 中的迭代限制错误
我正在 Modelsim 上为 d 触发器编写 VHDL 代码，当我尝试模拟它时出现错误：
错误：(vsim-3601) 在 400 ps 时达到迭代限制。
我不确定这意味着什么，但我已经检查了大部分源代码以查找错误，但没有成功。谁能猜出问题可能是什么？
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?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（6）
此错误通常表明 ModelSim 陷入无限循环。在 VHDL 中，当将信号放置在灵敏度列表中并且该信号在此过程中发生更改时，可能会发生这种情况。信号改变，触发过程，信号改变，信号再次触发过程，循环继续。
下面是一个导致无限循环的过程的简单示例：
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:
如果达到迭代限制，则意味着系统尚未稳定。最有可能的是：
a <= b;
--- 然后...
b <= a;
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;
我刚刚遇到了类似的问题。
我解决这个问题的方法只是增加测试平台的延迟。我将延迟从
100ps更改为1ns并且它已修复！因为FORLOOP的延迟超过了PicoSeconds的范围。I just had a similar problem.
the way I fixed it was just to increase delays in the testbench. I changed my delay from
100psto1nsand it was fixed! because the latency of theFORLOOPis more than within the range of PicoSeconds.大多数人在使用 VHDL 或任何其他 HDL 语言时遇到的一个问题是，他们不明白这不是顺序代码。流程中的所有内容都是并行发生的。
Ahmed 的例子是一个很好的例子：
HDL 模拟器尝试在每个模拟刻度后将计数值设置为“不计数”，并且该更改将触发另一个刻度，因为计数值已更改并且它会继续进行直到它崩溃或出现上述问题。
为了使 HDL 正常工作，您必须使用延迟，无论是时钟形式，还是如果不用于合成，则使用实际值延迟。
通过将上面的代码更改为
模拟将起作用并且计数将每 1 ns 切换一次。
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:
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
The simulation will work and the count will toggle every 1 ns.
您需要在代码中添加断点并单步执行，直到看到循环。
另一种可能更高效的技术是仔细检查迭代和敏感度列表，进行良好的代码审查。
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.
如前所述，问题在于信号不稳定。虽然可能的问题是两个组合逻辑信号不断相互替换，但为了后代，我想强调一些其他可能性。
正如 Xilinx 在 应答记录 #19068 中所述，它也可能是由进程引起的改变其敏感度列表中的信号。
最终解决我的问题的另一项检查是确保您的模拟分辨率足够小。我的数量级太高，并且测试台上的时钟在单个模拟步骤中运行了太多次。
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.