OASIS vs GDSII: when GDS gets huge

OASIS (Open Artwork System Interchange Standard) is a binary file format for hierarchical mask layout: cells, layers, and integer geometry. SEMI standardizes it as specification P39; the listed revision is P39-0416. It does the same job as Graphic Design System II, better known as the GDSII stream format: it hands a mask layout from one tool to another. The two formats differ in how they store the data. OASIS can attach a repetition to a single rectangle record: a start corner, a step in x, a step in y, and a count. A field of identical contacts is then stored as one rectangle plus one repetition instead of one record per contact.

The picture at the top of this page shows such a field of identical contact tiles. The editor draws every tile. An OASIS file can store the tile once and the repetition next to it.

GDSII remains the format that almost every shop can open. OASIS reduces file size most when a file is dominated by repeated vias, fill shapes, and optical-correction shapes, and when the receiving tool reads OASIS. A tool that reads only GDSII cannot open a .oas file at all.

What OASIS changes vs GDSII

SEMI's charter for P39 starts from the state of GDSII Stream. GDSII had been the de facto layout interchange format for more than two decades, and leading-edge chips exposed three limits: 16-bit and 32-bit integer fields, inefficient storage of large flat lists of native figures inside a cell, and structural overhead. Some files reached many tens of gigabytes. The charter asked the successor for:

• roughly an order-of-magnitude size improvement versus GDSII,
• full 64-bit integers,
• efficient cells that carry huge flat geometry payloads,
• richer layout-related information between design and manufacturing.

These are charter goals. They do not guarantee that every design shrinks by a factor of ten; a file of unique analog outlines may barely change in size.

The stream itself differs in five points:

• Numbers: many fields use variable-length encoding instead of fixed-width words.
• Modal records: if a value such as the layer or a coordinate is unchanged from the previous figure, the writer may omit it.
• Figure-level repetition: a geometry record can carry a repetition, either a regular array or a less regular list of offsets. A contact grid then needs no separate child cell.
• Figure types: rectangles, trapezoids, polygons, paths, and circles are separate record types.
• Compression: each cell can be compressed independently with an optional block compression.

Hierarchy remains part of the format. OASIS repetitions do not replace cells and instances; they are stored in addition to them.

	GDSII Stream	OASIS (SEMI P39)
Role	De facto IC/mask interchange for decades	Interchange among EDA, mask write, and mask inspect/repair
Integer width	16- and 32-bit fields in the classic stream	Chartered fully 64-bit capable
Flat geometry in a cell	Inefficient when a cell holds a huge native list	Efficient flat payloads were an explicit goal
Repetition	Cell placements and arrays (instance-level)	Instance-level and figure-level repetitions
Intrinsic packing	None; shops often gzip the file	Variable-length numbers, modal fields, optional per-cell compression
Size goal	—	About an order of magnitude vs GDSII (charter, not a guarantee)

OASIS.MASK, specified in SEMI P44, is a restricted subset of OASIS for photomask manufacturing equipment such as pattern generators and inspection tools. Its use in a mask flow is optional; a shop may accept full OASIS instead. For the layout engineer, two points remain to check: whether the receiving tool accepts .oas, and whether the writing tool keeps the repetitions.

A field of 36 identical contacts

A six-by-six contact field contains 36 tiles. Written as 36 independent rectangles, it takes 36 records that differ only in position. The grid is visible on screen but not recorded in the file. GDSII avoids this by placing one contact in a cell and instantiating that cell as an array. OASIS supports the same cell array and, in addition, a repetition on the rectangle record: start corner, x step, y step, six by six. The editor still displays all 36 tiles; the file stores the width and height once.

The size reduction depends on two factors: the fraction of the chip that actually repeats, and whether the writer keeps the repetitions or expands them into individual shapes on export. No single reduction factor applies to all chips. The repetition also changes how edits propagate. If the file declares the repetition, a change to the tile width applies to the whole field. If the file lists every tile as separate corners, it holds 36 independent rectangles, and OASIS gives no size advantage for that array.

Cell hierarchy is the second repetition mechanism, and GDSII already supports it: a cell drawn once and placed many times. OASIS repetitions can be used inside such cells. Flattening the layout into one list of polygons removes both mechanisms, and the file grows, while the screen display stays the same.

Three outlines with nothing to repeat

The second picture shows geometry that repetition cannot compress: three irregular polygons in gold, navy, and purple. Each has its own outline and a small cut that differs from the others. They share no width, no step, and no duplicate. Both formats can store them, and in both formats each outline needs its own vertices, because each is a different polygon.

A frequent misconception is that OASIS makes every file smaller, including files of unique analog shapes, logos, and one-off jogs. Unique shapes cost their vertices in either format. Variable-length numbers and modal fields reduce record overhead slightly; they do not merge three different outlines into one record. A real chip contains both kinds of geometry: large repeated contact and via fields, where OASIS reduces size, and a smaller number of unique shapes, which it stores at roughly the same cost.

Who asks for OASIS, and what you still send

SEMI designed OASIS primarily to carry hierarchical mask layout between electronic-design software, mask-writing tools, and mask inspection and repair systems. Foundries and mask shops publish which formats they accept; many accept both. Some rule decks and third-party blocks are still delivered as GDSII. Confirm with the receiver before keeping .oas as the only copy. LayoutEditor reads and writes OASIS files (.oas / .oasis); downstream viewers, LVS decks, or IP deliveries may not.

The format choice does not change the rest of the handoff. You still name a top cell, state the mapping from integer units to meters, and supply a layer map. In both formats a layer is a number; display colors are not stored. A correct six-by-six repetition on the wrong layer number is printed on the wrong mask. Mask fracture may later expand shapes for the mask writer. That expanded file is derived from the layout and is no reason to deliver flattened data.

To check a file, inspect one contact field: if it is stored as a repetition, OASIS reduces its size; if every tile is a separate record, converting the format does not restore the grid. Choose the format that the receiving tool accepts.