1. Introduction

Consider any modern gadget of our daily life, chances are very high that this device is controlled by one or more integrated circuit components. Transistors, the basic elements of integrated circuits, are omnipresent in our lives. As microelectronics is boosted by miniaturization, ever new applications emerge or become cheaper respectively. Until recently cellular phones were an expensive rarity and big in size. Meanwhile they have become main-stream products, size and weight have been reduced to an absolute minimum, and the battery lasts about a week. As a consequence of decreasing price and size a frantic urge to possess handsets directly lead to a mobile hype. In European countries a "mobile penetration" of over $60\%$ is more the rule than the exception [1]. Other applications like portable digital assistants (PDAs) already reach the power and memory capacity as was usual to have in desktop computers not far in the past.

The ever decreasing size of transistors brings up new physical effects of quantitative relevance in short time periods. TCAD simulation programs for simulating the fabrication process and the electrical behavior of transistors are well accepted in the semiconductor industry. They present an invaluable help in improving existing technologies and can drastically reduce development time for new emerging technologies and downscales. This imposes to the tool developer the ability to quickly react to changes discovered by engineers and scientists. Ideally, the engineer is not bothered with simulator details like parameter calibration or implementation of a certain physical model. In practice, however, the software developer desperately needs the feedback of the engineers to successfully improve her products.

As the computing power of workstations and servers increases, the demand to simulate complex semiconductor fabrication processes in three spatial dimensions can be satisfied. However, it is a hard task to extend an existing simulator that was not originally designed to work in all three spatial dimensions. Not only the physical models of the simulator have to be extended, also the data model must be capable of supporting and storing three-dimensional data before, during, and after a simulation. It is very troublesome if the supporting two-dimensional data model is tightly integrated with the simulator that is to be extended, because then data types and function calls need to be replaced (to support three spatial dimensions) throughout the whole program.

A TCAD software suite consists of several individual and often independent parts, sometimes this is not transparent to the user, as those programs are invoked from within a single command or program -- the framework. This composition of several components partly results from the different physical problems that are solved and partly from historical reasons. Obviously complex software programs like TCAD simulators cannot be abandoned or re-developed without investing significant person-power (and money). It has always been the endeavor of software industry to re-use as much of existing software as possible. Several paradigms supporting this strategy have emerged over the past decades [2]. Without a claim for completeness, they reach from the classical procedural programming paradigm:

over modular programming:

to the well adopted object-oriented programming paradigm that is widely used in most of the presently developed software packages:

In many TCAD software suites available today, a mixture of the above paradigms is present. This makes it inherently difficult (and expensive) to keep pace with the general development. Newer TCAD software suites are usually implemented according to newer paradigms. However, this software makes use of well established components like, e.g. linear algebra packages. Many of these components were developed according to the older, procedural programming, paradigm. As it is not desirable to re-implement all the existing code a mixture of programming paradigms occurs.

The coupling of the individual software parts, the so-called integration into a TCAD framework is an often underestimated, albeit complex endeavor. To execute a given process simulation flow the engineer should be able to choose among all tools available on the market and couple them as desired. In practice, however, the necessary integration is at best possible among the tools of one vendor. Due to a lacking standardization it is not possible to use parts of one suite within another. Thus, for a process flow simulation the engineer is usually restricted to using the tool set of one vendor.

Subsections

• 1.1 Existing Data Models
  • 1.1.1 VISTA
    • 1.1.1.1 PAL
    • 1.1.1.2 GRS
    • 1.1.1.3 G2S
    • 1.1.1.4 G3S
    • 1.1.1.5 GAS
    • 1.1.1.6 MAT
    • 1.1.1.7 CLS
  • 1.1.2 DF-ISE
  • 1.1.3 TIF
  • 1.1.4 Silvaco
  • 1.1.5 SWR -- Semiconductor Wafer Representation
  
  
• 1.2 Outline of this Thesis

2003-03-27