Hi,
I have no success in simulating.
I started with the sallen_key demo, and this works of course fine.
As a start I just replace the op-amp with someone else than the AD8051.
I have the tried 5 other spice models and none of them will simulate, these are NE5532, TSH22, LM358 and two different TL072.
As they all comes with the simulation error “doAnalyses: Too many iterations without convergence” I suppose that it is a common setup error or something that I have forgotten to enter.
There is by far not enough information to provide a concise answer. My guess is that the pin numbering is different for different OpAmps and you have to provide the correct pin number sequence (see http://ngspice.sourceforge.net/ngspice-eeschema.html#OpAmp)
You might also have a look at http://ngspice.sourceforge.net/applic.html#KiCad. The link provides some test circuits, among them a bandpass filter with two Sallen Keys in series using a TL072.
hi @holger,
the Sallen-Key TL072 test simulates perfect. And it was the numbering that was my issue. This is solved in the example by an obviously special written spice model, handling the 8 pins of the package by calling the subckt twice with U1A respectively U1B connections.
If I then want to simulate, lets say 6 packages TL072, must I then write my own spice model, handling the connections for all 12 op-amps?
You could also make a special symbol that matches the original spice model. My guess is that you would need to have the power pins on both subunit or you need to make a single unit symbol. Remember spice simulation has differing requirements and standards compared to PCB design. The official lib is created with PCB design in mind not for spice simulation (exceptions are the simulation_xxx libs). Which means most symbols from it are not directly usable for simulation. (And the simulation_xxx library symbols are not to be used for pcb design as they are meant only to be used in simulation projects.)
Hi @Rene_Poschl, I understand what you writes. But I was looking for more flexibility. The consequence of writing a dedicated spice model for the circuit to simulate is inflexibility. If I suddenly in the developing process, I want to replace one of the original op-amps with another type, then I must rewrite/edit the dedicated spice model. I do not find this appropriate, because it will take focus away from the actual developing process. I think we should consider how this issue can be solved general, so you as a user dont have to bother about writing interface spice models for each circuit you want to simulate
I am not shure if i understand correctly, but normally you define any “thing” in spice with a “.model xx yy()” directive which you then can apply on as many Symbols as you like to decribe them.
for example:
Describes a Transistor and every “NPN-symbol” now called “PUMH4” will act as you defined in the modell. If you want to change to another NPN Transistor, the symbol stays the same but you have to enter the variables for the new transistor. The principle is the same for opams.
The rest is more like making a GUI that makes your life easier to manage all your “.models” and symbols. Maybe you can get a bit more specific about where you need more flexibility.
Hi @Detzi, I think that a .subckt behaves some what different than the native types diode, BJT, MOSFET, JFET, but this must some of the experts explain
ngspice offers three types of devices (in reality there may be more, but the following three are sufficient for many designs):
very simple devices like resistors, capacitors and inductors
They are characterized by their devices instance names starting with R, C or L, their two nodes and their values.
simple active or passive devices (well sometimes they are not simple but …), like diodes, bipolar or MOS transistors, JFETs, transmission lines and some more.
They have their device instance names, the device name like 1N4148, the device type (D for diode) and the nodes.
ngspice has a built in model for diodes (or for transistors, tm lines). To inform ngspice about the device, the symbol will give the above information. However, this is not enough. How to tell ngspice about the specific data for this diode or device? This is achieved by adding device parameters. The parameters are provided in the .model (…) statement which is typically provided by the device manufacturer and which you have to attach to the specific device symbol.
complex devices
These are oscillators, OpAmps, logic gates, (even power MOS transistors) and others. Mostly they are integrated circuits. Here ngspice does not provide intrinsic models (due to the overwhelming large variety). However the device manufacturers offer complete models. They are assembled into a spice subcircuit. Again these subcircuit models have to be attached to the specific symbol, e.g. when you are using a specific OpAmp like a TL071. Of course you may attach the same subcircuit model to more than one symbol (if you use mor than one OpAmp of the same type).
The device manufacturers deliver a subcircuit model for a single OpAmp only (e.g. TL071). If you want to simulate a TL072 with two OpAmps in one package, you have to use an intermediate subcircuit that calls the vendor OpAmp subcircuit model twice. You don’t need to rewrite this subcircuit for the next TL072, but just attach it again to each of its symbols (the two OpAmp symbols and the power symbol, so not only U1A, U1B, but also U1C (I guess)!). However you have to write another intermediate subcircuit if you want to use a TL074 with four OpAmps in a package.
With this intermediate subcircuit model you will fulfill both the ngspice and the KiCad PCB requirements.
For sure selecting another OpAmp is part of the (circuit) design process. And you have to attach a suitable model (the one for the new OpAmp) to the symbol of the new OpAmp. How otherwise you (and ngspice) should get to know if the new OpAmp will do in your circuit?
Hi @holger, thank you for the informative and detailed description of the types. It was the intermediate layer I was missing. I have now learned so much that I can do my simulations though it could have been smarter. This thread has taken a twist away from the topic headline, so I think it will stop here.
