From: Al Davis (email@example.com)
Date: Tue Mar 27 2001 - 11:21:22 PST
The cause of this error is a convergence failure.
There are many factors in timestep control. Here's a list of some of
- iteration count
- truncation error in dynamic elements (capacitors, inductors,
- the time step you request
- events or break points
- transmission line (and delay element) length
- signal edge rates (dv/dt)
- interactions between these
Most of these can be determined explicitly, and do not contribute to
this problem. Understanding them may help you "solve" it. I put
"solve" in quotes because you are not really solving it. You are
just kicking it somehow to get past the problem.
The one that gets you is the iteration count. After succeeding in
the initial DC solution, the tranient analysis begins. At every
step, it iterates. If convergence fails, it rejects the step, backs
up a bit and tries again with a smaller step. Repeat until it works.
Usually, it does work, but sometimes it just keeps trying smaller
and smaller steps, unsuccessfully, and gives up, with the message
"internal timestep too small". (or in ACS "very backward time step").
So, you need to attack it as a convergence problem.
One approach is to mess with the convergence parameters. In Spice
derivatives, and even in some non-spice programs, the option "ITL4"
sets the number of iterations allowed on a time step. The default is
often 10, which is often not enough. If your circuit takes 12
iterations to converge, then you back off a bit and it still takes
12, it leads to timestep too small error. Just saying 12 is ok fixes
it. As Kim said, try 100, or maybe more. You might also try the
iterations tolerances (reltol, abstol, ...) Sometimes tighter makes
it better. Sometimes looser makes it better.
What I just said applies to the case where it almost works. It won't
help you if the circuit or model really has a problem. Perhaps there
is a discontinuity or bifurcation in the transfer function. Perhaps
there is a net negative resistance region. (IBIS-check tells you
about tables being non-monotonic.) It could be in the driver or load
or anywhere else. It could be that it is ok in the static case, but
a non-monotonic characteristic results during the transition.
Paradoxically, the algorithms that most accurately model the waveform
tables are most prone to this problem.
With the bifurcation problem, sometimes you can get by with an
arbitrary tweek. If the problem is at a specific point, minor
adjustments cause a different path, which might slip by the trouble
spot. Then, it starts working and you don't know why. It might be
something seemingly unrelated, and you conclude something like
"always set initial conditions to 7 volts" or something like that.
You can also attack it by changing the circuit a little. Load it a
little heavier. Put in a short, low impedance, transmission line.
Transmission lines are more likely to help than hurt. They decouple
sections of the circuit from each other.
You might also try a different integration method. If your simulator
defaults to trapezoid, try Gear or Euler. (if you have a choice).
Euler is usually the safest. Low order Gear is usually safer than
high order Gear.
**** To unsubscribe from si-list or si-list-digest: send e-mail to
firstname.lastname@example.org. In the BODY of message put: UNSUBSCRIBE
si-list or UNSUBSCRIBE si-list-digest, for more help, put HELP.
si-list archives are accessible at http://www.qsl.net/wb6tpu
This archive was generated by hypermail 2b29 : Thu Jun 21 2001 - 10:11:21 PDT