semi合集-English.pdf - 第5923页
SEMI P39-0304 E2 © SEMI 2004 26 34 XGEOMETRY Record 34.1 An XGEOMETRY record allows backward-compatible extension of OASIS <geometry> records. It has the following format: ‘33’ xgeometr y-info-byte x geometry-attri…

SEMI P39-0304
E2
© SEMI 2004 25
that propname-string (an n-string) is present and stores the property name locally. When C = 0, N is ignored, and
the value of modal variable last-property-name is used instead.
31.5 When V = 0, values of UUUU from 0 to 14 indicate the number of <property-value> fields which are part of
this record, and prop-value-count is omitted. When V = 0 and UUUU = 15, prop-value-count, an unsigned-
integer, is present and indicates the number of <property-value> fields. When V = 1, UUUU must be 0, and modal
variable last-value-list supplies the value list. See Section 7.8 on page 11 for a description of <property-value>
types.
31.6 When S = 1, a standard property is indicated; when S = 0, a non-standard or user property is indicated. The list
of OASIS Standard Properties appears in Appendix 2 on page 36. That appendix also describes how to represent
GDSII-Stream-style properties using the S_GDS_PROPERTY standard property.
31.7 Each successive PROPERTY record updates modal variables last-property-name and last-value-list.
31.8 In general, PROPERTY records directly follow the record with which they are associated. PROPERTY
records occurring directly after the START record are associated globally with the entire OASIS file. PROPERTY
records occurring after a CELL record or its corresponding CELLNAME record pertain to that entire cell.
PROPERTY records occurring after a PLACEMENT record pertain to the placement(s) it describes, including
repetitions. PROPERTY records occurring after an <element> record pertain to that element and any repetitions.
31.9 PROPERTY records do not associate with
CBLOCK or PAD records. Instead, property association occurs as
though all CBLOCK records have been uncompressed, and all PAD records have been deleted.
31.10 EXCEPTION HANDLING
— Implicit use of modal variables last-property-name or last-value-list when they
are in the undefined state should be treated as a fatal error. Use of a reference-number for which there is no
corresponding PROPNAME record should be treated as a fatal error.
32 XNAME Record
32.1 An XNAME record allows backward-compatible extension of OASIS <name> records. It associates a string
with a unique reference number. It has the following format:
‘30’ xname-attribute xname-string
‘31’ xname-attribute xname-string reference-number
32.2 xname-string is user-defined as an a-string, b-string, or n-string which holds the name. xname-attribute is an
unsigned-integer providing the ability to associate the XNAME with a user-defined class. The reference-number is
an unsigned-integer which is either implicitly or explicitly assigned to the name. Implicit assignment occurs in
record type ‘30’, by assigning sequential reference numbers beginning with 0 as each successive XNAME record is
encountered. Explicit assignment occurs in record type ‘31’.
32.3 Record types ‘30’ and ‘31’ may not both be used in the same OASIS file.
32.4 EXCEPTION HANDLING
— The appearance of two XNAME records in the same file with the same
reference number but different names should be treated as a fatal error. The appearance of both record types ‘30’
and ‘31’ in the same OASIS file should be treated as a fatal error.
33 XELEMENT Record
33.1 An XELEMENT record allows backward-compatible extension of OASIS <element> records. It has the
following format:
‘32’ xelement-attribute xelement-string
33.2 xelement-attribute is an unsigned-integer providing the ability to associate the XELEMENT with a user-
defined class. xelement-string is a b-string containing user-defined data.

SEMI P39-0304
E2
© SEMI 2004 26
34 XGEOMETRY Record
34.1 An XGEOMETRY record allows backward-compatible extension of OASIS <geometry> records. It has the
following format:
‘33’ xgeometry-info-byte xgeometry-attribute
[ layer-number ] [ datatype-number ] xgeometry-string [ x ] [ y ] [ repetition ]
34.2 The xgeometry-info-byte contains the bit pattern ‘000XYRDL’.
34.3 R is 1 if repetition is present. L is 1 if layer-number is present. D is 1 if datatype-number is present. Both
layer-number and datatype-number are unsigned-integers. When layer-number and/or datatype-number are
unspecified, they assume the value of modal variables layer and datatype, respectively.
34.4 x and y are signed-integer coordinates representing either the absolute or the relative (x,y) location of the
geometry. X is 1 if x is present, and Y is 1 if y is present. When either x or y is unspecified, the value of modal
variable geometry-x or geometry-y, respectively, is used instead. Refer to Section 21 on page 17 for a discussion of
how absolute and relative modes affect the interpretation of x and y.
34.5 xgeometry-attribute is an integer providing the ability to associate the XGEOMETRY with a user-defined
class. xgeometry-string is a b-string containing user-defined data describing the geometry.
34.6
Each successive XGEOMETRY record updates all XGEOMETRY-related modal variables.
34.7 EXCEPTION HANDLING
— Implicit use of modal variables layer, or datatype when they are in the undefined
state should be treated as a fatal error.
35 CBLOCK Record
35.1 A CBLOCK record provides a mechanism for embedding compressed data within the structure of an OASIS
file for additional compactness. It has the following format:
‘34’ comp-type uncomp-byte-count comp-byte-count comp-bytes
35.2 comp-type is an unsigned-integer describing the type of compression used for this record. uncomp-byte-
count is an unsigned-integer describing the number of bytes prior to compression, and comp-byte-count is an
unsigned-integer describing the number of bytes after compression. comp-bytes is a sequence of bytes containing
the compressed byte sequence.
35.3 When comp-type = 0, the compression scheme is the lossless DEFLATE Compressed Data Format, Version
1.3, as documented in RFC 1951 (1996). Other values of comp-type are reserved for future versions of the OASIS
format; the intent is to be able to support a mixture of compression methods within a single OASIS file for
maximum compactness.
35.3.1 One example of compression/decompression software that is compliant with RFC 1951 is found in ZLIB
version 1.1.4 (March 2002). This software version can be used without any licensing or legal encumbrances. It is
expected that future versions of the ZLIB software will also remain RFC-1951-compliant. Users of future releases
of ZLIB are cautioned to check for continued conformance to RFC 1951 as well as any changes in the terms of use.
35.3.2 Use of the ZLIB software is not mandatory in order to be compliant with the OASIS specification. Any
compression/decompression software that stores and processes data in conformance with RFC 1951 is OASIS-
compliant. It should be noted that alternatives to the CBLOCK record may emerge in the future, supporting other
compression mechanisms. Use of multiple compression methods within a single OASIS file is not ruled out.
35.4 The START, END, CELL, and nested CBLOCK records may not be stored within a compressed record. This
maintains the ability to perform random access at the cell level within an OASIS file. A CBLOCK record may not
encapsulate more than one “strict mode” name table (refer to Sections 13 and 14 beginning on page 13). All other
sequences of records, of any length, may be stored in a CBLOCK record.
35.5 EXCEPTION HANDLING
— During the reading of a CBLOCK record, it is a fatal error if the number of
bytes returned after decompression does not match uncomp-byte-count.

SEMI P39-0304
E2
© SEMI 2004 27
36 Detailed BNF Syntax
36.1 This specification uses a modified Backus-Naur Form (BNF) notation to describe OASIS file syntax. The
following table summarizes the conventions used in the modified BNF:
Table 16 Modified BNF Notation
Symbol Term Meaning
ABCD
Bold Uppercase Denotes an OASIS record name
abcd
Bold Lowercase Denotes a fundamental data type defined in Section 7
< > Angle Brackets Enclose an element name which is further defined elsewhere in the BNF
-> Arrow Means “is composed of”
[ ] Square Brackets Enclose element(s) which are optional, and if present, occur only once
{ } Braces Enclose element(s) which are required
| Vertical Bar Indicates a choice between mutually exclusive elements within { } braces
* Asterisk An asterisk following an element means the element may occur zero or more times
... Ellipsis Appears between elements to indicate a variable-length list of like type
‘ ’ Single Quotes Enclose a decimal number denoting an OASIS unsigned-integer
“ ” Double Quotes Enclose a literal character string
“<CR>” Control Character Angle brackets enclose the name of an ASCII Control Character within a string
// Double Virgule Indicates all characters to its right are comments—not part of the syntax
36.2 The OASIS syntax is detailed as follows:
<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 }
<magic-bytes> -> “%SEMI-OASIS<CR><NL>”
PAD -> ‘0’
START -> ‘1’ <version-string> <unit> <offset-flag> [ <table-offsets> ]
END -> ‘2’ [ <table-offsets> ] <padding-string> <validation-scheme> [ <validation-signature> ]
CELLNAME -> ‘3’ <cellname-string>
CELLNAME -> ‘4’ <cellname-string> <reference-number>
TEXTSTRING -> ‘5’ <text-string>
TEXTSTRING -> ‘6’ <text-string> <reference-number>
PROPNAME ->
‘7’ <propname-string>
PROPNAME -> ‘8’ <propname-string> <reference-number>
PROPSTRING -> ‘9’ <prop-string>
PROPSTRING -> ‘10’ <prop-string> <reference-number>
LAYERNAME -> ‘11’ <layername-string> <layer-interval> <datatype-interval>
LAYERNAME -> ‘12’ <layername-string> <textlayer-interval> <texttype-interval>
CELL -> ‘13’ <reference-number>