4.5 Optimization Framework SIESTA

The simulation framework ``Simulation Environment for Semiconductor Technology Analysis'' (SIESTA) has been developed at the Institute for Microlelectronics to provide a framework that supports different simulation flows which can be defined and reapplied with different input data. The simulation framework has been extended by optimizers and a load-balancing system [44] to provide distributed computing. The aim of SIESTA is to provide as much flexibility as possible to allow the user to configure and extend the environment for future purposes. The original version was implemented in VLISP^4.13 [289]. However, due to user requirements, the core of SIESTA was rewritten in PYTHON [290] now known as SEILIB [291]. SIESTA is now based on several modules to provide a better modularity. The base concept of SIESTA is shown in Figure 4.6, where the different modules are listed. SIESTA consists of the SEILIB core optimizer and the design of experiment module. These three modules are able to work together independently of the other SIESTA modules. Possible scenaria for this type of application are optimizations or a sequences of simulations for instance for design of experiments which do not require user interaction.

SIESTA provides with the SEILIB module facilities to communicate with spy-daemons on the remote computers to collect information for distributed computing and load balancing. A typical task for the SEILIB module consists of a configuration file where all data for the automatic and non-interactive mode is stored including a description of the simulation flow.

The optimization framework SIESTA provides facilities to setup an experiment either graphically or with text-based configuration files, to display the simulation results via an external viewer, and to export simulation results to files. For the setup of an experiment, the simulation flow can be constructed from scratch or it can be obtained from a template, which can be edited in the graphical configuration file editor for SIESTA (cf. Figure 4.7). The graphical user interface (GUI) is capable of performing a rudimentary consistency check. It verifies the type of quantities of the connection between input and output ports of the models. If these two types do not match the connection is refused in the GUI.

Figure 4.7 shows an example where a doping concentration (ChD) has to be optimized. This quantity is provided to the first simulation flow model which is the tool MKDEV [292,37], which constructs from a given template file a device geometry for the device simulator MINIMOS-NT [37] in the next simulation flow model. MINIMOS-NT performs a simulation and provides as result a quantity called IdIoff, which is the ratio of ``on'' and ``off'' current. This quantity is submitted to the next model which is an auxiliary arithmetic model which performs an arithmetic operation on its input results. However, the output of the auxiliary model is the quantity error and is submitted back to the optimizer which proposes according to this value the next ChD value to improve (minimize) the error value.

The consistency checker is very helpful for introductory examples. However, the consistency check mechanism in the GUI can for instance not verify whether a certain quantity type is a member of a subset of another type. For such specialized setup constructions a text editor provides enough possibilities and is more suitable to build arbitrarily complex optimization setups.

Figure 4.6: Block diagram of SIESTA showing the internal function blocks and its environment.

Figure 4.7: Graphical user interface to setup an optimization showing a simple simulation flow which consists of two different simulation tools and a post-processing step.

The setup of the simulation flow consists of several template variables in the configuration files which are substituted directly before the particular job is submitted to a computational (remote) node.

Once the simulation job has been submitted to a remote host the job is executed on the remote host and at the end of the simulation job the result files retransmitted to the original directory where the files are either stored or discarded after the required input data has been submitted to the next simulation task.

If the job at the remote host is stalled and not responding, or even if the SEILIB module or SIESTA is terminated, the spies on the remote hosts recognize this fact and terminate the currently running processes which have been started from the current SEILIB instance.

To communicate between the different software components a PYTHON binding of the QT [293] sockets have been chosen which provide fast, simple, and robust communication facilities compared e.g. to CORBA [294,295]. CORBA would provide direct access to a distributed object which is actually not really necessary. The QT messaging system is more suitable and requires less hardware resources and produces also less network traffic during data transmission. Moreover, the secure shell (SSH) connection provides a tunnel for the QT socket connections from the host on which SEILIB is running to the remote host. Hence, the two software parts communicate with each other by writing into standard I/O streams.