2.2 TCAD Users and Tasks

Data occurring in a TCAD system relate on one hand to the data expected and produced by the individual tools integrated in the TCAD system, and on the other hand to the data used by the TCAD system itself for generic services (like, e.g., visualization) and for controlling and ensuring global compatibility of the tools themselves. While for the former it is sufficient for their data to characterize a local problem (e.g. a single device with single bias conditions), the latter has to have a global view of the problem currently investigated.

The term problem needs a more specific investigation. The problems which should be solved (i.e. the tasks performed) by TCAD systems are widespread and not always clearly defined. They depend highly on the person using the TCAD system. The users of a TCAD system fall into one or more of the following categories (see also [Hala93a]):

Casual users
They are mostly layout engineers who need TCAD systems capability only on occasion, when they have to investigate a special design problem, for example when too much signal interference through electromagnetic coupling occurs between adjacent parallel lines. Also manufacturing staff engineers trying to track down process recipe bugs fall into this category.

Process/device engineers
These are typical ``power users'' of the TCAD system who need its full capability. However, they do not want to bother with the system's internals, and usually don't do customization. They rely on the functionality provided by the system ``as is''.

TCAD support group members
They prepare and customize a given TCAD system for use by the process/device engineers. They have to have good knowledge of the TCAD system's internals and usually write extension language programs to adopt the system's capabilities to the specific needs. It is notable that not every institution can afford a dedicated TCAD support group.

TCAD system developers
They are programmers developing and implementing whole new concepts and components of the TCAD system.

   
Process sequence run
This task is a precondition to all other higher-level tasks. It simply means running a complete process flow description (PFD) followed by a device analysis of the resulting structure. The corresponding requirements on the TCAD system range from supervising simulator runs to providing consistent simulator input and extraction of all respective output quantities. This, however, is by far nontrivial, considering the different structure, concepts, implementation, input/output formats, and capabilities of current state-of-the-art process and device simulators.

Device characterization
Given a premanufactured virtual device (i.e. a device geometry and associated material segments and doping profiles), we want to know the electrical behavior of the device. Various output quantities are calculated with many device simulator runs depending on several input quantities, thus creating a response surface (the device ``responds'' to a certain input stimulus with the output (hyper)surface). Response surface modeling (RSM) tries to calculate the output quantities by interpolating on the set of data points collected through various simulator runs, thus effectively providing the user with a comparatively exact answer without having to run the simulator, but performing just a numerically much less intensive point cloud interpolation. This is a promising technique for all kinds of characterization purposes and closely relates to the Design of Experiments task (see below).

Sensitivity analysis
A very important question in semiconductor manufacturing is ``how robust is a given design against variation of manufacturing parameters?'' TCAD systems can give an answer to this important question by providing a so-called sensitivity analysis. This means that the relative change of output quantities (i.e. threshold voltage of a MOS transistor) is observed while varying an input parameter (i.e. implant dose or mask edges). This change is an indication of how sensitive the design is against manufacturing variations of this input parameter, giving important hints to the TCAD engineer where to improve his design.

Optimization
This task gives design engineers the possibility to automatically fulfill design goals without violating the given design constraints. This is achieved through an optimizer supported by or built into the TCAD system. The optimizer is given one (one-dimensional optimizer) or many (multidimensional optimizer) input parameters including their respective variation ranges (parameter constraints). The user has to provide an optimization goal expressed as a function, for which the optimizer searches a global optimum in the hyperplane set up by this function dependent on its input parameters. The optimizer runs the given simulation sequence with the input parameters, evaluates the optimization goal function afterwards, varies the input parameters according to its optimization strategy, and runs the sequence again until the optimization goal is met.

Design of Experiments (DoE)
Although DoE relates to a much broader area of application [Boni94][Lore91], it is mostly used for the RSM technique in TCAD systems. The goal of an RSM model is to characterize its output quantity as accurately as possible with as little input samples as needed for that accuracy. This is equal to the goal of a minimal number of simulator runs and hence minimal time to compute the desired RSM model. The DoE task is now to compute this minimal set of input parameters to achieve this desirable property of the resulting RSM model. Since the output quantity is not known in advance, this is not a simple task.

All these tasks require data of different kind and format, and the data level has to support management of this data inside the TCAD framework. In the following we will roughly distinguish between the data required and handled by an individual tool integrated in the framework, and the data used by the framework itself to manage higher-level TCAD tasks.