LT Spice convergence

[grouchobyte]

From time to time I need to use SPICE to simulate a circuit. I have used many Spice variants over the years including Tek/Berkley SPICE, Pspice, Simetrix, and these days...LTspice. For simple circuits, it serves me just fine. Unfortunately, once in a while and especially if it gets over a limited number of nodes it can start to take a very long time to converge on a solution (classic SPICE problem). My usual method in mitigating this problem is to go to the control panel and tweak the settings until I get it working or just break up the sim into functional pieces and simulate them separately. Moreover, there are some third party models that work better than others.

I do all the usual stuff to like terminate floating nodes and turn off Gmstepping, etc.

Are there any other tricks that you use that perhaps I haven't found yet in my experience with this love-hate tool

@grouchobyte

[Marco]

Of all the free ones I have tried Simetrix has the least convergence problems.

Of course the more complex Spice models use the node budget up instantly.

[StillTrying]

If LT "sticks" adding 1R ESR to the large decoupling caps works 75% of the time for me.

Most of my simulations are well under 2 seconds to compute, if there's a cap taking 300mS to 1 sec to charge to a voltage, I insert a fake voltage so there's no charging to be done!

[exmadscientist]

When dealing with tricky convergence problems, LTSpice's .savebias and .loadbias commands can work magic. They are particularly useful for AC response simulations with stepped parameters where the DC operating point doesn't (meaningfully) change but takes a long time to calculate. Just save it once and reload it to skip the solution at every step!

You can also use them to grow a circuit bit by bit. Get a smaller subcircuit to converge, save the bias point, then start adding on chunks and saving again if it's stable. This can help a lot for things like servo loops.

And of course, don't forget the startup option for transient simulations where explicitly simulating the supply ramping can make the operating point easy to find. The downside is that the simulation can take a while to advance to the region of operation you're interested in.

[T3sl4co1l]

If LT "sticks" adding 1R ESR to the large decoupling caps works 75% of the time for me.

Most of my simulations are well under 2 seconds to compute, if there's a cap taking 300mS to 1 sec to charge to a voltage, I insert a fake voltage so there's no charging to be done!

Assign initial conditions!  (And make sure the configuration is set to use them.)

Increasing ESR arbitrarily is bad for a model.  Are you accidentally reducing ringing, or stabilizing an LDO or SMPS in the process?  How will you know?  Don't forget to include realistic trace and component inductances, too!

I do all the usual stuff to like terminate floating nodes and turn off Gmstepping, etc.

Are there any other tricks that you use that perhaps I haven't found yet in my experience with this love-hate tool

Well...

I never found default settings to be at all useful.  LTSpice is a bit better than most (and doesn't present most SPICE settings in the dialog!), and its improved solver helps, but I still find GEAR 2 to be the best integration method, particularly for switching circuits.

Crawling at fs/s, stuck on one point: normally, ITL4 (maximum transient timepoint iterations) is set to some value, and when that value is exceeded, it just crashes out -- Timestep Too Small.  One of the most maddeningly useless errors of all time...  LTSpice's default seems to be infinite iterations, so you have to watch it, otherwise it sits there chewing CPU and doing absolutely nothing.

Fixing timestep errors:
- Anything that requires precision numerical calculations.  This can be hard to figure out, but complex, nonlinear functions (any model you see lots of POLY and LIMIT and TABLE and V= or I={} functions in..) tend to cause problems, whereas SPICE primitives (passives, diodes, etc.) tend to behave themselves.

- Singular nodes (floating voltages between series capacitors, undefined current loops between parallel inductors, paralleled voltage sources or series'd current sources) usually result in their own error, but RSHUNT and GMIN mask this, and the result can be small timesteps.

- Very small RELTOL (default 0.001) and TRTOL (default 10) tend to slow things down, and increasing these can alleviate errors.  However, they also affect the quality of the number crunching.  RELTOL over 0.01 isn't recommended, and that's already pretty sloppy.  (If you're doing power and energy calculations in a switching circuit, you may want RELTOL 10e-4, perhaps even less for a very high efficiency circuit.)  TRTOL is about how suddenly the timestep slows down under sudden changes (like switching edges); a grossly high value (like 50+) can turn waves into mush.

- Pull some decimal points out of ABSTOL and/or CHGTOL.

Normally, ABSTOL is fine, and CHGTOL is about RELTOL times ABSTOL (i.e., default 1e-14 and 1e-17, though CHGTOL defaults to 1e-16 for some reason).  Honestly, higher ABSTOL and CHGTOL (and CHGTOL > ABSTOL) doesn't seem to cause much problems; change them by a few 10x and see if the waveforms, averages and differences, etc. degrade much, and if that fixes the hangups.

- Integration.  I always have better results with GEAR 2 (i.e., integration method = gear, .OPTION MAXORD=2), which produces smoother waveforms*, and runs faster anyway!

*Though Mike's done quite a good job of minimizing the point-to-point (numerical, not real) ringing that trapezoidal integration typically produces.

In LTSpice, any of these options not present on the config dialog (and still supported) are available by adding the SPICE directive .OPTION <name>=<value>.  Or if you just want to save them with the .ASC, that's good too.

Tim

[grouchobyte]

Well...

I never found default settings to be at all useful.  LTSpice is a bit better than most (and doesn't present most SPICE settings in the dialog!), and its improved solver helps, but I still find GEAR 2 to be the best integration method, particularly for switching circuits.

Crawling at fs/s, stuck on one point: normally, ITL4 (maximum transient timepoint iterations) is set to some value, and when that value is exceeded, it just crashes out -- Timestep Too Small.  One of the most maddeningly useless errors of all time...  LTSpice's default seems to be infinite iterations, so you have to watch it, otherwise it sits there chewing CPU and doing absolutely nothing.

Fixing timestep errors:
- Anything that requires precision numerical calculations.  This can be hard to figure out, but complex, nonlinear functions (any model you see lots of POLY and LIMIT and TABLE and V= or I={} functions in..) tend to cause problems, whereas SPICE primitives (passives, diodes, etc.) tend to behave themselves.

- Singular nodes (floating voltages between series capacitors, undefined current loops between parallel inductors, paralleled voltage sources or series'd current sources) usually result in their own error, but RSHUNT and GMIN mask this, and the result can be small timesteps.

- Very small RELTOL (default 0.001) and TRTOL (default 10) tend to slow things down, and increasing these can alleviate errors.  However, they also affect the quality of the number crunching.  RELTOL over 0.01 isn't recommended, and that's already pretty sloppy.  (If you're doing power and energy calculations in a switching circuit, you may want RELTOL 10e-4, perhaps even less for a very high efficiency circuit.)  TRTOL is about how suddenly the timestep slows down under sudden changes (like switching edges); a grossly high value (like 50+) can turn waves into mush.

- Pull some decimal points out of ABSTOL and/or CHGTOL.

Normally, ABSTOL is fine, and CHGTOL is about RELTOL times ABSTOL (i.e., default 1e-14 and 1e-17, though CHGTOL defaults to 1e-16 for some reason).  Honestly, higher ABSTOL and CHGTOL (and CHGTOL > ABSTOL) doesn't seem to cause much problems; change them by a few 10x and see if the waveforms, averages and differences, etc. degrade much, and if that fixes the hangups.

- Integration.  I always have better results with GEAR 2 (i.e., integration method = gear, .OPTION MAXORD=2), which produces smoother waveforms*, and runs faster anyway!

*Though Mike's done quite a good job of minimizing the point-to-point (numerical, not real) ringing that trapezoidal integration typically produces.

In LTSpice, any of these options not present on the config dialog (and still supported) are available by adding the SPICE directive .OPTION <name>=<value>.  Or if you just want to save them with the .ASC, that's good too.

Tim

Brilliant post Tim!

As always, your insights are dead on and are sure to help (and not just me, but others who read this thread.)
Indeed, all Spice engines have some sort of convergence problem, inherent to the nature of the beast. Too much precision or nodes is frequently the culprit and the model POLY functions are also problematic, as you point out.
I have spoken to Mike E about my issues and he has made the same suggestions you do. Before breaking up a sim into smaller chunks to prevent it from slowing to a crawl, I tweak the usual settings (gear integration, alt solver, RTOL, etc) until it starts working/moving/converging or until the result begins to look unrealistic or less-than-believable. What makes me wince is the fact that I have little clue how much I have compromised the result, more like what my gut tells me is correct is what I stick with. It's a feel-good exercise, anyways.

I guess I could always go back to dead-bugging some parts on copper clad ( not always practical) but then I would miss the "what if" scenarios as opposed the "WTF" scenarios  I get with LTSPICE now
My humble and experienced conclusion : do both.


@grouchobyte

[Cerebus]

Another tip. Include realistic source resistances on voltage sources used as power supplies. This prevents SPICE considering those ridiculous edge cases that involve things like sourcing 1000A from an AA battery. I've had things that just refuse to converge turn into instant convergence just by adding 0.01 ohms to the voltage sources supplying the rails. Obviously the best thing is to use the measured source impedance of the intended final power supply but if you don't have those figures use a reasonable guess.