next up previous contents index
Next: The Source Physical Button: Up: The Extract Menu: Extraction Previous: The Device Selections Button:   Contents   Index


The Source SPICE Button: Update From SPICE File

The Source SPICE button in the Extract Menu allows electrical information in a schematic to be updated or generated by reading a SPICE file. Pressing Source SPICE brings up a small pop-up containing an entry area for the name of a SPICE file to read, and three check boxes. The entry area is active as a drop receiver, so that the File Selection panel (or another file manager program) can be used to locate the file, and the name can be dragged into the entry area. The Go button will actually initiate the operation.

Node name mapping is turned on after the operation completes. Since a schematic produced in this way has every node name defined by a terminal, using the defined names, which correspond to the original SPICE file, is convenient.

The three choice buttons are:

all devs
If set, all devices in the cell which match a name in the SPICE file will be updated. If not set, only the devices that have names that were set explicitly by the user (by applying a name property) are updated.
create
If set, devices specified in the SPICE file that are not found in the schematic are created. If not set, only the properties of existing devices are updated. If the current cell is empty, create is taken as set.
clear
If set, the electrical part of a cell is cleared before reading the SPICE input. This implies create.

If create is set, or the target cell is empty, this command will create a schematic hierarchy from the SPICE file. The function may be used as follows: open a new cell and go to electrical mode. Use the Source SPICE button to read in a SPICE file. The devices and subcircuits referenced in the file will be arrayed in the drawing, each with the appropriate properties applied. Named terminals are placed at each device contact point, which establish connectivity (wires are not used). The drawing can be used for simulation or any purpose just as a schematic entered in the standard way. The created schematic can be modified by the user to replace the named terminals with wires and reset the device locations, to make a ``real'' schematic that is aesthetically decent.

Subcircuits are created as needed. They must be written out later (e.g., with the Save command). If a file exists in the search path with the same name as a subcircuit, it is ignored, as the subcircuit cells are created internally. When writing, therefore, it is possible to replace an existing cell file, but the previous version is retained with a ``.bak'' extension.

Devices are instantiated as needed, and given an assigned name from the SPICE file.

If create is not active, no new devices or subcells will be instantiated in a non-empty cell, though devices in the drawing with names which match those in the SPICE file will have their properties updated. Properties of existing devices are updated whether or not create is active. Similarly, if a subcircuit already exists, its devices will be updated, but no new devices will be created in the subcircuit.

If all devs is not set, only devices that have been assigned a name by the user will have properties updated. Devices with internally assigned names are skipped. This is to avoid problems due to the fact that internally assigned names will change when the circuit is edited, and updating from an out-of-sync SPICE file could be a disaster.

If clear is set, then the electrical part of the cell and subcells will be cleared before the SPICE information is read. This ensures that the cells contain only information supplied in the SPICE file.

In order to determine if a semiconductor device is a p-type or n-type, Xic will look for a corresponding model in the source file, or the model library if not found. If still not found, if the model name starts with ``n'' or ``p'', or if the model name contains ``n'' but not ``p'' or vice-versa, Xic will infer the type. If none of this succeeds, the operation is aborted, and the user must provide access to the device model.

Xic will also test the consistency of MOS models defined in the technology file (used when extracting physical data) and the MOS model assumed for use in the device library (usually the device.lib file). If the node count differs, a warning will be issued. The warning indicates that LVS will fail. See the discussion in the description of the DeviceKey global device library property in B.8.1 for more information.

All ``dotcards'' that are not otherwise handled are written verbatim in the top-level schematic as labels on the SPTX layer. Recall that the labels on this layer are ``spicetext'' labels (see 7.9.4), so that the label text is included in SPICE output generated from the cell. Labels will not be created if a label with matching text already exists.

There is no inclusion of text from .include or .lib lines or similar, these become labels on the SPTX layer in the top-level schematic.

Subcircuit calls that have no subcircuit definition will be written as spicetext labels, and a warning will be given. It is likely that they are resolved at simulation-time through .include or .lib inclusions.

All .model lines found in the SPICE source are written to a file in the current directory named ``cellname_models.inc'', where cellname is the top-level cell name. In the schematic of the top-level cell, a label is created on the SPTX layer containing a .include line for the models file (if the label does not already exist). Models that are defined within subcircuits are given a new hierarchical name to ensure uniqueness.

Nested subcircuit definitions are handled by assigning a new hierarchical name to the subcircuit (cell) which is unique.

Parameter definitions from .param lines, subcircuit definitions, and subcircuit instances are applied verbatim as param properties of cells and instances, or as labels on the SPTX layer for .param lines, within the cell corresponding to the subcircuit where found.

Although parameterization of subcell instances is allowed and works fine for simulation and other purposes, these parameters are effectively ignored in LVS. LVS requires that a unique master be created for each instantiation parameter set, and the parameterized instances be replaced by instances of the appropriate master.

Each of the option buttons has a corresponding !set variable. If the variable is changed while the pop-up is visible, the pop-up will be updated. Conversely, changing the state of the option buttons will set or unset the corresponding variables. The pop-up check box will be checked if the corresponding variable is set. The names of the corresponding variables are given in the table below.

all devs SourceAllDevs
create SourceCreate
clear SourceClear

There are two additional variables that are used by this command. These specify the names of the ground and terminal devices, as provided by the device library file, that this command will use. Generally, it is not necessary to set these variables, as the defaults should always be appropriate. The user may, however, prefer to use an alternative terminal style, or may have a custom device library with different names for these devices from those found in the device.lib file distributed with Xic.

SourceGndDevName
This variable specifies the name of the ground terminal device to use. If not set, the name ``gnd'' will be assumed. If this variable is set to a name, a ground device of that name must appear in the device library file.

SourceTermDevName
This variable specifies the name of the terminal device to use. If not set, the name ``tbar'' will be assumed, if that name is found for a terminal device in the device library. If not found, the name ``vcc'' will be assumed. If this variable is set to a name, that name must match the name of a terminal device in the device library file.


next up previous contents index
Next: The Source Physical Button: Up: The Extract Menu: Extraction Previous: The Device Selections Button:   Contents   Index
Stephen R. Whiteley 2017-11-08