semi合集-English.pdf - 第5910页

SEMI P39-0304 E2 © SEMI 2004 13 12.2 PAD rec ords m ay be inserted between any other two records. 12.3 EXCEPTION HANDLING — The presence of a PAD record befo re the START record or after the END record should be treated …

SEMI P39-0304

Table 10 Modal Variables

Modal Variables Related Records

repetition

PLACEMENT, TEXT, POLYGON, PATH,

RECTANGLE, TRAPEZOID, CTRAPEZOID,

CIRCLE, XGEOMETRY

placement-x, placement-y, placement-cell

PLACEMENT

layer, datatype POLYGON, PATH, RECTANGLE, TRAPEZOID,

CTRAPEZOID, CIRCLE, XGEOMETRY

textlayer, texttype, text-x, text-y, text-string

TEXT

geometry-x, geometry-y

POLYGON, PATH, RECTANGLE, TRAPEZOID

CTRAPEZOID, CIRCLE, XGEOMETRY

xy-mode

PLACEMENT, TEXT, POLYGON, PATH,

RECTANGLE, TRAPEZOID, CTRAPEZOID,

CIRCLE, XGEOMETRY, XYABSOLUTE,

XYRELATIVE

geometry-w, geometry-h

RECTANGLE, TRAPEZOID, CTRAPEZOID

polygon-point-list

POLYGON

path-halfwidth, path-point-list, path-start-extension,

path-end-extension

PATH

ctrapezoid-type

CTRAPEZOID

circle-radius

CIRCLE

last-property-name, last-value-list

PROPERTY

10.2 Modal variable xy-mode governs the interpretation of the x and y fields for those related record types indicated

in Table 10. Two interpretation modes are provided: absolute and relative. See Section 21 on page 17 for a

discussion of how these two modes work.

10.3 EXCEPTION HANDLING

— An OASIS record which implicitly references a modal variable which is in the

undefined state should be treated as a fatal error.

11 Records

11.1 The basic unit of information in an OASIS file is a record. A record consists of a single unsigned-integer

which encodes the record-ID, followed by the remainder of the record’s descriptive data. In this specification,

record-ID values are displayed as decimal numbers enclosed in apostrophes.

11.2 The CBLOCK record is a special case since it encapsulates a series of ordinary records in byte-compressed

form. When a CBLOCK record is encountered while reading an OASIS file, it is first necessary to decompress its

data, which will produce one or more ordinary records, which can in turn be decoded. For more information on

CBLOCK records refer to Section 35 on page 26.

11.3 Most records have an implicit length—the record must be parsed and decoded in order to determine its length.

The XNAME, XELEMENT, and XGEOMETRY records are exceptions to this. They encapsulate all of their user-

defined data in a single variable-length b-string, so they can be used for prototyping new record types, hiding

embedded proprietary data, supporting local non-interoperable extensions, etc. without rendering an OASIS file

illegible to older readers, which can simply note the string length and skip over the record.

11.4 EXCEPTION HANDLING

— OASIS processors should treat the nesting of a CBLOCK record within another

CBLOCK record as a fatal error.

12 PAD Record

12.1 A PAD record provides a simple way to reserve space within an OASIS file. It has the following format:

‘0’

SEMI P39-0304

12.2 PAD records may be inserted between any other two records.

12.3 EXCEPTION HANDLING

— The presence of a PAD record before the START record or after the END

record should be treated as a fatal error.

13 START Record

13.1 A START record identifies the beginning of an OASIS file, and immediately follows the <magic-bytes>

sequence described in Section 6.4 on page 3. It has the following format:

‘1’ version-string unit offset-flag [ table-offsets ]

13.2 The version-string is an a-string whose value is “1.0” for this version of the OASIS specification. Version

“1.0” corresponds to the OASIS format as described in this document.

13.3 The unit declaration is a positive

real number which specifies the global precision of the OASIS file’s

coordinate system in grid steps per micron. The OASIS unit value is essentially the reciprocal of the first value in

the GDSII Stream UNITS record.

13.4 offset-flag (an unsigned-integer) is 0 when the table-offsets structure is stored in the START record; offset-

flag is 1 when the table-offsets structure is instead stored in the END record. The option of storing table-offsets in

the END record is provided to make it possible to write an OASIS file sequentially, with no seek-and-update access

required, while still providing cell-level random-access capability for subsequent readers of that OASIS file.

13.5 The table-offsets structure consists of 6 pairs of unsigned-integers. Each pair consists of a flag field, and a

corresponding byte-offset field, in the following order:

Table 11 Table Offset Order

Flag Byte-Offset

cellname-flag cellname-offset

textstring-flag textstring-offset

propname-flag propname-offset

propstring-flag propstring-offset

layername-flag layername-offset

xname-flag xname-offset

13.6 Each of the flag fields is either 1, indicating strict mode, or 0, indicating non-strict mode, for its respective

table. The corresponding byte-offset field indicates the position of the first record of its respective table relative to

the first byte (byte 0) of the OASIS file. A byte-offset of 0 indicates the absence of that particular table.

13.7 In non-strict mode, records of the corresponding type may occur anywhere in the file, even if some of them

have been gathered into a table pointed to by the corresponding byte-offset.

13.8 In strict mode, all

records of the corresponding type (plus any associated PROPERTY records) have been

gathered into a single contiguous table pointed to by the corresponding byte-offset. PAD records are also permitted

in strict mode tables. In addition, strict mode guarantees

that all references to the corresponding class of objects

(names, strings, or cells) are made exclusively by reference-number.

13.9 When a given strict mode table has been encapsulated within one or more CBLOCK records, the

corresponding byte-offset should point to the first byte of the first CBLOCK record containing that table, and the

first record of the table must be the first record which appears after decompression of the CBLOCK record.

Adherence to this requirement means that it is not permissible to encapsulate more than one strict mode table within

a single CBLOCK record, nor is it permissible to begin a strict mode table in the middle of a CBLOCK record.

13.10 EXCEPTION HANDLING

— The absence of a START record as the first record in an OASIS file should be

treated as a fatal error. A value of unit which is NaN, Inf, or non-positive, should also be treated as a fatal error.

When a given table offset is nonzero and the table is flagged as strict, the presence of a “stray” record of that type

SEMI P39-0304

located discontiguously from its tabular group should be treated as a fatal error, and any records which fail to use

reference-number access for that class of objects should be treated as a fatal error. An OASIS reader which does not

rely on any of the record grouping, reference-number, and byte-offset guarantees provided by strict mode is not

required to detect and report any exceptions related to strict mode.

14 END Record

14.1 An END record identifies the end of the OASIS file. The END record must be the last record in the file; no

trailing bytes are permitted. It has the following format:

‘2’ [ table-offsets ] padding-string validation-scheme [ validation-signature ]

14.2 The presence of the table-offsets structure is governed by offset-flag in the START record (see Section 13 on

page 13). The padding-string (a b-string) must be sized and inserted by the OASIS writer so that the total byte

length of the END record, including the record-ID, is exactly 256 bytes. This makes it possible for an OASIS reader

to find the END record (and any table-offsets and validation-signature) using a relative seek from the logical end-

of-file, avoiding the need to store a forward pointer in the START record. The contents of padding-string should

be initialized to NUL characters.

14.3 validation-scheme is an unsigned-integer which selects the validation scheme used, and validation-signature

is an optional scheme-dependent group of bytes used for validating the integrity of the OASIS file. The following

validation schemes are defined:

Table 12 END Record Validation Schemes

Scheme Description Validation Signature Length

0 No Validation 0

1 CRC32 4

2 CHECKSUM32 4

14.4 CRC32 Validation

14.4.1 The CRC32 polynomial is specified in ISO 3309:

+ x

With the left-most bit representing the most significant bit, this corresponds to a value of:

binary 1 0000 0100 1100 0001 0001 1101 1011 0111

hexadecimal 104c11db7

14.4.2 The CRC32 value is computed using all of the bytes in the OASIS file from the first byte of the START

record to the END record’s validation-scheme integer. It is byte-order dependent. The resulting 32-bit word is

stored in the last 4 bytes of the file, with the least significant byte first. This calculation is usually implemented

using a table-lookup shift/XOR method. See Appendix 1 for sample C-language source code.

14.5 CHECKSUM32 Validation

14.5.1 The CHECKSUM32 validation signature is computed as a simple unsigned arithmetic summation of all of

the bytes in the OASIS file from the first byte of the START record to the END record’s validation-scheme

integer. This value is then truncated to its least significant 32 bits and stored in the last 4 bytes of the file, with the

least significant byte first. It is not byte-order dependent, and this characteristic makes it somewhat easier to

calculate if the file is not written sequentially. It is, however, far less effective than CRC32 for detecting errors. See

Appendix 1 for sample C-language source code.

14.6 EXCEPTION HANDLING

— OASIS processors should treat the absence of an END record in an OASIS file

as a fatal error.