semi合集-English.pdf - 第5900页

SEMI P39-0304 E2 © SEMI 2004 3 6 OASIS Basics 6.1 An OA SIS file is a sequence of bytes divided into records . The length of a reco rd is discernibl e from its structure and is not explicit (in contrast to GDSII Stream, …

100%1 / 7923
SEMI P39-0304
E2
© SEMI 2004 2
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
4
OASIS
TM
—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
E2
© SEMI 2004 3
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
SEMI P39-0304
E2
© SEMI 2004 4
Table 1 Unsigned-Integer Examples
Unsigned-Integer Value Binary Representation
0 00000000
127 01111111
128 10000000 00000001
16,383 11111111 01111111
16,384 10000000 10000000 00000001
7.2.2 A signed-integer follows the same byte-continuation scheme as an unsigned-integer, and is stored in signed-
magnitude form, with the significand left-shifted one bit and the sign bit stored in the least significant bit of the low-
order (first) byte. A sign bit of 0 indicates a positive number, and a sign bit of 1 indicates a negative number. Both
representations of zero (+0 and -0) should be treated as numerically equivalent for the purposes of comparison.
Figure 2
Signed-Integer Representation
Table 2 Signed Integer Examples
Signed Integer Value Binary Representation
0 00000000
+1 00000010
1 00000011
+63 01111110
64 10000001 00000001
+8,191 11111110 01111111
8,192 10000001 10000000 00000001
7.2.3 EXCEPTION HANDLING
OASIS processors which only support integer data in a restricted space (e.g.,
32-bit space) should treat any magnitude outside of this space as a fatal error.
7.3 Reals
7.3.1 A real number may be stored in one of several rational forms, or as a single-precision 4-byte (ieee-4) or
double-precision 8-byte (ieee-8) floating point value. The rational forms are usually more compact than the floating-
point forms, and have the advantage of being able to precisely represent many values which can only be
approximated by the binary floating point representation. The type of representation is stored in an unsigned-integer
which precedes the significant portion of the real: