A problem class enables to group all relevant implementations required for a specific simulation setup into a single entity. This approach is considered the core of the simulator, which implements its expandable modeling facility via a virtual class hierarchy. This hierarchy enables to specialize the assembly and solution steps according to problem-specific requirements. Each problem specialization ensures that the required boundary conditions and initial guesses are assigned, the PDE objects are prepared including optional additional models, the linear solver backend is set up, the discretization method is selected, and ultimately the problem is assembled and solved (Figure 4.13). The simplest problems are the Laplace problem and the DD problem, which are discussed briefly in the following.
The Laplace problem solves Laplace’s equation for the electrostatic potential via the FVM. This case is implemented by assuming that the simulation domain is charge free, thus Poisson’s equation is simplified to:
 | (4.6) |
Note that we keep the permittivity on the left-hand side to investigate jumps in the solution due to material transitions. Overall, such a Laplace problem is relevant for, e.g., capacitance simulations.
Due to the utilization of a symbolic math kernel provided by ViennaMath, the Laplace equation object is implemented in a straightforward manner.
The first parameter of make_equation resembles the left-hand side, whereas the second parameter holds the right-hand side of the equation. In this case, the differential operators div and grad are used, as well as two quantity objects holding data values for each mesh element. Note the strong resemblance of the original mathematical formulation (Equation 4.6) and the implemented equation object.
The mesh element-associated permittivity values (eps) are defined according to material parameters assigned to each segment of the mesh. This requires access to material-based parameters, as the device merely provides the material name, the actual relative permittivity has to be extracted from the material database, though. Accessing the permittivity for a given material name is based on the material database, via predefined queries, customized according to the actual material.
The boundary conditions are assigned using the segment roles provided by the device’s auxiliary methods. More concretely, segments tagged as contact, are assigned Dirichlet boundary conditions according to the contact potentials provided by the stepper class (Section 4.3.5). Non-Dirichlet contacts are implicitly treated as Neumann boundaries by the utilized ViennaFVM assembly routines. The linear solver kernel is defined via ViennaFVM and configured according to the configuration parameters (Section 4.3.4).
The DD problem implements the previously introduced basic semiconductor equations (Section 4.1), consisting of three coupled PDEs in a straightforward and expressive manner for the stationary case.
The equations follow the original formulations as shown in Equations 4.1-4.5. This approach is reasonable for a small set of models, however, with growing model numbers, such an approach quickly becomes confusing and thus prone to errors. As an alternative each model could alter the equation objects accordingly via a pipelined process, meaning that an initial PDE enters a pipeline of model-based adaptations, according to the end user’s model selection. Such an approach would be more expandable and maintainable, as each model implementation performs local adaptions to the equation objects. Concerning the mobility and the recombination, the corresponding variables (mu_n, mu_p, and R) can be associated with models evaluating mesh element-specific values.
The current implementation of the nonlinear solver required for the DD problem utilizes the simple yet effective Gummel’s method [127] as provided by ViennaFVM. Among the advantages of this particular nonlinear solver is the fact that it is easier to implement as compared to Newton’s method, e.g., no Jacobian matrix has to be assembled. However, a Gummel solver offers stability issues for certain problems, such as high bias scenarios [1]. Overall, Gummel’s method is a reasonable nonlinear solver technique for the investigations presented in this work, due to the focus on software design and especially as this particular solver is suitable for a considerable number of problems.