semi合集-English.pdf - 第5911页

SEMI P39-0304 E2 © SEMI 2004 14 located disconti g uously from its tabular group shoul d be treated as a fatal error, and a n y records whi ch fail to use reference-number access for that class of objects sh ould be trea…

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.

SEMI P39-0304

15 CELLNAME Record

15.1 A CELLNAME record associates the name of a cell with a unique reference number. This allows CELL and

PLACEMENT records, if desired, to avoid redundantly storing the actual text of the cell name and instead refer to

the cell by its assigned reference number. It has the following format:

‘3’ cellname-string

‘4’ cellname-string reference-number

15.2 cellname-string is an n-string which holds the cell name. The reference-number is an unsigned-integer

which is either implicitly or explicitly assigned to the cell. Implicit assignment occurs in record type ‘3’, by

assigning sequential reference numbers beginning with 0 as each successive CELLNAME record is encountered.

Explicit assignment occurs in record type ‘4’.

15.3 Two standard properties, S_BOUNDING_BOX and S_CELL_OFFSET (described in Section A2-2 on page

36), may be associated with each CELLNAME record. When all CELLNAME records have been grouped into a

single contiguous table in strict mode (as described in Section 13 on page 13), with an S_CELL_OFFSET property

for every CELLNAME record, the table forms a complete index of all cells in the OASIS file, suitable for random

access.

15.4 Record types ‘3’ and ‘4’ may not both be used in the same OASIS file.

15.5 EXCEPTION HANDLING

— The appearance of two CELLNAME records in the same file with the same

number but different names, or two CELLNAME records in the same file with the same name but different

numbers, should be treated as a fatal error. The appearance of both record types ‘3’ and ‘4’ in the same OASIS file

should be treated as a fatal error. The presence of more than one S_CELL_OFFSET or S_BOUNDING_BOX

property after a given CELLNAME record should be treated as a fatal error.

16 TEXTSTRING Record

16.1 A TEXTSTRING record associates a text string with a unique reference number. This allows TEXT records,

if desired, to avoid redundantly storing the actual text of the string and instead refer to the string by its assigned

reference number. It has the following format:

‘5’ text-string

‘6’ text-string reference-number

16.2 text-string is an a-string which holds the text string. The reference-number is an unsigned-integer which is

either implicitly or explicitly assigned to the text string. Implicit assignment occurs in record type ‘5’, by assigning

sequential reference numbers beginning with 0 as each successive TEXTSTRING record is encountered. Explicit

assignment occurs in record type ‘6’.

16.3 Record types ‘5’ and ‘6’ may not both be used in the same OASIS file.

16.4 EXCEPTION HANDLING

— The appearance of two TEXTSTRING records in the same file with the same

number but different names, or two TEXTSTRING records in the same file with the same name but different

numbers, should be treated as a fatal error. The appearance of both record types ‘5’ and ‘6’ in the same OASIS file

should be treated as a fatal error.

17 PROPNAME Record

17.1 A PROPNAME record associates the name of a property with a unique reference number. This allows

PROPERTY records, if desired, to avoid redundantly storing the actual text of the property name and instead refer

to the property name by its assigned reference number. It has the following format:

‘7’ propname-string

‘8’ propname-string reference-number