ModelSim vsim-3601 message

Good day,

I am trying to simulate a design for an Spartan3-200, on Webpack 7.1i SP4 with ModelSim XE III/Starter 6.0a.

The design simulates perfectly for a functional simulation, running own .do file on ModelSim.

However, if I run the same .do file on the simulation model generated with the "Generate Post-Synthesis Simulation Model" process, I get the following messages (several times):

# ** Error: (vsim-3601) Iteration limit reached at time 2350 ns. # ** Note: (vsim-3602) Delays were truncated during elaboration of the design.

And the design does not simulate further than 2350 ns (clock cycle is 100 ns, on .do file)

The same happens if I run the same .do file on the simulation model generated with the "Generate Post-Place & Route Simulation Model" process.

What do those messages mean, and how can I solve this issue?

For your help, thank you very much.

Regards,

--
Jaime Andres Aranguren Cardona
jaac@sanjaac.com
SanJaaC Electronics
Soluciones en DSP
www.sanjaac.com
Reply to
Jaime Andres Aranguren Cardona
Loading thread data ...

I am not a modelsim user but that message means that the event simulator doesn't converge, ie you have combinational loop somewhere which is generating arbitraryly large number of events at that simulation time so the simulation point doesn't progress and the simulator gives up at some point. This can happen when the input of an inverter is connected to its output etc., also with combinational latches. You need to figure out which device(s) is causing the loop and some how prevent it going into the loop. You may have to force some nets to reset the combinational latches or pass through a state where the input is X etc. Although there is a very small likelyhood that your iteration limit is too low and increaing it may help, I doubt that's your problem.

HTH.

Reply to
m

Hi Jaime,

Just type in verror 3601 to get some more info :

vsim Message # 3601: The simulator iterates at a given simulation time in zero delay until there is no more activity at that time. In order for it to not hang if there is a zero-delay oscillation, it limits the number of iterations to a default of 5000. If you reach this limit, the simulation will stop with an error. If you receive this error you can increase the iteration limit, (via "set IterationLimit ") and then try single stepping to attempt to determine which instances in the design may be oscillating. [DOC: ModelSim User's Manual - Detecting infinite zero-delay loops]

Hans

formatting link

Reply to
Hans

Hi,

First of all, thanks for your reply.

Certainly, I've got some stuff to deal with, as can be read from the warnings that I get. I am posting them here, asking for your kind guide on what should I apparently correct, what errors are inferred from these warnings. In advance, please apologize for the long post.

From the Synthesis report, I get the following warnings / infos:

WARNING:Xst:737 - Found 1-bit latch for signal . WARNING:Xst:737 - Found 19-bit latch for signal . WARNING:Xst:737 - Found 1-bit latch for signal . WARNING:Xst:737 - Found 1-bit latch for signal . WARNING:Xst:737 - Found 1-bit latch for signal . WARNING:Xst:737 - Found 19-bit latch for signal . WARNING:Xst:737 - Found 1-bit latch for signal .

-- trimmed

INFO:Xst:1767 - HDL ADVISOR - Resource sharing has identified that some arithmetic operations in this design can share the same physical resources for reduced device utilization. For improved clock frequency you may try to disable resource sharing.

-- trimmed

Found area constraint ratio of 100 (+ 5) on block memtest, actual ratio is

  1. FlipFlop presentState_FFd1 has been replicated 3 time(s) FlipFlop presentState_FFd3 has been replicated 1 time(s) FlipFlop presentState_FFd4 has been replicated 1 time(s)

-- trimmed

-----------------------------------+------------------------+-------+ Clock Signal | Clock buffer(FF name) | Load |

-----------------------------------+------------------------+-------+ clk | BUFGP | 9 | _n0029(_n00291:O) | NONE(*)(rd) | 3 | _n0030(_n00301:O) | NONE(*)(addressint_12) | 19 | _n0031(_n00311:O) | NONE(*)(status) | 1 | _n0032(_n00321:O) | NONE(*)(diffcount_2) | 19 | _n0033(_n00331:O) | NONE(*)(direction) | 1 |

-----------------------------------+------------------------+-------+ (*) These 5 clock signal(s) are generated by combinatorial logic, and XST is not able to identify which are the primary clock signals. Please use the CLOCK_SIGNAL constraint to specify the clock signal(s) generated by combinatorial logic. INFO:Xst:2169 - HDL ADVISOR - Some clock signals were not automatically buffered by XST with BUFG/BUFR resources. Please use the buffer_type constraint in order to insert these buffers to the clock signals to help prevent skew problems.

--
Also, from the Map Report, I get the folowing warnings:

WARNING:PhysDesignRules:372 - Gated clock. Clock net _n0029 is sourced by a
   combinatorial pin. This is not good design practice. Use the CE pin to
   control the loading of data into the flip-flop.
WARNING:PhysDesignRules:372 - Gated clock. Clock net _n0030 is sourced by a
   combinatorial pin. This is not good design practice. Use the CE pin to
   control the loading of data into the flip-flop.
WARNING:PhysDesignRules:372 - Gated clock. Clock net _n0032 is sourced by a
   combinatorial pin. This is not good design practice. Use the CE pin to
   control the loading of data into the flip-flop.
WARNING:PhysDesignRules:372 - Gated clock. Clock net _n0033 is sourced by a
   combinatorial pin. This is not good design practice. Use the CE pin to
   control the loading of data into the flip-flop.
WARNING:PhysDesignRules:372 - Gated clock. Clock net _n0031 is sourced by a
   combinatorial pin. This is not good design practice. Use the CE pin to
   control the loading of data into the flip-flop.
Reply to
Jaime Andres Aranguren Cardona

ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.