ModelSim vsim-3601 message
in [FPGA]
|
From: Jaime Andres Aranguren Cardona on 5 Jan 2006 00:43 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(a)sanjaac.com SanJaaC Electronics Soluciones en DSP www.sanjaac.com
From: mk<kal* on 5 Jan 2006 01:34 On Thu, 5 Jan 2006 00:43:31 -0500, "Jaime Andres Aranguren Cardona" <jaac(a)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.
From: Hans on 5 Jan 2006 03:30 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(a)nospam.sanjaac.com> wrote in message news:43bcb076$0$28926$6d36acad(a)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(a)sanjaac.com > SanJaaC Electronics > Soluciones en DSP > www.sanjaac.com > >
From: Jaime Andres Aranguren Cardona on 5 Jan 2006 07:05 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(a)4ax.com... > On Thu, 5 Jan 2006 00:43:31 -0500, "Jaime Andres Aranguren Cardona" > <jaac(a)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.
|
Pages: 1 Prev: PLX 9056 application Next: Help! FIR Filter - MATLAB fdatool - VHDL |