Mesh generation divides a physical domain into so-called mesh elements. This particular task is complemented by mesh adaptation, enabling to change an already existing mesh according to specific requirements. For instance, geometrical predicates, such as the element shape, can be used to guide a mesh adaptation step, to ultimately improve the worst element in a mesh [106]. Aside from geometrical predicates, meshes can be adapted according to distribution-based tagging mechanisms. For instance, mesh regions carrying high gradients in quantity distributions, like doping, are higher resolved1 , to minimize discretization errors [55].
As already indicated, device simulation tools usually receive the simulation domain in form of a mesh from process simulation tools, accompanied by doping profiles. The meshes provided by process simulation tools are usually not suited for device simulation, due to different requirements imposed by a different set of physical model equations. Among the possible manifestations are highly distorted elements, and insufficiently resolved meshes, especially in regions where high gradients in the device simulation solutions are expected, such as doping transitions. Such unsuited meshes may result in slow convergence or in the worst case in no convergence at all of the solution method used in the device simulator. This circumstance requires the availability of a meshing facility, allowing either to adapt the mesh or to generate the mesh from scratch according to extracted geometry information. However, in this particular case, the initial doping profiles provided by the process simulator must be interpolated to the new mesh, likely offering entirely new mesh elements. The interpolation process ensures that the initial doping distribution is mapped to the new mesh elements, required for the mesh element-wise assembly of the basic semiconductor equations, like Poisson’s equation (Equation 4.1).
The use of process simulation tools yielding a mesh including doping informations may be omitted, for instance, for testing purposes. In this specific case, a device simulation tool has to work with a bare input mesh generated by mesh generation tools, such as Netgen [60]. In this context, a bare mesh indicates a mesh without any device-related information, meaning that although the mesh provides segments representing the individual parts of a device such as oxides, the mesh object has no knowledge about the physical relevance. For instance, no material information is associated with the segments or whether the individual segments represent a contact, an oxide, or a semiconductor region. Similar to the previous case, where a mesh is imported from a process simulator, the externally generated meshes usually lack domain knowledge thus potentially represents an unsuitable mesh, as already described. The lack of a process simulator requires that a doping profile has to be assigned to the mesh via, for instance, analytic functions, ultimately enabling to perform the actual device simulation. Overall, it is therefore essential to interface a device simulator with meshing facilities, enabling - possibly automatized - mesh adaptation steps to adapt an externally provided mesh according to domain-specific information.
Furthermore, so-called template devices are of interest, as they provide convenient, simulation-ready devices to end users. This template mechanism allows to entirely omit an external process simulation and mesh generation step, and thus augments the device simulator with a standalone simulation capability. Such a feature is usually of interest for showcases, tests, and tutorial-related purposes. These templates provide a specific device type, such as a two-dimensional metal-oxide-semiconductor field-effect transistor ( MOSFET), but expose certain customizable device geometry parameters, such as the channel width. To support a reasonable mesh resolution, the template mechanism has to be coupled with a meshing backend, allowing to generate a high-quality mesh upon updated end user-provided geometry parameters. Similar to the previous case describing the application in the context of an external mesh generation tool, a doping profile has to be distributed on the mesh.
The three discussed application cases of mesh generation and adaption are characterized in Figure 4.3. The challenge is to interface the device simulator with mesh generation facilities, without relying on a single specific meshing backend. For instance, interfacing directly with Netgen confines the simulator to utilize this specific tool for all mesh generation and adaptation tasks. However, as already indicated different meshing tools - aside from supporting different mesh types such as three-dimensional tetrahedral meshes - implement different algorithms and strategies to generate high quality meshes. Having access to various meshing backends is especially important to the field of TCAD, where input geometries, consisting of thin layers and complex surfaces [107], require high quality mesh generation which is still a matter of ongoing research.
Also, mesh generation might be prone to scaling issues, induced by, for instance, meshes defined in the nanometer regime. Such cases involve very small numbers which - if remained unscaled relative to the device dimensions - might break numerical tolerance limits in the meshing backend, potentially prohibiting the generation mechanism to converge. Therefore, it is advantageous to perform the mesh generation step based on a normalized input, i.e., the mesh is scaled relative to its device dimensions. When the mesh has been generated, it is scaled to the intended regime. Such scaling mechanisms are of general interest to all meshing backends, thus these mechanisms have to be provided in an orthogonal manner, further favoring a unified meshing layer.
Overall, it is of utmost importance to interface the device simulator with a flexible meshing layer, in turn enabling access to the actual meshing backends (Figure 4.4). This way, the meshing tools utilized by the simulator can be exchanged and expanded without additional development effort. The selection of the actual meshing backends can be done either manually, driven by the individual properties of the meshing tools relative to the problem at hand, or automatically, by, for example, heuristical methods.