Книги2 / 1993 P._Lloyd,__C._C._McAndrew,__M._J._McLennan,__S._N

analysis tools may be used. The need to integrate a spectrum of models and tools demands a common semiconductor wafer representation (SWR) to store the wafer state and related simulation and analysis results. The wafer state includes the geometry, fields, and attributes of the wafer during simulation. Fields are a range on a domain, such as the doping concentration, electric field, electric current, or stress within a geometrical region. Attributes are name-value pairs attached to geometry or field objects. Such a central representation eliminates the need for many different data translation programs to communicate among the large number of tools. In addition, a central representation can provide services to greatly simplify the development of new tools. Acceleration of tool development is essential if TCAD is to closely track the rapidly changing manufacturing technology. We have developed the Chip Database (CDB) as the wafer representation that forms the heart of an integrated TCAD system, providing services for both tool integration and development [36]. PREDITOR and pdFab are both examples of such systems.

The need for a common SWR has been recognized for some time. The FABRICS statistical process/device simulator [19][20][25][24] was one of the first TCAD systems to integrate multiple simulation models, and hence one of the first to have a common representation. The Process Engineer's Workbench (PEW) [34][33] provided an interactive environment for quasi-three-dimensional process/device simulation using the FABRICS models, and was one of the first systems to use a centralized wafer state with a strong link to the mask artwork. Other simulation frameworks also included some form of wafer representation [2](21][37][38][32][17][16][31]. These systems had drawbacks, primarily in being specialized to one type of simulation model. Except for frameworks targeted at lithography modeling, most of these systems did not have any link to the mask artwork. Recently the need to link the wafer representation to the mask artwork has become more widely recognized [35][12].

In order to make it easier to combine the results of independently-developed simulation models, and to avoid reinvention, attempts have been made to develop an SWR standard. Initial efforts focused on an interchange language [6][10] and later on database servers [40][39][4][41][8]. An effort is currently underway to develop a standard SWR architecture and programming interface [1].

The relationship between a wafer state and its representation as CDB objects is shown in Figure 1. The surface of the wafer is partitioned into rectangular or trapezoidal regions, based on the needs of the simulation models. In most of the work described here, the partitioning is done using the mask artwork. Associated with each region is a layer stack, which describes the sequence of layers in the region. Associated with each layer within the stack is a list of attributes, or name-value pairs. In CDB fields are represented as attributes. Attributes can also be associated with regions or with the entire database.

The organization of CDB is shown in Figure 2. CDB is broken into the CDB database, CDB extensions, STEPS modules, and user-defined extensions. The programming interfaces of all of these modules are visible to client models and tasks. The philosophy of the CDB architecture is to provide a set of tools for building general-purpose or specialized wafer representations, rather than a single general-purpose representation. This permits the construction of fast but non-general implementations for specific needs, as well as general implementations.

The CDB module provides the basic data structures and methods for representing and accessing simple geometry and attJibutes, and perfOiming simple data extraction func-

tions. The CDB extensions include new abstract data types useful for process and device simulations, including fields. The STEPS module is a CDB extension that provides abstract data types and methods for creating, editing, and executing sequences of simulation steps, which include process or device simulation steps, or data extraction steps. In effect, simulation steps encapsulate all simulation and analysis tools. The result is that CDB also serves the functions of semiconductor process representation (SPR) [22] and task manager [3] . Rather than being a passive database accessed by the client tools, CDB performs the tool invocation.

FIGURE 1. CDn rep"esentation of wafer state

FIGURE 2. CDn organization

2.1Geometry

CDB geometry is defined by the composition of the layer stacks, and the layers within the stacks. The surface representation of each layer is defined using a layer model attlibute. Examples of layer models include flat, piecewise linear, and triangular facets. Since the layer model is attached to layers within stacks, it is possible to use different surface representations in different sections of the wafer. This is pUiticularly convenient if different process simulation models are used in different regions. Layers can consist of any material, including air, which permits the representation of nonconvex surfaces.

2.2Fields

CDB provides native field representations, such as analytical functions, and a variety of meshes. In addition, CDB provides a powelful mechanism, the virtual grid, which provides the ability to mix representations and dimensions. The virtual grid is an abstract data type for two-dimensional fields. These fields can be either the results of a full 2-D solution, or a set of I-D fields interpolated into 2-D. The I-D fields can be either analytical functions or meshes. A typical use of the viItual grid is to generate a 2-D doping field from a series of I-D results, and then use the 2-D result as input to a 2-D device simulator. The advantages of this interpolation approach are that it is much faster than a full 2-D field computation, and it is possible to consistently mix analytical and numerical results, depending on the solution accuracy needed in different locations of the field.

2.3Attributes

Each CDB database, region (layer stack) and layer can have a list of attributes associated with it. Attributes attached to the entire database are termed global attributes, while attributes attached to regions and layers are termed local attributes. CDB does not provide any predefined attributes. For each attlibute type, the CDB user provides an attribute type model with functions to interpret the value field. Each type must also include a set of standard functions that are used by CDB to create, and copy attribute information as well as to save and restore it. Layer models and fields are examples of attributes. Fields are normally associated with an entire CDB (e.g. a mesh with the substrate doping profiles), or with a region (e.g. the doping profile in the region). However fields can also be associated with a layer, such as the current flow or doping profile in a conducting layer. Other examples of local attributes are material type or device electrode. Examples of global attributes include the process flow and mask artwork used to create the database. A given attribute can be shared among several objects. For example, several layer stacks may share the same mesh that describes the doping profile across multiple regions. The general-purpose attribute mechanism is the key to CDB extensibility.

2.4STEPS Module

The STEPS module provides an abstract data type for simulation steps. A simulation step is a parameterized simulation routine such as a process simulation, device simulation, or data extraction step. Device simulation and data extraction steps are treated as equivalent to process simulation steps so that they can be inselted into the process recipe to perform analysis in a manner equivalent to taking in-line measurements in the real process. The STEPS module provides facilities for creating and editing simulation steps, assembling them into process recipes, and editing the recipes. These recipes can then be executed to modify the database or extract infOlmation from it.

New simulation steps are made known to CDB by writing step models. The step model is a data type which contains infOimation about step parameters such as parameter names, types, units, and default parameter values, as well as a simulation routine to call with the parameter values when the step is executed. Functions are also provided to execute an entire sequence of steps.

Step models make it easy to provide a unifOim interface for different simulation models operating at the same level of abstraction. For example, at the wafer environment level of abstraction, the essential parameters of an ion implantation are dose, energy, and species. A nearly-identical step model could be used to encapsulate a one-dimensional ion implantation step implemented using several different solution methods. The step model could add an additional layer of abstraction by implementing a generic ion implant step, and adding the implant simulation model as a parameter.

Simulation steps are the means by which physical models or external simulation tools transform the CDB state. Models encapsulated in a step can be viewed as CDB extensions, rather than CDB clients. The STEPS module also provide a flexible means for using CDB in applications outside the traditional TCAD domain. For example, in support of a functional yield simulator, a 3-D circuit extraction step and a Monte Carlo defect generation and fault analysis step have been developed.

2.5Representation Type Conversions

CDB does not provide an underlying universal representation for geometry and fields. Instead, a lazy evaluation approach is used to perform type conversion as needed by the simulation models. Each simulation step must check the representation type, and call the appropriate conversion routine if necessaty. It is our experience that clusters of simulation models use the same representation, so the cost of conversion is relatively low. Type conversions are also used to interface to external simulator file formats. For example, in order to plot a I-D doping profile, it would be converted to the "data type" used by the graphing program.

2.6Global Attributes

Attributes associated with the entire wafer are telmed global attributes. In addition to storing the process recipe, they act as a database for storing simulation results closely associated with the wafer state. Global attributes are used to store the results of task-level simulations. Examples of task~level simulation include Monte Carlo process and device simulations, factOlial designs, sensitivity analysis and latin hypercubes. In task simulation, the process and device simulation is repeated many times with the inputs vruying slightly from one run to the next. For a simple layout containing two to four transistors, the three dimensional CDB representation of the devices can consume O.5-2MB of data. Storing all the data generated during a IOO-sample Monte Carlo run would require 50-200MB. As with manufactming data, it is necessaty to discard some information. Unlike manufacturing data, where often only summary statistics are available, CDB uses the global attributes to store all process control settings, as well as all CIM database level attributes (Le., in-line measurements, I-VS., SPICE models, and simulated electrical tests) for each run. Since the process control settings for each run are stored, it is possible to regenerate the detailed three-dimensional representation for any of the individual runs. Just as with all other CDB data types, each global attribute has translators associated with it. Hence, Monte Carlo simulation results "know" how to be translated into correlation plots, while sensitivity runs

know how to be translated into bar charts. By using the global attributes, CDB can summarize data while still be able to regenerate the details. The type conversion paradigm used throughout CDB makes it possible to associate analysis functions with only certain classes of data types, preventing incorrect analysis of results.

2.7Relationship Between CDB and the SWR and SPR Standards

CDB and the SWR standard are both designed to represent the wafer state during process and device simulation, and to provide functions to make it easier to develop new simulation models. There are several significant differences between CDB and SWR:

1.Scope of area represented. CDB can represent a few to hundreds of transistors. This is necessary if one what to predict spatial variations across a chip, or yield/defect simulation. To accomplish this, CDB uses the layout to split the chip into regions which can be (but are not necessarily) represented with I-D models. The SWR is intended primarily for detailed process and device simulation of a few transistors.

2.Geometry representation. CDB uses the layer model to represent material boundal1es while SWR uses a cell complex representation. While both are equivalent, the former is more appropriate for the algorithms used in lithography simulation (since a pointer to a string function is easily accommodated), and the latter lends it self to 2-D thermal process simulation. Since CDB uses pointers to functions for boundaries, it can easily be modified to point to an SWR geometry server.

3.Field representation. SWR fields are primarily designed to represent meshes. CDB is designed to handle a spectrum of representations from l-D, mix analyticaVnumerical, and 2-D meshes. This is appropriate given the need to incorporate a spectrum of simulators.

In summary, from a representational standpoint, CDB and SWR should be viewed as complementary. The largest difference between the two is not the representation but how they are used. The SWR standard is envisioned as a slave interface, with the client tools driving the SWR. In contrast, CDB performs the tool invocation, sending information to and from the client tools. The advantage of the CDB approach is incorporation of off-the-shelf tools is much easier since the tools do not even need to understand the details of CDB. The disadvantage of CDB is that since its built-in layer models and field representations are limited, they must be extended to incorporate each new class of tools. For example, once an interface to a particular l-D process simulator was built, all l-D process tools could be accommodated. The same is true for 2-D process or 2-D device simulators. If a new 2-D lithography tool were added, CDB would need to have new layer models since the basic layer models would not be sufficient. However, since results are always stored in CDB once a tool is hooked into CDB, all other client tools can make use of the results.

We would like to eventually provide a CDB programming interface for the SWR standard. This would pennit tools that comply with the standard to be used without modification. We can build this interface with suitable CDB extensions.

As is the case with the SWR standard, the representation of process recipes in CDB is very similar to the objects and programming interface proposed for the SPR standard. The primary differences are: the SPR standard includes more levels of model and recipe abstraction than are currently available in CDB; the standard explicitly supports dynamic type creation while CDB does not; and the standard provides a passive simulator-driven inter-