This page contains a number of entries which control various defaults
and features that apply when reading data files. These settings
always apply when reading, in particular during use of the commands in
the File Menu, as well as through use of the Read File
page of this panel.
- PCell evaluation: Don't eval native
Setting this check box will prevent evaluation of native pcells when
an instance is found while reading file input. If an archive file
contains the sub-masters, it is more efficient to use them rather than
recreate them through evaluation. Note that if sub-masters are not
provided, the super-masters for the pcells must be available.
This check box tracks the state of the NoEvalNativePCells
variable.
- PCell evaluation: Eval OpenAccess
Setting this check box will cause Xic to attempt to evaluate
OpenAccess pcells when instances are encountered when reading file
input. By default, this is not done, as evaluation is likely to fail,
and the exporter has probably included the sub-master cells in the
archive.
This check box tracks the state of the EvalOaPCells variable.
- Don't create new layers when reading, abort instead
By default, when reading an input file, layers are created if
necessary to match layers found in the file. The new layers are
appended to the layer table. If the source is GDSII or another format
such as OASIS that provides layer and datatype numbers, the new layer
name will be an encoding of these numbers (see 14.6).
If this box is checked, new layers will not be created, and
encountering a layer in input that is not mappable into an existing
Xic layer will be treated as a fatal error.
The boolean NoCreateLayer variable tracks the state of the check
box.
- Default when new cells conflict
This menu determines the default behavior when a cell from a file
being read conflicts with the name of a cell already in memory. There
are five choices: Overwrite All, Overwrite Phys, Overwrite Elec, Overwrite None, and Auto Rename. If AutoRename is selected, when a name clash with a cell in memory is
detected, the cell name of the cell being read is automatically
changed to avoid the clash. A suffix ``$N'' is added to
the cell name, where N is a small integer, and a warning message
is added to the log file. The Merge Control pop-up will never
appear in this mode. For the other four choices, in graphical mode,
when a conflict is detected, the Merge Control pop-up will
appear, if enabled. The initial state of the pop-up will be
determined by this menu, but the actions can be modified by the user
on a per-cell basis. If the pop-up does not appear either because it
has been suppressed or the program is running in non-graphical (server
or batch) mode, the default action will be performed.
The default cell name conflict behavior can also be set with three
boolean variables: AutoRename, NoOverwritePhys and NoOverwriteElec. If AutoRename is set (with the !set
command or otherwise), the other two variables are ignored, and the
auto-rename mode is enabled. If none of these variables is set, then
the default action is Overwrite All.
When a cell is encountered while reading an archive file or native
cell into memory with the same name as a cell already in memory, and
we are overwriting cells in memory, the new cell will overwrite the
existing cell in memory in most cases. The exception is for existing
cells that were read through the library mechanism. These cells have
the IMMUTABLE (read-only) and LIBRARY flags set.
The IMMUTABLE flag has no bearing on whether or not a cell can be
overwritten in memory. The overwritten cell will no longer be
IMMUTABLE. In releases prior to 3.0.11, IMMUTABLE cells would not be
overwritten.
If the existing cell has the LIBRARY flag set, it will be overwritten,
unless the NoOverwriteLibCells variable is set. A warning
message will be included in the log file in this case, but the read
will be successful, with the result being as if overwriting was not
enabled. If overwritten, the cell will no longer have the LIBRARY
flag set. In releases prior to 3.0.11, LIBRARY cells would always be
overwritten, unless IMMUTABLE was also set, which is the default for
library cells.
- Don't prompt for overwrite instructions
In graphical mode, when a cell name clash with a cell already in
memory is detected while reading a file, the Merge Control
pop-up may appear. This can be used to change whether or not to
overwrite the cell in memory on a per-cell and per-mode basis. When
this button is active, the Merge Control pop-up will not appear,
and the overwriting will use the default setting.
This state can also be enabled by setting the boolean variable NoAskOverwrite with the !set command.
- Clip and merge overlapping boxes
When this button is on, boxes on the same layer are merged together,
if possible, as files are being read into the database. Overlapping
boxes are clipped and/or merged. This applies to box objects only,
and not polygons (even rectangular ones) or wires, and applies only
for physical mode data. Electrical mode boxes are never merged. This
tracks the setting of the boolean variable MergeInput, which can
(equivalently) be set with the !set command.
This mode applies when reading input from a layout file, and is
separate and unrelated to the object merging as controlled from the
Editing Setup panel from the Edit Menu. These settings
have no effect when reading layout data.
However, on layers where the NoMerge technology file keyword is
set, box (or any object) merging is inhibited, in all cases.
- Skip testing for badly formed polygons
When set, the reentrancy test for polygons is skipped while an input
file is being read into the database. The default behavior is to
check each polygon for potentially troublesome geometry specification
while the polygon is being created.
This mode can also be enabled by setting the boolean variable NoPolyCheck with the !set command.
- Duplicate item handling
When reading data from a layout file, identical objects and subcells
placed on top of one another are sometimes found. Although these
generally cause no harm, this is almost always a layout error. This
menu provides three choices of how to handle the situation. The
default action is to print a warning in the log file, but import the
duplicate objects into the database. The Remove Duplicates
choice will also issue a warning, but will not add the duplicates to
the database. The third choice suppresses checking for duplicates
entirely.
This menu tracks the status of the DupCheckMode variable.
- Skip testing for empty cells
When set, there is no checking for empty cells as an input file is
being read into the database, and the pop-up that normally appears
when a file is opened for editing or viewing if there are empty cells
in the hierarchy is suppressed. An ``empty cell'' actually means that
both physical and electrical cells of this name either don't exist in
the hierarchy, or contain nothing. It is possible to check for empty
cells at any time with the !empties command.
This mode can also be enabled by setting the boolean variable NoCheckEmpties with the !set command.
- Map all unmapped GDSII datatypes to same Xic layer
This setting affects only the creation of new layers when a GDSII or
OASIS file is read into the database. The default behavior is to
create a separate new Xic layer for each GDSII layer/datatype
encountered that is not mapped in the technology file. With the
variable set, all datatypes on the new GDSII layer are mapped to the
same (new) Xic layer.
This mode can also be enabled by setting the boolean variable NoMapDatatypes with the !set command.
- How to resolve CIF layers
This is an option menu which specifies how Xic interprets layer
directives in CIF files.
The layer directive has the syntax
L token;
If the token is an integer, it might indicate the name of a
layer with the name being the same integer string, or it might be an
index into the layer table. The choices in the menu enforce these two
behaviors.
The default resolution method (Try Both) works as follows: The
parser reads ``L token;''. If token matches
an existing layer name (as string comparison), that layer is accepted.
If there is no matching layer, and the token is an integer in
the range of 1 through a maximum number, and there is no leading 0,
the token is tested as an index. if a layer exists with that 1-based
index, that layer is chosen. If the layer still has not been
resolved, a new layer is created in the layer table, with the given
(numerical) name.
The option menu gives two additional choices. The By Name
choice will skip the index test. If the string match fails with all
existing layers, a new layer will be created. If the By Index
choice is selected, the layer tokens are assumed to be integers. The
string match test is skipped. If the index test fails, an error is
reported and the operation aborts. New layers are never created in
this mode. The layer tokens must be positive integers with no leading
zeros that have a corresponding layer table entry.
The CifLayerMode variable corresponds to this set of options,
where its value of 0-2 corresponds to the three choices.
- Don't flatten standard vias, keep as instance at top level
This mode may apply when flattening a physical cell hierarchy. When
set, instances of standard vias are retained as such, rather than
being written as geometry. This check box tracks the state of the
NoFlattenStdVias variable.
- Don't flatten pcells, keep as instance at top level
This mode may apply when flattening a physical cell hierarchy. When
set, instances of parameterized cells (pcells) are retained as such,
rather than being written as geometry. This check box tracks the
state of the NoFlattenPCells variable.
- Ignore labels in subcells when flattening
When flattening a cell hierarchy, if this check box is checked labels
found in subcells are ignored, meaning not placed in the current cell.
Labels defined in the current cell are not affected. This is intended
to prevent net name labels from subcells conflicting with net name
labels defined at higher hierarchy levels. The check box state tracks
the NoFlattenLabels variable.
- Skip reading text labels from physical archives
When set, text labels will not be read from a layout file when reading
physical-mode data. It is not generally advisable to use this, as
text labels, though not physical objects, should be assumed to be
present for a purpose. However, this check box gives the user the
flexibility to strip these out.
In Xic, text labels are included when the bounding box of a cell is
computed. If a text label actually determines the boundary of a cell,
the bounding box of the cell may report differently from other tools.
The effective size of a text label is not well defined, and other
tools will probably make different assumptions about font size, etc.,
or may not include text labels in bounding box computations.
The state of this check box tracks the status of the NoReadLabels variable.
