FPGARelated.com
Forums

ModelSim vsim-3601 message

Started by Jaime Andres Aranguren Cardona January 5, 2006
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


On Thu, 5 Jan 2006 00:43:31 -0500, "Jaime Andres Aranguren Cardona"
<jaac@nospam.sanjaac.com> wrote:

># ** Error: (vsim-3601) Iteration limit reached at time 2350 ns. ># ** Note: (vsim-3602) Delays were truncated during elaboration of the >design.
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.
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 <newvalue>") 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
www.ht-lab.com



"Jaime Andres Aranguren Cardona" <jaac@nospam.sanjaac.com> wrote in message 
news:43bcb076$0$28926$6d36acad@roc.nntpserver.com...
> 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 > >
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 <wr>.
WARNING:Xst:737 - Found 19-bit latch for signal <addressint>.
WARNING:Xst:737 - Found 1-bit latch for signal <rd>.
WARNING:Xst:737 - Found 1-bit latch for signal <status>.
WARNING:Xst:737 - Found 1-bit latch for signal <cs>.
WARNING:Xst:737 - Found 19-bit latch for signal <diffcount>.
WARNING:Xst:737 - Found 1-bit latch for signal <direction>.

-- 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 
3.
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.

--

From the Place and Route, I get this warning / information

WARNING:Route - CLK Net:_n0029
may have excessive skew because 3 CLK pins
failed to route using a CLK template.

**************************
Generating Clock Report
**************************

+---------------------+--------------+------+------+------------+-------------+
|        Clock Net    |   Resource   |Locked|Fanout|Net Skew(ns)|Max 
Delay(ns)|
+---------------------+--------------+------+------+------------+-------------+
|           clk_BUFGP |      BUFGMUX3| No   |    8 |  0.001     |  1.011 
|
+---------------------+--------------+------+------+------------+-------------+
|              _n0029 |         Local|      |    3 |  0.633     |  1.670 
|
+---------------------+--------------+------+------+------------+-------------+
|              _n0030 |         Local|      |   10 |  0.046     |  2.518 
|
+---------------------+--------------+------+------+------------+-------------+
|              _n0032 |         Local|      |   10 |  0.087     |  1.655 
|
+---------------------+--------------+------+------+------------+-------------+
|              _n0033 |         Local|      |    1 |  0.000     |  0.500 
|
+---------------------+--------------+------+------+------------+-------------+
|              _n0031 |         Local|      |    1 |  0.000     |  1.599 
|
+---------------------+--------------+------+------+------------+-------------+


"mk" <kal*@dspia.*comdelete> wrote in message 
news:j9fpr15bdhuk6ij7654e0mm2g1td85t456@4ax.com...
> On Thu, 5 Jan 2006 00:43:31 -0500, "Jaime Andres Aranguren Cardona" > <jaac@nospam.sanjaac.com> wrote: > >># ** Error: (vsim-3601) Iteration limit reached at time 2350 ns. >># ** Note: (vsim-3602) Delays were truncated during elaboration of the >>design. > > 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.