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.
Regards,
Fabrizio Zanella
Hardware Engineering
EMC Corporation
508-435-2075, x14645
FAX: 508-497-8027
[email protected]
-----Original Message-----
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
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
****
**** 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