I can’t figure out why the below simulation is not working:
It’s a basic op-amp based current sink, where the current through R2 should be V_in+ / R2. It seems like it is a problem with the MOSFET, the op-amp is trying to drive the gate right up to +10V, but it still is not “turning on” and causing current the flow through R2.
Sorry for no extra information, because I’m a new user I’m unable to upload a .zip file of the project or a second image of the simulation results.
I think your intuition is correct. Using a MOSFET with all parameters set to default never works out right. In addition, you are using an integrated circuit MOSFET topology (BSIM3) instead of a discrete power MOSFET (VDMOS) which is the type that you want. Try this model out by replacing your .model statement and then editing M1 to use 2N7002.
.model 2N7002 VDMOS(Rg=3 Vto=1.6 Rd=0 Rs=.75 Rb=.14 Kp=.17 mtriode=1.25 Cgdmax=80p Cgdmin=12p Cgs=50p Cjo=50p Is=.04p ksubthres=.1)
@Ste bingo! You were indeed correct. After reading up some more on what intrinsic SPICE models are I replaced that MOSFET model line with the one you provided (for anyone who wants a quick TLDR: they are built-in models for various components like MOSFETs that don’t require you to define a complicated subcircuit to simulate, instead you provide a .model line with model parameters instead).
I also had to update the symbol since the VDMOS model expects three pins in the order: drain, gate, source.
That’s odd. Did you get an explicit error or just changed the symbol in anticipation? VDMOS should still run with 4 terminals as long as source (3) and body (4) are connected together, which it was in your original schematic and why I didn’t mention it. Actually, running it with only 3 terminals just causes the software to automatically copy 3 to 4 behind the scenes. Anyway, using an actual power MOSFET symbol showing the intrinsic body diode is much better practice so please continue to do it like that.
@Ste I got an explicit error from ngspice. As per page 159 of the ngspice user manual (http://ngspice.sourceforge.net/docs/ngspice-33-manual.pdf) it states that the VDMOS has the general form:
MXXXXXXX nd ng ns mname <m=val> <temp=t> <dtemp=t>
.model mname VDMOS <Pchan> <parameters>
As you can see there are only three pins listed, nd, ng and ns.
BTW I am no expert with regard to modeling. Do you trust your models to be accurate enough to insure that your design will not oscillate? Depending on the actual op amp and the actual FET, some circuits might work OK in hardware as you drew it. But some could oscillate due to phase lag from the MOSFET gate capacitance loading the op amp output. If you are really going to build this, I recommend putting a decoupling resistor (maybe 200 ohms to 2K ohms) between the op amp output and the MOSFET gate. Add a second resistor (maybe 10K ohms) between the op amp inverting input and the MOSFET source. Finally add a capacitor (maybe 10 nF) between the op amp output and the op amp inverting input. This will limit phase lag around the op amp FB loop and prevent oscillation. The component values depend upon the exact op amp and MOSFET used and can be tweaked on the bench.
Thanks @BobZ for the input, that is really good advice to compensate for phase lag, I’ll take that into account.
We had also found this schematic below for the LT1492 that describes a similar compensation scheme.
Thanks. I understand that what it says in the manual, but it still works with 4-terminals specified since it is emulating LTspice model topology. Only reason I asked about an error is because I tried it myself and I was unable to duplicate such an error. If it exists I would consider it a bug and would report it to ngspice buglist. Because if this is true, then LTspice generated netlists would not run in ngspice. Would you be able to post your KiCad project which induces this error? Attached is my project in which I can’t get it to screw up as you describe:
vdmos_test.zip (4.2 KB)
Hi @Ste, I was able to replace the 3-pin MOSFET with the 4-pin MOSFET and get the error to occur again. Unfortunately I don’t have the privileges to upload the project files to this post, but I can post a screenshot of the MOSFET replacement and error message given during simulation:
To be honest, I would consider it a bug if a simulator requires 4 pins for a discrete power transistor. Power transistors definitely have 3 pins (except for some SENS-FETs which are not modelled at all). This aso would not be compliant with KiCad (What footprint for pin 4?).
ngspice currently offers the 3-pin VDMOS (D, G, S) and a 5-pin VDMOS which includes 2 thermal nodes (D, G, S, Tjunction, Tcase) for simulating self heating and the efficiendcy of heat sinks.
A 4-pin VDMOS model in ngspice might be something for the wish.list, probably using a compatibility switch.
Thanks for the screenshot! I appreciate you taking the time to try it again. I still can’t duplicate it, though, and I can’t figure out why. @moderators, sorry to bother you but it would really be helpful if you can give @gbmhunter file upload permissions.
I totally agree, which also means you are not understanding the point I was making. I never said anything contrary to your statements. I’ll try to explain in more detail, because it’s in the details where you can see why there could be an issue. Also, this is assuming the error is actually present, which I can’t duplicate at the moment on either ngspice-32, ngspice-33, or ngspice-33+.
LTspice’s schematic-to-netlist generator converts all 3-terminal MOSFET symbols to 4-terminals, including VDMOS by copying the 3rd node (source) to the 4th node (body) for each MOSFET “line”. You will find no netlist generated by LTspice which contains lines where a MOSFET only has 3-terminals specified. It’s always 4. Regardless of this behavior, its underlying SPICE engine can take either 3-terminal or 4-terminal when given a raw netlist input (i.e. not from a schematic). Therefore, if I created a schematic in LTspice and exported the netlist as a complete circuit, or as a subcircuit, ngspice would throw an error. I would consider this poor VDMOS emulation. One would have to manually remove the extra 4th terminal in each line of the exported netlist to get their subcircuit/library/model to work in ngspice.
ngspice should be able to duplicate LTspice’s SPICE engine behavior for a VDMOS, as such:
If 3-terminals are specified then it runs normally, and if 4-terminals are specified then it checks if they are the same, and ONLY if they’re not the same it throws an error similar to what LTspice does (see below) and refuses to run the simulation. Otherwise it should proceed as normal, auto-converting the 4-terminal to 3-terminal (or the other way around depending how you want to look at it).
@Ste given I can’t upload directly to here I’ve created a limited time OneDrive sharable link to the project files, see https://1drv.ms/u/s!AvTOGoG4ALv0j_xkuRTTzQVHBJ75-Q?e=J3qCts .
Thanks, @gbmhunter. I was able to figure out the issue. This bug has already been fixed in ngspice-32 (ships with KiCad 5.1.8), which means you are using an older version of KiCad which includes ngspice-31 or older. You can put the following text on your schematic to force the Simulator app to display the ngspice version in the log, as shown in the subsequent screenshots:
.control
version
.endc
Anyway, if you plan on doing plenty of simulations, I recommend upgrading to at least ngspice-32. Holger also made the latest ngspice features available to KiCad users by compiling a special version of ngspice-33 for Windows KiCad which can be found here: http://ngspice.sourceforge.net/download.html#kicad
Thanks for taking the extra time and effort in helping me debug this. Here’s an upload for my version of your entire project, for reference.
op-amp-current-sink-simulation.zip (8.5 KB)
@Ste you are indeed correct, I just checked with the command you mentioned…I’m running v31. Thanks for the assistance! I’ll update KiCad to the latest version and see if that gets me a newer version of ngspice, and if not, I’ll use that special build you linked above.