next up previous contents index
Next: Device Library Aliases Up: Device Library File Previous: Device Library File   Contents   Index


Device Library Global Properties

The device library file handles ``global properties''. These properties appear at the beginning of the file, after the initial line but before the definitions. The syntax is

Property identifier string
where Property appears literally, identifier is a keyword or equivalent integer as described below, and the rest of the line constitutes the string. There can be any number of these lines.

The following properties are recognized:

SpiceDotSave This property is identified by the keyword ``SpiceDotSave" or by the integer 20.

The string consists of a SPICE key letter for a device (such as `R' for a resistor), followed by the name of a parameter known to SPICE for that device. While a SPICE deck is being created, and if this property was given, each device in the circuit that is keyed by that letter will trigger the addition of a line in the SPICE file in the form

.save @name[param]
The name is the name of the device, and the param is the parameter name given in the property. This construct forms a vector name which the directive ensures will be saved during simulation, and thus be available for output. This is the means by which device parameter data are made available by default in SPICE runs initiated from SPICE output generated by Xic. WRspice and other SPICE3-derivative simulators will recognize this form, however only WRspice will actually save the vector in interactive mode. SPICE3 ignores .save lines, except in batch mode.

This property is used in the supplied device.lib file, for current sources and the ``c'' (current) parameter. The branch property for current sources references ``@name[c]'', so that it is important to ensure that this vector is saved. Thus, the appropriate global property is

Property SpiceDotSave I c
or equivalently
Property 20 I c
This will produce lines in the SPICE output like
.save @isource[c]
for a current source named isource.

DefaultNode
This property is identified by the keyword ``DefaultNode'' or by the integer 21.

This property is used for providing a default node name for the last node listed in a SPICE output device line. This allows the use of a three-node MOS device, with the substrate node connected automatically. The feature is enabled by adding the following property line at the top of the device library file:

Property DefaultNode device_name num_nodes node_name
or equivalently
Property 21 device_name num_nodes node_name

The parameters are:

device_name: name of device (e.g., nmos)
num_nodes: number of nodes expected by SPICE
node_name: name of node to be added

For example,

Property 21 nmos 4 NSUB

A Property line should be added for each device which has a default node. The respective device descriptions in the device library file should also be modified to remove the substrate mode. The supplied device.lib file contains MOS models with this feature included, and also standard models.

Using the example above, a SPICE output deck will contain lines like

M1 1 2 3 NSUB ...
Also, there will be a line added at the top of the deck:
.global NSUB
This line tells WRspice to not modify this node name during subcircuit expansion. The user must explicitly add a connection to the global node, usually to a voltage source. This can be accomplished in Xic by placing a terminal device, and modifying the terminal name to the node name (NSUB).

DeviceKey
This property is identified by the keyword ``DeviceKey'' or by the integer 22.

Although still recognized, this property is obsolete and should not be used. The DeviceKeyV2 property syould be used instead.

There is an internal table of mappings from letters to devices, in accordance with the definitions and traditions of SPICE. For example, `r' (case insensitive) maps to a resistor device. It is possible to define new device keys, overriding the defaults. It is also possible to define multi-letter keys.

These keys apply when Xic reads a SPICE file and maps devices to those found in the device.lib file.

The format for the property specification is

Property DeviceKey prefix opt val nnodes nname pname
or equivalently
Property 22 prefix opt val nnodes nname pname

prefix
This is a short (usually single-character) device identification prefix, the first character if which must be a letter.
opt
This is a binary value, the token can be 0, no, or off if unset, or 1, yes, or on if set. If set, then the presence of the last connection node of the device is optional (such as for a BJT, which has an optional substrate node).
val
This is a binary value as above. If set, text following the nodes is saved in a value property and the model property is unset, as for voltage/current source devices.
nnodes
An integer giving the number of device nodes, including the optional node if any.
nname
The device name, or the n-type device, in the library.
pname
If this is not 0 or missing, it is the name of the p-type library device.

DeviceKeyV2
This property is identified by the keyword ``DeviceKeyV2'' or by the integer 23.

This is an extended version of the now-obsolete DeviceKey property that supports current-controlled sources and switch, and will allow any number of optional nodes. The older format is still recognized, but can not be used to create standard keys for these devices.

The format for the property specification is

Property DeviceKeyV2 prefix min max devs val nname pname
or equivalently
Property 23 prefix min max devs val nname pname

prefix
This is a short (usually single-character) device identification prefix, the first character if which must be a letter.
min
This is the minimum number of nodes used by the device.
max
This is the maximum number of nodes used by the device. The difference from the min is the number of optional nodes.
devs
This is the number of device reference names, which is one for current-controlled sources and switch.
val
This is a binary value, the token can be 0, no, or off if unset, or 1, yes, or on if set. If set, text following the nodes is saved in a value property and the model property is unset, as for voltage/current source devices.
nname
The device name, or the n-type device, in the library.
pname
If this is not 0 or missing, it is the name of the p-type library device.

The internal table provides the following defaults.

prefix min ]it max devs val nname pname
a 2 2 0 true vsrc 0
b 2 3 0 false jj 0
c 2 2 0 false cap 0
d 2 2 0 false dio 0
e 2 4 4 true vcvs 0
f 2 2 1 true cccs 0
g 4 4 0 true vccs 0
h 2 2 1 true ccvs 0
i 2 2 0 true isrc 0
j 3 3 0 false njf pjf
k 0 0 2 false 0 0
l 2 2 0 false ind 0
m 4 4 0 false nmos pmos
n 0 0 0 false 0 0
o 4 4 0 false ltra 0
p 0 0 0 false 0 0
q 3 4 0 false npn pnp
r 2 2 0 false res 0
s 4 4 0 false sw 0
t 4 4 0 false tra 0
u 4 4 0 false urc 0
v 2 2 0 true vsrc 0
w 2 2 1 false csw 0
x 0 0 0 false 0 0
y 0 0 0 false 0 0
z 3 3 0 false nmes pmes

The user working with MOS technology may need to understand and set this property for ``m'' (MOS) devices. For LVS, is is required that the electrical and physical MOS devices assume the same number of nodes. The device library provides a choice of three-terminal (nmos, pmos) and four-terminal (nmos1, pmos1) devices. Although either type of device can be placed in a schematic that is used for simulation, for comparison to the physical layout consistency is required with the MOS device extraction templates defined in the technology file Device blocks (see 16.8.1).

For consistency, there are two choices:

  1. The technology defines a three-terminal ``nmos'' device, and the schematics exclusively use the nmos schematic symbol (similar for pmos). In this case, substrate/well connectivity is simply ignored in comparisons.

  2. The technology file defines a four-terminal ``nmos1'' device, and the schematics use the nmos1 schematic symbol (similar for pmos). In this case, the substrate/well connection at each transistor is included in the connectivity comparison.

Three and four terminal devices of the same sex can not be mixed in physical extraction, however they can be different for p and n devices. For example, in a process where only the pmos devices reside in a defined ``tub'', it might be convenient to use three-terminal nmos devices, and four terminal pmos devices. In this case, the technology file should define extraction devices for a three-terminal ``nmos'', and four terminal ``pmos1''. The standard device.lib file should include the line

Property DeviceKeyV2 m 4 4 0 false nmos pmos1

and the user should remember to use the three-terminal nmos and four-terminal pmos1 library devices exclusively in schematics that will be used with physical data.

The !devkeys command dumps the current keys to the console window, which can be useful for debugging this capability.


next up previous contents index
Next: Device Library Aliases Up: Device Library File Previous: Device Library File   Contents   Index
Stephen R. Whiteley 2017-10-02