None of the models I can find are .lib or .mod, which seem to be the only types that KiCAD can recognize. I tried .spi, but I receive a “too many parameters error”.
At this point, I think I need to create them myself in the appropriate file type. I can’t find a speck of info on how to do this for MOSFET nor anything on the syntax and required information for a .lib or .mod. I am happy to learn, but I need to start somewhere.
KiCad/ngspice either may use model parameter sets, e.g. models starting with a .model token. Or it accepts subcircuit models, e.g. models included in .subckt … .ends statements.
Whar else do you need?
The file name, expecially the file endings, like .lib, .spi, .mod, .md … are in no way connected to the contents of the file. There may be some preferences, but it does not matter for the model usage. So you will have to look into the file: Do I have a subcircuit model (which is typical for power devices), or a model parameter set starting with .model, and then you have to attach the model to your symbol accordingly.
What does a model (parameter) extraction require: You will need to study the intrinsics of a MOSFET, get to know what each parameter does contribute to the model. Then you will need to obtain suitable (measurement, data sheet) device I(V) and C(V) data. Then you will need to select a model type. Then you need to extract (optimize) the model parameters with a suitable software.
May I suggest that it is easier to switch-on Google and search for a spice model for IRF9Z24N ?
If you have finally found a model, you hen should give a step-by-step description of what you did to make use of the model and, if not successful, describe the error messages. Just stating “I receive a “too many parameters error”” is by far not enough information if you really want us to help.
Saber is a proprietary simulation tool, and the model shown is written in MAST, which is Saber’s proprietary hardware description language.
Spice is also a form of hardware description language, and by far the most common one. Most Spice languages are pretty similar, but there may be minor differences. Some of those differences are in the Spice netlist syntax, and some are stuff like filename extensions. Models are often in the form of subcircuits, and the file extension can be all sorts of things depending on the flavor of Spice. They are usually straight-up text netlists, though sometimes they are encrypted. A .lib file usually contains a collection of subcircuits, and is made accessible using a .include statement within the main netlist.
I have a suggestion that may provide clues to my age, but still think is worthwhile. Try to do a couple simple spice circuits with at least one part using a .model statement (internal spice component model) and at least one part using a subcircuit, and do this strictly as a text file. Once you do this, much about Spice will become more clear, and will go a long ways towards being able to troubleshoot simulations and understand what every Spice GUI front-end needs to do. I think that Ngspice is a good vehicle for this, but you can run such files from within LTspice as well.
This is the first Google offering from the Infineon site:
.SUBCKT irf9z24n 1 2 3
**************************************
* Model Generated by MODPEX *
*Copyright(c) Symmetry Design Systems*
* All Rights Reserved *
* UNPUBLISHED LICENSED SOFTWARE *
* Contains Proprietary Information *
* Which is The Property of *
* SYMMETRY OR ITS LICENSORS *
*Commercial Use or Resale Restricted *
* by Symmetry License Agreement *
**************************************
* Model generated on Mar 7, 97
* MODEL FORMAT: SPICE3
* Symmetry POWER MOS Model (Version 1.0)
* External Node Designations
* Node 1 -> Drain
* Node 2 -> Gate
* Node 3 -> Source
M1 9 7 8 8 MM L=100u W=100u
* Default values used in MM:
* The voltage-dependent capacitances are
* not included. Other default values are:
* RS=0 RD=0 LD=0 CBD=0 CBS=0 CGBO=0
.MODEL MM PMOS LEVEL=1 IS=1e-32
Edit: Paulvdh. @jmk: I put triple backticks around you model, so the forum software does not *&^%$#@! the text.
You can also use the Preformatted Text button:
Those formats all look fairly readable. It looks like that if you’ve got some experience with those models, hand editing from a saber model to a .model or .subcircuit would not be very difficult. Maybe there already are scripts to do this?
Somewhere down the lines you find the information on the node sequence: drain, gate, source. So you will need a power MOS (PMOS) symbol with three nodes.
So as a next step may I suggest that you create a very simple circuit with such a power PMOS, attach the model and run a simulation. If that fails, you may post the project (with this simple circuit) here, and I can have a look.
It seems that was the problem. I should have noticed this. Thanks.
The MMOSFET in my circuit has a 3-pin model, but the symbol is 4 pins with Source and B shorted, and it works. Weird. I assumed this would be the case for the PMOSFET.
I just did a very simple simulation with the Infineon Spice model (.spi) and it runs beautifully.
I simply used a standard PMOS symbol from the “Device” library.
“Alternate node sequence” is set to 2 1 3.
Not weird. I suspect you shorted it in your circuit, which is not the same as doing it in the library. Shorting it in the library would leave you with 3 pins, so it would work.
