Hoo boy…convergence issues. Unfortunately we’re way past beginner on this one. There’s a lot to cover on this topic, so I’ll cherry pick what I think is the most important to know.
First, I suggest reading 15.3.9 of the ngspice manual. The first parameter tstep of the .tran statement is not the timestep interval, but the data output print interval. SPICE has an internal timestep control algorithm which senses changes in the waveforms and automatically increases or decreases the timestep as it sees fit. However, you can specify a maximum to force it always to operate at or below a certain timestep size. That’s the 4th parameter tmax, but you need to specify the 3rd parameter tstart (even if it’s zero) to use it, like so:
.tran 1u 5m 0 1u
So that explains the error you get, but it doesn’t fix it. Some node within the opamp subcircuit is failing to converge when beginning at a certain time step. It fails, tries at a smaller step, fails, and repeats this cycle until it hits its minimum. There can be many causes, and therefore, many fixes. For beginners, I recommend trying a slew of various things until you can get it to converge. Here are some suggestions (not in any particular order):
1.) Try a different model from a different manufacturer. Some are outdated, poorly written, or poorly tested. I attached one which is more stable but might take longer to converge since it has many internal nodes. It is made out of the transistor-based schematic found in section 7.2 of the datasheet.
LM741.lib (996 Bytes)
2.) Tweak the tstep and/or tmax parameters, like we discussed above.
3.) Try adding the .options method=gear command to the schematic. This forces gear integration instead of trapezoidal integration (the default) for the capacitor/inductor differential equations. Trapezoidal integration can cause oscillations. Mostly, the oscillations just show up as error in the output, but I’ve seen cases where it exacerbates convergence issues.
4.) Sometimes an over idealized circuit can cause issues so it’s better to try to include parasitics which match a real-world scenario. For example, voltage sources or inductors without series resistance. Try adding some series resistance to these, even if it’s only on the order of 1m or 10m. Adding bypass capacitors on IC power pins can help too, as long as there’s series resistance on the lines since they work in tandem.
5.) Since SPICE default options are meant for IC simulations, you can increase the convergence tolerances to match discrete circuity better. This helps to avoid infinitely bouncing between values very close to each other and hit the iteration limit. For beginners, I would just mess with RELTOL (default is 0.001 or 0.1%). So for example, to increase to 1%:
.options RELTOL=0.01
6.) You can give the program more chances to arrive at a solution by increasing the iteration limit for each time step by modifying ITL4 (default is 10). For example:
.options ITL4=50
I actually did some low-level digging, and if I change the E-source to a V-source within TI’s LM741.MOD file (line 55) it seems to fix the convergence issues. I’m not a fan of E-sources, especially the ones with the POLY(x) modifier. They constantly cause convergence issues, from my experience. This type of tweaking is well beyond beginner or even intermediate, but I thought I’d mention it and at least attach the result if you wanted to try it out:
LM741_no_e-source.MOD (2.5 KB)