SPICE is a great tool for making sure your design works before you lay out the PCB and order it manufactured. However, if you're using the ngspice built in to KiCad, you'll be limited in what you can simulate. Through no fault of KiCad devs though. Here's how I came to know this.

I laid out the schematic for the Slave Board (Screw Terminals) portion of the modular power supply, and I decided I wanted to simulate the power multiplexer portion of the board, as I don't yet have much experience in power electronics.

The whole schematic looked like this:

I copied the power mux section and put it in its own schematic, added 5V, 9V, and 20V voltage sources on the respective rails, and put 3.3V on the gate of one of the MOSFETs, as I was going to drive the MOSFETs using GPIOs.

Good thing I simulated it, this was a terrible idea.

Here's the operating point simulation:

The computed voltages and currents are in the PDF, the voltage indicated on top of each net. You just need to zoom in to see them.

I found that there was a 3.12V drop across allegedly "ON" MOSFET (Q3)! It's supposed to have 20mOhms Rds at minimum drive voltage of 0.9V, which I thought I was well above by putting 3.3V on the gate. At a current of only 1.4A, ON-state Rds would not account for anywhere near that much of a voltage drop.

After a bit of head-scratching I realized my error: the drive voltage is V_gs, not V_g relative to ground. Since the FET was on the high-side, the voltage on the source, if an inversion layer were to form (that is, the FET become a closed switch), would be the rail voltage, so at least 5V. Gate voltage would only be GPIO voltage, so ~3.3V. And so there would be a negative bias on the gate-source junction, and the FET would begin to shut down.

This process stops at some point, once the bias becomes positive, hence the 1.88V on the output rather than 0V. But this is not at all what I want to happen.

With an enhancement-mode N-MOSFET on high-side, you need to apply a voltage higher than the power rail, necessitating some sort of additional voltage-boosting circuitry, perhaps a charge pump or a bootstrap circuit (described in this AN from TI). Bootstrapping is only useful with rapid switching, as it can only turn the N-MOSFET on for a finite time before the boost capacitor runs out of charge. It isn't clear that a charge pump couldn't work, but I figured there must be a better solution...

P-MOSFETs work great high-side, but they have too high R_ds. A depletion-mode N-MOSFET would be perfect, but hardly anyone sells them so there's quite poor selection. The cheapest on on Digikey with more than 10A I_max is $10.08. I settled on placing a load switch on each rail. Specifically the TPS22811LRPWR for rails below 16V and the TPS1HB16AQPWPRQ1 for rails above (up to 36V).

Having just caught an error with SPICE, I wanted to simulate my new load switch based design to see if I had missed anything else. I was careful to prefer TI parts, as they have been so reliable with SPICE models thus far. Indeed there are "unencrypted" models available for TPS22811 and TPS1HB16A. But note the scare quotes. I got an error upon running a simulation (after fixing several other errors):

warning, can't find model 'dbreak' from line
    d_u4_d12 u4_n01176 in dbreak

...

Error on line 281 or its substitute:
  d.xu3.d_u4_d12 xu3.u4_n01176 unconnected-_u3-in-pad5_ dbreak
could not find a valid modelname
    Simulation interrupted due to error!

Grepping the library tps22811x_trans.lib revealed dbreak was, in fact, not defined anywhere in there. I did a recursive grep on all the provided TI files and found this text in tps22811x_trans-PSpiceFiles/TPS22811x_Startup/published/published.json:

{"ModelName":"Dbreak","FileName":"c:\\spb_data\\cdssetup\\psptilibdir\\drv8304.lib","ModelType":".model","DeviceType":"D","Source":"FROM_INC","isLibSigned":"true","isAllowed":"true"}`

Looks like the model is supposed to be provided by an external library drv8304.lib. A web search for drv8304.lib model" yielded the product page for DRV8304, from which I could download drv8304.lib. But wouldn't you know it, the library is encrypted! It can only be used in TI's simulator.

So in fact, I cannot use the load switch model, even though it is unencrypted. Thanks, TI, for sending me down this rabbit hole.

It seems that no manufacturers of load switches publish usable unencrypted SPICE models. Rohm's are totally encrypted. ST doesn't even provide any for the models I looked at. I guess the IP it reveals is too valuable.

Therefore, I present this lesson: the KiCad simulator is great, but it's limited to simple components by the fact that the complicated models are virtually all encrypted.

Another popular simulator, LTSpice, has the same problem. Models are encrypted using the public key of a particular simulator. And it seems that PSpice is usually the targeted simulator---at least it is for TI and Rohm models, which are the two suppliers of load switches I wanted to try.

There is a free program which can decrypt TI models, PSpice for TI, but it seems like it can't decrypt anything but TI models, so you're still SoL for Rohm models for example. And it's not Linux or WINE-compatible. Full PSpice costs about $3k for one year. Forget that.

And as far as availability of simple models, I found that ST, TI, Analog, onsemi, and Nexperia are all pretty good. Diodes Inc is bad. So are the random Chinese companies on Digikey.

Please send comments to blogger-jack@pearson.onl.