Data-handling issues for OPC
09/01/1998
Data-handling issues for OPC
Kurt Wampler, Roger Caldwell, MicroUnity Systems Engineering Inc., Sunnyvale, California
Five years ago, most industry experts dismissed full-chip optical proximity correction mask enhancement as utterly impractical for volume production. The compelling need for resolution-enhanced photomasks, however, was strong enough to drive the development of techniques that make full-chip optical proximity correction not only possible, but practical for a large class of layouts. This technique can stress many of the hardware and software components involved in fracturing, tape out, mask writing, and inspection and repair of production photomasks. As its capabilities move forward, the software tools used must be able to handle the associated data volumes to avoid a disproportionate increase in mask-making costs.
There are various hurdles to the implementation of optical proximity correction (OPC) in lithography. Specifically, successful application of OPC on reticles requires a clear understanding of the various software data-handling issues associated with design, and tools for computer-aided design (CAD) and mask writing. Adding OPC to a design means a much greater burden in the amount of data used to represent the circuit pattern. For example, aggressive OPC can increase data volume ten times or more. In addition, the type of pattern data representation format can add varying degrees of complexity to the OPC process (see "Pattern data volumes: The OPC hit" on page 92). It is important to understand the differences between hierarchical and nonhierarchical (or "flat") representations of design data. A robust and production-worthy OPC software tool needs to be able to deal efficiently with both types of input.
 |
Hierarchical descriptions of reticle layout artwork have been used since computer-digitized representations were first applied to mask making. Briefly, a hierarchy defines a geometric prototype and then makes single or arrayed placements ("instances") of the prototype to describe a complicated, but regular layout compactly and efficiently. This description method is amenable to ICs with extremely regular and repetitious structures, such as memories. In these cases, hierarchical treatment is reasonably tractable.
Historically, the well-behaved properties of memory layouts coupled with high production volumes for a given product design have made it feasible to perform manual optimization and OPC of memory cells. As a result, even without automated CAD tools, manufacturers have been able to implement manual OPC on memory, allowing them to achieve payback for resolution-enhancement techniques in manufacturing much earlier than their counterparts designing ASICs, microprocessors, and random logic.
Because of shorter product life cycles and lower production volumes, ASIC, microprocessor, and random logic manufacturers have become increasingly reliant on highly automated place-and-route layout tools to meet time-to-market and circuit performance requirements. This has given rise to a layout structure whose large volume of flat, irregular, and random IC artwork (e.g., wiring data) is not amenable to hierarchical description. Such data can overwhelm a CAD tool designed around the assumption that incoming layout is regular and hierarchical. Manual optimization and OPC is out of the question for this type of layout structure. Aerial image simulation alone, even when run on massively parallel hardware, is challenged by flat place-and-route data.
Hierarchical vs. flat data files
A general comparison (Fig. 1) of the GDSII (graphical design system) stream format and MEBES (e-beam writing system) pattern file format provides an understanding of the fundamental structure of IC pattern data and shows where limitations in full-chip OPC application can occur. The GDSII data stream is the IC pattern representation created by typical hierarchical layout tools, and MEBES is the most common format used to drive reticle-writing tools.
 |
Figure 1. Representations of a) the GDSII data stream and b) MEBES pattern data.
The GDSII stream file is a canonical list of cells, and each cell contains two basic groups of information:
native geometry - drawn rectangles and polygons on various layers that describe actual artwork, and
cell pointers - references to other cells in the canonical list, where each pointer represents a placement or "instance" of one cell within another cell. Instances may be individual or arrays.
The GDSII stream format achieves a very compact representation of an IC pattern layout when the native geometry content is small, instance counts are high, and hierarchy is many levels deep, in other words, when there is not a high degree of flat native geometry data in any one cell. However, this file format is very inefficient when it comes to representing native geometry. A single rectangle description occupies 64 bytes in a stream file. Even a modest amount of flat geometric data causes a GDSII stream file to inflate quickly. In addition, with this type of representation only cells can be arrayed; there is no mechanism inside the stream file for arraying native geometry.
MEBES data cells are called stripes, derived from a very rigid tiling scheme in the MEBES pattern file format. The MEBES format carves pattern design space into a regular array of tiles (stripes) with a fixed 32:1 x-y aspect ratio. (By contrast, the GDSII stream file cells may have arbitrary boundaries that abut or overlap, little cells inside big cells, and other arrangements.) Essentially, this striped tiling is a first rigid layer of hierarchy in the MEBES file. A second layer of hierarchy permits arraying of geometric information within any given stripe whenever there are repeated figures. Polygons cannot be represented in MEBES format; instead, polygons are decomposed ("fractured") into simpler rectangles and trapezoids.
With MEBES data, figure arrays or repeating figures are confined to the space of a single stripe or tile. This figure array mechanism can be exploited to recondense repeated structures even after flattening has taken place. So, it is possible to identify regularity in the final pattern data and coalescence that into a one-level hierarchical representation within the stripe. In addition, arrays can often be extracted from even relatively irregular random data. Due to gridding, there is usually some degree of regularity that allows a certain amount of compaction to be achieved, even if the data was not hierarchical to begin with.
The message in this brief analysis of pattern data files is that, although the data starts in a hierarchical form, it must always be transformed into flat, fractured pattern data due to the nature of today`s mask-writing tools. While the computational overhead associated with applying OPC might be less with certain arrangements of hierarchical data, the necessary flattening of pattern data as it progresses into MEBES format dictates that any viable OPC solution must be able to produce results that move efficiently through the flattening process and into MEBES format.
Memory vs. logic pattern data
As mentioned briefly above, there are significant differences between memory hierarchies and those of microprocessors or ASIC pattern data (Fig. 2).
Memory structure is extremely regular and hierarchical with many high-replication-count cell arrays.
Microprocessor designs contain large amounts of flat geometric data generated by automatic place-and-route tools.
 |
Figure 2. a) Memory structure is very regular and hierarchical, while b) microprocessor designs contain large amounts of flat geometric data generated by automatic place-and-route tools.
These hierarchical differences are illustrated in Fig. 2, a graphical representation of the hierarchy of a typical memory vs. a microprocessor or ASIC design - the top node in each tree represents the master structure. Each node below the top represents instances of other cells. The size of the node implies its native geometry payload.
The memory structure shown is very regular with many highly replicated cells. Typical microprocessor or ASIC circuits exhibit one or more structures that resemble memories; these could be RAM caches, ROM, programmable logic arrays, etc. However, a large part of a microprocessor or ASIC design consists of flat place-and-route results, the random logic and control parts of the circuit (represented by the bubble on the right side of Fig. 2b). The flat place-and-route data consists of instances of standard cells (the small nodes hanging from the bubble), and large numbers of wires and vias interconnecting the standard cells.
These flat place-and-route results are not amenable to hierarchical treatment, and any OPC software tool that expects to exploit hierarchy to overcome computational inefficiency is likely to choke.
Examining the spectrum of circuit designs, we see:
Memory designs, with areas dominated by repetitive structures, are amenable to efficient hierarchical representation. Random logic typically occupies <20% of the area. The caveat is that for some memory designs, error correction circuitry, redundant blocks, and random logic increase this percentage as designs grow more complex.
Microprocessor designs are characterized by a 30-50% area devoted to cache and memory structures. Typically, >50% is random logic. While there is some exploitable hierarchy, there is also a large content of flat wire, via, and contact place-and-route data.
ASIC designs typically contain >80% flat, nonhierarchical data. The only exploitable hierarchy involves the chip`s gate mask and the layers below.
Clearly, ASIC designs represent some of the most challenging circuits to treat with OPC. This complexity also foreshadows the increasing demands that will be placed on OPC software tools in the future: Today, OPC is being applied to transistor gate masks - the first point in the conventional semiconductor manufacturing process where optical lithography begins to break down. However, as lithography for contact layers, metal layers, etc., progressively reaches its limits, the need to apply OPC to a wider range of features will grow. As the industry progresses, these issues associated with the complexity of applying OPC to random logic will become even more significant.
Cell context
Although hierarchical OPC calculations may seem desirable, cell context may limit the advantages of hierarchy (Fig. 3).
Adjacent cells may be different in different instances of a given cell. In each case, interface boundaries between the cell geometries vary, necessitating different OPC treatments for each unique context.
Cells often overlap other cells, making the problem of context recognition difficult. This is usually the situation with wiring layers.
 |
Figure 3. Cell placement results in a) different boundary conditions (i.e., different neighboring cells) or b) differences in overlapping cells.
These context situations alone can force a hierarchical OPC tool to reprocess an individual cell hundreds or thousands of times, which is likely to be computationally intractable for simulation-based OPC algorithms.
These issues with cell context drive home the point that OPC software tools which rely on hierarchy as a way to overcome mask computational inefficiency are likely to exhibit huge slowdowns when confronted with ASIC- and microprocessor-style layouts.
A hierarchical simulation-based OPC tool that processes data in stream format and then re-stores data in stream format will actually suffer from data explosion in three ways:
1. As technology moves into deeper wavelength regimes, the computational requirements of simulation increase to deal with the increased complexity of diffraction-limited photolithography.
2. The number of calculations required increases with the increasing number of cell instances.
3. Most cells in a hierarchy will have to be duplicated several times and reprocessed for OPC based on the number of unique cell contexts.
Even if the hierarchical tool is successful at processing and restoring data in the hierarchical format, there is no guarantee that the downstream fracture tool will not exceed its operating limits when fed the increased amount of data.
Operating system limits
Operating system limits are also a concern for OPC application. The typical 32-bit operating system limits are 2-Gbit virtual memory, 2-Gbit single file size, and 2-Gbit file system partition.
Non-OPC IC designs are now beginning to exceed 1 Gbit at certain points in the CAD flow, leaving less than "2? headroom" for handling more complex designs. When OPC is added, the 5? to 10? data complexity increase can exceed the available headroom, rendering the problem intractable with ordinary CAD tools and flows. Keep in mind that Moore`s Law predicts circuits two or four times as complex in the near future.
When the computer industry advanced to 32-bit hardware, the common belief was that this was big enough to represent any application for a long time. Ironically, in the maskmaking world, perhaps the root of computer technology, we are already starting to see applications that bump into the limits of a 32-bit address space.
One recourse with 32-bit hardware is to partition a design - carve it into slices, process one slice at a time, and reassemble slices on the patterning tool. This process, however, is a tedious, error-prone, manual operation that requires careful attention to the boundaries between slices and has the potential of introducing artifacts.
Fortunately, 64-bit operating systems are starting to emerge; these will relax the 2-Gbit limits on virtual memory, file size, and partitions. While this is the ultimate solution, it does present a porting issue for CAD tool suppliers, because many of them have built code that implicitly assumes 32-bit integers and pointers and does not automatically recompile to 64 bit without a programming effort.
Solutions short of 64-bit hardware include extended file systems that ease partition restrictions and file size, freeing at least one bit in the upper bit of an address word, resulting in up to 4 Gbit on 32-bit hardware. Ultimately, however, everyone will want and need a 64-bit operating system to handle really big OPC and fracturing applications.
Data precision tradeoffs
Although the presence of large amounts of flat, random data in microprocessor and ASIC layouts is a serious issue and can fundamentally limit the implementation of some OPC methods, this is not the only data-processing concern associated with full-chip OPC implementation. Precision tradeoffs exist that can severely limit the cost effectiveness of OPC. To appreciate these precision trade-offs, consider that both hierarchical representation (GDSII stream) and flat representation (MEBES pattern files) are integer formats that operate on some arbitrary, user-defined grid. For example, the grid inside a stream file is often 1 nm and a MEBES pattern file grid is typically tied to the mask-writing system`s spot size and raster-writing structure. These grids govern the physical size of stripes stated in pixels.
The consideration is that adjusting the grid of pattern formats is directly related to various tradeoffs; that is, the grid cannot be arbitrarily fine or arbitrarily coarse without incurring problems. For example, the need to make subresolution proximity corrections to a layout invites the use of a smaller grid step than used to draw the original figure. The finer the corrections needed, the finer the enabling grid step. However, decreasing the grid step or address unit involves several hidden costs.
The table illustrates what happens to MEBES file size with decreasing address unit. It grows because more stripes must be described; each stripe has an associated overhead; and capturing figures into 2-D figure arrays is limited to within the confines of a given stripe. In other words, as stripes get smaller, less geometric information is captured so compaction effectiveness is lost.
 |
The resulting relationship between address unit and mask write time is important, because mask write time is usually directly proportional to mask cost. The longer the write time is, the higher the price of the mask (Fig. 4). Statistically, long-writing masks also have a higher probability of error because of system drift problems during writing.
 |
Figure 4. Write time and mask cost increase dramatically as address unit is decreased on raster-based, e-beam mask-writing equipment.
This trade-off between address unit and mask cost is eased somewhat through the application of OPC scattering bars, combined with limited feature biasing at dense feature pitches, as opposed to an OPC scheme based solely on aggressive feature biasing across the entire pitch range. The scattering bar provides two significant benefits: a significantly enhanced depth of focus for sub-wavelength features and the ability to achieve printed feature-width adjustments that are finer than the writing grid [1, 2]. Scattering-bar-based OPC thus provides a process window for the wafer fab.
Conclusion
Viable solutions for OPC must include careful consideration of circuit design, CAD and mask-writing data representations, 32-bit operating system limits, and the limitations of mask-manufacturing equipment (see "Engineering an OPC data solution" on page 96). For a technology which just a few years ago was dismissed as impractical, the implementation of full-chip OPC is now viewed as a competitive advantage in an industry being driven relentlessly to ever deeper sub-wavelength manufacturing processes. In this environment, as volume increases for these chips and the production of full-chip OPC masks becomes mainstream, the hidden barriers and cost tradeoffs are becoming more widely understood, driving the development of better tools and methods.
Engineering an OPC data solution
Our initial OPC goal at MicroUnity addressed processing very large microprocessor and random logic applications (i.e., greater than ten million transistors). We crafted an OPC software tool, MaskRigger, capable of handling very large amounts of flat geometric data (see figure). This OPC technology played an important role in the SEMATECH Delphi Project`s recent achievement of 100-nm features using 248-nm DUV wavelength exposure on a 4? stepper (see "`Manufacturable` 100-nm features from 248-nm lithography," Solid State Technology, July 1998, p. 54).
 |
MicroUnity`s MaskRigger software avoids data explosion problems by first representing the data in extremely efficient scan line vertex format and subsequently adding OPC as the mask-writing file is created.
MaskRigger can read GDSII hierarchical data and flatten it before OPC assist features are added. The tool also accepts CIF hierarchical data and relatively flat MEBES and Hitachi pattern file formats. All of these formats can be incorporated into virtual memory using scan line vertex representation, which provides significant data-handling efficiency. Each geometric rectangle is represented with approximately 3 bytes compared to 64 bytes in stream format.
This OPC software performs data flattening before adding OPC features, thus avoiding a 5? to 10? figure-count burden. While the data is in this memory-efficient pre-OPC stage, many of the operations required during fracture - such as grow, shrink, Boolean layer operations, and arraying operations - are performed without incurring any penalty for OPC. This tool then computes rule-based OPC, tile by tile, as the final pattern file is created. When computing OPC one tile at a time, it considers the contents of the tile together with an appropriate guard band around the periphery of the tile for context. All OPC corrections are computed within the confines of the tile`s context. Finally, once the OPC is calculated for a tile, it identifies naturally occurring repeated arrays within the tile, including arrays of OPC assist features, and coalesces them into compacted MEBES or other pattern file formats.
Using MaskRigger, large microprocessor circuit masks with full-chip OPC are fabricated without suffering the write-time penalty normally associated with aggressive OPC treatments. To further demonstrate the viability of this approach for future generations of design technology, a facsimile 20-million transistor ASIC suitable for 193-nm lithography (i.e., 0.15-?m design rules) was successfully written in less than six hours, and inspected on commercially available equipment.
Acknowledgment
MaskRigger and MaskTools are registered trademarks of MicroUnity.
References
1. J.F. Chen, T. Laidig, K.E. Wampler, R. Caldwell, "Practical Method for Full-Chip Optical Proximity Correction," SPIE Proceedings, Vol. 3051, March 1997.
2. J.F. Chen, T. Laidig, K.E. Wampler, R. Caldwell, "An OPC Technology Roadmap to 0.14-Micron Design Rules," SPIE/BACUS Proceedings, September 1997.
KURT WAMPLER received his BSEE from California State Polytechnic University, Pomona. At MicroUnity he has been the primary author of the company`s MaskTools software and coauthor of several related patents.
ROGER CALDWELL received his BS in chemical engineering from the University of Texas, Austin. He has three US patents and nine patents pending in the areas of lithography, metallization, and process integration. Caldwell is VP of silicon technology at MicroUnity Systems Engineering Inc., 475 Potrero Ave., Sunnyvale, CA 94086-4118; ph 408/734-8100, fax 408/734-8136, e-mail [email protected].