文章详细介绍了OASIS文件格式的结构和记录类型，包括CELLRECORD、XYABSOLUTE和XYRELATIVE记录的使用，以及模态变量的作用。OASIS文件包含各种记录类型，如CELL、TEXT、RECTANGLE等，用于描述图形元素和布局信息。文件以START记录开始，END记录结束，中间包含各种数据记录，如CELLNAME、TEXTSTRING、LAYERNAME等，以及压缩数据的CBLOCK记录。模态变量用于节省空间和提高压缩效率。异常处理部分强调了对未定义或错误数据的处理方式。
8 CELL REFERENCING
8.1 跟GDSII文件一样, 在OASIS文件中， cells也是用名字来标识的。一个CELL record不仅要包括一个cell的定义，还要包括它的名字。 PLACEMENT record根据cell的名字来指定cell的放置位置。跟GDSII一样，在OASIS中没有匿名的cells，所有的cell都要有名字。
9 LAYERS, DATATYPES, AND TEXTTYPES
跟GDSII一样，每个<geometry>都跟一个layer number和一个datatype number关联在一起； 每一个text element都跟一个textlayer number和一个texttype number关联在一起。
10 MODAL VARIABLES
译者备注：
这里先对modal variable进行说明。modal variable类似于文件中的内置的全局变量，存储着比如element的放置位置、间隔等信息。当解析一个新的element的时候，element的相关值会存在这些变量里面，后面的element如果不明确指定这些值，就用前面element的值来作为自己的值。由于文件中很多数据是相同的，所以后面的记录(record)中的参数，可能跟前面的一样，所以它就可以省略这些参数，直接将前面record的参数作为自己的参数，从而提高文件的压缩性。
10.1 为了压缩的目的，在很多的OASIS records里面的数据元素，可以用modal variables或者存储状态(stored state) 来隐式定义(implicitly specified)。
在文件的开头和一个CELL或者<name> record的开始， 所有的modal variables，除了以下列举的这些（placement-x, placement-y, geometry-x, geometry-y, text-x, 和 text-y），都是未定义的。下面6种： placement-x, placement-y, geometry-x, geometry-y, text-x, 和 text-y，如果没有赋值，它们不是未定义的，而是应该认为赋予初始值是0.
所有的变量元素(various element)都在cell的描述(description)种定义。跟这些变量元素相关联的modal variable则在元素定义种设置。这些modal variable可以被后继的元素隐式的使用。一个modal variable可以是一个值（比如geometry-w的一个值）, 或者包含多个变量的一个结构（比如一个repetition）。
10.2 在上表 Table 10-1中罗列出来了一共12种Modal variable。 其中的的xy-mode类型，用来管理对应的记录(record)的x和y字段（filed）的解释。也就是说一个record中，怎么解释它的x和y field，是由这个record对应的xy-mode类型的Modal variable决定的。 xy-mode有两种模式，绝对值和相对值。具体见21小节对这两种模式的讨论。 （译者注：简单说就是一个record对应的xy-mode决定了这个record的x和y的值，是绝对坐标和相对坐标。）
10.3 异常处理: 如果一个OASIS record对应的modal variable状态是未定义的状态，那么应该当作fatal error 处理。
11 RECORDS
11.1 OASIS文件的基本信息单元就是一个record， 我暂且翻译为记录。一个record 首先是一个无符号整型表示的record-ID, 然后接着这个记录的描述数据。 在本协议中record-ID显示的时候，是一个单引号包起来的十进制整数。
11.2 CBLOCK record是一个特殊的record, 它采用了字节压缩的方式，封装了一系列普通的records. 当解析程序读到一个CBLOCK记录的时候， 首先要解压缩，从而产生一个或者多个普通的record; 然后再依次将这些record解码。更多的CBLOCK record信息可以参考35节。
11.3 大多数records有一个隐含的长度。记录必须被解析和解码以后，才能确定它的长度。 但XNAME, XELEMENT和XGEOMETRY这三个record类型除外。（译者注:就是这三种数据无需解析和解码，就可以知道它的长度）。 这三种类型的record将所有未定义的数据封装在一个变化长度的b-string类型中 因此他们能作为新record类型的原型(译者注:类似基类)，隐藏自身嵌入的数据，支持局部的非通用性扩展， 等等。 这样对于一些不支持这些record的解析器，他们可以很容易的知道这些字符串的长度，并且跳过这些不能解析的record.
11.4 异常处理：如果解析发现一个CBLOCK记录嵌套了另外一个CBLOCK记录，这个认为是fatal error.
12 PAD RECORD
12.1 一个PAD记录提供了一个简单的方法在OASIS文件中保留一段空间。它包含下面的格式：‘0’.
12.2 PAD 记录可以插入在任何两个记录中间。
12.3 异常处理： 解析的时候如果在START记录之前或者END记录之后，出现PAD记录，那么认为是fatal error.
13 START RECORD
13.1 一个START记录表示一个OASIS文件的开始， 它紧接在<magic-byte>的后面。<magic-byte>可以参照6.4节的介绍。START记录有下面的格式：
‘1’ version-string unit offset-flag [ table-offsets ]
13.2 上面version-string 字段是一个字符串，在当前的OASIS版本中它的值是 “1.0”.
13.3 unit 字段是一个正的实数，定义了OASIS文件的坐标系统中坐标系统的全局精度。OASIS文件系统坐标系统是用每1微米作为步长定义的的网格系统。OASIS的unit的值本质上是GDSII文件格式中的UNITS记录中的第一个值的倒数。
13.4 offset-flag是一个无符号的整数，当offset-flag值是0的时候表示table-offsets结构存储在START记录中； offset-flag是1的时候表示table-offsets结构存储在END记录中。把table-offsets存储在END结构中提供了顺序写入OASIS文件的可能性，不需要seek-and-update操作，也就是说不需要到最后返回到前面来更新START记录。然而依然可以为顺序(sequence)的readers提供随机访问cell级别的能力。
13.5 table-offsets 结构由六个无符号整数对组成。每个整数对由一个flag和一个byte-offset组成。按照table 13-1的顺序组成。
13.6 上面表格中的Flag字段，要么是1， 表示对应表格中的数据是严格模式(strict mode)；或者是0， 表示的是非严格模式（non-strict mode）.
上面的byte-offset字段，表示的是它对应的table表中的第一条记录相对于oasis文件开头（byte 0）的位置。如果byte-offset为0则表示没有对应的table表。
13.7 在非严格模式中(non-strict mode), 对应类型的记录可能出现在文件中的任何位置，即使它们中的一些记录已经被集中放在table表中用byte-offset指向的位置。
13.8 在严格模式下（strict mode）, 对应类型的所有记录（包括与之相关的PROPERTY记录），都会被集中放在table中对应的byte-offset指向的一段连续的位置。PAD记录也可以放在严格模式的table表中。另外，严格模式保证对相应类对象(name, strings or cells)的所有引用均由reference-number独家计数。
13.9 当一个严格模式table表被一个或者多个CBLOCK记录封装时，对应的byte-offset应该指向封装这个table的第一个CBLOCK记录的第一个字节。并且这个table的第一条记录必须时CBLOCK记录解压以后的第一条记录。基于这个要求协议不允许在1个CBLOCK记录中封装多于1个的严格模式table表， 也不允许在CBLOCK记录中间开始一个严格模式table表。
13.10 异常处理：如果一个OASIS文件的开头第一个记录(record)不是START类型的记录，应该认为是一个fatal的错误。如果unit的值是Nan, Inf或者非正数值， 应该认为是fatal错误。当一个tale offset是非0，并且table表是严格模式，如果存在该类型的“杂散”(“stray”)记录与它的表格组（tabular group）存放在不连续的位置，那么应该认为是fatal的错误。任何任何记录未使用reference number来访问该类对象， 应该认为是fatal错误。
一个并不依赖任何严格模式提供的record grouping，renference-number和byte-offset 的OASIS的文件解析者，并不需要检测和报告由严格模式引起的任何异常。（译者注：也就是说，对于文件解析器，如果我没有用到strict mode中的信息，那么我就不需要去专门去检查和报告严格模式中的这些错误，因为我没有用到它，所以我也不关心它。）
14 END RECORD
14.1 END 记录标识OASIS文件的结束。END记录必须是文件中的最后一个记录；不允许有后继的字节。它的格式是：
‘2’ [ table-offsets ] padding-string validation-scheme [ validation-signature ]
14.2 上面的table-offsets结构体是由offset-flag管理的数据，具体可以参看START记录（第13章）。 上面的
padding-string (a b-string) 必须是由OASIS写者计算和写入的，它的目的是使整个END记录，包括record-ID， 正好是256个字节。这样，OASIS的读者就可以从文件的末尾开始寻找，正确找到END记录（以及相关的table-offsets和validation-signature）, 从而避免存一个指向START记录的前向指针。padding-string的内容必须初始化成NUL字符。
14.3 validation-scheme是一个无符号整型数据，它表示文件使用哪个验证方案(validation schema)。上面的validation-signature 就是表示根据validation scheme所对应的验证方案生成的验证字节数据，用来验证OASIS的完整性。下表是验证方案(validation scheme)的定义。
14.4 CRC32 验证方法
14.4.1 The CRC32 多项式是在ISO 3309中定义的：
x32 + x26 + x23 + x22 + x16 + x12 + x11 + x10 + x8 + x7 + x5 + x4 + x2 + x1 + x0
其中最左边的bit表示的是最高位（most significant）bit. 比如下面是二进制数据以及对应16进制数据:
binary 1 0000 0100 1100 0001 0001 1101 1011 0111
hexadecimal 104c11db7
14.4.2 CRC32值的计算使用所有的OASIS文件的字节， 从START记录的第一个byte到END记录的validation-scheme整数。并且它跟byte的顺序是有关的。它计算的32bits的结果记录在文件的最后四个字节中，最小byte在前面(with the least significant byte first)。 它通常用查表并结合偏移/异或(shift/XOR)的方法来计算。在附录1中给出了用C语言实现的源代码。
14.5 CHECKSUM32 验证方法
14.5.1 CHECKSUM32验证签名计算方式是把OASIS文件从START记录的第一个byte到END记录的validation-scheme整数， 做简单的无符号求和。最后的结果截取最低的32 bits并存放在文件的最后四个字节中，存放的顺序是低字节优先(with the least significant byte first)。它跟字节顺序无关，这个特性使得它更容易计算，尤其是当文件不是顺序写入的时候。但是它对错误的检测能力比CRC32要弱。在附录1中有用C语言实现的源代码。
14.6 异常处理: 如果在OASIS文件中没有END结构认为是一个Fatal的错误。
15 CELLNAME RECORD
15.1 一个CELLNAME记录把一个cell的名称关联到一个全局唯一引用数(a unique reference number)。这允许CELL和PLACEMENT记录，当需要的时候，避免冗余存放cell的名称，而用引用数来替代。(无符号整数长度比字符串短小)。它的格式有两种：
‘3’ cellname-string
‘4’ cellname-string reference-number
15.2 cellname-string 是一个n-string类型的数据，存放着cell的名称。Reference-number是一个无符号整数，它显式或者隐式的赋值给一个cell。如果记录类型是’3’， 那么它是非明显的赋值，它从0开始赋值，每个CELLNAME记录都递增1来赋值。如果记录类型是’4’，那它是明显赋值，对应的reference-number就是记录中赋值的无符号整数
15.3 两个标准的属性: S_BOUNDING_BOX 和 S_CELL_OFFSET (在A2-2节描述
), 可能会跟每个 CELLNAME 记录关联。当在严格模式（严格模式在第13节叙述）下 所有的CELLNAME记录都被组织在一个连续的table表中的时候， 对于每个CELLNAME记录都有一个S_CELL_OFFSET属性，这个表格就是整个OASIS文件所有cell的一个完整索引，以便随机访问cell.
15.4 在同一个文件中， CELLNAME记录中的记录类型 ‘3’ 和 ‘4’ 不应该同时出现。（同一个文件中，要不都用类型3, 要不都用类型4，不要混在一起用。）
15.5 异常处理： 如果有两个CELLNAME记录有相同的名字但不同的引用号；或者相同的引用号但不同的名字，应该认为是fatal错误。如果同一个OASIS文件中同时出现类型‘3’和类型‘4’, 应该认为是fatal错误。在一个特定的CELLNAME记录后出现多于一个S_CCELL_OFFSET或者S_BOUNDING_BOX属性，属于fatal错误。
16 TEXTSTRING RECORD
16.1 一个TEXTSTRING记录把一个文本字符串跟一个全局唯一的引用数联系在一起。这允许TEXT记录，当需要的时候，避免存储冗余的字符串，而用对应的引用数替代。它有下面两种格式（跟CELLNAME记录类似）：
‘5’ text-string
‘6’ text-string reference-number
16.2 text-string 是一个a-string类型的字符串，保存实际的文本字符串。而reference-number则是一个无符号整型，对应的这个字符串的全局唯一引用数。有显式和隐式的两种赋值方式。如果记录类型是‘5’，则是隐式的赋值方式，从0开始递增，每遇到一个TEXTSTRING记录加1。 如果记录类型是’6’则是显式的赋值方式。
16.3 记录类型 ‘5’ 和 ‘6’ 不应该出现在同一个OASIS文件中。
16.4 异常处理： 如果出现两个相同名字但是不同引用数的TEXTSTRING记录，或者相同引用数但不同名字的TEXTSTRING记录， 应该认为是一个fatal错误。如果记录类型‘5’ 和 ‘6’ 出现在同一个OASIS文件中，也应该认为是Fatal的错误。
17 PROPNAME RECORD
17.1 一个PROPNAME记录把一个属性名字和一个全局唯一引用数对应起来。这可以使PROPERTY记录，当需要的时候，避免存放冗余的属性名字字符串，而用这个全局唯一的引用数替代。它有下面两种格式：
‘7’ propname-string
‘8’ propname-string reference-number
17.2 propname-string 是一个n-string类型的字符串，存放属性的名字。而reference-number 则是一个无符号整型数据， 表示对应的全局唯一引用数。它有隐式和显式两种赋值方式。如果记录类型是’7’， 则是隐式的赋值方式，记录号从0开始，每遇到一个PROPNAME加1. 如果记录类型是’8’， 则是显式的赋值方式。
17.3 记录类型 ‘7’ 和 ‘8’ 不应该同时出现在同一个OASIS文件中。
17.4 异常处理：如果在一个OASIS文件中，出现两个相同名字但是引用数不一样的PROPNAME，或者出现两个相同引用数但不同名字的PROPNAME，应该认为是个Fatal错误。如果在一个OASIS文件中同时出现记录类型’7’和记录类型’8’, 应该认为是个Fatal错误。
18 PROPSTRING RECORD
18.1 一个PROPSTRING记录把一个属性字符串和一个全局唯一的引用数关联在一起。这样就可以用全局唯一的引用数替代属性字符串，从而避免冗余的属性文本字符串。它有两种格式：
‘9’ prop-string
‘10’ prop-string reference-number
18.2 prop-string 是一个 a-string, b-string 或者 n-string的字符串用来存放属性字符串。 reference-number是一个无符号整型，有隐式赋值和显式赋值两种方式。如果记录类型是 ‘9’则是隐式赋值，引用数从0开始，每遇到一个PROPSTRING记录加1。 如果类型是 ‘10’则是显式赋值。
18.3 记录类型‘9’ 和 ‘10’ 不应该出现在同一个OASIS文件中。
18.4 异常处理：如果出现两个PROPSTRING 记录有相同引用数但有不同名称，或者有相同名称但有不同引用数，则被视为Fatal错误。如果记录类型 ‘9’ 和‘10’ 出现在同一个文件中认为是Fatal错误。
19 LAYERNAME RECORD
19.1 一个LAYERNAME记录把数值对 (layer,datatype)或者 (layer,texttype) 和layer的名称结合在一起，其中(layer,datatype)或者 (layer,texttype)它可以是一个范围的数值。LAYERNAME有下面两种格式：
‘11’ layername-string layer-interval datatype-interval
‘12’ layername-string textlayer-interval texttype-interval
19.2 记录类型 ‘11’提供了数值对(layer,datatype) 和 layer名称的映射； 记录类型 ‘12’ 则把数值对
(textlayer,texttype) 和layer名称映射在一起。
19.3 layername-string 是一个n-string 类型的数据，提供了layer的名称。
19.4 每一个interval的域值 fields由一个表示间隔类型的无符号整数， 以及一个（当类型是4的时候有两个）表示间隔边界的无符号整型组成。 具体格式和含义如下表所示。
19.5 对于同一个layer名称， LAYERNAME 记录可以重复多个， 这样可以把多个layer, datatype和texttype值(范围段range)映射到同一个layer名称.
20 CELL RECORD
20.1 一个 CELL
最低0.47元/天 解锁文章
扫一扫
3196
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
