Under Unix/Linux, files are opened in 64-bit offset mode. This enables files larger than 2Gb to be processed.
Native Xic cells use a CIF-like ASCII format, with one cell per file. This is the default format used by Xic, but is not particularly efficient with respect to input/output speed and disk space.
In addition to the native cell-per-file format, Xic supports a number of archive formats, which can contain one or more cell descriptions.
The GDSII directives absolute magnification, absolute angle, and absolute path width are not supported in Xic. If found in input, the values are taken as relative, and a warning is issued. These are not supported by other file formats in a portable way, and should be considered obsolete.
More information is available from wrcad.com/oasis.
The present status of OASIS support in Xic is complete:
Although it is ``not documented'', Xic can directly read OASIS files that have been compressed with the gzip program or equivalent. Unlike for GDSII files, this is not really supported, and it is not possible to write gzipped OASIS output from Xic. It is preferable to use the compression provided in the OASIS format.
If the input file is in CIF format, and symbol (cell) names are not provided (i.e., no symbol name extension is found), the generated symbol names will be ``SymbolN'', where N is the integer symbol number given in the CIF file.
In general, files produced with this Xic release are NOT compatible with pre-Xic-4.0 releases.
The native cell files and CIF now accept and generate arbitrarily long layer names. These are not compatible with traditional CIF, or with older Xic releases. Older Xic releases will fail to read native cell files, or CIF files, with non-traditional layer names. Traditional CIF layer names contain four characters or fewer.
Native cell files and CIF files from the 4.0 branch that use traditional CIF layer names should be backward compatible in this respect.
There is a new syntax used for electrical node property strings. This will, in general, prevent backwards compatibility of schematic files. If the Out32nodes variable is set, files written will use the old node syntax, with loss of some data that is not supported by the older syntax, but files will be readable by older Xic programs.
The Convert Menu entry brings up a menu containing commands which perform explicit translations and other manipulations and diagnostics.
The table below lists the commands found in the Convert Menu, and gives the internal name and a brief description.
|Export Cell Data||exprt||Export Control||Create a cell data file|
|Import Cell Data||imprt||Import Control||Read a cell data file|
|Format Conversion||convt||Format Conversion||Direct file-to-file format conversions|
|Assemble Layout||assem||Layout File Merge Tool||Merge layout data|
|Compare Layouts||diff||Compare Layouts||Find differences between layouts|
|Cut and Export||cut||Export Control||Write out part of a layout|
|Text Editor||txted||Text Editor||Text edit cell file|
The Open command in the File menu can be used directly to read files in the supported formats for editing. When a cell is written to disk, it is by default written in the format of origin, though a format change can be coerced in the Save As command by supplying a file extension. Thus, there are alternatives to using many of the commands in the Convert Menu.
During a conversion, a log file is written by the converters. This file contains a record of messages emitted during the conversion. If during a conversion an error or warning message is emitted, a file browsing window containing the log file will appear when the conversion is complete, though this can be suppressed by setting the NoPopUpLog variable. These messages also appear on the prompt line during the conversion. The file browser is a read-only version of the text editor window, and has a number of associated keyboard commands, including word searching. See 3.13.2 for a listing of these commands.
On GDSII and OASIS input, if there is no specified mapping for a given layer and datatype, an attempt is made to map to the existing Xic layers, and if that fails, a new layer is created.
When reading CIF, layer names are matched to those defined in the current technology in a case-insensitive mode. This differs from native and CGX file types, which use case-sensitive matching. Layers found in the file which do not match any in the technology are created, using default parameters.