# Convergence problems?

*I have been trying to understand your models of PWM controllers. You seem to use a BI current source in series of a capacitor very often. Can you please let me know why a capacitor is needed, and how you determine the capacitor value? Is it to help the convergence or to implement the pole of op amp? For example, the nodes of "hys", "latch", "Ierr" in UC3842A model you created, as attached.*

Whenever possible, I try to arrange a model so the capacitors do double duty, that is to both aid transient convergence and to provide some direct function (e.g., an opamp pole).

*I am puzzled with the necessity of adding the capacitor (with various value) when converting a current to a voltage. I would think a current source in [parallel with a] 1 Ohm resistor is adequate.*

This is fine for low frequencies and dc, but the capacitor is there to aid transient convergence in the face of behavior nonlinear enough to fall outside of the various error tolerance limits (to which the solver responds by reducing the time step). If the time steps go small enough, the capacitor will dominate the I/V behavior of any finite impedance (hence, the need to use current sources with parallel resistors rather than voltage sources). Since capacitors are linear devices, the behavior becomes linear and the solver can get through the highly nonlinear behavior zones by taking them in small steps.

It is best to make a real circuit capacitance (perhaps a circuit parasitic) perform this duty, but, since the solver will go down to picoseconds, it is almost always possible to choose a capacitor that has absolutely no effect within the normal bandwidth of the circuit, yet still functions very well as a transient convergence aid.

*I always use either "a voltage source in series of a 1G Ohm"...*

Never use a strict voltage source if you can avoid it. In LTspice, this can be as simple as filling in realistic values for a voltage source's parasitic resistance and capacitance (right mouse click on the source - advance for capacitance). LTspice will automatically convert such sources into their Norton equivalent (save you having to do the calculation manually).

*...or "a current source in series of a 1 Ohm" for "equation-type" solving purposes. However, it did not work all the time, either with the wrong value or convergence problem. I did also try adding a capacitor after I read your models. It seems to me adding a capacitor would not help.*

This is either because of other stiff voltage type sources elsewhere within the circuit or because the solver failed when it was trying to find the dc operating point (during which all the capacitors are completely ignored). The solver combats this by Gmin and/or source stepping (more on this later).

As good as it is, LTspice is not magic, and the old maxim "garbage in - garbage out" still applies. Many, if not most, third party subcircuit models are poorly written (don't let a big company name fool you). In order to get good dc convergence, a good model should have all its I/V relationships be continuous with continuous derivatives.

In order to get good transient convergence, a good model should, as much as possible, contain elements with only voltage inputs and only current outputs (Norton equivalents should be used to produce voltage sources). The only voltage sources should be zero volt sources used for current sensing. It can't be stressed enough that stiff voltage sources (especially nonlinear behavioral types) are problematic because, unlike current sources and/or resistors, they will not yield to capacitances at small time steps during convergence difficulties in a transient analysis.

Whenever the simulator reduces the time step, it is because of nonlinear circuit behavior. The implicit assumption is that, as the time step is reduced, the various parasitic and stray capacitances will come to dominate the nonlinear bits (which don't depend on time). At really small time steps, only the capacitances will matter and, since capacitances are linear, the circuit will converge and the simulator will be able to get past the nonlinear behavior. Of course this can't work if the models omit the "parasitic" capacitances (and resistance).

To follow these rules means that p/n junctions (and other nonlinear element nodes) should never be without some series resistance and some parallel capacitance.

Now back to problems finding the dc operating point. When the direct Newton method fails the simulation goes through the process of GMIN stepping and then if that fails, it tries source stepping. The source stepping algorithm makes uses the foreknowledge that a realistic simulation always will have a known starting solution when all its sources are set to zero (i.e. that all node voltages and branch currents are zero as well). It also takes advantage of the fact that most all nonlinear elements (e.g. diodes, MOSFETs, etc.) exhibit linear behavior locally around zero (all junctions are off and other nonlinearities are, by definition, operating with small signals).

So, by starting from a known linear solution (i.e., zero ) the solver can bootstrap itself up to the normal operating point by gradually ramping up all the sources. In theory each successful step along the way allows linearly extrapolating an almost perfect set of initial conditions for solving the succeeding nearby step.

Problems come when starting at zero doesn't yield a zero output. For example, a behavioral error amp with a numeric reference voltage in a difference equation (i.e. "5-V(fb)") will go to 5V when all sources are at zero (LTspice actually has extended source stepping to B-sources to address this). Difficulties can also occur when ramping up through sharp corners or discontinuities in a nonlinear device's characteristic. Multiplying a trouble point by a unity node voltage (explained later) helps because it tends to tilt the solution trajectory slope closer to the expected path, thereby keeping it locally monotonic so it won't get stuck.

Also, bear in mind that a simulated circuit may have several numerically valid dc solutions, only one of which usually corresponds to the real circuit's natural solution. If an ac analysis produces wildly unexpected results, it may be due to an improper dc solution. Just because you don't get a dc convergence error message, don't assume all must be well - run a .op and check some of the numbers.

If you are having dc solution problems, first examine your simulation circuit for behavioral sources or other devices that may go highly nonlinear as the sources are stepped up from zero. Splitting a very nonlinear element into several pieces across several nodes can sometimes dilute the problematic behavior to the point where the solver no longer gets hung up on one very bad element. In such cases, adding more nodes can actually make the simulation run much faster.

If not already available somewhere in the circuit, a unity node may be created by setting up an isolated dc voltage source equal to one volt. Clearly, any b-source expression may be multiplied by the voltage on this node as many times as needed without changing the value of the expression during an analysis. The only effect on such an expression occurs during source stepping while seeking the dc operating point. Then, as this unity node is reduced to near zero, anything multiplied by it is also forced to approach zero.

Differencing circuits with a lot of dc and gain are always good candidates for the unity node treatment as are abrupt limiters. Behavioral expressions with node voltages in their denominators such that when the sources go to zero, the expressions blow up (something gone small / something gone to zero => infinity) can be especially troublesome. These types of expressions can be multiplied by the unity node raised to whatever power required to make them behave.