The Open Artwork System Interchange Standard (OASIS) was designed by the SEMI consortium as a modern alternative to the GDSII standard. A draft specification (SEMI Document 3626 2003/04/23) of the OASIS format standard was circulated, and subsequently adopted with very minor changes. The final standard document is available from the SEMI organization.

The main objective of the OASIS standard is efficient representation of mask layout geometry, both in hierarchical and flat representations. The format makes use of a number of techniques to this end.

• A compact variable-size integer representation is used. Along with heavy use of offsets, one and two byte integers can be used extensively in place of the larger fixed-size integers used in other formats.

• Extensive use of modal variables greatly reduces repeated information.

• String and name referencing by number eliminates repetition of these data.

• A flags byte indicates the presence or absence of certain data fields in most records, so that unused or unset values do not need to be included in the stream.

• Special compact representations for trapezoids and other common features save space.

• An encoding mechanism for repetitions can be used to consolidate arrays of objects.

• A data compression mechanism is supported.

1. Xic can read any spec-conforming OASIS file.
2. OASIS output from Xic is readable by any other spec-conforming tool.
3. Exceptions to the above are *bugs*, please report!

• Files can be read directly into Xic, either using the Edit 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 Xic "skeleton mode" feature, where only the cell hierarchy is read into memory initially, applies to all archive formats. A similar but more recent "archive context" feature also applies. These features are intended to provide the ability to manipulate files that can not be read into memory due to memory size limitations.

• 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 script functions that split a file spatially into pieces, WriteGeomSplit() and SkelWriteGeomSplit(), apply to all archive formats for both input and output.

• This is still a little preliminary. The OASIS format should not be used for anything critical at this point, but use is encouraged in order to validate the code.

• 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/html/anuvad.htm), which has been our "reference" in establishing portability.

  Few of the features have been extensively tested at this point. There are probably a few flat-out bugs since this represents a large block of new code.

• 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 OASIS files from memory.

• 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 used.

  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.

  Bits	Purpose
  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 object.

• The draft spec says:

  "... strict mode guarantees that all references to the corresponding class of objects (names, strings, or cells) are made exclusively by reference-number"

  Xic does not enforce this.

• 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.

We at Whiteley Research are impressed with the careful thought that went into and the completeness of the OASIS draft specification. However, since the OASIS format is still in draft form, there are a few aspects of the format that we would like to comment on, and in a perfect world, change. Priorities: 1 (most important) to 5 (least important).

1. Priority 1
   It should always be possible to read an OASIS file in one pass. This simplifies the design of the reader, and reduces the time to process a file. In its present form, an OASIS reader would be required in general to read the file twice. This is due to the lack of a requirement that <name> records appear before references. Although it can be guaranteed that <name> records are parsed before references through use of strict mode offset-table entries, in other cases a reader must take two passes through the file: first to read all of the <name> records and set up internal tables, second to read the data.

   Adding the following two conditions to the OASIS specification would eliminate any need for two-pass reading, simplifying the reader and reducing the time to process the file, while adding little or no complexity to the OASIS generator. Files produced by Xic always follow these conditions.

   • <name> records that are not included in offset tables must appear ahead of the first reference involving that record in the OASIS file. This ensures that if the records are read sequentially, the references can be satisfied. The offset table is read while parsing the START record (even if it is located in the END record) so records in tables are assured of being read before the references.

   • If an offset table exists for a given record type and is not in strict mode, then the table must appear ahead of any other records of that type. In this case, the reference number is the count, in sequence of appearance, of that record type. Unless we look through the entire file, we don't know the reference number of the first record in the table, unless this restriction is accepted.

2. Priority 3
   It is generally useful for a design database file to have some kind of identification tag, which makes the file traceable to a particular generating source. This would be particularly useful for a new format of some complexity such as OASIS. As a vendor, when a customer complains about problems reading a particular file, it is often useful to know the origin of that file. To this end, it is recommended that a field for an arbitrary a-string be added to the START record. This might be called the "info string", and could be anything, including null. A tool would typically add something like

   "XYZ, Inc. FileWriter-1.5 12/15/2003 14:23"

3. Priority 5
   It would be useful if one could specify a "rounded" end style as part of the end specification in a PATH record. This would enable direct translation to and from GDSII paths, without loss of the GDSII PATHTYPE=1 attribute. Xic uses "rounded" end paths as one means for generating physical text characters from the internal vector font.

4. Priority 5
   It would be useful to add presentation attributes to the TEXT records. In Xic, these specify labels that appear on-screen in the layout. In systems where TEXT records are not displayed, such information would not be needed, so the presentation record would be optional. The presentation record could consist of an unsigned width, followed by a byte whose bits represent various rotations and justifications. For Example:

   bits 0-2	rotations in 45-degree increments
   bit 3	mirror
   bits 4-5	left, center, right justification
   bits 6-7	bottom, center, top justification