From: zanella, fabrizio ([email protected])
Date: Thu Jan 20 2000 - 06:14:01 PST
We have had luck in eliminating 'internal time step too small' errors in
HSPICE by setting the following options
'.option lvltim=3 dvdt=4'
The time step error also is dependent on the transistor model used, we've
found certain models give us time step errors most of the time, and in some
cases this error occurs with HSPICE v1999.2 but not with v1998.4.
From: Kim Helliwell [mailto:[email protected]]
Sent: Wednesday, January 19, 2000 8:06 PM
To: [email protected]
Subject: Re: [SI-LIST] : **error**: internal
timestep too small
Dmitri Kuznetsov wrote:
> Interestingly, to get rid of the "internal timestep too
> one needs to make the time step SMALLER.
> The error is caused by nonconvergence due to previous time
> too large. SPICE tries to "backtrack" and redo the
> 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
> which makes the problem worse.
I think that's a bit simplistic, though. There are timestep
that are simply not amenable to any manipulations of the
because there is a model discontinuity of some sort, for
I'm curious what you mean by reducing the timestep. Do you
reducing TMAX or TSTEP in the .TRAN line? Or do you mean
the tolerances tighter? In the first case, sometimes that
but more often not. In the second case, if that helps, it
a problem with the circuit topology (what I call numerical
The more standard approach (I'm going to give away my bag of
now!) is first: check all model and device parameters for
ludicrous values. For example, setting the diode parameter
.001 could cause convergence problems for any temperature
than the default. But some macromodel developers have been
to do that!
Then: increase the per-timestep iteration limit (ITL4) to
50 or 100 or more. Then increase RELTOL until just before
Increasing ABSTOL might also be helpful in some cases.
If none of this solves the problem, consider using a modern
(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.
in conjunction with ITL4=100, you could be in for a long
Berkeley SPICEs do a maneuver called BYPASS, which saves
by fudging the calculation of the iterate quantities for
device. Back when I was supporting simulators, I put in a
switch to turn off bypassing, and I've found that that
many timestep problems. I do not know whether this is
in the current SPICE 3 from Berkeley. I don't know whether
or PSPICE even does bypassing or not. But if I were
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
hurts more than it helps.
Senior CAE Engineer
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
**** 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
This archive was generated by hypermail 2b29 : Thu Apr 20 2000 - 11:34:45 PDT