OASIS Support in Xic
This section describes the OASIS capabilities in Xic. Unless
stated otherwise, this also applies to the derivative products
XicII and Xiv. The present status of OASIS support in
Xic is complete, the bottom line being
OASIS is one of the supported archive formats, along with GDSII, CIF,
and CGX. CGX (Computer Grapnics eXchange) format
is another "improved" GDSII developed and placed in the public domain
by Whiteley Research. The archive formats have the following capabilities
- Xic can read any spec-conforming OASIS file.
- OASIS output from Xic is readable by any other
- Exceptions to the above are bugs, please report!
- Files can be read directly into Xic, either using the Open
command, or with similar buttons and functions in Xic.
- Files can be converted directly to another (or the same) archive
format, or to Xic native symbol files, from the Convert
function in the Convert Menu. While converting, scaling,
windowing (clipped or not) and flattening can be employed. There is
also provision for selecting the layers to convert.
- Xic can output a hierarchy in memory to any of the archive
formats. The default format is the format of origin, if any.
- The "random access" of cells from the file, such as with the
Contents function of the Files Listing or the library
access mechanism applies to all archive formats.
- The Cell Hierarchy Digest (CHD) and Cell Geometry Digest (CGD)
features, which facilitate working with very large files (too large to
fit into the main memory database) apply to all archive formats.
- The script function that splits a file spatially into pieces,
ChdWriteSplit applies to all archive formats for both
input and output.
OASIS Interface Notes and Limitations
This capability was designed from the draft SEMI-3626 document, but
has incorporated changes from the final specification.
Xic was the first (to our knowledge) commercial
implementation of the OASIS format. Some limited tools have been made
available from Mentor Graphics (GDSII/OASIS translator), and SoftJin
(GDSII/OASIS translator and text mode converters). We highly
recommend anuvad from SoftJin (http://www.softjin.com),
which has been our "reference" in establishing portability.
(This company was acquired by Mentor, the anuvad free download may no
Characteristics of OASIS Output From Xic
The basic OASIS file generated by Xic has the characteristics listed
- By default, all strings are saved locally as strings, i.e., no
indirection is used, so there are no <name> records. This can be
changed with the OasWriteNameTab variable (see below), which
is connected to check boxes in the Conversion pop-ups.
- By default, no REPETITION records are generaged for <geometry>
records. If the OasWriteRep variable or the corresponding
check box is set, REPETITION record types may be generated. This
option attempts to recognize arrays of identical objects when writing
- By default, three and four-sided polygons will be written as
TRAPEZOID or CTRAPEZOID records, however this can be disabled with the
- By default, wires (paths) will retain that data type. However,
rectangular two-vertex paths will be converted to a more compact
rectangle representation if OasWriteWireToBox is set.
- The following record types are not generated by Xic:
CIRCLE, XNAME, XELEMENT, XGEOMETRY.
- When writing OASIS files with StripForExport set, i.e., writing
physical data only, and when using string tables, the offset table is
placed in the END record. With StripForExport not set, in general we
write two sequential OASIS databases into the file, the first for
physical data, the second for electrical. This is a
Xic-specific extension. In this case, string tables are used
in the physical part only, and the offset table is placed in the START
record. PAD records are added to avoid overwriting data since this is
a non-sequential operation. In all cases, strict-mode tables are
Note: If a design contains physical data only, the electrical records
are absent, so that the file becomes conventional. Even if electrical
records are present, the reader will probably ignore them (as does
anuvad-0.2). However, when exporting physical data, for
portability StripForExport should always be set.
The string tables themselves are written just ahead of the END
record in all cases (when tables are used).
- There are no file properties given.
- All integer values are 32-bit limited, except for values that represent
offsets into the file, which may be 64-bit.
- The OASIS format does not provide a native code to indicate a
rounded-end wire. For wires that have rounded ends, i.e., that originated
as GDSII PATHTYPE=1, the half-width extension is specified, and the PATH
record is given an empty (info byte = 0x4) property named "XIC_ROUNDED_END".
- The OASIS format does not provide codes for TEXT element presentation.
In Xic, these are used for on-screen labels, and are treated by
Xic as any other database object, but they will not appear on the
mask layout. Thus, at least for Xic internal use, TEXT presentation
attributes are important. They are stored in a property applied to TEXT
records named "XIC_LABEL". The XIC_LABEL property contains two unsigned
integers. The first is the width of the label, in database units.
The second is the "xform" code used by Xic which determines the
justification and rotation.
|0-1 ||0-no rotation, 1-90, 2-180, 3-270|
|2 ||mirror y after rotation|
|3 ||mirror x after rotation and mirror y
|4 ||shift rotation to 45, 135, 225, 315
|5-6 ||horiz justification 00,11 left, 01 center, 10 right|
|7-8 ||vert justification 00,11 bottom, 01 center, 10 top|
|9-10 ||font (GDSII)|
- All other properties, which might be given to CELL or
<geometry> records, are named "XIC_PROPERTY" and consist of
concatenated number/string pairs. Xic uses properties indexed
by a number, with string-type data, so that the XIC_PROPERTY consists
of the list of properties as known to Xic for that cell or
There are several options in Xic that modify OASIS
input/output. Many of these can be controlled by check boxes in the
OASIS page in the Set Export Parameters and Conversion
panels from the Convert Menu, which reflect the status of the
variables (which can also be set with the !set command or
|Convert Menu - Input and ASCII Output|
|OasReadNoChecksum||Ignore checksum in OASIS input file|
|OasPrintNoWrap||Use one line per record in OASIS ASCII output|
|OasPrintOffset||Add file offsets to OASIS ASCII output|
|Convert Menu - Output|
|OasWriteCompressed||Compress records in OASIS output|
|OasWriteNameTab||Use string table referencing in OASIS output|
|OasWriteRep||Try to combine similar objects in OASIS output|
|OasWriteChecksum||Compute and add checksum to OASIS output|
|OasWriteNoTrapezoids||Don't convert polys to trapezoids|
|OasWriteWireToBox||Convert wires to boxes when possible|
|OasWriteNoGCDcheck||Don't look for common divisors in repetitions|
|OasWriteUseFastSort||Use faster but less effective sorting|
|OasWriteNoXicTextPrps||Don't write certain text properties|
Requirements And Limitations for Reading OASIS
Xic can very likely read any OASIS file that meets the published
specification. Exceptions should be reported as bugs!
Properties are ignored, unless the name matches one of those understood
by Xic (see above). The file properties set an internal variable
but otherwise do nothing.
The XNAME, XELEMENT, and XGEOMETRY records are ignored.
The CIRCLE record will create a polygon object approximating a circle,
with the number of sides using the internal variable in Xic.
The TRAPEZOID and CTRAPEZOID records will create a polygon object.
- The REPETITION records found in PLACEMENT records will define a
cell array if possible (i.e., represents a periodic Manhattan
configuration), otherwise individual cell instances will be created
and replicated. In <geometry> records, any REPETITION is
accepted, but the repetition is decomposed and separate objects are
created in memory.