Using OASIS to contain the size of data files in the manufacture of photomasks

Steffen Schulze, Mentor Graphics

The data volumes of individual files used in the manufacture of modern photomasks have become unmanageable using existing data-format specifications. The International Technology Roadmap for Semiconductors (ITRS) indicates that single-layer files in manufacturing electron-beam exposure system (MEBES) format from Etec (Hayward, CA) may exceed the 200-Gbyte threshold in 2004. To address this problem, a two-year development project was begun by the SEMI Data Path Task Force. In June 2003, members of the SEMI voted on a new standard for design data representation, the Open Artwork System Interchange Standard (OASIS), and approved it.¹ The task force hoped that the new format would generate files that are one-tenth the size of those generated by graphic design system II (GDSII); efficiently handle flat geometric data, including arrayed geometric figures; remove 16-bit and 32-bit restrictions, allowing integers to extend to 64 bits and beyond when required; and enhance overall information richness.

During the development phase, data have been published demonstrating that the new format is promising. Experiments using software based on the final OASIS specification indicate that data containment can be achieved using the innovative principles of data representation that have been incorporated into the new format.^2,3 With the approaching conclusion of development work, it is important to understand how OASIS works and the benefits it offers to contain the sizes of the data files used to manufacture photomasks.

OASIS versus GDSII

Unlike GDSII, which has fixed-length integers, OASIS uses flexible-length integers. By assigning a continuation bit that indicates if additional storage space is necessary, OASIS can adjust integer length to the size of the number that needs to be represented. In addition, the format uses the concept of relative coordinates. Instead of defining absolute coordinates for every vertex, it defines the anchor point of a primitive in absolute coordinates relative to the origin of the data set, whereas any other point is described relative to the anchor point or the previous point in a point list. Since the lengths of edges of elementary figures are usually represented using small numbers, single-byte integers suffice to represent them in most cases. Variable delta definitions (1-delta, 2-delta, 3-delta, and g-delta) are defined to describe the 2, 4, 8, or arbitrary directional displacements.

In OASIS, high-content design data appear in Manhattan-type structures and form 45° angles. Consequently, polygons can be represented by efficient point lists that rely on single deltas that assume the alternate x and y alignment of edge segments. Five types of point lists, which address special applications and general sequences, have been defined.

OASIS continues to use the concept of cells and hierarchy used in GDSII files. However, it outperforms GDSII in that repetitions can also be applied to geometries and text elements. Hence, OASIS is much more efficient at handling flat data that represent regular structures. Similar to point-list definitions, characteristic definitions of repetitions are described separately in the most effective form, while constructs are maintained for the most general cases.

Acknowledging that many data elements in a design database—such as data layer, data type, array parameters, and coordinates—share common features, OASIS has introduced modal variables. These variables define a stored state for a certain feature that applies as long as it is not overwritten. Thus, a data layer must be defined only once for a sequence of polygons as long as they all belong to the same layer. Only when a polygon on a different layer must be described is it necessary to redefine the data layer. Since OASIS also represents the types of less-hierarchical data that are frequently generated when maskwriter data are prepared during fracturing, primitives such as general trapezoids and ctrapezoids (which contain only 45° and 90° angles) can be defined. By understanding the limited structure of such primitives, OASIS can achieve a more compact representation than it can with polygons.

An OASIS file can be accessed randomly when the application that creates it constructs cell tables and cell offset tables that function as an embedded encryption system. With this feature, parts of a file can be compressed while others remain uncompressed.

Performing OASIS Experiments

To test the effectiveness of converting GDSII files into OASIS databases, experiments based on the final SEMI specification were performed. The first experiment explored the ability of OASIS to represent flat data translated from the commonly used MEBES format. The second illustrated an efficient mask data preparation flow that generated variable-shaped beam maskwriter data based on an OASIS input file.

All experiments tested the implementation of OASIS version 1.0 using Calibre and Calibre-viewing tools from Mentor Graphics (Wilsonville, OR). MEBES data were generated using the Calibre FRACTUREm utility, while data written in VSB11 format from NuFlare Technology (Yokohama, Japan) were generated using the Calibre FRACTUREt utility. The translation of GDSII files into OASIS was conducted using a stand-alone gds2oasis translator. Flat data representation was achieved using a mebes2oasis translation utility. Optical proximity correction (OPC) was performed using Calibre OPCpro.

The translation experiments were conducted on a 450-MHz server using a single cpu from Hewlett-Packard (Palo Alto, CA). Fracturing was conducted on a 1-GHz Itanium server with four cpus. The test samples underwent a standard mask data preparation flow, including sizing and Boolean operations. Run times and file sizes were recorded.

Figure 1 summarizes the sizes of various design data files represented in GDSII and OASIS formats and the size ratios between them. Across a range of different input file sizes, the ratio is larger than the targeted benchmark of a tenfold reduction in file size. The OASIS file for a test sample not shown in the figure was 200 times smaller than that of the GDSII file for the same sample. In addition to its smaller file size, the OASIS format enables applications to use different algorithms to perform extended data compression because it offers a large variety of data-representation possibilities.

Translation experiments, the results of which are presented in Figure 2, were conducted on test files after the implementation of OPC. For a large variety of input file sizes, OASIS files, on average, were more than 10 times smaller than GDSII files.

To understand the differences in the distribution of shapes in a file, design data were investigated before and after OPC was implemented. The results for a test case are summarized in Table I. The table lists the total counts of representative records along with counts for the portion of each record captured through repetitions. Cell and placement records were approximately 10% smaller after OPC implementation than before. Because of the interaction range of the OPC effect, some reduction is to be expected in the hierarchy present. The incoming data had similar numbers of rectangles (1.9 million) and polygons (1.1 million). To a large extent, the rectangles were called out in repetitions while the polygons are mostly unique. The post-OPC rectangle count was 7.2% smaller than the pre-OPC data, while the polygon count was 3.4 times larger. The repetition counts for both types of shapes changed accordingly. That result is not surprising. The implementation of OPC fragments the edges of simple rectangles, thus transforming them into complex polygons and adding vertices.

In addition to representing hierarchical data efficiently, OASIS was optimized to represent flat data. The experimental data in Table II were collected on the translation of MEBES into OASIS files. In all cases investigated, the OASIS files were 1.29 to 2.62 times smaller than the MEBES input files.

The smaller size of OASIS files indicates that the format can serve as a hierarchical data transfer format—for example, between a design house and a mask manufacturer. The need to perform mask-data manipulation for process optimization, mask proximity correction, and final maskwriter formatting at mask houses has been discussed in the literature.⁴ It is widely accepted that hierarchical processing results in faster processing times and smaller output files than flat processing.^4,5 It is thought that OASIS will replace GDSII data for that purpose.

To test the flow efficiency of OASIS for performing hierarchical data transfer, two data-preparation sequences were compared:

Table III compares the time required to generate a VSB11 file from an OASIS input file with the time required to generate such a file from a MEBES, the commonly used transfer format. The hierarchical flow associated with OASIS is 7.4 times faster than the flat flow associated with MEBES. Figure 3 compares the file sizes resulting from the two types of flows. While the input formats available until recently—GDSII and MEBES—are almost the same size, the OASIS input file is approximately 10 to 11 times smaller. The output VSB11 data resulting from a hierarchical flow is nearly nine times smaller than the data generated via flat MEBES data.

Conclusion

The OASIS-format standard has been approved by the semiconductor industry and has been released by SEMI. Experimental data based on the use of OASIS version 1.0 show that the target of achieving a tenfold reduction in average file size for design data has been achieved and, in many cases, exceeded. Experiments conducted after OPC implementation show an average tenfold reduction in file size. The ability of OASIS to represent flat data efficiently has been proven. With file sizes up to 2.6 times smaller than MEBES files, the OASIS format is enabling the industry to redefine the file size growth outlook predicted for coming device generations by an order of magnitude.⁶

Figure 3: Input file sizes of data in GDSII, OASIS, and MEBES formats and VSB11 output files transferred via OASIS. The MEBES file commonly used as an intermediate format and transfer medium is larger than the OASIS file derived from the hierarchical GDSII input data. Generating VSB11 data using the OASIS format leads to a VSB11 file that is nearly nine times smaller than a VSB11 file generated from a MEBES file.

OASIS is an efficient alternative to GDSII for post-tape-out data preparation flow processing. While performing hierarchical processing—which translates into faster processing times and decreased output file sizes—OASIS also generates files that are smaller than the files generated from MEBES, which is still widely used in the industry to perform data exchange, although MEBES files require reformatting at the mask house.

References

1. "Open Artwork System Interchange Standard (OASIS)," SEMI P39-0304E (San Jose: SEMI, 2004 [cited 2 August 2004]); available from Internet: www.semi.org.

2. P Lacour et al., "New Stream Format: Progress Report on Containing Data Size Explosion," in Proceedings of SPIE, vol. 5042: Design and Process Integration for Microelectronic Manufacturing (Bellingham, WA: SPIE, 2003), 214–221.

3. A Reich, K Nakagawa, and R Boone, "OASIS vs. GDSII Stream Format Efficiency," in Proceedings of SPIE, vol. 5256: BACUS Symposium on Photomask Technology (Bellingham, WA: SPIE, 2003), 163–173.

4. S Schulze, P LaCour, and P Buck, "GDS-Based Mask Data Preparation Flow: Data Volume Containment by Hierarchical Data Processing," in Proceedings of SPIE, vol. 4889: BACUS Symposium on Photomask Technology (Bellingham, WA: SPIE, 2002), 104–114.

5. S Schulze, E Sahouria, and E Milsolavsky, "High Performance Fracturing for Variable Shaped Beam Mask Writing Machines," in Proceedings of SPIE, vol. 5130: Photomask and Next-Generation Lithography Mask Technology (Bellingham, WA: SPIE, 2003), 648–659.

6. The International Technology Roadmap for Semiconductors, Lithography section, Table 79a, "Optical Mask Requirements" (San Jose: Semiconductor Industry Association, 2003); available from Internet: http://public.itrs.net.

Steffen Schulze, PhD, is the product manager for the Calibre mask data preparation tools at Mentor Graphics (Wilsonville, OR). Based on his knowledge of mask operations and silicon processes, he worked at the Center for Microelectronics in Dresden, Germany, and later at Siemens and Infineon Technologies in East Fishkill, NY. He received a PhD in electrical engineering from the Institute for Microsensors at the University of Bremen in Germany. (Schulze can be reached at 503/685-8000 or steffen_schulze@mentor.com.)