9.1 Introduction and Overview

TCAD tools like SIESTA [139,94] have been successfully used for optimizing semiconductor devices [93] and for inverse modeling [140]. Although SIESTA proved to be a valuable tool and several interesting results [132,133] were achieved using it, it did not, at that time, offer any global optimizer, but two gradient based optimizers [92]. The most recent advances include new, global optimizers, combine these two approaches to optimization, and improve on the robustness, flexibility, and extensibility.

Over the years, it has been recognized that a successful TCAD optimization framework has to meet the following criteria.

1. The ability to execute simulation tools on a number of computers in the local network, and to schedule the execution of these simulation tools in reaction to changes in this network. For example, in a heterogeneous network that is not solely dedicated to executing simulation tools, the question how the tasks have to be scheduled so that the overall execution time is minimized is not trivial. Furthermore, software and hardware failures have to be taken into account.
2. Stability. This property is crucial for a program that usually runs for several days and has to deal with all kinds of software failure.
3. Extensibility. A TCAD framework has to deal with various programs [27], various data formats [17,18,15] and combinations thereof. Evaluating the goal function (i.e., the function to be optimized) often entails several calls to simulation tools. Because of the abundance of possible goal functions, a framework has to provide a flexible extension language which enables the user to succinctly describe the desired goal function.
4. Specialized Optimizers. The evaluation of the goal function is usually very expensive: times range from about a minute to one hour or more for process simulations on current hardware. Strategies for finding global extrema of computationally very expensive functions are needed. The respective advantages and disadvantages of local optimizers and evolutionary computation are discussed in Section 8.6.
5. Finding a suitable starting value is often the most difficult and time consuming task when using a local optimizer. Hence global optimizers which do not need a starting value sufficiently near to the global extremum are called for.

It should be noted that the goal function of an optimization in TCAD analysis may not even be a function in the mathematical sense. Simulation tools like MINIMOS [115,123,16] provide modes of operation which are not deterministic, i.e., the same input may lead to slightly different results which, however, are bound by some accuracy criterion [16]. In the case of MINIMOS this is due to dynamic preconditioning which depends on the elapsed simulation time. Furthermore, it happens in practice that simulation tools do not converge for certain inputs, or yield results only after consuming exceptionally long computation time.

Figure 9.1: Overview of SIESTA.

Figure 9.1 depicts the control and data flow in a typical optimization run. After setting up an experiment, one of four optimizers is started by SIESTA and its evaluation requests are fulfilled in parallel, where each evaluation entails an arbitrary number of calls of simulation tools on remote machines. In each run the definition of the experiment and the progress of the optimization are saved to files and can be examined from within MATHEMATICA [149].

SIESTA was originally implemented in a dialect of Lisp [75,76] called XLISP [14]. Because of new developments in language design and implementation since XLISP was written, the choice of a suitable base language for SIESTA was thought over. In order to meet the requirements described in Chapter 9, we posed the following demands on a suitable base language.

1. It has to provide an interface to the underlying operating system and network.
2. There has to be one (preferably more) stable and well supported implementation.
3. It has to support multiprocessing (or multi-threading).
4. An extension language is necessary in order to provide the required flexibility.
5. The implementation has to be able to load additional code at run time and to enable the user to execute commands interactively.
6. It should be well designed and preferably standardized.

After evaluating several languages, namely C, C++, Common Lisp, Java, Perl, Python, Scheme, and Tcl, we decided to use Common Lisp [41] with multiprocessing support. In addition to fulfilling all of our requirements, it provides the following features which helped reducing the implementation time.

1. Common Lisp supports the paradigms of functional programming and of object oriented programming.
2. All language constructs are available at run time.
3. Several implementations on all major platforms are available and all of these provide compilers and interactive listeners.
4. A powerful macro system makes Common Lisp a very extensible programming language.
5. Its condition system and operators like unwind-protect and ignore-errors contribute to stability and robustness.
6. Common Lisp is covered by an ANSI standard.

SIESTA runs on UNIX platforms, since UNIX provides good support for executing commands on remote computers and distributing files in a cluster of computers. Apart from these requirements, SIESTA is platform independent.

The requirements on the software infrastructure installed on the cluster of computers to be used in an experiment have been reduced to a minimum. Early versions of SIESTA required that the user's home directory is visible on all computers of the cluster and relied on NFS (network file system). NFS, however, is a source of problems since it does not provide sufficient synchronization between the state of files on different computers. Files are synchronized only after a pause, which leads to problems when the result file of a simulation tool exists on a client, but is not seen on the computer where SIESTA runs. Furthermore, it is not possible to request a synchronization between two computers manually.

Several solutions for that problem were tried, yet none worked satisfactorily. One attempt was to wait a certain amount of time (up to thirty seconds) after a simulation tool had finished. Because of this limitation of NFS, we decided to dispense with it and use rcp or scp instead [19].

In order to run SIESTA, the following programs have to be installed on a cluster.

• One of these possibilities for communication has to be chosen:
  • rsh, rcp, and rshd. These are standard on UNIX, but not secure.
  • ssh, scp, and sshd. These are not found on every UNIX system by default, but are secure.
  Of course these programs have to be set up such that no password entry is needed for each individual login, but only once per session.
• Standard UNIX commands like kill, mkdir, rm, top, and uptime.
• Finally it goes without saying that the simulation tools to be used have to be installed. Licenses are managed as described in Section 9.2.6.

SIESTA has been used for several optimizations of real world devices on a cluster of a dozen workstations and has proven to be very robust and to yield good results. The combination of local optimizers and evolutionary computation allows to take advantage of the benefits of both approaches. While the default configurations of the optimizers provide reasonably good performance, lots of aspects of an optimization run can be customized. The output of one or more optimization runs can be combined and used as input for the next run. This interoperability allows for interesting combinations of optimizers, comparisons of their performance, and specialization to the problem at hand.