Re: [SI-LIST] : **error**: internal timestep too small

About this list Date view Thread view Subject view Author view

From: Kim Helliwell ([email protected])
Date: Wed Jan 19 2000 - 17:05:45 PST


Dmitri Kuznetsov wrote:
>
> Interestingly, to get rid of the "internal timestep too small" error,
> one needs to make the time step SMALLER.
>
> The error is caused by nonconvergence due to previous time steps being
> too large. SPICE tries to "backtrack" and redo the current time
> iteration with subsequently smaller time steps, and when it fails, the
> above error is generated.
>
> I am sure you knew about that. But many novice SPICE users try to
> increase the time step when they see the "timestep too small" error,
> which makes the problem worse.
>

I think that's a bit simplistic, though. There are timestep problems
that are simply not amenable to any manipulations of the timestep,
because there is a model discontinuity of some sort, for example.

I'm curious what you mean by reducing the timestep. Do you mean
reducing TMAX or TSTEP in the .TRAN line? Or do you mean making
the tolerances tighter? In the first case, sometimes that helps
but more often not. In the second case, if that helps, it indicates
a problem with the circuit topology (what I call numerical
instability).

The more standard approach (I'm going to give away my bag of tricks,
now!) is first: check all model and device parameters for physically
ludicrous values. For example, setting the diode parameter N to
.001 could cause convergence problems for any temperature other
than the default. But some macromodel developers have been known
to do that!

Then: increase the per-timestep iteration limit (ITL4) to
50 or 100 or more. Then increase RELTOL until just before it hurts.
Increasing ABSTOL might also be helpful in some cases.
If none of this solves the problem, consider using a modern simulator.
(Hint: Not Berkeley SPICE 3.)

Another dodge is to essentially prevent matrix reordering
by setting PIVREL to 1 (or maybe .9). I've gotten that to
work, but it's a truly desperate maneuver, since it has the
potential of vastly increasing computation times. Especially
in conjunction with ITL4=100, you could be in for a long
haul!

Berkeley SPICEs do a maneuver called BYPASS, which saves time
by fudging the calculation of the iterate quantities for each
device. Back when I was supporting simulators, I put in a
switch to turn off bypassing, and I've found that that solves
many timestep problems. I do not know whether this is available
in the current SPICE 3 from Berkeley. I don't know whether HSPICE
or PSPICE even does bypassing or not. But if I were designing
a simulator today, I would either not do bypassing or put in
a switch to allow it, but have the default be OFF. I think it
hurts more than it helps.

-- 
Kim Helliwell
Senior CAE Engineer
Acuson Corporation
Phone: 650 694 5030  FAX: 650 943 7260

**** To unsubscribe from si-list: send e-mail to [email protected]. In the BODY of message put: UNSUBSCRIBE si-list, for more help, put HELP. si-list archives are accessible at http://www.qsl.net/wb6tpu ****


About this list Date view Thread view Subject view Author view

This archive was generated by hypermail 2b29 : Thu Apr 20 2000 - 11:34:45 PDT