The first thing to do with any spice simulation problem is check your netlist, which is the easiest way to debug with graphical spice packages. If you don't have a .lib and the name of your downloaded package then you have a problem. (you can do this in view->spice netlist)
The second thing is you need to get your paths straight. If you do have a .lib statement, then the path of your .subckt file needs to follow the .lib statement. Example: if your .subckt file was named NCP1217.cir (or whatever its extension is, they are all text files anyway) was located in C:\LTC\libraries then the spice command that needs to show in the spice netlist is:
.lib c:\LTC\libraries\NCP1217.cir
If you put your file in the LTspice\lib\sub folder you don't need to provide the entire path.
There are ways through the attributes list (in your symbol files, .asy to be more specific) to include the .lib statement.
The last thing is you need your X line in the netlist to have the appropriate nodes, double check each node of the lt spice netlist and make sure it matches up with the netlist in your 3rd party model. Then if you have multiple devices, the last thing should be the name of the subcircuit.
Here is an example:
XU1 posrail negrail posterminal negterminal output DEV1376
Keep in mind that no spice model will even come close to the real world, most all models are simplified in spice to model selected parameters in the datasheet by the manufacturer and only approximate the real world. (after all if they really did a transistor model of each device, all you would have to do to create a copy of the device is download the spice file) Some models will give some kind of disclaimer as to what the model can and can't do.
That's a good step using current sources over voltage ones. You can use transfer functions under the form of Laplace
expressions, looking like this:
Laplace=(s + 1)/(s^2 + 2);
This, as seen, would be entered as the value of a G
source, for example. LTspice will know to transform s
into the complex exponential. It can also work in a behavioural source.
BUT while the Laplace
expressions will work flawlessly in frequency domain, they can result in garbage in time domain, something mentioned in the manual.
This is why, unless you're dealing with exotic transfer functions having sqrt(s)
, or similar, non-multiple of s
, it's better to derive your transfer functions using the basic RLC
elements. For example:
These can be combined into full-sized transfer function expressions, but they should be proper transfer functions; for improper ones, you'll have to juggle with the basic building blocks above, somehow. For stability issues, it's also a good idea to split the longer expressions into 2nd order ones. Here is an example:
You could also use S-param
files, but, IIRC, they're based on Laplace
. These are just examples on how to do it and, remember, it's just to avoid the awful performance in time domain of Laplace
expressions. Ultimately, the choice is in your hands.
The generic transfer function for the 2nd order block is this:
$$H(s)=\frac{a_{2}s^2+a_{1}s+a_0}{s^2+b_{1}s+b_0}$$
where \$a_n\$ and \$b_n\$ are the ones in the image, while \$s\$ is expressed as \$\frac{1}{2\pi f}\$ (since, as seen in the 1st image, G+C
means \$1/s\$).
As a reminder, the transfer function should be proper: the order of the numerator is less than or equal to the denominator's.
Best Answer
I edited the model into something LTspice understands. The model had a few issues with the SPICE syntax (LTspice is pretty strict about using Spice3 derived syntax).
Here is a updated model, and a discussion of the changes and compromises will follow:
I had to remove the spaces between the values and units in the model, which accounted for a lot of the ignored parameters right off the bat.
And LTSpice does have a
GASFET
model, but it is namednmf
(for n channel MESFET). Changing the model to the correct type for LTSpice further reduces the ignored parameters.Most of the those parameters are secondary parameters (and thus are included in a model for convenience, but can be modeled just as well using a netlist around the model) which I accounted for in the ATF34 subcircuit. Specifically, ohmic gate resistance and fixed drain to source capacitance.
The Tnom parameter is simply the nominal temperature, which is a global parameter in LTSpice and already defaults to 27 anyway, so that isn't needed.
Delta
is the power law for triode region operation and isn't accounted for by LTSpice's nmf MESFET model, so we will have to do without. But if your application is a LNA, then I would assume you'd only care about the saturation region, in which case this doesn't really matter for your application anyway and shouldn't influence your simulation meaningfully.Vbi
is just a different term for the gate bias voltage, which is referred to byPb
in LTSpice, so I changed it to the correct parameter name. That leaves just one unrecognized parameter,P
.This is the drain noise coefficient, and is not part of the model. The Statz model includes the flicker noise coefficient, and LTSpice's model DOES support that parameter, so I added it (
Kf
).It should work reasonably well but the noise might not be modeling drain noise noise correctly, and of course triode region voltage to current power law behavior.