Tons of convergence errors

Hi,

I am constantly getting convergence errors with most TI models, the OPA333, OPA387, OPA135, and a lot more, like the INA133, some models from Maxim, ADI, etc… It is not in a specific circuit, almost all circuits I do have issues. Both LTSpice and Tina-TI are able to handle these models without any issues, but QSPICE sends a fail gmin stepping, then starts doing pseudo transient analysis, then just fails. Sometimes no errors are shown, yet, the results are completely off. Sometimes the Pseudotransient analysis does converge but it takes like 45 seconds.

I’ve been messing around with gmin, gshunt, with no luck. Any suggestions?

Picked two TI model OPA333 and INA133, according to their PSpice example. No convergence issue can be observed.

parent.OPAx333.qsch (6.6 KB)
OPAx333.txt (18.4 KB)

parent.INAx133.qsch (5.5 KB)
INAx133.txt (3.8 KB)

1 Like

That being said,
I do often get frustrating convergence problems when putting an op-amp model in a Spice version different from what the model was made in.

  • The manufacturer’s model works fine in a test setup.
  • The rest of the circuit works fine with a simple representation of the op-amp,
    including realistic bandwidth, phase margin, etc.
  • But the manufacturer’s model will not converge in the application circuit.

The logarithmic amplifier below simulates fine with the OPA376, but TI’s model of the OPA333
oven settles to operating points with +7.5 V at the output, given ±2.5 V supplies. Even when the initial condition is found, a .tran simulation with the OPA333 is soon stuck in small timesteps.


[Edit: In my case, I can avoid the problem by removing the a coarsely modelled pair of protection diodes across the inputs:
.SUBCKT ESD_BB_OPAx333 ESDN ESDP
.MODEL ESD_SW VSWITCH(RON=50 ROFF=1E12 VON=2700E-3 VOFF=650E-3)
S1 ESDN ESDP ESDN ESDP ESD_SW
S2 ESDP ESDN ESDP ESDN ESD_SW
Here, VSWITCH is syntax from HSPICE, but QSpice seems to interpret it reasonably, but somehow that protection diode is tripping intermittently, and breaking the assumption of a negative gain from IN- to OUT.
I do not think that was the root problem, just one element in the chain of events that lets the problem appear in my application.
]

I do not think it worth too much time to try to avoid the problem, but instead build your own simpler representation of the op-amp that reproduces the things you care about, and move on the prototyping the circuit.

I will upload a schematic with the problem I have. I don’t know if it is the way I am importing the models. Thanks for your contribution.

I don’t think the problem is your method of importing the model.


TI’s model for the OPA333 works in Qspice in only small set of applications, that happens to include their example file.

  • If we use an offset of 0.1V sin 0.1 1 1k so the initial voltage is nonzero, Qspice finds an stable operating point with −7.5-V output.
    We can skip finding the operating point with the option ‘Use Initial Conditions’ (UIC) but then we need to specify an initial voltage with ic= on each capacitor . . . or just let Qspice use the default zero voltages and try a transient simulation from there. After a brutal first 10 µs, the transient luckily settles on a reasonable solution.

  • If we increase the gain from 1× to 5×, the output clips, and at 0.4 ms when the circuit begins to recover from overload, Qspice gets stuck in small timesteps.

Analysis
OPA333_expanded.qsch (221.0 KB)
TI’s model OPAx333.lib contains no transistors nor diodes. It matches the experimental results with a behavioural model, using Rs, Cs, linear G-devices, nonlinear B-devices with I=limit(x, upper, lower) and switches.
All the gain is in the first stage, later stages gain 1.0, probably so signals can be easily interpreted as the effect they would have on the output; this means intermediate signals can go beyond the power rails, as the signals are scaled up from the real voltages on wires.

The model comprises
Error Integrator – Active Filter – Output Buffer

The Output Buffer is clipped by comparing its output voltage with the power rails, and applying a correction to its input to clip the output.

When the Output Buffer is clipped, the Error Integrator continues to charge its output capacitor in a direction to correct the output (as if it could overcome the clipping). We have integrator windup.

There is a BLOCK_DC switch that acts like a pair of Zener diodes between the corrected input to the Output Buffer and the Error Integrator output. This BLOCK_DC conducts when the integrating capacitor is outside ±10V from the clipped output – thus allowing just some integrator windup, presumably to match the experimental recovery from saturation.

That BLOCK_DC switch, when closed, is positive feedback around the active filter. Due to rounding errors entering the Rs and Gs, the low-frequency gain of the active filter is 1.0006, so we have the potential for positive feedback with amplification.

With 0.1 V input, the Error Integrator will work to charge its capacitor to AvOL×0.1V = 300 kV. The G-devices have no problem with 300 kV, and the Active Filter output is approaching 300 210 V. The clipping circuit will correct that high voltage, with some delay, but the clipping circuit has a limit(x,upper,lower) function that restricts it to a reasonable correction, negligible compared to 300kV.

BLOCK_DC shorts, to try to bring the capacitor within 300 210 V ±10 V, which is larger than 300 kV. The voltage grows until other nonlinear devices stop it.

The Gmin-stepping method of finding the operating point happens to find a solution where the integrating capacitor has 112 886 kV, amplified to 112 967 kV by the Active filter, but then reduced back to 112 886 kV by the clipping circuit.

We can avoid this operating point (by not using Gmin-stepping, reducing the Active Filter gain, ic=0 on the integrating capacitor, or otherwise).
But even then, if we increase the gain or the input such that the output clips in the transient simulation, the simulation stops due to the timestep going to zero.

The switches in BLOCK_DC have Ron=10mΩ Roff=1GΩ with a transition voltage of 10 mV. So in the transition SPICE is computing a resistance from 1e9Ω to 1e-2Ω so one can imagine it may be difficult to coding the maths for this transition using 14-digit IEEE double-precition registers. NgSPICE recommends a ratio below 1e12, or else adjusting some options. Ron=1Ω here lets the simulation continue.

The BLOCK_DC function should be done differently. Preferably, the Error Integrator itself would slow its rate of charging the integrating capacitor as the voltage on that capacitor approaches the power rails.

Moral
I wasted a lot of time (which have time at the minute) reverse-engineering the Rube-Goldberg device that TI assembled over the years to match experimental data. But now I know what I’m missing if I forego a TI model that doesn’t converge.

Often software helps to get useful work done.
Sometimes software distracts us from useful work.

Burr-Brown designed some nice amplifiers, so we should feel free to design using them, but might sometimes have to do so without a manufacturer’s SPICE model.

1 Like

A minimal patch for OPAx333.lib to work in Qspice would be

- E_E4          N3116457 MID CL_CLAMP MID 1
+ E_E4          N3116457 MID CL_CLAMP MID 0.99; need loop gain < 1

- S_S1         3 4 1 2 _S1
+ S_S1         3 4 1 2 _S1 OFF
= RS_S1         1 2 1G
- .MODEL         _S1 VSWITCH ROFF=1E9 RON=10M VOFF=0.0V VON=10MV
+ .MODEL         _S1 VSWITCH ROFF=1E9 RON=1 VOFF=0.0V VON=0

- S_S2         3 4 1 2 _S2
+ S_S2         3 4 1 2 _S2 OFF
= RS_S2         1 2 1G
- .MODEL         _S2 VSWITCH ROFF=1E9 RON=10M VOFF=0.0V VON=10MV
+ .MODEL         _S2 VSWITCH ROFF=1E9 RON=1 VOFF=0.0V VON=0

Cutting the gain below 1.0 in the feedback loop, that can be formed when the output stage goes beyond the rails, removes the unreasonable high-voltage candidates for the initial operating point.

Declaring the BLOCK_DC switches to start in the ‘off’ state, solves the some cases where Qspice could not find any initial condition. (This might be redundant to reducing the gain but reducing the gain makes sense on its own.) VSWITCH is a Pspice feature, and Pspice does not document the ‘off’ flag so I’m not sure if this would cause a warning back in Pspice.

I think the .model for those switches should have been fine, based on the documentation for the various SPICEs. In fact, Pspice warns against making 'Von ’ and ‘Voff’ too close.
But here the control-voltages are tapped from the terminals of the switch itself, making a 2-terminal device like an ideal diode, and making Von = Voff creates a device with a simple piece-wise linear I-V curve. This avoids the “timestep too small” problem, so far as I have found, when Qspice comes to opening these switches.

1 Like

@OHara, I ran some tests based on your suggestion. I tried to make as minimal changes as possible, and by simply adding OFF in S_S1, S_S2, and changing VON=0 in .model _S1 and _S2, it seems quite stable.

parent.OPAx333.qsch (7.2 KB)
OPAx333_Ohara_ONLYSW.txt (18.6 KB)

Do you have a counterexample where changing the E_E4 gain must also be done to make the model operate stably? I also have experienced that modifying the switch can be helpful in TI model. I recall Mike explaining this in one of my reported cases: The technical issue is that the PSpice style switch doesn’t have IV slope once fully on or fully off, and it leads to false convergence.

No (realistic) counterexample.
I agree that specifying the off initial state seems to be enough to prevent Qspice’s initial-condition finder from stumbling onto the potential runaway feedback in the chain involving E_E4 (unless someone excites it on purpose with something like .ic V(clamp•x1)=105Meg)

I also agree that those S_S1 and S_S2 seem to work fine with the original 10-mΩ on-resistance, so long as Voff=0

I do not understand how to use the explanation about the “PSpice-style switch doesn’t have I-V slope once fully on/off.” The original SW as in Qspice has constant resistance Ron(Roff) when fully on(off) – the same as is documented for PSpice.

I can see how a discontinuous I-V curve could make it difficult to find a self-consistent operating point. I would guess Spice even needs a bit of help with things like Gunn diodes, with a continuous but non-monotonic I-V curve that makes it self-oscillate.

In this particular case, the switch is wired with the control lines across the switch, so the I-V curve is monotonically increasing in either case. When the OPA333 goes into or out of saturation, the voltage across the switch swings quickly (at the 0.2-V/µs slew rate of the amp) across the original 10-mV transition, Qspice slows the timestep dramatically.

In the OPAx333 model with many other elements around the switch, Qspice would need to iterate to find the current through the switch, and I think SPICE in general uses one or a fixed number of iterations per timestep, even when the thing requiring iteration (here a nonlinear I-V curve) does not itself depend on time. Qspice seems relatively aggressive about simulating quickly when it can, and this switch is inside that cursed feedback loop, which seems to be enough to break Qspice’s timestep control when the switch has a transition curve.

1 Like

I did send a couple bug-reports (with examples attached) to the official email under help::about

  1. QSpice sometimes finds the wrong operating point in TI models, .ns V(out)=0 can help
  2. QSpice often slows or stops with small timesteps when using TI models, setting a shorter max-timestep in tran often helps
    finds_unstable.qsch (13.3 KB)
    switches3.qsch (10.6 KB)
    switches2.qsch (10.1 KB)

I’m not sure, though, if it is feasible for QSpice to keep compatibility with TI’s PSpice at that level; I suspect the TI engineers will keep making more complicated models to match the details of their products, so long as those models work for them in PSpice.