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

Edited by F. Fasching, S. Halama, S. Selberherr - September 1993

The SATURN Technology CAD System

W. Jacobs

SIEMENS AG, Corporate Research and Development,

Otto-Hahn-Ring 6, D-81739 Miinchen, GERMANY

Abstract

This paper describes the SATURN TCAD system developed at SIEMENS. The architecture of the TCAD system and the philosophy behind it is explained and demonstrated by examples. An overview of the available simulation tools is given.

1.Introduction

In microelectronics, a TCAD system is designed to support the design and manufacturing of integrated circuits from a technological and physical point of view. The physicBJ. processes of the different manufacturing steps are simulated with the help of physical models. The geometrical structure and the distribution of dopants within the devices are obtained as result. To investigate the static and dynamic behavior of a device towards different circuit environments and bias conditions, the semiconductor device equations are solved. Thus, the device characteristics are obtained which allow parameters for compact circuit models to be extracted. These parameters serve as technology-specific input for circuit simulation and allow circuits to be designed at a very early stage without requiring measured data to exist.

The SATURN TCAD environment is used in process and device development. The design process is usually performed in a closed loop in which the device simulation serves to characterize the process flow and the layout geometry. The process flow and the geometry are repeatedly altered till the device reaches its optimum with respect to specified objectives. In addition, this optimum should be as insensitive as possible to process and layout variations.

In connection with the MEGA project the SATURN project was started in 1986. It aimed at developing a system that fulfilled the requirements mentioned above within a foreseeable period of time. No such system was available either commercially or from universities at that time. It was to be used for technological applications as well as in research and development. New programs were to be integrated in the whole system quickly in order to investigate new model approaches.

At the time, the hardware platform was determined by mainframes running the proprietary SIEMENS operating system BS2000. To automate simulation tasks, all programs were to be controlled by application-specific procedures. In order to facilitate migration of the SATURN system to UNIX workstations, which were steadily increasing in performance, a command-line interpreter [19] was developed in BS2000 the command structure and run control of which were modeled on the UNIX C shell. A menu-driven user interface was neither envisaged nor wanted. After migration to UNIX workstations (WS30, HP9000), all SATURN functions were transformed into stand-alone programs that run under direct control of the Berkley C shell.

In fact, a number of SATURN-integrated simulators had already existed as standalone programs, which had been run in individual environments. These were to remain stand-alone program modules and to be developed as such for obvious reasons. The SATURN system was to adapt to the simulators, not vice versa. For the purpose of integrating the simulators in the whole system, clearly defined interfaces for attachment to the run control (shell) and the SATURN file system were introduced. On the one hand, these interfaces helped to ensure data consistency, on the other, they facilitated migration between different hardware and software environments. Apart from that, the individual simulation programs are included in the traditional way: they obtain information from input or control files and write the results into corresponding output files.

The SATURN TCAD system was developed to perform so-called simulation experiments rather easily. An experiment is controlled by design parameters. The result of an experiment is described by response parameters, which are automatically related to the corresponding design parameters. All parameters are available in a database as well as on the shell level.

The choice of design parameters is free and depends on the application. If, for example, the process simulation is to be calibrated with measured profiles, the parameters chosen correspond to the model parameters of the underlying physical process. To optimize the process flow and the layout of the device, process and layout-specific quantities, such as furnace temperature and spacer width, are chosen as parameters.

Section 2 summarizes the simulation programs which are the building blocks of the TCAD system. Special emphasis is laid on those programs developed or further developed at SIEMENS.

Section 3 explains the system architecture of SATURN. The applicationand simulatorindependent approach to keep track of simulation variants across an arbitrary program flow as well as the method of tool integration are described more detailed.

Section 4 gives two application examples to illustrate the main features of SATURN.

2. Building Blocks

Fig. 1 gives a schematic overview of the SATURN system and its installed programs, which make up the building blocks. Process and device simulation levels are completely integrated. The circuit simulator TITAN [9] is connected via the MOS parameter extractor JANUS. The postprocessor SATGRAF is used to create various graphical representations of virtually all interchange data like distribution of dopants, potential, densities or currents available throughout the system.

Depending on the problems being investigated, three different design threads are available.

The first one handles all cases, where planar structures are sufficient. It is used for characterizing and optimizing active MOS transistors. It consists of the process simulators MIMAS I and POSEIDON, the "profile manager" PHOEBE, which composes a complete MOSFET doping structure from source/drain and channel profiles, and the device simulator MINIMOS 4.

The second design thread is used for general devices and non-planar MOSFET structures. It comprises the general purpose process simulator MIMAS II [6], developed at SIEMENS, and the device simulation programs MINIMOS 5 and GALENE. SATURN also provides interfaces to accept data from other process simulators (e.g. SUPREM IV).

MIMASII

Figure 1: Building Blocks of the SATURN TCAD system

The third design thread is mainly used for bipolar process and device development and contains all programs for characterizing and optimizing one-dimensional doping profiles. The characterization is performed by the mixed-mode simulator MEDUSA [17]. Several one-dimensional profiles can be connected by suitable transportances to take into account the lateral voltage drop due to majority carrier flow.

2.1POSEIDON

POSEIDON is a process simulator for one-dimensional problems. It is compatible to SUPREM IlIon the input deck level, but comprises advanced models for oxidation, diffusion als well as improved algorithms (eg adaptive mesh). At the same time it is capable of simulating complete process flows. An overview of these models is given in this section.

Three hierarchical levels of equations for describing dopant diffusion can be selected from the input deck level. The lowest level uses effective dopant diffusivities in equivalence to the models used in the well-known SUPREM III process simulator [1]. The second level includes the simulation of point defect (silicon interstitial and vacancies) distributions, where dopant diffusivity is calculated from the local point defect supersaturation (Hu's model [2]). On the most complex level, the coupling between point defect and dopant diffusion is included, taking into account the pairing between interstitials or vacancies and the dopant species (pair diffusion model [3]).

The initial distribution for point defects can be chosen from being the distribution of the previous processing step, the equilibrium concentration or an externally generated profile. The point defect distribution resulting from damage created during dopant implantation can be calculated from analytical expressions which have been deduced from Monte Carlo calculations [4].

The boundary conditions for point defects depend on the process conditions. When the silicon surface is oxidized, interstitials are injected into the silicon which gives rise to the well-known Oxidation Enhanced Diffusion (OED) effect for B, P and As dopants. This effect is modelled using an interstitial generation term which depends on the oxide growth rate.

For dopants, the crucial boundary effect is segregation at interfaces. In addition to the standard segregation model, which specifies the ratio of the dopant concentration on both sides of an interface, a new segregation model is implemented. This model is based on the assumption that there exists a monolayer of trapping sites for dopants at the interface which is filled and emptied by the dopant flux from either side of the interface. While at equilibrium the results are in agreement with the standard model mentioned above, this model predicts the existence of time constants for reaching equilibrium that may be longer than some of the processing times in a modern sub- p,m technology. Also, this model satisfactorily explains the pile-up of phosphorus at the interface, as has been verified experimentally [5].

2.2MIMAS

MIMAS I and MIMAS II are two-dimensional process simulators. With physical models at a level comparable to SUPREM III, MIMAS I is designed to achieve high computational efficiency for planar structures, featuring a fully adaptive finite-difference grid and fast numerical solving schemes, suited also for vector processors. This program is used for the calculation of MOSFET structures in cases where non-planarity can be neglected (e.g. for the calculation of basic device parameters like Vth or 11ft).

MIMAS II is a general purpose non-planar process simulator. The finite element method is used for describing the mechanical properties and oxidant diffusion during oxidation processes as well as the point defect and dopant diffusion during furnace processes. New approaches are used to overcome the problems which come along with the moving boundary between silicon and silicondioxide [7, 8].

To describe dopant diffusion, most of the models described for POSEIDON are available. The fully coupled pair diffusion model is being implemented. Deposition and

etch processes are simulated by a string algorithm similar to the SAMPLE program

[16].

2.3MINIMOS

For MOSFET structures, the MINIMOS program [13] is the most efficient and proven device simulator. It can be used for planar and non-planar structures in two or three dimensions (including some of the MOSFET-like isolation devices). It has been demonstrated that the enhanced drift-diffusion description of carrier transport in MINIMOS is sufficient to calculate the I-V characteristics of MOSFETs with channel length down to O.Ip,m [14]. MINIMOS is being enhanced by models for the injection of carriers into the gate oxide and trapping of these carriers in the oxide [15]. This

us to calculate self-consistently the degradation of MOSFETs due to hot

2.4GALENE

Special device structures are simulated with the general purpose simulator GALENE [18]. Arbitrarily shaped devices can be investigated. A band-to-band tunneling model

[11] is implemented which facilitates the simulation of degradation in bipolar devices [12]. Since the solution algorithm of GALENE can be customized from the input deck level, devices like SOl structures that normally face severe convergence problems with other simulators can be tackled.

3.System Architecture

3.1Overview

Figure 2 shows the SATURN system architecture. The system consists of tool layer, data layer and framework layer. These layers are available for all applications.

The hierarchical database contains all design and response parameters of a SATURN application. Its structure is an exact copy of the program flow of a design thread across several program levels as well as all stored variants. The application thread is not restricted to a sequence of program calls, but can be branched at almost any point. The system assigns a table (relation) to each program step and creates a table entry for each calculated variant. Each program step is supplied with its own, userdefined control file. In addition to the usual program-specific directives, the control file contains the input parameters serving to characterize the simulation variants. The corresponding table contains the parameter values of all simulation variants, which differ in at least one parameter value. Characteristic results of a simulation process are also available as response parameters in table form. They can be easily related to design parameters either in table-oriented or graphical form.

All data exchanged between the individual simulation programs are stored in UNIX files in a compact form. Due to strict naming conventions, each file within the system corresponds unambigiously to one entry in the hierarchical database.

All simulators and utilities operating on interchange files are connected to the system only via UNIX files to make them largely independent of system-specific interface requirements and to integrate simulators without having to change the code.

The framework level performs all operations in connection with the generation of input files and the extraction of output parameters. In addition, it allows checking the consistency between input and output tables across all simulation levels. Each access to hierarchically connected tables checks and inforces the consistency of the database. All framework functions are stand-alone programs. They can be called interactively as well as from within a shell script and are thus available to all applications.

As mentioned above, SATURN was developed with the intention of allowing simulation experiments to be performed. They can be related directly to real experiments and measurements. For instance, the splitting of a lot at a specific point within a process flow corresponds to a branching point in the simulation design thread. From here, two or more simulation processes must be performed in parallel. If splittings are performed at several points, there are possibly a lot of parallel simulation branches to be calculated. The result is a tree structure with its root at the top (fig. 3). This tree structure can be mapped directly to a table where the split parameters appear on the left side and the finally determined characteristic response quantities on the right (tab. 1).

The idea behind the concept followed by SATURN is to store such a variant tree consistently in order to be capable of extracting the dependence of the response parameters on the "experiment" parameters at any time and even across several simulation levels. The results on one simulation level can be compared with each other without any restrictions. Design and response parameters are available in the

Simulation Variants

Figure 3: Multi-Level Variant Tree

Table 1: Table Representation of a Multi Level Variant Tree

form of one single table which can be further processed by SATURN utilities and external programs.

3.2User Interface

The UNIX shell as well as the SATURN framework commands make up the user interface of the SATURN system. The shell programming language is used for supervising and controlling simulation programs as well as for automating simulation tasks. The values of input parameters of a design thread are available as shell variables and can be easily changed, which allows the whole design thread being rerun with different input parameters. The response parameters are extracted and are also made available on the shell level. Therefore simple control tasks like search of a minimum or maximum of a response value are easily handled by using standard UNIX tools like awk.

More complicated applications, like multi-dimensional optimization, require dedicated programs, which are also activated on the shell level. They use the shell as "simulation engine" to obtain the results belonging to a specific set of parameters. In addition, they can make use of the internal database to handle several runs of a design thread.

The commands of the SATURN framework are listed in table 2.

3.3Input File Generation

An important system feature of the framework is the generation of the simulator's input file, which contains all neccessary information for one program or simulation step within a given design thread.

Input file generation is independent of the attached simulator. SATURN requires only that one step is supplied with one input file and does not care about what this file is used for.

The input file is derived from a "prototype" or template file, which has to be created by the user. Usually, libraries of prototype files exist for each process or product which the user can choose from. A prototype file may contain all kinds of application-specific variables and makes use of macro facilities, which allow parts of the input file to be included or excluded depending on design variables. Local variables can be derived from design parameters by arithmetic expressions [20].

A variable part within a prototype file is marked in the following way:

diffusion temp=Y.{templ-900:d5}

A variable is defined by its name, a default value as well as the format of the character representation (d. below).

The values of variables are set on the shell level as follows:

set tempi = 920

The prototye file needs only to be edited if new variables are introduced. The SATURN command xsim which activates the individual simulators evaluates the variables and replaces them with their corresponding values. If a variable value is not defined

as a shell variable, the default value is used. Variables can be replaced by numerical values, by character strings or by names of files that contain interchange data of previous simulation steps.

Previously constant parts of a control file can be replaced by new variables at any time, and thus be changed from outside. The previous constant value must be specified as default value of the new variable to update the existing runtable entries.

before: implant boron energy=25

after: implant boron energy=y.{energy-25:d3}

Variants which were previously calculated with an energy of 25 keV are extended by a new variable with a default value of "25". The xsim command recognizes, whether the specified prototype file is modified, and internally calls the rtmod command to update the runtable.

The control program converts the value of each variable with a user-defined format into an ASCII character string. This is required, for example, to recognise 25.00 and 2. 5e+l as identical. By specifying the field length, the user decides how many significant digits are stored.

The variable configuration is a character string consisting of the character representations of all parameters. To determine the simulation variant, the variable configuration is compared with all previous configurations (variants) stored in the runtable. If a configuration has already been stored, its variant number is taken over unless the user explicitly specifies another number. The built-in make mechanism checks whether the corresponding result file is newer than all input interchange files of this program step. If this is the case, the result of this simulation step is regarded as consistent and the simulation program need not be called any more. The existing result is used as input for the next simulation steps.

If one input file is newer than the result file, xsim takes the prototype file and replaces all its variables by their current values, creates the control file and, finally, starts the simulation program.

3.4Connecting Runtables Across a Design Thread

The hierarchical database allows the parameter dependence8 to be traced across all simulation steps required. This is achieved by a special type of link variable, which has to be defined inside of a prototype file exactly in the same way as the design parameters described in the previous section. The linkage, once established, is static and cannot be changed during the design process.

The name of this reference variable reflects the name of the previous simulation step, which supplies an interchange file:

MOS CHANNEL=y'{chan_pos2:Rl0}

Its value is simply the file name, which consists of the variant number and the file type:

set chan_pos2 = n005.pa

The example given above references the fifth simulation variant of the prototype file chan for simulator POSEIDON (pos2). The file type of the interchange file is marked by file extension pa. This kind of shell variables are automatically created when a simulation step is finished. Since the next simulation step uses the same naming convention for accessing its input files, the file names of interchange data are passed between program steps automatically.

3.5Response Parameter Extraction

Response parameters like device characteristics are easily extracted from ASCII files using the rtload command. The extraction process may be applied to a set of simulation variants. Therefore, the results of several simulation variants of a design thread are collected in one single table. In addition, other quantities can be derived directly from the extracted variables.

Keeping the output table separate from the corresponding input table enables rtload to extract more than one block of response data per simulation variant. This is important for device characteristics data, because most device simulators work more efficiently when several bias points are calculated in a sequence.

The output table is linked with all input tables via the reference variables described above. Thus, it contains the complete amount of information required by an application.

The response parameters are extracted with the help of awk procedures. In cases where the number of response parameters is fixed, these procedures can be created by a program generator from marked ASCII files. This allows extraction of quantities which are not taken into account in the predefined procedures.

3.6Interchange Data

Most of the integration effort was spent on allowing the simulation program to access interchange data supplied and expected by SATURN. Due to the development in this field, a clear standard was not available at that time (1987). Therefore a common format for all interchange data within the process and device simulation level of the planar design thread had to be introduced using a reasonable approach.

An interchange data file contains a sequence of several blocks, each of which consists of a key and a data part. The key part uniquely determines the type of the data object that follows. An application program is not forced to read the file sequentially but can read a specific block by specifying the corresponding keys. This behaviour allows new blocks to be added to a file without changing programs that do not expect the new data block. In addition, compatibility to existing programs as well as program maintenance are improved.

This common format enables the graphical postprocessor to access all available distribution data in a fairly flexible way.

However, this format is limited to finite-difference based distributions. No effort was spent to extend it to finite-element data structures, required by non-planar process simulation programs. Instead specialized conversion programs are provided for interfacing them to MINIMOS and GALENE.

3.7Integration of Simulation Programs

As can be seen from fig. 2, simulation programs are coupled to the SATURN framework by UNIX files only. They read a single input or control file and create one or more output files. One of them contains interchange data processed by the next step of a design thread.

The framework command xsim forms the interface between the application level (shell) and a specific simulator. In addition to creating the simulator's input file, described above, xsim starts the simulation step. In this context, a simulation step can be made of either a single executable program or a shell script, which in turn