semi合集-English.pdf - 第5899页

SEMI P39-0304 E2 © SEMI 2004 2 NOTICE: Unless ot herwise indi cated, all documents cited shall be the latest published versions. 5 Terminology 5.1 Abbrevi ations and Acronyms 5.1.1 BNF— Backus-Naur Form 5.1.2 EDA— Electr…

SEMI P39-0304

OASIS

– O

PEN ARTWORK SYSTEM INTERCHANGE STANDARD

This standard was technically approved by the Global Micropatterning Committee and is the direct

responsibility of the North American Microlithography Committee. Current edition approved by the North

American Regional Standards Committee on July 12, 2003. Initially available at www.semi.org December

2003; to be published March 2004.

This document was modified in April 2004 to correct editorial errors. Changes were made to Sections 29.8

and 36.2. This document was also editorially modified in July 2004 to correct editorial errors. Changes were

made to Section 36.

1 Purpose

1.1 The purpose of this specification is to define an

interchange and encapsulation format for hierarchical

integrated circuit mask layout information.

1.2 Background — In the fall of 2001, SEMI’s Data

Path Task Force formed a working group to define a

successor to the venerable GDSII Stream format, which

had served the I.C. industry as a de facto standard for

layout interchange for more than two decades. The old

format, limited by 16-bit and 32-bit internal integer

fields, by its inefficient representation of cell-native

geometric figures, and by high structural overhead, was

becoming difficult to use for leading-edge designs, and

file sizes were becoming unwieldy, in some cases

growing to many tens of gigabytes. The successor

format was chartered with several overall goals:

 Achieve at least an order-of-magnitude file size

improvement compared to GDSII Stream.

 Remove all 16-bit and 32-bit integer width

restrictions—make the new format fully 64-bit

capable.

 Efficiently represent cells with large payloads of

flat native geometric figures.

 Provide a richer information palette to facilitate

interchange of layout-related information between

design and manufacturing.

1.2.1 In the months leading up to the formation of the

SEMI Data Path Task Force, International Sematech

sponsored a series of meetings focusing on Mask EDA

issues. Many of the Task Force participants were also

involved in these Sematech meetings, and carried

forward much useful information from those sessions

into the definition of this specification.

2 Scope

2.1 This format is designed primarily to encapsulate

hierarchical mask layout for interchange between

systems such as EDA software, mask writing tools, and

mask inspection/repair tools.

2.2 This format is designed to be both hardware- and

software-independent.

NOTICE: This standard does not purport to address

safety issues, if any, associated with its use. It is the

responsibility of the users of this standard to establish

appropriate safety and health practices and determine

the applicability of regulatory or other limitations prior

to use.

3 Limitations

3.1 Use of extension records such as XNAME,

XELEMENT, and XGEOMETRY may impair

interoperability between tools. It is recommended that

these extensions be used primarily for prototyping, and

that interoperability be maintained through the formal

inclusion of extensions to this specification.

4 Referenced Standards

4.1 IEEE Standards

IEEE 754-1985 — IEEE Standard for Binary Floating-

Point Arithmetic

4.2 ISO Standards

ISO-646-IRV — “US-ASCII” Character Set

ISO-3309 — Information technology —

Telecommunications and information exchange

between systems — High-level data link control

(HDLC) procedures — Frame structure

4.3 IETF Standards

RFC 1951 — DEFLATE Compressed Data Format

Specification version 1.3

1 Institute of Electrical and Electronics Engineers, IEEE Operations

Center, 445 Hoes Lane, P.O. Box 1331, Piscataway, New Jersey

08855-1331, USA. Telephone: 732.981.0060; Fax: 732.981.1721,

Website: www.ieee.org

2 International Organization for Standardization, ISO Central

Secretariat, 1, rue de Varembé, Case postale 56, CH-1211 Geneva 20,

Switzerland. Telephone: 41.22.749.01.11; Fax: 41.22.733.34.30,

Website: www.iso.ch

3 Internet Engineering Task Force, Website: www.ietf.org

SEMI P39-0304

NOTICE: Unless otherwise indicated, all documents

cited shall be the latest published versions.

5 Terminology

5.1 Abbreviations and Acronyms

5.1.1 BNF—Backus-Naur Form

5.1.2 EDA—Electronic Design Automation

5.1.3

OASIS

—Open Artwork System Interchange

Standard

5.2 Definitions

5.2.1 Most definitions of terminology specific to

OASIS are found within the text of the paragraphs that

contain them.

5.2.2 cell — a named object in a layout hierarchy,

containing native geometric information, annotation

information, and/or placements of other cells.

5.2.3 geometry — a two-dimensional geometric figure

such as a polygon, rectangle, trapezoid, path, circle, etc.

with inherent attributes of layer and datatype.

4 Used with consent by the owner.

5.2.4 placement — a specification by reference that a

copy of a cell is to be placed within the coordinate

space of another cell at a particular location,

orientation, and scale. Cell placement is the

fundamental mechanism which makes hierarchy within

the OASIS file possible.

5.2.5 property — an annotation element consisting of a

name plus an optional list of values, supplying

descriptive information about the characteristics of the

file or one of its components.

5.2.6 record — the principal data division in an OASIS

file.

5.2.7 text element — an annotation element consisting

of an (x,y) coordinate point and an associated string.

5.3 Symbols

5.3.1 “->” — indicates a mapping of an argument to its

contents or its meaning.

SEMI P39-0304

6 OASIS Basics

6.1 An OASIS file is a sequence of bytes divided into records. The length of a record is discernible from its

structure and is not explicit (in contrast to GDSII Stream, where all record lengths are explicit).

6.2 An OASIS file has the following overall syntax (using the modified BNF notation described in Section 36 on

page 27). Individual record types appear in bold uppercase and are described in more detail in following sections.

<oasis-file> -> <magic-bytes> START { CBLOCK | PAD | PROPERTY | <cell> | <name> }* END

<name> -> { CELLNAME | TEXTSTRING | LAYERNAME | PROPNAME | PROPSTRING | XNAME }

<cell> -> { CELL { CBLOCK | PAD | PROPERTY | XYRELATIVE | XYABSOLUTE | <element> }* }

<element> -> { <geometry> | PLACEMENT | TEXT | XELEMENT }

<geometry> -> { RECTANGLE | POLYGON | PATH | TRAPEZOID | CTRAPEZOID | CIRCLE | XGEOMETRY }

6.3 An OASIS file may represent a complete layout hierarchy, a portion of a layout hierarchy, or multiple layout

hierarchies. These interpretations are not intrinsic to the format and are governed by application semantics only.

Each OASIS file must be syntactically complete—it must begin with <magic-bytes> and contain at least a START

and END record.

6.4 The <magic-bytes> element is a sequence of 13 ASCII characters: “%SEMI-OASIS<CR><NL>” where

<CR><NL> represents the ASCII hexadecimal sequence 0D 0A. It is provided as a recognition signature to make

OASIS files easily identifiable to the UNIX file utility. (The intent of the carriage return and newline is to help

detect corruption by FTP programs operating in non-binary mode.)

6.5 EXCEPTION HANDLING

— OASIS processors should treat any deviation from the syntax presented in this

document as a fatal error. OASIS readers are not required to implement syntax-check preprocessing in order to be

considered compliant with this specification. The sequence in which exceptions are detected and reported is entirely

application-dependent. In addition, for access requests which do not require the interpretation of the entire file (such

as retrieval of a single cell or a subset of the cells within the file), this specification does not require OASIS readers

to exhaustively check the validity of the entire file.

7 Data Constructs

7.1 Bytes

7.1.1 A byte is a fixed-length 8-bit value. Bit patterns for bytes are shown with the least significant bit (bit 0) on the

right.

7.2 Integers

7.2.1 An unsigned-integer is an N-byte (N > 0) integer value. The low-order byte appears first

in the OASIS

format. Integer byte length is variable and integers are represented as byte-continuations where the most significant

bit of each byte except the last in the chain is a 1; the remaining seven bits in each byte are concatenated to form the

actual integer value itself. There are no restrictions on integer byte length (and hence, magnitude).

Figure 1

Unsigned-Integer Representation