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

About this list Date view Thread view Subject view Author view

From: zanella, fabrizio (zanella_fabrizio@emc.com)
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
fzanella@emc.com

                -----Original Message-----
                From: Kim Helliwell [mailto:khelliwe@acuson.com]
                Sent: Wednesday, January 19, 2000 8:06 PM
                To: si-list@silab.eng.sun.com
                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
majordomo@silab.eng.sun.com. 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 majordomo@silab.eng.sun.com. 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