Device models

In order to simulate the behaviour of the individual components, they have to be described mathematically. The underlying equations that describe the behaviour of a component are written into the simulator program (sometimes they can be added by the user).

The equations that describe basic components such as resistors (I = V/R), capacitors (I = CdV/dt) and inductors (V = Ldi/dt) may be reasonably straightforward. The equations that describe diodes, bipolar (bjt) and a variety of field effect (jfet) and MOS transistors become increasingly complex, sometimes with several equations describing the behaviour of different aspects of device performance in different regions of operation.

Because these sets of equations are very much based on the semiconductor physics of devices and the manufacturing processes used to fabricate them, for some families of devices, such as MOSFETs, different sets of equations may be used to describe devices in the same family. The different sets of equations may be used because the manufacturer wishes to describe the operation of their devices to a greater or lesser degree of accuracy.

Although the equations themselves are hidden deep in the source code for a simulator, in general the coefficients of the sets of equations are collected together in the form of a list. Individual devices of any particular device family can then be described by a list of coefficients.
This list of coefficients is called a model.

The individual coefficients in a model are called the model parameters.

A device model written in this way is called a .model statement.

Some devices such as Thyristors, opamps, linear regulators and switch mode supply chips are made up from a number of other devices connected together to form subcircuits.

A spice netlist of a device defined by a subcircuit is also referred to as a model.

A device model written in this way is called a .subckt.

Subcircuit models may themselves contain .model statements.

Subcircuits can also contain parameters and can also have parameters passed to them to change their characteristics for example to tailor them to a particular device variant.

Why are there different models for the same device?

Because each family of devices (resistors, diodes, bjts, jfets, MOSFETs etc.) is described by one or more sets of equations, each family has one or more models available for it.

One reason there are different models available for devices in the same family is because manufacturers give device models away for free. Therefore they do not want to spend any more time on developing device models than they need to. Basically, the more complex a model is, the more time the manufacturer has to spend on making measurements in order to derive the model parameters. Therefore if one manufacturer feels that a device can be adequately described by a simple model then they will use that rather than a more accurate but more complex and so more expensive one that may be available from a different manufacturer.

Another reason there may be differences between models of the same device is that there may be slight differences in the semiconductor fabrication processes of different manufacturers.
In the same way ththeyat there may be more than one .model available for a device. there may be different .subckt defined models available.

There may be differences between .subckt models because there are implementation differences in the device models and/or the physical devices from different manufacturers. For example there are slight differences in internal timings and even a subtle difference in the internal circuitry of the oscillator section of the UC384x family of SMPS controllers between the various different manufacturers.

Sometimes, there are differences in the models just to get around the copyright protection. Some differences are to optimise the model for a particular simulator and some differences are simply down to the preferences of the model writer.

.model statements

In the spice netlist of a circuit, the user can see the models listed in .model statements. When a schematic is saved, these .model statements are pulled in to the netlist by EasyEDA recognising the symbols and their associated device names given in the schematic. Each model may either be pulled in from a library or - for devices that are not in the EasyEDA libraries - by downloading a model from a manufacturer’s website and then manually pasting it directly into the schematic (the process of doing this will be described later).

Ngspice model types

To help identify model types and in particular if they are for N or P type devices, the following table of model types may be helpful.

Code Model Type
R Semiconductor resistor model
C Semiconductor capacitor model
L Inductor model
SW Voltage controlled switch
CSW Current controlled switch
URC Uniform distributed RC model
LTRA Lossy transmission line model
D Diode model
NPN NPN BJT model
PNP PNP BJT model
NJF N-channel JFET model
PJF P-channel JFET model
NMOS N-channel MOSFET model
PMOS P-channel MOSFET model
NMF N-channel MESFET model
PMF P-channel MESFET model

Although it is beyond the scope of this document to go into detail there are some other points about models that are worth mentioning.

  • Models for the basic resistors, capacitors and inductors used in a schematic are usually not shown in the netlist;
  • Some device models have a full list of parameters, some may only have a partially completed list. Missing parameters in models are simply replaced by default values.
  • Different simulators support different sets of models so in some cases the simulator may warn the user that some parameters are unrecognised and so are ignored. This often has little effect on the simulation results but if the user is particularly concerned about their effects then the only options are to find a model which only uses parameters recognised by ngspice or change to using a simulator (such as LTspice) that supports all the relevant parameters.

.subckt definitions

Not all devices are described by .model statements.

Models of more complex devices such as Thyristors (SCRs, Triacs and also Diacs), Insulated Gate Bipolar Transistors (IGBTs), operational amplifiers (opamps) and even many MOSFETs are often made up by connecting lower level devices to make a circuit that behaves like the desired device. This is called a subcircuit. The spice netlist of this subcircuit is then used to create a type of device model defined by what is called a .subckt. The low level components in subcircuits are described by the same sort of models (those lists of parameters or coefficients) as for the basic diodes etc., already referred to so a .subckt will often contain a list of .model statements describing the devices that are used to build the .subckt itself. Complex .subckts may even call other .subckts.

Behavioural models

Using Behavioural Voltage and Current Sources and expressions it is possible to create what are called behavioural models of components. These are models that behave like a device but which have little or none of the actual underlying realistic circuit defined and are mostly - or perhaps completely - described by explicitly defined expressions (equations). The models for most devices internally comprising more than one active component, i.e. ICs, are largely behavioural. This is a way of hiding the detailed information about the manufacturer’s process technology that low level spice modelling reveals.

The use of expressions and behavioural sources in EasyEDA is explained later in the book.

What if there is no model available for a device?

Not all devices have spice models that can be run in ngspice. There are a number of possible reasons for this.

1) Some models are encrypted and can only be run in certain proprietary simulation tools;

2) Some proprietary simulators support models that are not available in ngspice;

3) Some devices have models that only run in specific non-spice based simulation tools and which, for whatever reason, cannot be translated into spice models;

4) Some devices do not have publically available models;

5) Many devices predating the creation of the original spice program do not have models;

6) Models for some devices simply do not exist because the manufacturers have never created them;

7) Some models may be unavailable in EasyEDA because they are restricted by copyright or end user licenses so they can only be run in certain proprietary simulation tools or cannot be shared publicly.

In cases (1) to (3), there is no way they can be run in ngspice. They must be run in the simulation tools for which they were written.

In cases (4) to (7), it is sometimes possible to find an equivalent, alternative or similar device for which a spice model is available. The user must exercise caution and use their judgement in deciding if such an approach offers satisfactory simulation results.

It must be noted that spice was not originally written with support for thermionic devices (valves or tubes) so models for such devices exist only in .subckt form. They are usually created by enthusiasts rather than manufacturers and so they (a) can be hard to find and (b) should be used with caution. EasyEDA does have a library of valve models gathered from sources that we believe have written reasonably accurate models.

Note that models obtained from manufacturers are often subject to copyright restrictions. Please respect any copyright notices contained either in end user license agreements that may have to be accepted prior to the granting of access to a downloadable copy of a model or in the models themselves.

Similarly, models contained in the libraries of commercial simulation tools are subject to copyright restrictions.

It is often possible to find device models offered in forums, discussion groups and various online collections of models. Again, the user must exercise caution and use their judgement in deciding if such models really are suitable. Often it is not possible to establish where they originate from so their validity is very hard to verify. It is also possible that such models have been copied in breach of the originators’ copyright.

Where possible, models should be obtained from the device manufacturer but please read their End User License Agreements carefully to avoid falling foul of their copyright restrictions.

Finally, note that not all 3rd party models are compatible with ngspice syntax. Spice3 (.sp3) versions of models should run out of the box. Pspice models may require modifications to make them work in EasyEDA. TINA TI models generally take a lot of work to translate them into ngspice compatible models.

The relationship between spice models and device datasheets

Although some of the device models in EasyEDA have been specially written so that the user can easily tailor them to simulate a range of devices by editing parameters that can be found directly in - or inferred from - device datasheets (see: About the relationship between spice models and real world behaviour below), most of them are off-the-shelf models from the device manufacturers.

It is important to understand that, for many of these off-the-shelf models, the underlying equations and therefore the .model parameters and .subckt definitions bear little relationship to the sort of information that is given in typical component datasheets. Therefore it is usually not possible to take a device datasheet and simply write down a device models from the information given in it.

Whilst it is possible to extract spice parameters for a variety of devices from device datasheets and from actual device measurements, it is beyond the scope of this document to describe how this can be done.

More information about what the model parameters mean in diodes, bipolar transistors and MOSFETs, is available from:

http://www3.imperial.ac.uk/pls/portallive/docs/1/56133736.PDF

with individual slide sets:

http://www3.imperial.ac.uk/pls/portallive/docs/1/7292571.PDF

http://www3.imperial.ac.uk/pls/portallive/docs/1/7292572.PDF

http://www3.imperial.ac.uk/pls/portallive/docs/1/7292573.PDF

For more detailed information about bjt’s in particular, this book:

Modelling the Bipolar Transistor by Ian Getreu

is available from:

http://www.lulu.com/spotlight/iangetreu

And:

http://www.amazon.com/Modeling-Bipolar-Transistor-Ian-Getreu/dp/B000EYPQLU

Another excellent (and free) book about transistor modelling, is available by going to:

http://www.aeng.com/spice_modeling.htm

and registering to get a copy of:

Definitive Handbook of Transistor Modeling

More information about ngpsice is available from here:

http://ngspice.sourceforge.net/presentation.html

More information about Larry Nagel and SPICE is available from here:

http://www.omega-enterprises.net/The%20Origins%20of%20SPICE.html

Larry’s PhD dissertation Dissertation:

Laurence W. Nagel., “SPICE2: A Computer Program to Simulate Semiconductor Circuits,”

Memorandum No. ERL-M520, University of California, Berkeley, May 1975.

http://www.eecs.berkeley.edu/Pubs/TechRpts/1975/ERL-520.pdf

is actually very readable and instructive.

For more information about electronic circuit simulation and spice in particular, see:

http://en.wikipedia.org/wiki/Electronic_circuit_simulation

And:

http://en.wikipedia.org/wiki/SPICE

The relationship between spice models and real world behaviour

Not all spice models are created equal.

Here are just some of the things to be aware of.

Models of the same device from different manufacturers may offer differing degrees of accuracy. Sometimes models are kept simple in the interests of speeding up the simulations at the expense of accuracy. Sometimes they are complex because accuracy is considered to be more important than simulation speed. Models may contain some text at the beginnings of them to describe some of their limitations or their special features. It is often useful to read this information as it can help improve the convergence of simulations using them.

Not all diode models simulate reverse breakdown voltage.

Zener diode models can be of varying accuracy and are best put into test jigs to run a curve trace on them to compare them with the datasheet. Zener diodes are sometimes used as white noise sources. Zener models do not accurately generate the levels and spectrum of noise seen in real devices.

None of the bjt models simulate the reverse bias base-emitter breakdown voltage. Very few model collector-emitter or collector-base junction breakdown voltages.

Some models, particularly of high speed and high frequency devices may include package parasitics such as lead inductances and pin capacitances. Such models are almost always .subckt definitions of devices defined by .model statements but which have the parasitics connected to form a subckt. If the high frequency behaviour is not important, simulation speed can be improved by using only the .model statement without the parasitics. This .model can be cut and pasted out of the .subckt definition but often the .model statement will be for a transistor that is defined as a .model in its own right somewhere else on the manufacturer’s site or as an equivalent from another vendor.

Thyristor and Triac models can be of varying accuracy or simulate only a limited selection of all the device parameters.

EasyEDA has an in-house behavioural Thyristor macromodel and a behavioural Triac macromodel.

As far as possible, the EasyEDA in-house Thyristor and Triac models model almost all the datasheet parameters of the target device with the exception of di/dt behaviour with inductive loads. These devices can be tailored to model almost any device simply using the values taken from the datasheet for the target device.

Metal Oxide Varistors (MOVs) are a nightmare to model and are best avoided! Even the commercially available models sometimes do not run reliably in all conditions.

Some opamp models are highly detailed and can be very accurate but care must be taken to check that they are written using a syntax that is compatible with ngspice. Devices tailored for some of the commercial simulators will not run in ngspice without some syntax changes. Some may require special .options to be invoked for the simulator.

Beware that even some quite complex opamp models do not simulate supply current drains even as simple DC quiescent currents let alone the dynamic behaviour with load currents added in. This can be an advantage since it reduces the signal currents that have to be simulated. It also means that there is absolutely no point in including any supply rail decoupling for those device that are known to not model supply current drains since they do not draw any current: they only use the supply voltage to define things like common mode range or output swing.

Here is an example of a third party opamp model that does not model supply or output currents:

LM108 test jig

Some opamp models may make no attempt to accurately simulate the output stage behaviour versus load current. Similarly, many device models do not simulate the behaviour of inputs and outputs when they are taken above or below the supply rails.

Few device models simulate the excessive supply current drain of a supply reversed misconnection or a correctly connected device that is subject to a supply voltage above the stated absolute maximum supply differential.

There are a several device models in EasyEDA that have been specially written to reproduce the real world behaviours - such as described above - of the devices that they model.

For example, the EasyEDA in-house opamp behavioural macromodel can be set up to give an output voltage swing anywhere from a rail-to-rail to the more restricted swings of non-rail-to-rail output opamps. The output swing can be asymmetric.

Input resistance, bias and offset current and input offset voltage are modelled.

The input differential and common mode voltage ranges are modelled.

The current drain behaviour of the device if input or output pins are taken above or below the supply rails or if the supply polarities are reversed are modelled. Output polarity reversal due to inputs exceeding the common mode range is modelled for devices that exhibit such behaviour.

Frequency dependent common mode and power supply rejection are modelled.
Noise and temperature dependent effects are not modelled at present.

EasyEDA has an in-house behavioural macromodel which can be tailored to model a wide range of 3 terminal fixed and adjustable positive and negative linear voltage regulators which feature similar real-world behaviour to the opamp models.

For all of the in-house EasyEDA models, more information about them can be found in the .subckt definition itself simply by viewing the spice netlist of any saved circuit they have been put into.

How to change the model attached to a symbol

Please note that before attempting to edit device models, it is essential that the user is familiar with and understands the relationship between spice pin names and numbering, described in the section on Schematic symbols: prefixes and pin numbers.

To find device simulation models available in EasyEDA, see:

https://easyeda.com/forum/topic/How_to_find_simulatable_parts_and_run_a_simulation_in_EasyEDA-1YgasK2kC

Right now there are a couple of ways to change the model for a device.

1) Place a device from the EasyEDA Libs and then edit the device model name either in place in the schematic or in the right hand properties panel.

For instance, when an NPN bjt is placed in a schematic, it comes in with a default name of editing the model name of 2DC2412R. This name pulls the associated default 2DC2412R model into the spice netlist. Editing the device name from 2DC2412R to 2N2222 will pull the 2N2222 model from EasyEDA’s spice model library into the netlist.
The problem here is that until a model search function is up and running this approach is obviously too hit and miss for an arbitrary choice because there is no way to see which models are available to choose from.

2) The second option is a bit more fiddly but it allows almost any unencrypted device model to be run in a simulation. The process is similar for both .model and .subckt defined models.

For .MODEL defined models

1) Find a spice .model for your target device;

2) Copy and paste it into a text placeholder (the T hotkey) in your schematic (but please respect the EULA and copyright of commercial files);

3) In the right hand properties panel, change the text type from comment to spice;

Properties > Text type > spice

4) Place a symbol for the device from the EasyEDA Libs palette onto the schematic;

5) Edit the model name to the exact name of the model in the pasted file.

6) Done!

There’s an example of this here:

Playing with model parameters

This is another example showing using a generic depletion mode MOSFET.

It also shows a way to hack a MOSFET defined by a LEVEL 3 .model statement but which has a problem with some of the parameters not being recognised as being part of the model by ngspice, so that it can still be used directly with the MOSFET symbol.

In this example the L and W parameters of the original model are recognised as part of the .model statement. Note also that some of the other parameters are also simply not recognised by ngspice.

Here’s how:

1) Find a spice .model for your target device;

2) Copy and paste the .model statement into the schematic canvas;

3) Turn it into a spice directive:

>**Text Attributes > Text type > spice**

4) Place an N channel depletion mode MOSFET symbol onto the schematic;

5) Edit the ‘model’ attribute for M1 to include the unrecognised or modified L and W parameters so they look like this:

IXTT20N50D L=2E-6 W=5.5

This can be done either in place or via:

Part Attributes > Model > IXTT20N50D L=2E-6 W=5.5

Note that adding an asterisk at the start of the two lines in the .model statement that define the L and W (and any other unrecognised parameters as deemed necessary) parameters will comment them out. This stops these parameters being reported as model issues in the simulation report but it is not required to do so.

This process is illustrated in the following example:

N channel depletion mode MOSFET using a .model statement

For .SUBCKT defined models

The process described above works fine for simple .model defined models but for .subckt defined models it is a little more complicated because you need to tell EasyEDA that the model is a .subckt and not a simple .model.

Even some humble diode models are in fact .subckt defined to include things like package parasitics. For example, compare the 1N4148 and the 1N4148W-V models in the netlist.

There are three stages in attaching a .subckt to a symbol that already has a spice prefix of ‘X’ and so is expecting to call a .subckt statement.

  • Place the .subckt text into the schematic and activate it;
  • Place the symbol in the schematic;
  • Change the name of the symbol to exactly the same as the name of the .subckt;

The detailed steps to associate a new .subckt model to the symbol are:

1) Find a spice .SUBCKT for your target device;

2) Copy and paste it into a text box (the T hotkey) in your schematic (but please respect the EULA and copyright of commercial files);

3) In the right hand properties panel, change the text type from comment to spice;

Text Attributes > Text type > spice

4) Place a symbol for the device from the EasyEDA Libs palette onto the schematic;

5) Edit the model name to the exact name of the model in the pasted file;

6) Press the ‘I’ Hotkey or:

Click the ‘Edit Symbol…’ button in the Properties panel:

Part Attributes > Edit Symbol…

or do:

Right-click on the symbol > Edit Symbol

7) In the ‘Modify your symbol information’ dialogue box, check that the ‘Spice Prefix’ is ‘X’;

8) Check that the NUMBER of pins in ‘Edit Pin Map information’ is exactly the same as in the .SUBCKT pasted into the schematic: if it is not then the wrong symbol has been placed for the chosen .SUBCKT (or vice versa) so a different symbol (or .SUBCKT) must be chosen.

Note that ‘number of pins’ here means how many pins, not the pin numbers or names used to describe the nets they connect to in the .subckt netlist;

9) Check that the ORDER of the pins in ‘Edit Pin Map information’ is exactly the same as in the .SUBCKT pasted into the schematic. This can be very confusing because the pin NAMES may be different between the symbol and the .SUBCKT so it is first necessary to reconcile the two sets of names before attempting to confirm their order.

10) Click OK in the ‘Modify your symbol information’ dialogue box;

11) Done!

This process is illustrated in the following example:

Attaching a .subckt to a symbol 01

Some of the EasyEDA symbols such as bjts and all the MOSFETs have a Spice Prefix of ‘M’ and so are expecting to call a .model statement. To associate a .subckt to a symbol with a Spice Prefix of ‘M’ there are four stages.

So, in the following example, the NMOS_E symbol placed into the schematic from the EasyEDA Libs palette must be edited to change the ‘Spice Prefix’ of the symbol from ‘M’ (for a .model defined part) to ‘X’ (for a .subckt defined part).

  • Place the .subckt text into the schematic and activate it;
  • Place the symbol in the schematic;
  • Change the name of the symbol to exactly the same as the name of the .subckt;
  • Change the ‘Spice Prefix’ of the symbol from ‘M’ (for a .model defined part) to ‘X’ (for a .subckt defined part).

The detailed steps to associate a new model to a symbol and to tell EasyEDA that a device model is a .subckt and not a simple .model are:

1) Find a spice .SUBCKT for your target device;

2) Copy and paste it into a text box (the T hotkey) in your schematic (but please respect the EULA and copyright of commercial files);

3) In the right hand properties panel, change the text type from comment to spice;

Text Attributes > Text type > spice

4) Place a symbol for the device from the EasyEDA Libs palette onto the schematic;

5) Edit the model name to the exact name of the model in the pasted file;

6) Press the ‘I’ Hotkey or:

Click the ‘Edit Symbol…’ button in the Properties panel:

Part Attributes > Edit Symbol…

or do:

Right-click on the symbol > Edit Symbol

7) In the ‘Modify your symbol information’ dialogue box, change the ‘Spice Prefix’ from ‘M’ (for a .model defined part) to ‘X’ (for a .subckt defined part);

8) Check that the NUMBER of pins in ‘Edit Pin Map information’ is exactly the same as in the .SUBCKT pasted into the schematic: if it is not then the wrong symbol has been placed for the chosen .SUBCKT (or vice versa) so a different symbol (or .SUBCKT) must be chosen.

Note that ‘number of pins’ here means how many pins, not the pin numbers or names used to describe the nets they connect to in the .subckt netlist;

9) Check that the ORDER of the pins in ‘Edit Pin Map information’ is exactly the same as in the .SUBCKT pasted into the schematic. This can be very confusing because the pin NAMES may be different between the symbol and the .SUBCKT so it is first necessary to reconcile the two sets of names before attempting to confirm their order.

10) Click OK in the ‘Modify your symbol information’ dialogue box;

11) Done!

This process is illustrated in the following example:

Attaching a .subckt to a symbol 02

Another example of the process described above to change the Spice Prefix of a symbol is illustrated with the same EasyEDA N channel depletion mode MOSFET symbol from the EasyEDA Libs that was used earlier with the IXTT20N50D .model statement. In this example the MOSFET symbol is attached to a .subckt that has been created from the orignal IXTT20N50D .model statement in order to wrap up the L=2E-6 W=5.5 parameters and so make using the original model easier.

An N-channel depletion mode MOSFET using an EasyEDA .subckt

Attaching models to custom symbols

This is basically the same as attaching a model to any of the predefined symbols from the EasyEDA Libs except that the symbol is one that has been created from scratch or by editing an existing symbol. The rules for assigning and checking that the spice prefix matches the type of model to be attached (‘M’ for .model or ‘X’ for .subckt) and checking that the spice pin numbering matches that of the type of device defined by the .model statement or by the pin sequence of a .subckt defined model.


goToTop