next up previous contents index
Next: Special Escapes Up: Property Specifications Previous: User-Specified Electrical Property Specifications   Contents   Index


Xic-Managed Electrical Property Specifications

The properties that are set by Xic in electrical mode are described below. The electrical property values use the integers 1-21. The values 22-30 are reserved for future use.

bnode property, number 9
The bnode property identifies the location of a ``bus connector'' which is used to specify multiple connections to a device or subcircuit. It may appear in subcircuit cell definitions and instance references.

5 9 index beg_range end_range x y;

The index is a non-negative integer index which serves to link the bus node to an existing node with the same index. The beg_range and end_range are non-negative integers which set the indexing of the bus. The bus bit indices range from beg_range through end_range. Note that the numbers can be ascending or descending. The ``bit'' for beg_range is connected to the node with the given index. The ``bit'' for end_range is connected to the node with index equal to index + abs(beg_range - end_range). If no node property has an equal index value, then that ``bit'' is simply open.

For cells, the elecX and elecY each have the general form

schemX[:symbX[,symbX ...]]
and similar for the Y values. This represents a single X,Y contact location in the schematic, and an arbitrary number of contact locations in the schematic symbol. The schematic value is separated from the symbolic values by a colon. The symbolic values are separated from each other by commas. If the 3.2 format is being written due to the Out32nodes variable being set, at most one number will appear following the colon, the first that would otherwise be listed if there are multiple contact points.

If there is no symbolic representation, or the terminal location has not been set in the symbolic view, the elecX and elecY each consist of a single number. In the more general case, both terms should supply the same number of integers.

In cell instances, there is no colon delimiter, and the general form is simply a comma-separated list of numbers. This is all identical to the coordinate specification for a node property.

node property, number 10
The node property defines a circuit connection point. It appears as a property of wires, device and subcircuit instances, and cells. Its string is a bit different in the three cases.

Wire property

5 10 circuit_node

Any text that follows the form shown above is ignored. The circuit_node is the node number in the current cell of the net containing the wire. All wires that participate in connectivity, i.e., on the SCED layer and any layer with the WireActive technology file keyword applied, should have a node property.

Instance property

5 10 circuit_node index elecX elecY [name]

A subcircuit or device instance will have one node property per circuit connection. The circuit_node is the node number of the connection in the current cell. The index is the terminal ordering parameter. Each node property of an instance will have a unique index. The indices form a compact run starting with 0.

The elecX and elecY, are integers, or comma-separated lists of integers. Both terms specify the same number of integers. Taken as ordered X,Y values, these provide the ``hot spots'' where connection to the terminal can be made. Xic allows an arbitrary number of hot spots per node. If the Out32nodes variable is set, which forces output compatible with earlier Xic releases, the elecX and elecY will each consist of a single value, the first in the list that would otherwise be output if there are multiple contact points.

Internally, there are 1000 integer counts per ``micron'', and hot spots must appear on a 1 ``micron'' (1000 unit) grid. In a cell file, scaling may be applied. In particular, the default for CIF and native cell files is 100 units per micron, but this is usually changed to 1000 units with the RESOLUTION 1000 directive. Anyway, if a user is for some reason writing a node property string by hand, the hot spot locations must be chosen appropriately, arbitrary locations do not work.

Anything that follows is actually ignored by the reader. The terminal's name is printed in output since it might be of interest to humans.

Cell property

5 10 circuit_node index elecX elecY [0xflagstype name phyX physY layer_name];

Cell property, old 3.2 syntax

5 10 circuit_node index elecX elecY [name phyX physY flags layer_name type_name];

The node properties applied to a cell make it possible for the cell to be instantiated and used as a subcircuit (or device) in another cell.

The property string parser can recognize and read the old release 3.2 string format for compatibility. When writing output in any file format, if the variable Out32nodes is set, the old string format will be generated. This will, however, strip out multiple contact points if any have been defined, as this is not supported by the older format, which allows exactly one contact per node. The variable tracks the Use back-compatible format (warning! data loss) check box in the Export Control panel from the Export Cell Data button in the Convert Menu.

The circuit_node is the node number in the current cell where contact is to be made. In a device cell that has no internal nodes, this will be -1. The index is an ordering parameter as discussed above. Index zero is the reference node. When the device or subcircuit is placed in a schematic, the location of the reference node corresponds to where the user clicks.

The elecX and elecY each have the general form

schemX[:symbX[,symbX ...]]
and similar for the Y values. This represents a single X,Y contact location in the schematic, and an arbitrary number of contact locations in the schematic symbol. The schematic value is separated from the symbolic values by a colon. The symbolic values are separated from each other by commas. If the 3.2 format is being written due to the Out32nodes variable being set, at most one number will appear following the colon, the first that would otherwise be listed if there are multiple contact points.

If there is no symbolic representation, or the terminal location has not been set in the symbolic view, the elecX and elecY each consist of a single number. In the more general case, both terms should supply the same number of integers.

The remaining tokens are optional. The flagstype is a hex integer that if present must be prefixed with ``0x'' or ``0X''. The least significant byte contains a value that specifies a terminal type. This is a numerical equivalent of the optional type_name which appears in the old 3.2 format syntax. The values and keywords are listed below. Xic does not presently use this.

value keyword
0 input (default)
1 output
2 inout
3 tristate
4 clock
5 outclock
6 supply
7 outsupply
8 ground

The remainder of the word may contain any of the following flag bits.

0x100 (BYNAME)
The terminal will associate to a wire net by name, there will be no connectivity due to placement location in the schematic.

0x200 (VIRTUAL)
The terminal is ``virtual'' meaning that there is no wire vertex or subcircuit or device contact at the terminal's location in the schematic. This is irrelevant if the BYNAME flag is set.

0x400 (FIXED)
It set, Xic will not move the corresponding physical terminal location in the layout. This indicates that the location has been ``locked'' by the user.

0x800 (INVIS)
The terminal will be invisible in the schematic, except when the subct command from the side menu, used for terminal editing, is active. The corresponding terminal in the layout will show normally.

The name is the terminal name. This is either a short name provided by the user, or if not provided a default name will be created by Xic. The name is unique among the cell's terminals.

If the cell has a physical counterpart, the remaining arguments have significance. In particular, if the cell has no physical counterpart, or the node has no physical counterpart, the remaining parameters should not appear. The lack of physical coordinates informs the reader that this terminal has no physical counterpart. The coordinates should be set to zero in device cells that have a physical implementation.

If the node has a corresponding physical implementation in the layout, the physX and physY will be given. When the property is being read, the presence of these numbers indicates that internal setup to link to the layout is required. If both numbers don't appear, the node will exist in the schematic only. This is appropriate for devices that don't have a physical implementation, such as voltage sources, or for cases like the phase node of a Josephson junction, or in the case where there is no layout. In output, if the physical association exists. the two numbers give the corresponding point in the layout. These will be nonzero if the corresponding location has been identified, either by running extraction, or if the location was set by hand.

It is not necessarily true that all nodes of the device either have or don't have the optional parameters. The phase node of a Josephson junction device, for example, does not have a physical counterpart. The other two nodes do have physical implementations, since these are the physical connection points. A side-effect is that in SPICE files extracted from physical data only the two nodes will appear in the device instantiation lines. This is acceptable to WRspice, since the phase node is optional. If a device has no nodes with the optional parameters given, then it can never have a physical counterpart. The nophys property should also be given in that case. This is true for devices like voltage sources that have no physical implementation.

If the physical location is valid, a layer_name will be provided. This is the name of a physical layer which has the Conductor attribute, and an object on this layer touches or is under the physical location.

In the old 3.2 format, the flags values are the following:

0x2 (VIRTUAL)
The terminal is ``virtual'' meaning that there is no wire vertex or subcircuit or device contact at the terminal's location in the schematic. This is irrelevant if the BYNAME flag is set.

0x4 (FIXED)
It set, Xic will not move the corresponding physical terminal location in the layout. This indicates that the location has been ``locked'' by the user.

In the old format, instead of a numerical type code, an optional type_name can be given. This is one of the keywords from the table shown earlier.

name property, number 11
The name property gives the device an identifying prefix or name. If a name has been assigned to the device with the Property Editor panel or equivalent, that name will be used in SPICE output. Otherwise, the name prefix is suffixed with a unique integer generated by Xic to form the name. SPICE expects that the first character of the name match the convention for the device, for example, resistors use R, capacitors C, etc. (see the SPICE documentation).

Cell property, macro flag set:

5 11 prefix macro
Cell property, prefix starts with X or x:
5 11 prefix 0 subckt
Cell property, otherwise:
5 11 prefix

Cell instance property:

5 11 prefix.assigned_name devnum [subckt [physX physY]];

The prefix is the default name prefix, and should conform to the SPICE conventions. The assigned_name, if present, will be used in actual spice output. The assigned_name should not be present in device definitions, it is used in cell files for device instances to which a name has been assigned with the Property Editor. The prefix can start with any character, but is intended to have significance to SPICE. The character `@' is reserved for the terminal device. The assigned_name can be any contiguous string. The devnum is an index assigned by Xic to the device, and is used when forming the default device name. When reading, this value is ignored.

The name property for cells contains an internal macro flag, which replaces the macro property in 4.3.6 and later. This flag will be set if any of the following apply:

  1. Exactly two words are given, i.e., a single word follows the prefix, which can be anything.

  2. The word ``macro'' appears in a third word, following an integer.

  3. A macro property is found.
This syntax is backwards compatible with release 4.3.5 and earlier.

When the macro flag is set, its only effect is that in SPICE output, an `X' is prepended to the device name in device instantiation lines. Thus, SPICE will treat the device instance as a subcircuit call. These instances must have a model property that will match a .subckt definition somewhere, likely from a PDK device model file.

This accounts for devices that are likely the electrical part of parameterized cells, that implement nonlinear behavior through a network of controlled sources expressed as a subcircuit in the SPICE model definitions file. MOS capacitors and poly resistors are devices that are frequently modeled this way.

If the macro flag is set and the prefix already begins with X or x, the device is taken as a macro, meaning that Xic will not output a subcircuit definition for the cell, and a model property will provide the name of a subcircuit definition expected to be found in the model library or elsewhere.

The name property for instances is printed as shown. The ``subckt'' appears if prefix starts with ``X'' or ``x'' and macro is not set in the master. Coordinates additionally appear if a physical label was placed (in extraction). This is where the physical subcircuit instance label is located. All but the prefix and assigned_name (if any) are ignored by the reader, but can be seen printed in native cell files (for example).

Xic generates the internal device or subcircuit index, used as part of the default device or subcircuit name, according to the position of the upper-left corner of the bounding box of the object. The numbering starts with zero, and increases for positions with smaller Y value, or with larger X value for devices with the same Y coordinate. Each device and subcircuit type has its own numbering.

labloc property, number 12
The name, model, value, param, and devref property values are normally displayed on-screen near the device body. This is a device property for setting the default locations of the property labels when shown on-screen. If this property does not appear, the internal default locations are used. This property allows more control over label placement, on a per-device basis. This property should only be used in devices in the device library file. Presently, the property can only be added with a text editor by editing the property strings in the device library file.

5 12 pname code [ pname code ] ... ;

The pname is one of the literal tokens ``name'', ``model'', ``value'', ``param'', and ``devref''. For backward compatibility, ``initc'' is accepted as an alias for ``param''. The code is an integer, -1 - 23. If the code is -1, the default placement is used. If code is 0 - 23, the placement and justification are as shown in the figure: The '.' position implies the justification. Horizontally, all are left or right justified except for 16 and 19 which are centered. Similarly, vertical justification is bottom or top except for 17 and 18 which are center justified.

Figure D.1: Locations and justification for character position codes around the device bounding box.
\begin{figure}
\vspace{1.5ex}
\begin{center}\setlength{\unitlength}{3947sp}%
...
...put(2101,-1111){\framebox{(}1125,1200){}}}
\end{picture}\end{center}\end{figure}

The default locations are shwon in the table below. The locations differ when the height of the placement bounding box is less than or greater than the width.

Property height > width height < = width
name 5 2
model 8 13
value 8 13
param 11 14
devref 18 12

oldmut property, number 13
This property is used for compatibility with the mutual inductors used in the schematic files produced by the Jspice3 program. The format should not be used, and is not documented.

mut property, number 14
This property appears with the properties of cells containing mutual inductors, and is not copied to instantiations of the cell. Mutual inductors do not appear as devices in the device library file, rather, they are implemented with this property. Mutual properties are generated by selecting the ``mut'' device from the device menu, with one property assigned for each mutual inductor pair in the circuit.
5 14 num name1 num1 name2 num2 coeff [name];

This property appears only in the list for cell definitions, and not for instances. It defines a mutual inductor pair within the cell. The num is the index of the mutual inductor pair, used in forming the default specification to SPICE: ``Knum''. However, if the name appears (supplied in Xic by using the label editor on a mutual inductor label), the SPICE specification will use name (without num). The name1, num1, name2, num2 are the prefixes and assigned numbers of the inductors in the mutual inductor pair. The coeff is a string which represents the coupling factor as given to SPICE.

branch property, number 15
The branch property is used to define a ``hot spot'' that when clicked on yields a device parameter, such as device current, which can be used in plots. In SPICE, voltage sources and inductors have internal storage for current values present by default. Other device parameters may require additional computational or storage overhead. If the branch property is given in the device definition in the device library file, it is added to instantiated devices by Xic.
5 15 x y dx dy [string];

The x and y values specify the hot spot where the branch current can be accessed by clicking. The next two numbers specify the assumed direction of current flow. They are interpreted as a unit vector directed outward from the origin along the + / - x or y axes. Thus,

direction dx dy
+ y 0 1
- y 0 - 1
+ x 1 0
- x - 1 0
are the options. The string will be expanded and added to the token list in the prompt line when the branch is selected for plotting.

When the hot spot is clicked on, an expression will be produced which after expansion is added to the input line in the plot command. The string token can contain the following literal tokens, which will be replaced with the appropriate values during expansion:

<v> Voltage across the device
<value> The ``value'' property
<name> The device name

Anything else in the string will be copied literally. If the string is absent, the expression will be ``<name>#branch''.

Here are some examples. for a resistor, the string is

<v>/<value>
to return the current. Similarly for a capacitor,
<value>*deriv(<v>).
Thus the current will be computed using the WRspice deriv function. For an inductor or voltage source, no string is required, as the default
<name>#branch
is appropriate. For a current source, one can use
@<name>[c].
This works through the WRspice @device[param] mechanism, however the vector must be saved, most conveniently by setting the LibSave global property for the device (see B.8).

labref property, number 16
The labrf property is applied by Xic to labels that are associated with device properties or wire nodes. The property is not used in the device library file.

5 16 name num property; 5 16 x y 10;
This property applies only to labels, and indicates that the label is to be bound to a given property of a certain device or mutual inductor, or wire.

The first form applies to a label for an instance or mutual inductor property. Bound labels automatically reflect changes in the underlying property string, and may be used to set the string using the label editing function in Xic. The name and num are the device prefix and assigned number of the device to which the label is bound. The property is the property number of the bound property. If the label is assigned to a mutual inductor pair, the name is `K'.

The second form applies to labels that have been attached to a wire, and are used to contribute a name for the net containing the wire. The x and y specify the coordinates of a vertex of the wire. The 10 is the value of the node property.

mutlrf property, number 17
This property is assigned to inductor instances which are referenced for use in mutual inductor pairs. One such property exists per reference. It is not used in device library files.
5 17 mutual;
This property applies only to inductors that are referenced as one of a mutual inductor pair. There can be several such properties if the inductor is associated with multiple mutual inductor pairs.

symbolic property, number 18
The symbolic property is a property applied to cells which have a symbolic view associated. It does not appear in device library files, as all devices are essentially symbolic. It is not inherited by instances.
5 18 0/1 geometry_spec;
The third field is nonzero if the symbolic mode is active, and 0 if symbolic mode is inactive. The geometry_spec is a string of separated CIF primitives for the symbolic representation, which can include L, B, P, W, and 94 (label) directives. Each record (CIF primitive) is terminated by a colon (not a semicolon!) which must be immediately followed by an end-of-line character. Colons that are not at the end of a text line will not terminate a record.

The symbolic property may be applied to subcircuit instances, in which case it will negate the effect of a symbolic property found in the instance master cell. In this utilization, the property is named nosymb. The flag and geometry_spec are ignored and need not be provided. A subcircuit instance with this property would (in all cases) be displayed as expanded. Thus, it is possible in Xic to have different instances of the same subcircuit cell master display symbolically and expanded within the same containing cell.

nodemap property, number 19
The nodemap property is applied to the electrical cell definition and is not inherited by instances. The nodemap property provides a mapping between internally generated node numbers and assigned textual names.

5 19 0/1 name x y name x y ...;

The third token can be 0 or 1, but is unused. In releases prior to 3.1.5, a 0 value would disable the node map. In current releases, node mapping is always enabled.

The remainder of the line consists of triples containing an assigned name and a coordinate pair. The coordinates correspond to a device or subcircuit terminal connected to the assigned node, and serve as the reference to that node. See 7.11 for more information on node mapping.

The ``global'' properties are added to the electrical top level cell of a hierarchy when being saved. They save plot points and other information in the file, to use as defaults when the file is subsequently loaded for editing.

run property, number 7101
The run property string specifies the default analysis command entered when the run button is pressed which initiates a simulation.

plot property, number 7102
The Plot property is used only in electrical mode. The string represents the plot points used in the plot command, in the format of arguments to the WRspice plot command.

iplot property, number 7103
The Iplot property is used in electrical mode. The string specifies the points to plot when using the iplot button, in the format of arguments to the WRspice plot command.

The strings for the plot and iplot properties may contain special escape sequences indicating hypertext references or other characteristics. These are described in D.4.

In SPICE, Each line of a given device type begins with the device name, set by the name property. This is followed by the device nodes, corresponding to the order of enumeration in the device_node of the node properties. This is followed by text from the devref property, which is intended to provide a reference device name for current-controlled sources and the current-controlled switch. It is not used generally. This is followed by the value or model property (these are really just two different names for the same text field). This is followed by the text of the param property.

The device name, if not assigned by the user with the Property Editor command, and nodes are assigned by Xic so as to be unique.

The line looks like:

name n1 ... nLast devref value/model parameter_string

The name is either the user assigned name, or the device prefix with a unique numerical suffix created by Xic if no name was assigned. The nodes can be numbers or text tokens, in accordance with the current node name mapping (see 7.11). The remaining properties are read verbatim from the specifications, with hypertext references expanded.

Hypertext references are generated when assigning properties by clicking on devices or other features in the drawing. Since Xic assigns device names and nodes, if one needs to reference a specific device or node, a hypertext reference provides a link which is independent of the assigned values, which can change.

When applied to subcircuit cells and instances, the param property provides support for subcircuit parameterization, which is available in WRspice and some other simulators.

Here is a brief description of how to use parameterization. Suppose that you are editing a cell that contains a resistor, and you wish to parameterize the resistance value. Give the resistor a value property consisting of some word, say ``rshunt''. Using the Cell Properties Editor, give the cell a param property something like ``rshunt=2.5''. This will give the resistor a default value of 2.5 ohms. Editing another cell, place two instances of the previous cell. Using the Property Editor give one of the instances a param property of ``rshunt=5''. A label will appear containing this text. The other instance will not have a similar label. The resistor in the labeled subcircuit will have value 5, set by the param property applied to the instance. The other instance will have resistance value 2.5, as set by the param property applied to the master, which serves as the default value.


next up previous contents index
Next: Special Escapes Up: Property Specifications Previous: User-Specified Electrical Property Specifications   Contents   Index
Stephen R. Whiteley 2022-05-28