LtSpice computation limitation: Which conditions do affect it?

Question

I am trying to simulate a transistor level circuit in LtSpice. There are more than 200 transistors in the design and a few opamps. Mostly logic structures.

The problem is that LtSpice can not solve the equations after some time(Like 100 us). CPU usage hits to 100%. But here is the strange thing, if I put (a bit large) capacitors to each output of each structure, LtSpice can solve the circuit full time(still very slowly with 100% CPU usage but it comes to the end at least). So here is the thing: I can not put large capacitors on each output. Due to some efficiency consideration, I can't!

So, can you help me with this? I don't have a super computer and I need to do this simulation. Are there any solutions for LtSpice being in a deadlock. Thanks.

Answer 1

LTspice does not have a limit on the number of components or nodes.

Likely, not the number of components or the overall size of yor schematic is the problem, but you might be facing some no-nos that make your circuit hard to solve.

If you have capacitors, try adding a small ESR by editing the component properties. If you have inductors, adding a DC (copper) resistance is even more important.

Also, ideal diodes or ideal transistors won't solve well sometimes. Try using models of reals components (e.g. 1N4148 instead of the generic, unlabeled diode). Maybe your logic or opamp models interact in weird ways with their neighbourhood.

It is also possible that something in your schematic tries to oscillate at some very high frequency when, in reality, it wouldn't. (3 GHz around an audio frequency BJT? No way!) Such behavior is often caused by unwanted resonance of too-ideal parasitics or L/C tanks. Try locating the root cause for these possible oscillations and add some additional resistors here and there. Just as bad as severy oscillations are very, very steep spikes. Do you see some traces going up to the kA or kV range when all you have is a little, small-signal circuit?

Answer 2

I am not that good with explanations, but I'll try.

Mike, the creator of LTspice, had went through great lengths to ensure that the solver does not encounter abrupt changes which could pose problems. This means that even the ideal diode, when simulated, will show a small rounding around the knee. Add enough points and it will get sharper, but zoom in and you still get a small rounding. This is true for (as I know it) all nonlinear elements.

However, there are cases when two or more nonlinear elements, when coupled, can produce a transfer function that can get too abrupt, which means the solver needs to reduce its time step to accomodate with the increasingly greater chages, and it gets slower and slower, until, if it can't go anymore, it coughs up "Time step too small", or similar. This is true for all SPICE engines, I think.

One cause (for LTspice, in particular), is using "stiff" voltage sources, which have (machine) zero Ohms source and can cause convergence problems. The official help states that it is better to use current sources terminated in appropiate resistors, since these not only will converge faster, but they will not be a problem to the circuit. Why am I mentioning this? Believe it or not, recently there has been a case where someone couldn't simulate a simple op-amp because of its supply sources (the model was a black box, true, so who knows what went on inside). As soon as he added Rser to the supplies, everything worked! You probably know this, but adding Rser to a voltage source makes LTspice convert it, internally, to a current source.

Another known solution is adding (small) capacitors across offending nodes, so that the derivative around the sharp transitions becomes smoother, thus allowing the solver to hop over it. The capacitance should be small enough to not prove an additional unwanted poles, yet at the same time large enough that it should have an effect on the possible discontinuity. Tipical values are fF ~ pF. Another solution might be adding gmin to help DC currents, also with values that should not distort the original circuit's response, but, at the same time, help. Values are usually at least GOhms, up.

Since a circuit like yours is -- as you say -- composed with a vast majority of transistors, thus nonlinear elements, finding the "offending node(s)" can be cumbersome, if at all possible, so for this there's the official option .opt cshunt and .opt gshunt, which, according to the manual, adds capacitances and conductances across all the nodes. I should add that this solution should be used with care, as, even if in the real life there are capacitances everywhere, they may not be the same everywhere or have values that matter, so use with care. For example, adding .opt cshunt 1n may obliterate any convergence issues, but you will be left with 1nF capacitances across every node, to ground.

Not least, the models/subcircuits, themselves, sometimes can be cumbersome, in that whomever made them didn't make such a great job, or, it may work better in one simulator than another. The solutions, here, are so vast it deserves another SE site, at least.

Besides what has already been said, I can't find, currently, something else to say, so I'll just add good luck, since, even if LTspice has no limits other than your hardware (as noted by @zebonaut), it's still at the mercy of hardware and software, especially true with growing schematic complexity. Good luck.

Answer 3

The great answer of Zebonaut was about the circuital aspects that may impact the simulation. I'll add a couple of points on the software side aspects:

• Try increasing the precision LTspice uses in performing the calculations. By default it uses single precision. If you add the directive .options numdgt=12 on the schematic it will use double precision. This may help convergence (and on some systems may also improve speed. Sometimes in hardware double precision is handled better than single precision. YMMV.)

• Use LTspice's option dialog and fiddle with the simulation engine parameters in the SPICE tab. In particular, you can use the alternate solver, which is slower but have higher internal accuracy, which could make some simulations converge. Refer to the help file for further information.

• Try to break down your schematic in simpler parts and see if they can be simulated separately. Sometimes a small part of a circuit is hard to simulate and it causes trouble even when included in a bigger schematic. If you identify such a culprit, you may try to narrow down the problem more easily, since you could simulate the smaller circuit faster (that's not to say that if all the sub-circuits work in isolation they'll work together well; sometimes you are unlucky!)