ASIC and Custom IC Cell Information Representation:GDS2

GDS2

The Graphical Design System (GDS) format is a binary format developed by Calma Company in 1971 to convey IC layout information between IC designers and fabricators. Calma presented GDS2 format, the improved version of GDS, in 1978. Finally in 1991, when Cadence acquired Calma, GDS2 rights were transferred to it.

In the design process, after the completion of routing and placement, design rule check (DRC) and layout versus schematic (LVS) are performed to verify the ﬁnal layout. Then the veriﬁed layout, dumped in a GDS2 ﬁle, is transferred to IC foundries for fabrication.

GDS2 File Format

GDS2 is a standard mask layout intermediate format containing a single cell or a library of cells each of which includes a number of geometrical objects such as boundaries, paths, boxes, etc. These objects correspond to different layers of a cell where each layer is speciﬁed by a layer number and data type [3].

The ﬁle format of GDS2 is in binary. A GDS2 ﬁle contains a number of variable length records each of which follows immediately the previous one. The ﬁrst four bytes of each record, known as the record header, contain the information about the entire record, while the rest of the record (starting with byte 5) contains data. The ﬁrst two bytes of the header represent the total record length, while its 3rd and 4th bytes introduce the record type and its current data types, respectively.

Data Types

Byte 4 of a GDS2 record indicates the type of data included in this record. Allowable data types in the GDS2 format are bit array, 2-byte signed integer, 4-byte signed integer, 4-byte real, 8-byte real, and ASCII string. These types are represented in sequence by the integers between 1 and 6. Value 0 for the data type is used for types of records with no available data.

A bit array data is a 2-byte data regarded as 16 individual bits of data. In a GDS2 ﬁle, signed integer and real number types use 2’s complement and ﬂoating point formats, respectively. Each ﬂoating point number is composed of three different parts: sign, exponent, and mantissa, where its most signiﬁcant bit represents the sign, the next 7 bits introduce the exponent, and the rest of the bits specify the mantissa of the real number. In this format, the actual exponent of a ﬂoating point number is 64 units less than the value presented by the related bits [4]. Thus the value of a ﬂoating point number is equal to (−1)sign × (mantissa) × 16(actual exponent)

ASCII strings include a number of ASCII characters each of which are one byte long. According to the GDS2 format the size of each record should be an even number of bytes. Thus if the ASCII strings includes an odd number of characters, a null character is appended to the end of the string.

Note that value 0 is allocated to the types of records with no available data. Obviously the number of data pieces in each record can be speciﬁed by considering the record length and its current data type. Each record can be between 4 and 65536 (=216) bytes long where a 4-byte record contains no data. An example of a 4-byte record is TEXT record which indicates the state of a text record.

Record Types

Byte 3 of a GDS2 record indicates the type of the record. A GDS2 ﬁle contains a number of ordered variable lengths records, i.e., the order in which records appear in a GDS2 ﬁle must be according to the GDS2 syntax. This ﬁle starts with the header record and is followed by other records in the order shown in Figure 93.4.

In Figure 93.4, items marked with an asterisk (FORMATTYPE and STRUCTURE) represent a group of records while other items are individual records. Of the records shown in Figure 93.4, a GDS2 ﬁle must include HEADER, BGNLIB, LIBNAME, UNITS, and ENDLIB records while it may or may not include the other records.

As discussed above, record type and data type of records are each 1 byte long. However, all combinations of record types and data types are not valid, i.e., for each predeﬁned record type only one unique data type is valid.

Commonly used record types and their related data type values are discussed below. A 4-byte number represents record and data types: the ﬁrst two digits show the hexadecimal value of the record type and the other two digits specify the data type. For example, the HEADER record is represented by 0002, where 00 shows that the record type is header and 02 represents that its corresponding data type is a 2-byte signed integer.

A GDS2 Example

To better understand the structure of GDS2 that will be described in the next section, a simple example and its record ﬁle will be presented here. We will refer to this example when describing records and data types of GDS2.

Figure 93.5 shows the physical layout of an inverter. Because of the size of the GDS2 ﬁle for this complete layout, only a section of this design along with its hexadecimal representation of the related GDS2 ﬁle are shown in Figure 93.6(a) and Figure 93.6(b) respectively. GDS2 records, which consist of a header and data, are shown in Figure 93.6(b). For each record, the header is shown in bold, and its

corresponding data follows it. For clarity in the GDS2 information, we have also provided a symbolic representation of the GDS2 ﬁle of Figure 93.6(b). This representation (Figure 93.7) uses mnemonics for record types. The actual data of the records follow the mnemonics.

Structure of GDS2

The structure of a GDS2 ﬁle is as described here.

Header. A GDS2 ﬁle starts with the HEADER record (code 0002), which indicates the GDS2 version number. This is shown in line 1 of Figure 93.6(b) and in Figure 93.7.

Library specification. Speciﬁcation of a library of cells in GDS2 begins with the BGNLIB record (line 2, Figure 93.6(b)) and if the optional records do not exist, it is followed by LIBNAME (line 3, Figure 93.6(b)) and ends with the ENDLIB record (line 42, Figure 93.6(b)).

The BGNLIB record is identiﬁed by 0102 and as data, it has the date of the library. The data included in the BGNLIB record includes twelve 2-byte data which are the corresponding year, month, day, hour, minute, and second of the last modiﬁcation and access times, respectively (line 2, Figure 93.6(b)).

Following the BGNLIB, the LIBNAME record (code 0206, example: line 3, Figure 93.3) contains the library name. In our example the library name is INV. The ENDLIB record (code 0400, example: line 42, Figure 93.6(b)) contains no data.

A library speciﬁcation may also include several optional records discussed here. When a new library is created, the number of pages in the library directory as well as the access control list data and the name of the sticks rules ﬁle can be introduced by the LIBDIRSIZE(code 3902), LIBSECUR(code 3B02), and SRFNAME(code 3A06) records, respectively. Furthermore, to attach reference libraries to a working library, the REFLIBS record (code 1F06) is used. This record speciﬁes consecutively the name of all reference libraries allocating 44 byte for each library name.

Units. The geometrical dimensions of the elements of a GDS2 ﬁle are expressed using the UNITS record (code 0305, example: line 4, Figure 93.6(b)), which shows the relation between database and user units. The UNITS record contains two 8-byte real numbers to demonstrate in sequence the size of database unit in user unit and meters.

Structures and elements. A GDS2 ﬁle contains a number of structures, each of which includes an arbitrary number of elements. Mnemonic STRUCTURE∗ in Figure 93.4 represents a group of records for deﬁning a structure. Each structure begins with BGNSTR and is identiﬁed by its name (using STRNAME record, code 0606).

The last modiﬁcation and access date of the structure are included in the BGNSTR record (code 0502, example: line 5, Figure 93.6(b)). The end of a structure is marked by ENDSTR (coded with 0700, example: line 41, Figure 93.6(b)). Note that BGNSTR record includes twelve 2-byte data in the same format as the BGNLIB record.

GDS2 elements are geometrical objects assigned to different layers of a design. These objects have the following types:

• Boundary

• Path

• SREF

• AREF

• Text

• Box

• Node

Boundary. A boundary element is a closed polygon speciﬁed by the XY coordinates of its vertices in database units. The ﬁrst and last vertex of a boundary must be the same. A boundary speciﬁcation starts with the BOUNDARY record (code 0800, example: line 23, Figure 93.6(b)), is followed by LAYER (code 0D02, example: line 24, Figure 93.6(b)), DATATYPE (code 0E02, example: line 25, Figure 93.6(b)), and XY (code 1003, example: lines 26 and 27, Figure 93.6(b)) records, and terminates with the ENDEL record (code 1100, example: line 28, Figure 93.6(b)). LAYER and DATATYPE records specify the layer number and label of the speciﬁed element, respectively, while the XY record includes an array of XY coordinates related to the vertices of the speciﬁed object. Note that the number of speciﬁed XY coordinate pairs for a boundary element should be between 4 and 200.

Path. A path element is an open polygon speciﬁed by the XY coordinate pairs of its vertices. Each path speciﬁcation starts with the PATH record (code 0900), is followed by LAYER, DATATYPE, and XY records, and terminates with ENDEL record. The minimum and maximum number of required XY coordinate pairs to specify a path element are 2 and 200, respectively. In addition to the above records a path speciﬁcation may contain two other records to specify element width in database units and the type of path endpoints.

SREF. Utilizing a structure reference (SREF) element within a structure results in the instantiation of that structure and its placement in the referencing structure. Each SREF speciﬁcation starts with SREF (code 0A00) record, is followed by SNAME (code 1206) and XY records, and terminates with ENDEL record. SNAME and XY records demonstrate in sequence the name of the referenced structure and its location within the referencing structure. In addition to the above records, an SREF speciﬁcation may contain another record to deal with reﬂection, magniﬁcation, and rotation of the referenced structure in the referencing one.

AREF. An AREF element is used to instantiate and locate an array of speciﬁed structures within another structure. An AREF speciﬁcation starts with AREF record (coded with 0B00) and is followed by SNAME, COLROW (coded with 1302), and XY records and terminates with ENDEL. COLROW speciﬁes the size (number of rows and columns) of the instantiated array. The XY record in an AREF element includes three pairs of XY coordinates. The ﬁrst pair introduces the array reference point while second and third pairs are used to specify the locations of other instantiated elements. Similar to an SREF element, an AREF element may contain another record to deal with reﬂection, magniﬁcation, and rotation of the referenced structures in the referencing one.

Text. Each text speciﬁcation in a GDS2 ﬁle starts with the TEXT record (code 0C00, example: line 7, Figure 93.6(b)), is followed by LAYER, TEXTTYPE, XY, and STRING records, and terminates with ENDEL record. TEXTTYPE (code 1602, example: line 9, Figure 93.6(b)) represents the text-type speci- ﬁcation, while the STRING record (code 1906, example: line 13, Figure 93.6(b)) includes the character string that is presented by this element. The location of each text element is speciﬁed by a single pair of XY coordinates. In addition to the above records, a text speciﬁcation may contain other records to deal with the text font, alignment, and width as well as the format of its endpoints, reﬂection, magniﬁcation, and rotation of that text element.

Box. A box is a four-sided polygon represented by exactly ﬁve pairs of XY coordinates, where the ﬁrst and last pairs must be exactly the same. Box is a special case of boundary. A box speciﬁcation starts with BOX (code 2D00), is followed by LAYER, BOXTYPE (code 2E02), and XY records, and terminates with the ENDEL record.

Node. A node element speciﬁcation starts with the NODE record (code 1500), is followed by LAYER, NODETYPE (code 2A02), and XY records, and terminates with the ENDEL record. Each node location can be introduced by at most 50 pairs of XY coordinates.

In addition to the discussed records, each element speciﬁcation may contain two other records to introduce template and external data as well as Plex number and Plexhead ﬂag.

Other specifications. GDS2 ﬁles can be categorized into two different groups: archive stream and ﬁltered stream ﬁles indicated by the FORMAT record (code 3602). In the former, the elements of GDS2 structures can be located in all layers and data types. In the latter category, only the user-deﬁned layers and data types may include the elements. In an archive stream ﬁle, UNITS must immediately follow the FORMAT record, while in a ﬁltered stream at least one MASK record (code 3706) precedes the UNITS record. In this stream, the last MASK record must be immediately followed by ENDMASKS record (code 3800). The MASK record is used to represent the list of layers and datatypes speciﬁed by the user when creating the ﬁle. Mnemonic FORMATTYPE∗ in Figure 93.4 introduces a group of records representing the stream type of the GDS2 ﬁle as well as the list of related layers (if available).

In a GDS2 stream, the number of preserved copies and back-up structures is speciﬁed by utilizing GENERATIONS record.

Our Coverage of GDS2

GDS2 is a mask layout intermediate format used to convey layout information between EDA tools. We discussed the basics of GDS2 in the preceding section and provided a layout example along with its hexadecimal and symbolic representations of the related GDS2 ﬁle.

The constructs not included in this example follow the same basic patterns discussed here. For a more complete description of this language readers are encouraged to see the references at the end of this chapter [3,4].

The following section is on EDIF. This EDA format is a standard data interchange format used to transfer design data between different EDA tools. In the following section, we deal with the common constructs of the EDIF format.

Search This Blog

Integrated circuit course