5.1 Setting Up a Simulation Using Garand VE
5.2 Variability Analysis
Garand VE can simulate Id–Vg, Id–Vd, and C–V curves. Simulations are performed at fixed biases for a range specified by users. In addition, Garand VE can perform VT search simulations, where a series of simulations is run according to an internal algorithm until a threshold voltage that satisfies a user-defined current criterion is found. In this case, you can specify only the initial bias for the search, together with the current criterion and the degree of accuracy of the search.
It is important to point out that the interface between Garand VE and Sentaurus Workbench is represented by gpythonsh, which acts as a controller for both the Garand VE simulation status and the flow of data between Garand VE and Sentaurus Workbench.
In addition, gpythonsh harvests and stores the simulation data in a database (see Section 2. TCAD to SPICE Database).
This section demonstrates how to set up Garand VE inside a Sentaurus Workbench project and how to control, through gpythonsh, the simulation types and the flow of data to and from the database.
See the API documentation for a comprehensive guide to controlling Garand VE through the gpythonsh wrapper.
To access the API documentation, right-click a TCAD to SPICE tool icon and choose TCAD to SPICE API Documentation as illustrated on Figure 1.
PrerequisitesThis section covers the following topics:
Garand VE can be added to a Sentaurus Workbench project like other tools as follows:
Sentaurus Workbench adds the Garand VE tool at the current project location and automatically provides two input files:
Sentaurus Workbench preprocesses both files by using standard Sentaurus Workbench preprocessor syntax. These are discussed in detail in the next sections.
The Base Garand VE Input File should contain the input commands that are common to the Garand VE tools inside the same Sentaurus Workbench project. Generally, the Base Garand VE Input File contains basic models, material properties, the path to input structure files, output types, solver information, and other basic Garand VE simulation attributes.
There must be only one Base Garand VE Input File for each Sentaurus Workbench project.
If necessary, standard Sentaurus Workbench variable substitution can be used in the Base Garand VE Input File to produce a preprocessed input file that will be used by gpythonsh.
gpythonsh uses the Base Garand VE Input File as a generalized parent file and creates a specialized runnable child file for each Garand VE tool instance inside the Sentaurus Workbench project. In each of these runnable files, some of the input commands are overwritten or new input lines are added.
In Figure 4, the Garand VE tool instances in the Sentaurus Workbench project are specialized in performing Id–Vg, Id–Vd, and VT simulations. All tool instances share the same Base Garand VE Input File, but have different Python template files.
The main idea is to declare, in the Base Garand VE Input File, all the parameters that are constant across the project (such as temperature and Gummel accuracy). In the Base Garand VE Input File, you can also specify placeholders for those parameters that will change across the project (such as gate bias). There is no special syntax for these placeholders. However, the used keyword must exist. gpythonsh will modify the value of these placeholders according to the instructions specified in the template file (see Section 5.1.3 Python Template File for Garand VE).
For a list of all Garand VE input commands, refer to the Garand User Guide.
Here is the Base Garand VE Input File used in the example project:
# ------------------------------- SIMULATION TYPE ------------------------------ SIMULATION solve=on # Perform solution SIMULATION sim_type=IdVg # [IdVg, IdVd, target] SIMULATION accept_unconverged=on # if "off" all unconverged datapoints will # appear as '0' in the database #if "@Type@" == "pMOS" #define __BAND__ valence SIMULATION n_or_p=p # p-type simulation BIAS drain=-0.05 # Drain Bias [V] BIAS gate=0.0 # Gate Bias [V] BIAS substrate=0.0 # Substrate Bias [V] BIAS delta=-0.07 # Voltage step for I-V curve [V] BIAS ivpoints=11 # Number of points in the I-V curve #else if "@Type@" == "nMOS" #define __BAND__ conduction SIMULATION n_or_p=n # n-type simulation BIAS drain=0.05 # Drain Bias [V] BIAS gate=0.0 # Gate Bias [V] BIAS substrate=0.0 # Substrate Bias [V] BIAS delta=0.07 # Voltage step for I-V curve [V] BIAS ivpoints=11 # Number of points in the I-V curve #endif # ------------------------------- SIMULATION MODEL ----------------------------- MODEL density_gradient=on # Density gradient solution (majority carriers) MODEL minority_dg=on # Density gradient solution (minority carriers) MODEL dg_doping_limit=5e19 # DG application density threshold [/cm3] MODEL fermi_dirac status=off # Fermi-Dirac statistics SIMULATION gummel_acc=1e-4 # Gummel loop accuracy SIMULATION bounded_fermi = on SIMULATION import_bands = off SIMULATION T = 300 # simulation temperature #------------------------------ SIMULATION DOMAIN ------------------------------ STRUCTURE IMPORT filename=@tdr@ # Device structure file STRUCTURE gate_length=@<lgate*1e3>@ # Nominal gate length [nm] #------------------------------- MESH DEFINITION ------------------------------- MESH IMPORT # import the whole mesh in the structure #------------------------------ CONTACT DEFINITION ----------------------------- # Gate contact bounding box CONTACT metal_gate import=@gate_con@ name='@gate_con@' # Source contact bounding box CONTACT source import=@source_con@ name='@source_con@' # Drain contact bounding box CONTACT drain import=@drain_con@ name='@drain_con@' # Substrate contact bounding box CONTACT substrate import=@bulk_con@ name='@bulk_con@' CONTACT work_function=@workfn@ # set the metal workfunction CONTACT confined_boundary=off # Do not apply DG at contact interfaces # ---------------------------- MATERIAL REDEFINITION --------------------------- MATERIAL Silicon.__BAND__.dgy 0.3 # Density gradient mass x [me] MATERIAL SiliconGermanium.__BAND__.dgy 0.3 # Density gradient mass x [me] MATERIAL Oxide.__BAND__.dgy 0.1 # Density gradient mass x [me] MATERIAL Silicon.__BAND__.dgx 0.3 # Density gradient mass x [me] MATERIAL SiliconGermanium.__BAND__.dgx 0.3 # Density gradient mass x [me] MATERIAL Oxide.__BAND__.dgx 0.1 # Density gradient mass x [me] MATERIAL Silicon.__BAND__.dgz 5.0 # Density gradient mass x [me] MATERIAL SiliconGermanium.__BAND__.dgz 5.0 # Density gradient mass x [me] MATERIAL Oxide.__BAND__.dgz 5.0 # Density gradient mass x [me] MATERIAL Nitride.permittivity 7.5 # Setup permittivity of Nitride material MATERIAL Oxide.permittivity 3.9 # Setup permittivity of Oxide material MATERIAL Silicon.permittivity 11.7 # Setup permittivity of Silicon material MATERIAL LowK.permittivity 2.5 # Setup permittivity of LowK material # ---------------------------- MATERIAL STRESS --------------------------------- STRAIN import=on # enable strain import # ---------------------------------- MOBILITY ---------------------------------- MATERIAL Silicon.__BAND__.mobility.bulk masetti # bulk mobility model MATERIAL Silicon.__BAND__.mobility.eprp yamaguchi # low-field mobility model MATERIAL Silicon.__BAND__.mobility.elat caughey # high-field mobility model # ------------------------------ SIMULATION OUTPUT ----------------------------- OUTPUT directory=results # Directory to which output files are written OUTPUT experiment=n@node@ # Output file header if running I-V curve
The template file contains the user-defined instructions for gpythonsh, which controls the execution of each Garand VE tool instance.
Each Garand VE tool instance has a different template file.
If necessary, Sentaurus Workbench variable substitution can be used in the template file.
Each template file reads the Base Garand VE Input File and produces a specialized copy of it to perform the simulation required in each tool instance.
gpythonsh defines the Garand VE simulator as an object (garand), which has attributes that allow you to set up inputs of the object. In addition, methods allow you to drive the object to perform specialized functions. The most important attributes and methods used in this example are presented in Table 1 and Table 2. For an extended list, see the API documentation.
The typical syntax for attributes in Python template files is:
garand.attribute_name = attribute_value
The syntax for methods is similar to a function call. Therefore, the typical syntax is:
garand.method_name(input_parameters)
Attribute | Description | Default value |
---|---|---|
wait | Waits for current simulation to finish before continuing. | False |
clear_data | Clears old data from the database on first Garand VE call. | False |
inputfile | Links the Garand VE input file to the user-specified path. | – |
Method | Description | Inputs |
---|---|---|
Wait() | Garand VE waits at this line of the script until all currently running Garand VE simulations are completed. Note the uppercase letter with respect to the attribute, which has a lowercase letter. | – |
simulate() | Executes Garand VE with the specified conditions. | Any Garand VE commands that users want to add to the Base Garand VE Input File upon execution. |
The template file has three main sections:
##################################################################### ### The garand object is injected into the environment by ### ### gpythonsh. A small amount of setup is required before usage. ### ##################################################################### # Set full path to Garand VE input file garand.inputfile = open(os.path.join("@pwd@","@nodedir@","pp@node@_eng.garinp")) garand.clear_data= False garand.wait = True ##################################################################### ### Because of the simple structure of the Garand VE input file, ### ### you can directly alter the options of the Garand VE ### ### simulation. The attribute inputfile is set up like a Python ### ### dictionary with key-value pairs; therefore, access or ### ### substitution to all Garand VE inputs inside the file is ### ### very easy. ### ##################################################################### garand.inputfile["STRUCTURE IMPORT filename"] = "@pwd@/@tdr@" garand.inputfile["BIAS delta"] = @<Vdd_nom/8>@ garand.inputfile["BIAS ivpoints"]=9 ##################################################################### ### You can now execute Garand VE with the bias settings in the ### ### input file already attached to this tool instance ### ##################################################################### garand.simulate({"bias drain": @Vdd_lin@}) # Run Garand VE full IdVg at low Vd garand.simulate({"bias drain": @Vdd_nom@}) # Run Garand VE full IdVg at high Vd
This example of the template file performs an Id–Vg simulation. The aim is to properly set up the input file (a range of gate biases) using the Garand VE object (garand named in the Python code) and then to run the Garand VE simulator when Vd = Vdd_lin, where Vdd_lin is the parameter defined in Sentaurus Workbench.
The first line sets up the full path to the Garand VE child input files. gpythonsh will not delete the old data in the database because garand.clear_data=False, and Garand VE will wait for the full simulation to finish because garand.wait=True.
Next, the path to the TDR file is defined and applied to the Garand VE input file using the garand.inputfile attribute. Note that garand.inputfile is set up similarly to a Python dictionary with keyword ("STRUCTURE IMPORT filename") – value ("@pwd@/@tdr@") pairs. The path to the TDR file is set using standard Sentaurus Workbench variable substitution. It becomes very easy to access and modify commands inside the file.
Finally, you call the garand methods needed to perform the required functionality. In this example, you simply specify the drain bias input and pass it to the garand.simulate() method.
Garand VE supports running three types of simulation: Id–Vg, Id–Vd, and VT. Because of the easy access and manipulation capability of the Garand VE input file, the gpythonsh wrapper allows you to control the simulation type in a straightforward way. Section 5.1.3 Python Template File for Garand VE shows how to run a simple Id–Vg simulation. The example script in Section 5.1.3.1 Example can be modified to run an Id–Vd simulation, as shown here:
##################################################################### ### The garand object is injected into the environment by ### ### gpythonsh. A small amount of setup is required before usage. ### ##################################################################### # Set full path to Garand VE input file garand.inputfile = open(os.path.join("@pwd@","@nodedir@","pp@node@_eng.garinp")) garand.clear_data= False garand.wait = True garand.inputfile["STRUCTURE IMPORT filename"] = "@pwd@/@tdr@" garand.inputfile["BIAS delta"] = @<Vdd_nom/8>@ garand.inputfile["BIAS ivpoints"]=9 garand.inputfile["SIMULATION sim_type"] = "IdVd" ##################################################################### ### You can now execute Garand VE with the bias settings in the ### ### input file already attached to this tool instance ### ##################################################################### #if "@Type@" == "pMOS" gate_bias_list=[@<Vdd_nom+0.3>@, @<Vdd_nom+0.15>@, @Vdd_nom@] #else gate_bias_list=[@<Vdd_nom-0.3>@, @<Vdd_nom-0.15>@, @Vdd_nom@] #endif for vg in gate_bias_list: # Execute Garand VE with a different Vg every time garand.simulate({"bias gate": vg}) garand.Wait()
Again, you are simply exploiting the keyword–value pair structure of the Python dictionary garand.inputfile attribute, assigning the value IdVd to the keyword SIMULATION sim_type. The Garand VE simulation is then launched specifying a different gate bias value at each iteration.
Similarly, to perform a VT search simulation by using the tool instance VT_simulation, the Python template will be modified as:
##################################################################### ### The garand object is injected into the environment by ### ### gpythonsh. A small amount of setup is required before usage. ### ##################################################################### # Set full path to Garand VE input file garand.inputfile = open(os.path.join("@pwd@","@nodedir@","pp@node@_eng.garinp")) garand.clear_data= False garand.wait = True VT_init = 0.0 # Initial Vg value for the VT search algorithm ##################################################################### ### Because of the simple structure of the Garand VE input file, ### ### you can directly alter the options of the Garand VE ### ### simulation. The attribute inputfile is set up like a Python ### ### dictionary with key-value pairs; therefore, access or ### ### substitution to all Garand VE inputs inside the file is ### ### very easy. ### ##################################################################### garand.inputfile["STRUCTURE IMPORT filename"] = "@pwd@/@tdr@" garand.inputfile["SIMULATION sim_type "] = "target" garand.inputfile["SIMULATION target_current"] = @VT_current_criterion@ garand.inputfile["SIMULATION target_acc"] = 1e-4 garand.inputfile["SIMULATION target_iter_max"] = 25 garand.inputfile["SIMULATION target_init_slope"] = 70 ##################################################################### ### You can now execute Garand VE with the bias settings in the ### ### input file already attached to this tool instance ### ##################################################################### # Run Garand VE VT search, at low VD, starting VT search from Vg=0.0 garand.simulate({"BIAS drain": @Vdd_lin@, "BIAS gate": VT_init})
gpythonsh manages the flow of information to and from different tools by using an underlying database (see Section 2. TCAD to SPICE Database). All simulation results are stored in a database location named after the Sentaurus Workbench @node@. This allows an easy link between Sentaurus Workbench jobs and the database location, and an easy convention for data to be stored to, and retrieved from, the database.
In the specific case of Garand VE, the tool has a direct interface with the database and it automatically saves the simulation results to the database using a naming location based on the Sentaurus Workbench @node@ value. In the case of an Id–Vg (or Id–Vd) simulation, Garand VE identifies the gate (or drain) bias as the independent variable (ivar) and the drain current as the dependent variable (dvar), and stores these values in the database.
There is, therefore, no burden on the user side. After the garand.simulate() method is invoked, data is stored automatically. Table 3 lists all the metadata that Garand VE saves to the database.
Metadata | Description |
---|---|
Release | The current Garand VE release |
SimulationType | Id–Vg, Id–Vd, or target (that is, VT search) |
ivar | The independent variable (for example, Vg) |
dvar | The dependent variable (for example, Id) |
DeviceType | nMOS or pMOS |
CurrentUnits | Units for the electron current (for example, [A]) |
CapacitanceUnits | Units for the capacitance (for example, [F]) |
LengthUnits | Units for the geometrical features (for example, [nm]) |
L | Gate length |
W | Gate width |
Temperature | Simulation temperature |
AreaFactor | Same scaling factor as in Sentaurus Device |
drainLabel | Name of the drain contact |
sourceLabel | Name of the source contact |
gateLabel | Name of the gate contact |
substrateLabel | Name of the substrate contact |
RDC | Drain contact resistance |
RSC | Source contact resistance |
Given the previously mentioned naming convention for the database storage locations, retrieving data is straightforward. Assume you have a previous Garand VE tool instance that performed a simple Id–Vg simulation. You now create, in Sentaurus Workbench, a tool instance to retrieve the data that Garand VE saved to the database.
The data to be retrieved from the database is identified by the Retrieve_DB_data_idvg script with the following:
The specific code is given by the following line:
project_data_ld = Data.from_db(project="@node|IdVg@", ivar="v@gate_con@", \ dvar="i@drain_con@",**{drain_bias_filter:@Vdd_lin@})[0] project_data_hd = Data.from_db(project="@node|IdVg@", ivar="v@gate_con@", \ dvar="i@drain_con@",**{drain_bias_filter:@Vdd_nom@})[0]
For details about the syntax and options for the available gpythonsh methods, see the API documentation. It is worth mentioning that the Data.from_db method returns a data container, which can be exported in several formats (including CSV and PLT).
After data is retrieved from the database into the data container project_data, it is then grouped in a way to be written into a single PLT file by using the Data.concat_data() method. The method write_plt() finally exports the data into a PLT file, which can be visualized by the next Sentaurus Visual tool instance. Moreover, note the Vt(ic=ivt) method applied to the low-drain data to extract the threshold voltage (VT_extr) from the Id–Vg curve: this value can be compared with the one obtained by the VT_simulation tool instance.
project_data_ld.write_plt(os.path.join(output_dir_root,\ f"n@node@_idvg_stage_ld_0.plt")) VT_extr = project_data_ld.Vt(ic=ivt) # Threshold voltage extracted from IdVg print(f"DOE: VT_extr {VT_extr:.5}") project_data_hd.write_plt(os.path.join(output_dir_root,\ f"n@node@_idvg_stage_hd_0.plt"))
It is worth noting that, in the case of a VT search simulation, the value of the found threshold voltage is pushed as a metadata (TargetVoltage) together with an auxiliary metadata (TargetFound) that will confirm whether the simulation has converged to a threshold voltage value within the user-specified level of accuracy. The tool instance to retrieve the database data will, therefore, be modified as:
data = Data.from_db(project="@node|VT_simulation@", ivar="v@gate_con@", dvar="i@drain_con@")[0] if data.metadata["TargetFound"] == "True": VT = data.metadata["TargetVoltage"] else: VT = np.nan print(f"DOE: VT_sim {VT:.5}")
In addition, in Sentaurus Workbench, you can export the database content associated with a simulation node into a CSV file. This is achieved directly by using the Node Explorer, through the graphical user interface of Sentaurus Workbench (choose Node > Node Explorer).
The CSV file can then be postprocessed by any other script or analyzed in a spreadsheet application as shown in Figure 7.
This section presents an overview of the different sources of statistical variability and the commands used to enable them and to control how they are applied. The section also covers the commands that should be used in the Garand VE input file.
The example provided makes extensive use of the methodology previously discussed to run Garand VE in Sentaurus Workbench. The example demonstrates how to run Garand VE simulations with statistical variability, to switch on and off the different variability sources, and to modify some of the model parameters.
This section covers the following topics:
Garand VE can evaluate the impact of several statistical variability sources on device characteristics. These sources can be enabled and defined by using the Base Garand VE Input File or injected into the final Garand VE input file by the Python template file. The corresponding parameters should be provided. These are set using the variability command:
variability <variability_source> <parameter>=<value>
In the fabrication of semiconductor devices, dopants such as phosphorus (P), arsenic (As), and boron (B) are introduced by ion implantation and are activated through a high-temperature annealing process, resulting in inherently random discrete dopant (RDD) distributions. Random dopants are introduced in Garand VE through a rejection technique based on the continuous doping profile coming from a standard TCAD process simulation.
To represent the "average" TCAD doping profile statistically, each Si lattice site within the device is visited and the Si atom is replaced by a dopant, based on a calculated probability that depends on the nominal continuous doping concentration at that point. Consequently, the number of discrete dopants follows a Poisson distribution.
As the placement of discrete dopants depends only on the nominal doping profile, no additional parameters are required when enabling the simulation of RDD. You can specify whether all the dopants are discrete, or solely acceptors or donors. The positions of randomly generated discrete dopants will be written as particle data to the output TDR file.
The status parameter controls whether RDD is included in a specific simulation by using the variability command as:
variability RDD status=on
The dopants parameter controls whether all dopants should be discrete, or solely acceptors or donors. The possible options are shown here:
variability RDD dopants=all variability RDD dopants=acceptors variability RDD dopants=donors
It is also possible to specify individual dopant species fields for RDD generation. To enable this function, you define the parameter separate_species in the Garand VE input file:
variability RDD separate_species=on
Note that if it is enabled, each species will be considered independently. Therefore, the generated discrete dopant distribution will change.
By default, all dopant species are considered to be discrete dopants. To specify specific dopant species fields to use for RDD, use the commands:
variability RDD acceptor_fields = <acceptor fields> variability RDD donor_fields = <donor fields>
where <acceptor fields> and <donor fields> are comma-separated lists of acceptor and donor dopant fields, respectively. For example:
variability RDD acceptor_fields = BoronActiveConcentration variability RDD donor_fields = PhosphorusActiveConcentration
This example flags the BoronActiveConcentration and PhosphorusActiveConcentration species fields as being discrete, where the continuous doping profile associated with each species will be replaced by discrete dopants. Any doping fields that were imported and not flagged as discrete (for example, ArsenicActiveConcentration) will be included as a continuous doping profile as it was originally imported from the process simulation.
By default, discrete doping will be generated everywhere in the simulation domain except at contact regions. The RDD region can be restricted to a specific part of the device structure by providing a bounding box given by the parameters xmin, xmax, ymin, ymax, zmin, and zmax. It is not necessary to specify all of these parameters because, by default, this bounding box will fill the entire simulation domain, with the default values for the min and max parameters being the minimum or maximum extent of the simulation domain in the respective directions.
For large device structures, reducing the size of the RDD region is advisable as initializing a random dopant distribution can take time if the simulation domain is large. This is done in the later example to reduce the depth into the substrate to which discrete dopants are generated, using the command:
variability RDD xmax=100.0
which restricts the RDD generation to the region of the device structure where x < 100 nm.
Line edge roughness (LER) is introduced in Garand VE through randomly generated lines, which are used to modify the device structure.
These random lines are generated using a Fourier synthesis technique and are characterized by the following parameters:
To add LER to an arbitrary structure, the variability type LER is used. All the options for the particular specification of LER must be supplied on the same input file line. This is because LER can be applied in multiple directions simultaneously. For example:
variability LER <option1>=<value1> <option2>=<value2> ...
The status parameter controls whether LER is included in a specific simulation by using the variability command as:
variability LER status=on
The LER is characterized by two random lines. In the example here, this is used to apply gate edge roughness. The position of the midpoint of the LER region defines a plane, normal to which the structure will be modulated to follow the roughness. This plane is defined by a direction (x, y, or z) and a position.
To apply gate edge roughness, these should be the channel direction, and the point in the middle of the gate in that direction. If, for example, you wanted to apply roughness to the side walls of a FinFET, you would specify the point in the center of the fin in the width direction.
The direction along this plane in which the random lines should propagate is specified by using the dir parameter. In the example of gate edge roughness, this is the width direction, which is the y-direction in the example. For the example of fin edge roughness in a FinFET, this would be the channel direction. Finally, the RMS amplitude (rms) and the correlation length (corr) are required.
In the example Base Garand VE Input File, LER is specified with the command:
variability LER status=on z=0.0 dir=y rms=0.5 corr=25.0
For details about LER, refer to the Garand User Guide, along with other options that are available.
The polycrystalline nature of the metal gate is another potential source of statistical variability. Metal grains with different crystallographic orientations have different workfunctions at the metal–oxide interface, resulting in statistical variation of the local threshold voltage in the gate region.
Metal gate granularity (MGG) is introduced in Garand VE through the generation of random 3D grain patterns based on a 3D Voronoï tessellation, where the specified average grain size determines the average number of grains in the gate volume. Each grain is assigned a workfunction randomly from the list given by users. In the list, the number of grains with different workfunctions and the probability that the corresponding grain exists in the gate region are provided.
The status parameter controls whether MGG is included in a specific simulation by using the variability command as:
variability MGG status=on
The number of grains having different crystallographic orientations in the gate metal depends on how many grains you define using an add_grain statement.
For each grain orientation, you must provide two numbers: the first is an offset from the specified nominal workfunction, which will define the workfunction used within the grain, and the second is the probability (between 0.0 and 1.0) for that crystallographic orientation to occur. For example:
variability MGG add_grain wf_delta=-0.12 probability=0.4 variability MGG add_grain wf_delta=+0.08 probability=0.6
You must ensure that the sum of the probabilities for the defined grains equals 1.0. Otherwise, an error message is displayed, and the simulation stops.
You can also specify the average diameter of the grains (in nm) using the diameter parameter. For example:
variability MGG diameter=7.0
This diameter is one of the parameters that can be modified in the example Sentaurus Workbench project.
The granularity of polysilicon gates can be an important source of statistical variability due to surface potential pinning along the grain boundaries. As with metal gate granularity, polysilicon gate granularity (PGG) is introduced in Garand VE through the generation of random 3D grain patterns based on a 3D Voronoï tessellation, where the specified average grain size determines the average number of grains in the gate volume. Arbitrary surface potential pinning can be introduced at the grain boundaries.
The status parameter controls whether PGG is included in a specific simulation by using the variability command as:
variability PGG status=on
The other options you can specify are:
variability PGG diameter=30
variability PGG pinning=0.2
Polysilicon granularity is not included in the example here, as the device used has a metal gate.
Taking the basic Id–Vg simulation from the Sentaurus Workbench project of Section 5.1 Setting Up a Simulation Using Garand VE, Sentaurus Workbench parameters related to the statistical variability have been added.
These parameters will be used in the Python template file to control the application of the different variability sources in the simulation. The function of each Sentaurus Workbench parameter is as follows:
The device structure used as an example here is a stacked nanosheet MOSFET, which is the same example structure used in Section 5.1 Setting Up a Simulation Using Garand VE. The structure is shown in Figure 9.
The Base Garand VE Input File is the same here except for the addition of commands for the variability sources. The commands added to the Base Garand VE Input File are listed here:
# ----------------------------- VARIABILITY SOURCES ---------------------------- # RDD: Random discrete dopants VARIABILITY RDD status=off # Switch on / off RDD VARIABILITY RDD dopants=all # Apply to all species VARIABILITY RDD separate_species=on # Separate species fields VARIABILITY RDD xmax=100.0 # Range of the RDD region # LER: Line edge roughness VARIABILITY LER status=off z=0.0 dir=y rms=0.5 corr=20.0 # LER definition # MGG: Metal gate granularity VARIABILITY MGG status=off # Switch on / off MGG VARIABILITY MGG diameter=5.0 # Average grain diameter [nm] VARIABILITY MGG add_grain wf_delta=-0.12 probability=0.4 # delta[eV],probability VARIABILITY MGG add_grain wf_delta=+0.08 probability=0.6 # delta[eV],probability
These commands are sufficient to enable the variability sources as they are. However, several parameters act as placeholders that will be overridden by gpythonsh based on the template file. As already mentioned, gpythonsh can adjust the Garand VE simulation environment before executing a Garand VE simulation.
The RDD statements set up the simulation to generate discrete dopants for both acceptors and donors. The "separate species" mode is activated, although in the example here, there is only one species of acceptor (boron) and one species of donor (phosphorus).
The bounding box for the RDD region has been set with a maximum extent in the x-direction (xmax=100 nm). This is sufficiently deep in the device to cover the active part of the device, but excludes most of the deep substrate, where the discreteness of the dopants would have no effect on the device characteristics. This will help to reduce the setup time required to generate RDD.
The only RDD parameter that will be set by gpythonsh is the status parameter, which activates RDD in the simulation.
The LER statement in the Base Garand VE Input File, in this example, is set to model gate edge roughness. LER is set up by defining a plane through the structure. Two random lines are generated, then the structure on one side of the plane is modified by one of the lines, and the other side is modified by the other line. You then specify the direction in which the roughness should propagate. This is explained in more detail in the Garand User Guide.
In the example here, the plane is defined by specifying z=0.0, which defines a plane through the middle of the gate. This is illustrated by the green plane in Figure 10. Specifying dir=y means the roughness will propagate across the width of the device.
The statistical characteristics of the generated random lines are dictated by the RMS amplitude (rms parameter) and the longitudinal correlation length (corr parameter). The rms parameter here is a placeholder that will be replaced by gpythonsh using the value of LER_rms specified in the Sentaurus Workbench project. If you wanted to, you could also set up the corr parameter to be controlled from a Sentaurus Workbench parameter.
The metal gate granularity (MGG) is set up to include two different grain orientations. One orientation is associated with a workfunction of (WF0 − 0.12) eV with a probability of 0.4. The other orientation is associated with a workfunction of (WF0 + 0.08) eV with a probability of 0.6.
Here, WF0 is the nominal gate workfunction specified in the Garand VE input file by the CONTACT work_function statement, where the value of the workfunction used is provided as a Sentaurus Workbench parameter. Note that the average workfunction, weighted by the probability of each grain orientation occurring, is equal to WF0, that is:
0.4 × (WF0 − 0.12) + 0.6 × (WF0 + 0.08) = WF0
The average diameter of the generated metal grains is specified by the diameter parameter. A value of 5 nm is given in the Base Garand VE Input File, but this is simply a placeholder that will be replaced by gpythonsh using the value of MGG_dia specified in the Sentaurus Workbench project.
The way in which Garand VE simulation jobs and the Garand VE input file can be controlled by gpythonsh is discussed in Section 5.1 Setting Up a Simulation Using Garand VE. Here, those techniques are reused to set up the variability simulations and to launch a statistical ensemble of simulations from which you can obtain an ensemble of Id–Vg curves.
The basic setup where the Garand VE input file is identified, the structure file to import is set, and some bias information is specified, are as before. Commands to control the application of statistical variability in the Garand VE input file, based on the Sentaurus Workbench variables, have been added.
Here is the Python template file used to control the variability simulations in Garand VE:
##################################################################### ### The garand object is injected into the environment by ### ### gpythonsh. A small amount of setup is required before usage. ### ##################################################################### # Set full path to Garand VE input file garand.inputfile = open(os.path.join("@pwd@", "@nodedir@", "pp@node@_eng.garinp")) garand.clear_data = True garand.wait = True ##################################################################### ### Because of the simple structure of the Garand VE input file, ### ### you can directly alter the options of the Garand VE ### ### simulation. The attribute inputfile is set up like a Python ### ### dictionary with key-value pairs; therefore, access or ### ### substitution to all Garand VE inputs inside the file is ### ### very easy. ### ##################################################################### garand.inputfile["STRUCTURE IMPORT filename"] = "@pwd@/@tdr@" garand.inputfile["BIAS delta"] = @<Vdd_nom/7>@ garand.inputfile["BIAS ivpoints"]=8 if @TDR@: garand.inputfile["OUTPUT tdr"] = "on" ##################################################################### ### You can now execute Garand VE with the bias settings in the ### ### input file already attached to this tool instance ### ##################################################################### if @RDD@: print("RDD is enabled.") garand.inputfile["VARIABILITY RDD status"] = "on" if @LER@: print("LER is enabled.") garand.inputfile["VARIABILITY LER status"] = "on" garand.inputfile["VARIABILITY LER rms"] = @LER_rms@ if @MGG@: print("MGG is enabled.") garand.inputfile["VARIABILITY MGG status"] = "on" garand.inputfile["VARIABILITY MGG diameter"] = @MGG_dia@ if @VT_only@: print("VT only simulation enabled. Running VT search algorithm.") garand.inputfile["SIMULATION sim_type "] = "target" garand.inputfile["SIMULATION target_current"] = @VT_current_criterion@ garand.inputfile["SIMULATION target_acc"] = 1e-4 garand.inputfile["SIMULATION target_iter_max"] = 25 garand.inputfile["SIMULATION target_init_slope"] = 70 # Execute Garand VE full IdVg at low drain bias for an ensemble of devices garand.simulate({"bias drain": @Vdd_lin@}, start=1, n=@ensemble_size@)
The Sentaurus Workbench variables TDR, RDD, LER, and MGG are substituted directly as Python Boolean variables, and therefore must be valid Boolean values, that is, either True or False.
If RDD, LER, or MGG are True, then the status of each respective variability source is set to "on", thereby enabling the corresponding source of variability in the simulation. In addition, if LER is True, then the LER rms parameter is overridden by the value of LER_rms set in the Sentaurus Workbench project. If MGG is True, then the MGG diameter parameter is overridden by the value of MGG_dia set in the Sentaurus Workbench project.
Other Sentaurus Workbench parameters could be added, and a statement included in the corresponding section of the Python template file to override different variability model parameters, such as the LER correlation length, corr.
If TDR is True, then a command is injected into the Garand VE input file that enables the output of a TDR file at the end of each bias point simulation. Within the Garand VE results directory, a subdirectory is created for each bias point. The viz folder in each bias-dependent subdirectory contains the output TDR files. One TDR file is created for each device in the statistical ensemble, with the file name containing the number of the device within the ensemble.
When running statistical variability simulations, if the TDR parameter is switched on, then the number of TDR files produced can be large, occupying a significant amount of disk space. For this reason, TDR output is typically deactivated when running statistical simulation jobs. Then, if you want to understand the behavior of a particular device within the ensemble, you can switch on the TDR parameter and run only that device to obtain a TDR file for analysis.
Figure 11 shows examples of visualization of the sources of variability from a simulation in which RDD, LER, and MGG were activated. The positions of the random discrete dopants are shown by spheres in Figure 11 (left). In Figure 11 (right), the variation between the two specified gate workfunctions for MGG are shown in the gate. The structural variations due to LER can also be seen across the width of the device.
As described in Section 2. TCAD to SPICE Database, gpythonsh manages the flow of information to and from different tools by using an underlying database. Garand VE saves simulation results directly to the database, while gpythonsh can be used to extract data from the database for further use, for example, by writing PLT files for visualization.
The Retrieve_Plot_DB_data_variability_idvg tool instance of the Sentaurus Workbench project collects all the simulated Id–Vg data from the database and produces PLT files. One .plt file is written for each device in the statistical ensemble. Therefore, in this example, where ensemble_size is set to 10 in the Sentaurus Workbench project, ten .plt files are written.
The Visualize_Plots_Variability_idvg tool instance executes a script in Sentaurus Visual to load all the .plt files written at the previous tool instance and to plot the Id–Vg curves. Example results are shown in Figure 12 from simulations of an ensemble of 10 NMOS devices with RDD, LER, and MGG activated as sources of variability.
In the case of the VT_only simulation, this plotting tool instance will open a .png (created by the previous tool instance) showing a quantile-quantile plot of the threshold voltage distribution (see Figure 13).
main menu | module menu | << previous section | next section >>
Copyright © 2022 Synopsys, Inc. All rights reserved.