Automated recipe health optimization

Abstract

A process recipe has process parameter values ​​for each step in the recipe. The recipe may be verified to determine whether it can be reliably implemented. A recipe that is deemed invalid may be optimized to determine minimum or maximum target values ​​for the recipe, which may differ from the target values ​​determined to be valid by the initial verification. The recipe may also be optimized to determine recipe margins and optimal process parameter values ​​for the process parameters of the recipe's steps.

Description

[Background technology]

[0001] [Related Applications] A PCT application is filed herewith as a part of this application. Each application identified in the PCT application to which this application claims benefit or priority is incorporated herein by reference in its entirety.

[0002] Semiconductor device manufacturing systems are constantly evolving as technology nodes shrink. Process recipes are developed, validated, and used to manufacture new devices. Process recipes tend to be complex and are typically developed based on the knowledge and experience of process engineers. The system on which a process recipe is developed may differ from the system on which the process recipe is executed, which may result in the process recipe not performing as expected.

[0003] The background and context discussion contained herein is provided solely for the purpose of generally presenting the contents of the disclosure. Much of the present disclosure represents work by the inventors, and the mere mention of such work in the Background section or as context elsewhere herein does not constitute an admission that it is prior art. Summary of the Invention

[0004] In one aspect of the embodiments herein, there is provided a method including: (a) receiving a first recipe for a semiconductor manufacturing operation, the first recipe including a plurality of steps, each step having one or more process parameters, each process parameter having a corresponding parameter value; (b) identifying steps of the first recipe; (c) executing the steps a plurality of times, each execution using different parameter values ​​for one or more process parameters associated with the step; (d) identifying sensor data associated with each execution of the steps; (e) determining optimal parameter values ​​for at least one process parameter based on the sensor data; and (f) associating the optimal parameter values ​​with the first recipe.

[0005] In some embodiments, the method further includes, prior to step (b), providing the first recipe to one or more validation models, each validation model outputting a health indicator. In some embodiments, the first validation model outputs a first health indicator that exceeds a first threshold, the first threshold representing a threshold at which the first recipe can be stably executed. In some embodiments, the method further includes determining that the first recipe can be stably implemented based on optimal parameter values. In some embodiments, the method further includes updating the first recipe based on the optimal parameter values. In some embodiments, the optimal parameter values ​​represent a recipe margin. In some embodiments, the method further includes (g) executing the first recipe based on the optimal parameter values, wherein during execution of the first recipe, a second health indicator exceeds a second threshold; and (h) generating a report indicating that the second health indicator exceeded the second threshold. In some embodiments, the second health indicator represents a plurality of sensor data, and the report indicates one or more sensor data that most contributed to the second health indicator exceeding the second threshold. In some embodiments, the method is performed during process recipe approval.

[0006] In another aspect of embodiments herein, a method is provided, the method including: (a) receiving a recipe for a semiconductor manufacturing operation, the recipe including a plurality of steps, each step having one or more process parameters, each process parameter having a corresponding parameter value; (b) identifying a first step of a first recipe; and (c) performing the first step using a manufacturing tool, wherein during the performance of the step, one or more of the following cycles are performed: (i) identifying sensor data associated with performance of the first step; (ii) determining one or more health indicators based on the sensor data; and (f) modifying one or more process parameter values ​​of the first step based on the one or more health indicators and the sensor data.

[0007] In some embodiments, the one or more health indicators each represent a plurality of sensor data. In some embodiments, one or more cycles are performed until the health indicators converge to a maximum or minimum value. In some embodiments, the modified one or more process parameter values ​​are saved to the first recipe after the health indicators converge. In some embodiments, the health indicators are also based on baseline health indicator metrics, the baseline health indicator metrics being health indicators associated with the first step for a previous execution of the first step. In some embodiments, the previous execution of the first step was by a manufacturing tool different from the manufacturing tool performing the first step. In some embodiments, modifying the one or more process parameter values ​​of the first step is further based on the one or more health indicators exceeding a threshold. In some embodiments, modifying the one or more process parameter values ​​of the first step is further based on the one or more health indicators exceeding a threshold for a predetermined period of time. In some embodiments, one or more cycles are not performed during the initial period of performing the first step. In some embodiments, the method further includes generating a failure mode report for the first step of the recipe based on process parameters for the first step and sensor data collected during performance of the first step, wherein the first failure mode indicates one or more sensor data that contributed to the first health indicator exceeding a threshold.

[0008] In another aspect of embodiments herein, a system for optimizing a recipe is provided, the system including a process chamber and one or more processors configured to: (a) receive a recipe for a semiconductor manufacturing operation, the recipe including a plurality of steps, each step having one or more process parameters, each process parameter having a corresponding parameter value; (b) identify a first step of a first recipe; and (c) perform the first step in the process chamber, during the performance of the step, perform one or more of the following cycles: (i) identify sensor data associated with performance of the first step; (ii) determine one or more health indicators based on the sensor data; and (f) modify one or more process parameter values ​​of the first step based on the one or more health indicators and the sensor data.

[0009] These and other features of the disclosed embodiments are described in detail below with reference to the associated drawings. [Brief explanation of the drawings]

[0010] [Figure 1] FIG. 1 illustrates an example recipe in accordance with various embodiments of the present disclosure.

[0011] [Figure 2A] FIG. 2A illustrates a process flow for optimizing parameters of a recipe in accordance with various embodiments herein. [Figure 2B] FIG. 2B illustrates a process flow for optimizing parameters of a recipe in accordance with various embodiments herein. [Figure 2C] FIG. 2C illustrates a process flow for optimizing parameters of a recipe in accordance with various embodiments herein.

[0012] [Figure 3] FIG. 3 shows a chart of radio frequency (RF) power versus conductance.

[0013] [Figure 4] FIG. 4 shows a chart of RF power versus confinement ring position.

[0014] [Figure 5] Figure 5 shows a chart of pressure and RF reflection coefficient over time.

[0015] [Figure 6A] FIG. 6A shows a schematic diagram of a system for determining health according to various embodiments herein.

[0016] [Figure 6B] FIG. 6B shows a chart of failure modes for the recipe.

[0017] [Figure 6C] FIG. 6C shows a time series chart of the health index scores for the recipes.

[0018] [Figure 7] FIG. 7 shows a schematic diagram of a processing system for carrying out various embodiments herein. DETAILED DESCRIPTION OF THE INVENTION

[0019] background context Some disclosed embodiments provide the flexibility to deploy variations of a previously approved recipe for a device manufacturing tool having a particular configuration. Some disclosed embodiments provide the flexibility to change one or more device manufacturing tool parameters without re-approving a previously approved recipe for the original tool configuration. In the past, the tool and recipe ecosystem imposed a specific set of parameter settings on a tool to effectively execute a recipe, resulting in inflexibility. For example, if a customer makes a minor change to the process conditions under which a particular process, such as an ALD process, was performed, this variation of the original or approved recipe could be deemed invalid. To provide tool users (e.g., IC manufacturing facilities) with more flexibility to change parameters associated with a given tool or set of tools and still safely use variant recipes, tool users and / or device manufacturing tool vendors may employ embodiments disclosed herein.

[0020] In some embodiments, recipes may be validated based on various models that analyze the recipe's process parameter values. These models may be simplistic and biased toward underinclusion, such that recipes that may be validly executed are deemed invalid. Recipes may be actively validated against sensor data from detailed experimental testing to determine a more accurate assessment of whether the recipe can be validly executed.

[0021] term Process Parameters—Process parameters are parameters that characterize the execution of a process in a device manufacturing tool. Examples of process parameters include process conditions such as temperature (pedestal, wafer, showerhead, chamber walls, etc.), pressure in the chamber, plasma characteristics (power, frequency, pulse characteristics, bias, etc.), process gas characteristics (composition, flow rate, etc.), and duration or time of a particular operation (etch process, number of ALD or ALE cycles).

[0022] Sensor Data—Sensor data includes information collected by sensors deployed throughout the semiconductor manufacturing process. The sensors may collect data such as temperature, pressure, mass flow rate, etc. The sensors may also collect data regarding electrical properties such as frequency, power, voltage, current, and reflection coefficient. In some embodiments, sensor data may include derivative information or statistics determined based on other sensor data, such as the variation of DC bias voltage during a time window.

[0023] Recipe—A recipe is a set of process parameter values ​​at which a manufacturing operation or portion of a manufacturing operation is to be performed. A recipe may function (successfully execute a process) on one or more device manufacturing tools with one or more configurations; these configurations are sometimes referred to herein as “fingerprints.” Examples of process parameters whose values ​​are collectively provided in a recipe include chamber pressure, process gas flow rate, process gas composition, pedestal temperature, plasma power, and process duration. In various embodiments, a recipe is a set of conditions within a “process window” of a device manufacturing tool. In such embodiments, a recipe may represent a point within the process window. In other words, a recipe may represent a collection of discrete parameter values ​​rather than a range of such values. In certain embodiments, a recipe for a multi-step process may include a series of discrete process space points, one point for each step. Even simple, non-cyclic processes may have multi-step recipes. For example, an etch process may have a recipe that includes (a) an initialization step that defines the handling of the wafer before or during its introduction into the etch chamber, and (b) an etch process step that defines the process conditions in the etch chamber while the wafer is being etched.

[0024] Recipe Margin—A recipe margin represents a range of process parameter values ​​associated with a given tool that defines the region of process parameter space in which a recipe can be stably implemented. Outside this range, the process may become unstable or may not function properly. For example, outside the margin, the process may not support a stable plasma. Recipe margin may be represented by a single parameter value, such as a minimum or maximum pressure, or by a combination of parameter values, such as a combination of gas flow rates, pressure, and RF power.

[0025] Fingerprint—A fingerprint represents a specific set of tool parameter values ​​for a device manufacturing tool. In some embodiments, a fingerprint is a collection of discrete tool parameter values ​​rather than a range of such values. As an example, a fingerprint may be a unique set of hardware, firmware, and / or software for each of several components that together make up a tool. A fingerprint may be provided for a particular recipe developed or approved using the tool having the fingerprint. A fingerprint may include one or more of software configuration options, software configuration variables, firmware versions, hardware configurations, warning policies, scheduler policies, calibration files, compensation files, and data log signals.

[0026] Model—A model is a set of rules or other algorithm or logic for determining whether a given recipe is suitable for implementation on a particular tool component or collection of tool components that may collectively have a particular fingerprint. In some embodiments, a model is configured to determine whether a given recipe can be deployed, or can continue to be deployed, on a particular tool having a particular combination of settings or other parameters. A model may be configured to receive a recipe and one or more current tool parameter values. In some embodiments, a model may be configured to output optimized parameter values ​​for one or more steps of the recipe. In some embodiments, a model may be configured to output the health of a tool component executing the recipe. The health may indicate whether the tool component can successfully execute the recipe.

[0027] Failure Mode—A failure mode represents the root cause of why a recipe, recipe step, or step condition is considered unhealthy. In some embodiments, the failure mode may be determined based on one or more models used to determine health. Health may exceed a threshold, indicating that a portion of a recipe is unhealthy. The failure mode may represent the root cause of the health exceeding the threshold. The failure mode may include information about which step or state and which sensor data caused the health to exceed the threshold. In some embodiments, the failure mode may include information about expected sensor data or expected statistics derived from sensor data, such as bias voltage variation. When the variation exceeds a predetermined value, the variation-based health indicator changes. In some embodiments, the failure mode may include process parameters associated with the sensor data that caused the health to exceed the threshold. The failure mode helps identify the specific sensor data and / or process parameters that caused the health indicator to exceed the threshold and the recipe / step / state to be considered unhealthy. In some embodiments, the failure mode may be automatically remedied by predetermined rules for modifying one or more process parameters based on the particular failure mode. In other embodiments, the failure mode may be part of a generated notification that a process engineer or other person may use to modify the recipe or potentially the tool on which the recipe is running, for example, to replace a consumable part.

[0028] Health or Health Indicator—A health or health indicator represents a set of rules or other algorithms or logic applied to a fingerprint and / or recipe, particularly when attempting to execute the recipe. During recipe execution, hundreds of signal parameters / sensor data (e.g., bias voltage, gas pressure, radio frequency, etc.) may be collected. These signals may be analyzed to determine whether the recipe is executing successfully. However, reviewing all signal parameters is resource-intensive. Therefore, the sensor data or a subset of the sensor data may be analyzed to determine one or more health indicators that can be used to determine whether the recipe is executing successfully. In some embodiments, a health indicator may be associated with a health threshold. In some embodiments, if a health indicator exceeds a health threshold, a notification may be generated alerting a user that the health indicator has exceeded the threshold. In some embodiments, if a health indicator exceeds a health threshold, a recipe modification is automatically performed to restore the health indicator within the health threshold.

[0029] In some embodiments, if the health indicator cannot be restored, a notification may be generated. In some implementations, the notification may include a potential cause, such as a failure mode, for the health indicator to exceed a threshold. For example, a health indicator associated with a pressure sensor along a gas delivery manifold may exceed a certain value, and potential causes may include a clogged inlet to the process chamber, corrosion in the piping or various valves, a degraded pumping system, or a miscalibrated mass flow controller. In some embodiments, the health indicator may be restored by changing process parameters. In other embodiments, the health indicator may not be restored without changing hardware or performing a process to modify the tool, such as a chamber cleaning process or replacing parts within the tool.

[0030] As used herein, a "semiconductor device manufacturing operation" or "manufacturing operation" refers to an operation performed during semiconductor device manufacturing. Typically, a general manufacturing process includes multiple semiconductor device manufacturing operations, each performed within its own semiconductor manufacturing tool, such as a plasma reactor, electroplating bath, chemical-mechanical polisher, wet etcher, etc. Types of semiconductor device manufacturing operations include removal processes, such as etching processes and planarization processes, and material-additive processes, such as deposition processes (e.g., physical vapor deposition, chemical vapor deposition, atomic layer deposition, electrochemical vapor deposition, electroless plating). In the context of an etching process, a substrate etching process includes a process that etches a mask layer and, more generally, a process that etches any layer of material previously deposited and / or otherwise present on the substrate surface. Such an etching process may etch a stack of layers in a substrate.

[0031] A "manufacturing apparatus" or "manufacturing tool" is a device in which a manufacturing process is performed. A manufacturing apparatus may include a processing chamber in which a workpiece resides during processing. Typically, in use, a manufacturing apparatus performs one or more semiconductor device manufacturing operations, which may be performed according to a "recipe." Examples of manufacturing apparatus for semiconductor device manufacturing include subtractive process reactors and additive process reactors. Examples of subtractive process reactors include dry etch reactors (e.g., chemical and / or physical etch reactors), wet etch reactors, and ashing apparatuses. Examples of additive process reactors include chemical vapor deposition reactors, atomic layer deposition reactors, physical vapor deposition reactors, and electroplating baths. A device manufacturing tool typically consists of various subsystems, such as an RF source, temperature controller, gas delivery, and pressure controller.

[0032] Recipe Optimization FIG. 1 shows an example recipe 100 having three steps. For each of steps 1, 2, and 3, a value is associated with each process parameter 102. Note that recipes typically have more process parameters and additional steps than shown in FIG. 1. In some embodiments, the values ​​associated with the process parameters may depend on or reference other modules. For example, the bias match adjust delay process parameter is associated with a "default" value that may reference another module. In some embodiments, the dependency may reference a best known method "BKM" module. The BKM module allows a user editing a recipe to automatically reference BKM process parameter values ​​for specific process parameters and specific steps.

[0033] Recipe 100 may also include various health indicators. Confinement health 112 is an example of a health indicator related to whether the plasma generated during execution of recipe 100 is confined. Plasma may become unconfined for various reasons, and unconfined plasma may be undesirable. Thus, confinement health scores 114, 116, and 118 indicate whether the plasma is likely to become unconfined during that step. In the example of FIG. 1 , a “0” indicates that the health of the step has not been analyzed, a “−1” indicates that the plasma is unconfined (i.e., “unhealthy”), and a value greater than “0” indicates a threshold to be maintained, such as a minimum, maximum, or range of values. In FIG. 1 , the value 18.5 for step 3 for confinement health may indicate a minimum pressure to be maintained to generate a confined plasma. In some embodiments, the health indicator may represent a minimum, maximum, or range of values ​​for a process parameter. In other embodiments, the health indicator may indicate that the step can be performed while the health indicator exceeds a threshold. The value 18.5 may be determined using various processes described herein. In FIG. 1, the containment health score 118 is shown as "-1->18.5." This represents an initial determination of unhealthy and is subsequently updated to the threshold value of 18.5 by performing the processes described herein. While FIG. 1 shows a single health index for each step, in some embodiments, the health index may be determined as a time series of a recipe with multiple health indices determined during a step, as shown in FIG. 6C, described further below. In some embodiments, the health index may be normalized to a value between 0 and 1, and the step is considered "healthy" as long as the normalized value is greater than a threshold value, e.g., 0.8. Various thresholds may be used. In some embodiments, the threshold may be determined based on:

[0034] 2A-2B are flowcharts for determining optimized parameters for a recipe. In some embodiments, the optimized parameters may represent parameter values ​​that best achieve a desired result. In other embodiments, the optimized parameters may represent recipe margins, and the recipe may stably perform within the optimized parameters. Beginning in FIG. 2A, a recipe is received (202). The recipe may be represented, for example, as a series of steps having process parameter values ​​for various process parameters, as shown in FIG. 1. In some embodiments, the processes of FIGS. 2A-2B may be performed as part of recipe approval. Recipe approval may include determining that the recipe is stably executable and sound for each step of the recipe.

[0035] In some embodiments, the recipe may be executed and / or analyzed to determine baseline metrics (204). The baseline metrics may include sensor data and health indicators. In some embodiments, the baseline metrics may include an initial determination that the recipe is unhealthy. For example, if a health indicator is determined to exceed a threshold, the recipe or a step of the recipe may be considered unhealthy. Health may be recipe-specific, and a recipe may have multiple health indicators. For example, in FIG. 1, the recipe may be unhealthy based on a containment health value of −1 in steps 2 and 3.

[0036] In some embodiments, baseline metric health may be evaluated using models. These models may be used to deterministically validate recipes. Recipe parameters may be analyzed to determine whether process parameter values ​​fall within ranges previously determined to be healthy. In some embodiments, these models may use thresholds for combinations of process parameter values. FIGS. 3 and 4 show examples of such models. FIG. 3 shows power / conductance curves that distinguish between a confined plasma region 302, an unconfined plasma region 306, and a potential unconfined plasma region 304. While RF power and conductance are shown here, additional parameters such as total gas flow rate or pressure may also be considered. If a recipe's process parameter values ​​fall within the confined plasma region, the recipe may be validated as successful (or at least validated with respect to confined plasma). Alternatively, if a process parameter value falls within the unconfined plasma region or a potential unconfined plasma region, the recipe may be considered unhealthy or potentially unhealthy. 4 shows a similar graph of RF power and confinement ring position, where certain combinations of RF power and confinement ring position may be determined to result in confined plasma, unconfined plasma, or potentially unconfined plasma. The unconfined plasma zone 404 and the confined plasma zone 402 may be defined based on the confinement ring position and the total RF power. In some embodiments, the total gas flow rate and pressure may also affect whether the model successfully validates the recipe. For example,

[0037] If the process parameter values ​​fall within the confined plasma region or potentially confined plasma region of Figures 3 and 4, the recipe may fail verification. Furthermore, in some embodiments, the model based on Figures 3 and 4 may be a series of thresholds for various process parameters, and if any predetermined combination of thresholds is exceeded, the recipe may be deemed unhealthy based on an unconfined plasma. This may occur even if the recipe could be run with a confined plasma with the current process parameters. A recipe may fail verification based on the model used for verification, but may actually run successfully.

[0038] Because the models used to validate a recipe do not necessarily reflect the exact configuration of the tool at the manufacturing site or account for all process parameters, a recipe that actually runs successfully may fail validation, so a recipe may still run successfully even though it is deemed unsound based on the validation model. Alternatively, the current process parameter values ​​for a recipe may result in an unconfined plasma, but it would be useful to suggest minimum or maximum target values ​​for the process parameter values ​​that result in a confined plasma rather than simply generating a notification that the recipe cannot generate a confined plasma. Furthermore, in some embodiments, the model used for validation may not be able to determine recipe margin for the recipe.

[0039] For example, a model used to verify a recipe may determine that steps 2 and 3 of the recipe shown in FIG. 1 are invalid because the plasma may not be confined. However, as shown in FIG. 1 and discussed further herein, the recipe may be stably executed at a pressure of at least 18.5 mTorr. Because the pressure in step 3 is 30 mTorr, step 3 should be stably executed based on the updated optimal parameters determined in accordance with the embodiments discussed herein, even though the verification model states it is unsound. Using embodiments disclosed herein, this recipe margin may be determined with greater specificity than the deterministic model used to initially verify the recipe. This recipe margin may then be saved with the recipe as an exception to the verification model and as a more specific indicator of the recipe's stable process window.

[0040] In some embodiments, baseline metrics or recipe verification may be used to determine which process steps require further analysis. For example, if a step is initially deemed healthy, it may not be further analyzed or optimized. Alternatively, if a process step is deemed invalid, it may be further analyzed to determine optimal parameter values. In some embodiments, process steps may be manually selected and analyzed.

[0041] Returning to FIG. 2A , a recipe may be optimized by modifying one or more steps of the recipe, executing the modified steps, and collecting sensor data associated with the modified steps. As shown in blocks 206, 208, and 209, a recipe step may be modified and executed multiple times, each time with different process parameter values. In some embodiments, a test recipe may be determined in which a single step is repeated multiple times, e.g., 10 or more times, with one or more process parameters modified for each iteration. Sensor data associated with executing the step with each process parameter value may then be collected (210) and used to determine optimal parameter values ​​(212). The sensor data may be health indicators, e.g., parameters derived from various signals, or raw sensor data from one or more sensors. In some embodiments, a specific set of sensor data is collected.

[0042] This flow may be repeated (213) for different process parameters or different steps of the recipe. In some embodiments, blocks 206-212 may be performed for any health indicators deemed unhealthy in step 204. In some embodiments, blocks 206-212 may be manually triggered by a user to determine optimal parameter values ​​for particular process parameters and / or recipe steps. Blocks 206-212 may be performed as a design of experiments (DOE) analysis across a range of process parameter values ​​for one or more process parameters.

[0043] The sensor data may then be used to determine optimal parameter values ​​(212). The optimal parameter values ​​may represent specific target values ​​for the recipe or recipe margins. The recipe margins may indicate a stable process window for the process parameters. In some embodiments, instead of the recipe being modified based on the recipe margins, the recipe margins are associated with the recipe to assist the process engineer in determining whether a combination of parameter values ​​is stable.

[0044] FIG. 5 illustrates an example of modifying pressure steps during a recipe step to determine an optimal pressure. In FIG. 5, the process chamber pressure may be incrementally modified from 21 mTorr to 17.5 mTorr while the plasma is being generated. The left axis and line 502 represent pressure, and the right axis and line 504 represent the RF reflection coefficient. Each change in pressure reflects a different parameter value for pressure for the same step of the recipe, e.g., step 3 of recipe 100. The repeated recipe steps in FIG. 5 are performed to determine the relationship between pressure and plasma confinement. Therefore, sensor data or health indicators related to plasma confinement may be collected. The RF reflection coefficient may be an example of health indicator or sensor data related to plasma confinement. The RF reflection coefficient may be strongly correlated with plasma confinement, and a sudden change in the RF reflection coefficient as the pressure is modified may indicate that the plasma is becoming or has become unconfined. Thus, as shown in the graph of FIG. 5, as the pressure is reduced to 18 mTorr, the RF reflection coefficient similarly exhibits a sudden change from 0.16 to 0.08. This change may be interpreted as indicating a change in the plasma, specifically, that the plasma is unconfined. While a single sensor data is shown in Figure 5, in some embodiments, multiple sensor data may be identified, collected, and analyzed. In some implementations, the sensor data and / or health indicators may be predetermined as being related to a health indicator of interest, such as plasma confinement.

[0045] As used herein, optimal parameter values ​​may refer to various types of process parameter values. In some embodiments, optimal parameter values ​​may be minimum or maximum process parameter values ​​for a recipe to execute at a predetermined steady state, e.g., recipe margin. A stable implementation may be defined by, for example, a health indicator such as plasma confinement, which itself may be defined by a combination of sensor data. In other embodiments, optimal parameter values ​​may be specific target values ​​from an objective function applied over a range of process parameter values ​​to maximize a value of interest, e.g., to maximize a health indicator.

[0046] Returning to FIG. 2A, the sensor data may be analyzed to determine optimal parameter values ​​(212). The optimal parameter values ​​may be determined using various statistical analyses or objective functions on the collected sensor data. For example, a change in RF reflection beyond a threshold amount may indicate a change in a characteristic of the plasma, such as the plasma becoming unconfined.

[0047] In some embodiments, the optimal parameter may represent a minimum or maximum parameter value. As shown in FIG. 5, a pressure below 18.5 mTorr results in a change in the RF reflection coefficient, indicating that the plasma is not confined. Therefore, the optimal parameter value is a pressure of at least 18.5 mTorr. Although a single parameter value is shown in FIG. 5, in some implementations, multiple parameters may be optimized. For example, assuming that pressure and RF power each affect plasma confinement, the optimal parameter may be a threshold value for pressure and RF power relative to each other. For example, if the RF is less than 2000 W, the pressure must be at least 18.5 mTorr, but if the RF power is greater than 3000 W, the pressure must be at least 16 mTorr. In some embodiments, this optimal parameter may be written into the recipe to indicate a minimum pressure, as shown by process parameter value 118 in FIG. 1.

[0048] In some embodiments, the optimal parameter values ​​may override the process parameter values ​​to modify the recipe. In some embodiments, the process parameter values ​​may be overwritten based on a health indicator. For example, if the pressure value of the recipe is less than the pressure value determined as the minimum optimal process parameter value, the pressure may be adjusted to the optimal pressure value determined in block 212. In some embodiments, the optimal parameter values ​​may be written into the recipe after a verification step such that the optimal parameter values ​​result in a successful recipe.

[0049] The recipe may be run using the optimal parameter values ​​(216). Running the recipe may be used to collect data and verify that the determined optimal parameter values ​​are valid. For example, as described above, the model used to initially verify the recipe may not fully account for variations in tool or recipe implementation in the manufacturing field. While the DOE analysis used to determine the optimal parameter values ​​is more accurate than the model used for verification because it is performed in the manufacturing field, the recipe and execution results may differ when run as intended to process substrates. Therefore, in some embodiments, the recipe may be run with the optimal parameters to verify stable implementation. Various sensor data may be collected during the recipe run.

[0050] Health indicators may be determined (218) from the sensor data of the recipe run using the optimal parameter values. The health indicators may be similar to the health indicators used to determine the optimal parameter values, e.g., the RF reflection coefficients shown in FIG. 5 . The health indicators may then be analyzed to determine whether each health indicator is within an acceptable range. For example, if the RF reflection coefficient is not within a particular range, it may be determined that the plasma is not confined. Other health indicators may also be used. In some embodiments, the health indicators used to determine whether the recipe is healthy are the same as the health indicators used to initially verify the recipe. In other embodiments, the health indicators are different from the health indicators used to initially verify the recipe.

[0051] If the recipe is deemed sound, the optimal parameter values ​​may be saved to the recipe (222). In some embodiments, the optimal parameter values ​​are saved as additional metadata for a process engineer to consider when designing a recipe. For example, a recipe margin may be saved that a process engineer can use to understand how low a pressure a process can run at while still confining the plasma. Alternatively, in some embodiments, the optimal parameter values ​​may be saved as process parameter values ​​for a step in the recipe. In such an embodiment, the recipe may be saved using the optimal parameter values ​​instead of the previous process parameter values. At run time, the recipe uses the optimal parameter values.

[0052] If the recipe is deemed unhealthy, a report may be generated based on the failed health indicators (224). In some implementations, the health indicator may be a combination of various sensor data, and the report may indicate which sensors contributed most to the low health score. For example, a health indicator for plasma confinement may be based on 10 or more sensor data, including statistics determined from such sensor data, such as averages, deviations, maximum / minimum values, etc. In some implementations, a subset of the sensor data may significantly contribute to the low health index score. In such implementations, the report may indicate which sensor data contributed most to the low score. The user may then determine whether the recipe is faulty or whether the sensor data is faulty, for example, whether a sensor or other component is faulty and needs to be replaced. In some implementations, the report may be used by a process engineer to update the recipe. The recipe may then be re-run through the process flowchart shown in FIGS. 2A and 2B.

[0053] 2C shows another flowchart for determining optimized parameters for a recipe. The same reference numbers may be used to indicate that similar operations are performed. A recipe is received (202). In some embodiments, an optional operation may be performed to determine baseline metrics (204).

[0054] The steps of the recipe may then be executed (258). In some embodiments, this step may be executed as part of the development or approval of the recipe in a test environment. In some embodiments, the recipe may be executed on production wafers in a production environment. During execution of a recipe step, the step may be optimized or modified to improve execution results. Blocks 260, 268, 270, and 252 may be executed during execution of a recipe step.

[0055] Sensor data associated with the performance of the step may be acquired 260. In some embodiments, the sensor data may include measurements of, for example, current, power, conductance, reflection coefficient, etc. In some embodiments, acquiring the sensor data may include performing a transformation or statistical analysis, such as, for example, standard deviation of current over a period of time.

[0056] The sensor data may be used to determine one or more health indicators (268). Each health indicator may indicate whether a step is running successfully, e.g., whether it can run steadily without adverse effects, such as an increase in defects on the wafer. Each health indicator may be based on the acquired sensor data. Each health indicator may be determined based on various calculations of the sensor data, including transformations, thresholds, filters, statistical analyses, etc.

[0057] Once one or more health indicators are determined, the step may be analyzed for health (270). In some embodiments, this determination may be based on the health indicator being out of range or outside a threshold. In some embodiments, health may be based on comparing the health indicator determined in 268 to a baseline health indicator. If the recipe is unhealthy, one or more process parameters of the step are modified (252) based on the sensor data and the health indicator. After modifying the one or more parameters, blocks 260, 268, and 270 may be repeated based on the modified process parameters. If the step is healthy, the process parameters may be saved to the recipe (272).

[0058] In some embodiments, the health of a step may be based on the health index being below a threshold. For example, Figure 6C shows a chart of the health index score for a recipe over time. The health index is normalized to a value between 0 and 1, with a value of 0.8 or greater indicating a healthy recipe (i.e., higher values ​​are better). In some embodiments, a step is considered unhealthy when the health index falls below 0.8.

[0059] In some embodiments, a step is considered unhealthy if the health index remains below a threshold for a minimum period of time. For example, the health index may be determined by various step or intra-step conditions, such as a change in one or more process parameters, such as gas flow rate or temperature. Vertical line 653 indicates a step change in which one or more process parameters may be altered, resulting in a subsequent temporary decrease in the health index. These changes are reflected in the collected sensor data and may cause the health index to decrease, but after the change is made, the health index quickly rises as the process chamber stabilizes to the new process parameters. For example, spike 650 indicates a momentary decrease in the health index score, but then quickly increases above the threshold of 0.8. In such embodiments, a temporary decrease in the health index may be considered acceptable.

[0060] In other embodiments, after changing one or more process parameters, the health index may decrease and remain decreased for a period of time, e.g., at least 3 seconds, which may indicate that the step associated with that time index is unhealthy. Box 655 shows a decrease in the health index score that persists for approximately 5 seconds, indicating that the step is unhealthy rather than simply transitioning to a different state. In some embodiments, as described above, the health index may be used to indicate that a step (or a state within a step) is unhealthy based on the health index remaining below a threshold for a minimum period of time. In some embodiments, because the health index is expected to fluctuate, the health index may be ignored for a period of time after a new step is initiated or a process parameter is changed. Therefore, the health index should not be used to determine that a step is unhealthy for the first 1, 2, 3, or 4 seconds after a new step or state is initiated.

[0061] In some embodiments, the chart in FIG. 6C itself may be used as a baseline metric. In some embodiments, a recipe may be validated or run on a tool or process chamber with a particular fingerprint, and then the recipe is run on another tool with the same fingerprint. In some embodiments, the time-series health index charts generated when running a recipe on different tools may be different, even though the tools have the same fingerprint. A recipe may run differently on different tools for a variety of reasons, including differences in wear of consumable parts, differences in degradation of physical components, or differences in software configurations even if considered the same fingerprint (e.g., a fingerprint may be defined as having at least software version 1.2, but one tool may have version 1.2.4 and another tool may have version 1.2.5). It may also be desirable to adjust a recipe to generate the same time-series health index across different tools with the same fingerprint.

[0062] Thus, in some embodiments, a time series chart such as that shown in FIG. 6C may be used as the baseline metric. In such embodiments, a current time series health index chart may be determined as part of block 258 and / or blocks 206-212. The current time series health index chart may be compared to the baseline time series health index chart, and a comparative health index may be generated based on the difference between the current and baseline health indexes. If the comparative health index exceeds a threshold value, e.g., a value of 0.05 for a health index normalized to [0,1], as shown in FIG. 6C, the step or state may be considered unhealthy because it does not match the baseline metric, even though the current health index exceeds the threshold. Conversely, if the current health index falls below a threshold that would otherwise indicate unhealthy, it may still be considered healthy because it matches the baseline health index (which may also be considered healthy despite being below the threshold, e.g., less than the threshold for less than a predetermined period, as described above).

[0063] In some embodiments, the impact of various process parameters on the health index may be determined based on one or more relationships between the process parameters, sensor data, and the health index. For example, referring back to FIG. 5 , if pressure is known to affect the RF reflection coefficient, a desired range of values ​​for the RF reflection coefficient may be predetermined. If the RF reflection coefficient is outside this range, the health index may fall outside the threshold. In some embodiments, when the health index changes in a way that is considered unhealthy, the RF reflection coefficient may be determined to contribute to the unhealthy score, and a process parameter, such as pressure, may be modified to modify the RF reflection coefficient so that it is within the desired range.

[0064] While the impact of some process parameters on health indicators may be generally understood, modeling can be difficult given the large amount of sensor data available. For example, dozens or hundreds of process parameters may be set for a given step in a recipe, and the health indicator may be based on sensor data associated with a variety of different process parameters. Therefore, it is difficult to understand how changing a process parameter will affect the health indicator. Using the methods disclosed herein, process parameters may be empirically optimized by modifying them to optimize the health indicator.

[0065] In some embodiments, the loop of blocks 260, 268, 270, and 252 may be repeated until one or more health indicators converge to an optimal value. For example, the health indicator may be treated as the result of an objective function, and one or more process parameters may be modified to minimize / maximize the health indicator value. Thus, for example, if increasing a process parameter such as pressure decreases the health indicator, the pressure may be increased instead. Once the health indicator converges to a local maximum / minimum, the modified one or more process parameters may be considered optimal and saved to the recipe.

[0066] While the examples presented herein discuss modifying one or two parameters, it will be understood that a recipe step may include tens or hundreds of parameter values ​​that may be modified. In some embodiments, a subset of such parameters may be selected for optimization by the process shown in FIG. 2C. This may then be repeated for different subsets of parameters or different steps of the recipe.

[0067] 2C may be performed during the execution of a recipe step to modify process parameters without resetting the step. For example, sensor data may be collected and analyzed in real time to modify process parameters during the execution of a recipe step, such as by modifying the pressure while the plasma is ignited and measuring how the RF reflection coefficient changes in response to modifying the pressure. Modifying process parameters while the step is executing may increase throughput in finding optimal process parameters by iterating more quickly with different parameters.

[0068] In some embodiments, as described above, the process of FIG. 2C may be performed as part of recipe development or approval, i.e., recipe determination may be performed stably. In other embodiments, the process of FIG. 2C may be performed during execution of a recipe in a production environment. In some embodiments, the process of FIG. 2C may be used to modify process parameters when health indicators indicate that a step is unhealthy. For example, if health indicators indicate that the plasma is unstable, pressure (or other process parameters) may be modified to improve plasma stability and the corresponding health indicator. Process parameters may be changed within recipe margins and / or according to a model.

[0069] FIG. 6A shows a schematic diagram of a health determination system. The system of FIG. 6A may be used to determine health indicators as described above in 218 and 268. Sensor data inputs 602 may be identified as input states 604, analyzed by a model to determine output states 606, and processed via combination logic 608 to generate health indicators 610. The sensor data inputs 602 may be the same as the sensor data discussed with respect to blocks 210 and 260 above. In some embodiments, the sensor data inputs may represent 100 or more different parameters. Examples of sensor data inputs are shown in FIG. 6 and include recipe parameters, metrics / sensor data from bias output generators, voltage sensors, TCP internal and external coils, etc.

[0070] The sensor data inputs may be identified as one or more input states 604. A state may represent a particular configuration of hardware and software during a step. In some embodiments, a step may have only one state, and in such embodiments, the terms state and step may be considered synonymous. In other embodiments, a step may have multiple states. For example, a plasma process may have one or more radio frequency (RF) sources that cycle between low and high power. In some embodiments, the plasma may be characterized by pulses having two or more states, such as off / on, off / low power / high power, different power levels for each RF source, etc. In such embodiments, it may be desirable to analyze the RF characteristics for each state within a step rather than analyzing the step as a whole, since each state may be independently optimized or malfunction.

[0071] The sensor data may then be analyzed by the model to determine an output state 606. Each output state may have a single health index score, and in some embodiments, may have sensor data indicative of the metric that most contributed to the decrease in the health index score, e.g., a fault. In some embodiments, a step may have a single state, while in other embodiments, a step may have multiple states, as described above. In some embodiments, there is a corresponding output state for each input state.

[0072] The combining logic 608 may then combine the health index scores and contributing metrics across states and / or steps. For example, the health index scores may be combined using various statistical methods, including average, minimum / maximum, or weighted sum. The combined output state may then be presented as a single overall health for a step or series of steps. For example, a single RF score health index may represent the health of the RF system. Various error codes or contributing metrics may be associated with the health index and may represent potential causes of the health index score. For example, an error code may indicate which sensor data contributed most to the health index score, allowing a process engineer to more quickly diagnose and correct the cause of a low health index score.

[0073] In some embodiments, the system of FIG. 6A may be used to optimize parameter values. For example, various parameter values ​​may be provided to the system of FIG. 6, and a health index score may be maximized for various combinations of recipe parameter values. In some embodiments, the system of FIG. 6 may be used to determine optimal parameter values ​​as discussed at 212 and 258 based on sensor data collected during execution of a recipe step. As mentioned above, a step may have multiple states, which in some embodiments are analyzed in the same way, and a health index score may be attributed to the entire step rather than just each state.

[0074] In some embodiments, the output state may be determined based on one or more models. For example, in the context of RF metrics, an instability model and a misadjustment model may be used to analyze the stability and adjustment of RF pulse shape data, respectively. Various sensor data may be provided to an instability model, which determines whether the RF pulse data is stable, e.g., based on fluctuations or spikes around a steady-state value. Similarly, the sensor data may be provided to a tuning health model, which determines how close the steady-state value from the sensor data is to a desired target value. If these models determine that the RF pulse data is unstable and / or misadjusted (e.g., based on the sensor data exceeding a threshold), the health index score will be adversely affected, and specific error codes related to stability and adjustment may be provided in a report for process engineers to troubleshoot.

[0075] In some embodiments, the system of FIG. 6A may be used to identify root causes of sensor data and / or process parameters that adversely affect a health index. For example, if sensor data provided to the system of FIG. 6A is processed and the health index score indicates that a step is unstable, it may be desirable to determine what is contributing to the poor health index score. However, the captured sensor data may represent hundreds of different types of data collected over a period of time, resulting in thousands of data points to analyze. Thus, in some embodiments, the system of FIG. 6A may be configured to determine potential causes of the poor health index score.

[0076] FIG. 6B shows an example report that explains potential causes of a poor health index. The illustrated information may be based on a data log of sensor data and a recipe, which may be analyzed as described herein, particularly in connection with FIG. 6A . As shown in FIG. 6B , step 2 of the example recipe may have a low health index score, which is determined to be due to sensor data related to RF stability in state 1 (S1) of step 3. In some embodiments, a failure mode may be provided. The failure mode may explain the reason for the low health index score. For example, in FIG. 6B , there is a failure mode related to variations in bias settings and TCP settings. In some embodiments, the failure mode may provide information that explains the root cause of the low health index, such as which process parameter or which sensor data is causing the low health index.

[0077] In some embodiments, the failure mode may include information about a process parameter of the recipe related to the root cause, such as a target value for power output. In some embodiments, the failure mode may include information about specifications for the sensor data to be considered healthy, such as, for example, that the average step variation should be less than 1.5% or less than 10%. In some embodiments, the failure mode may provide sensor data or statistical data derived from the sensor data that does not meet specifications, such as, for example, that the average step variation should be 4.2% and less than 1.5%. In the example of FIG. 6B , the failure mode is for State 1 in Step 2; additional states may exist within a step, or alternating states may exist within a step, such as, for example, alternating between a first state and a second state. Additional information about RF stability for State 1 may be provided, including process parameters related to RF stability, such as power output, as well as additional statistical information. In some embodiments, information about how to improve the health index may be provided, for example, for a process engineer to modify the recipe. In other embodiments, the recipe may be automatically modified, as described above in connection with FIG. 2C .

[0078] Background Context for Disclosed Computing Embodiments Certain embodiments disclosed herein relate to computing systems for generating and / or using machine learning models. Certain embodiments disclosed herein relate to methods for generating and / or using machine learning models implemented on such systems. A system for generating a machine learning model may be configured to analyze data to calibrate or optimize a formula or relationship used to represent a classification, source, or remediation of defects on a substrate. A system for generating a machine learning model may be configured to receive data representing physical processes occurring during semiconductor device manufacturing operations and instructions, such as program code. In this manner, a machine learning model is generated or programmed on such a system. A programmed system for using a machine learning model may be configured to (i) receive input, such as metrology data of defects on a substrate, and (ii) execute instructions to determine a classification, source, or remediation of defects on the substrate.

[0079] The disclosed systems for implementing machine learning models and algorithms for generating and / or optimizing such models may employ many types of computing systems having any of a variety of computer architectures. For example, the systems may include software components running on one or more general-purpose processors or specially designed processors such as application-specific integrated circuits (ASICs) or programmable logic devices (e.g., field-programmable gate arrays (FPGAs)). Furthermore, the systems may be implemented on a single device or distributed across multiple devices. The functionality of the computing elements may be integrated together or further divided into multiple sub-modules.

[0080] In some embodiments, the code executed during the generation or execution of a machine learning model on a suitably programmed system may be realized in the form of a software element storable on a non-volatile storage medium (optical disk, flash storage device, mobile hard disk, etc.) that contains a number of instructions for configuring a computing device (personal computer, server, network equipment, etc.).

[0081] At one level, software elements are implemented as a set of commands prepared by a programmer / developer. However, modular software executables on computer hardware are executable code allocated to memory using "machine code" selected from the specific machine instruction set, or "native instructions," designed for the hardware processor. The machine instruction set, or native instruction set, is known to and inherently built into one or more hardware processors. It is the "language" through which system and application software communicates with the hardware processor. Each native instruction is a discrete piece of code recognized by the processing architecture that can specify specific registers, specific memory locations or offsets, and specific addressing modes used to interpret operands for operations, addressing, or control functions. More complex operations are constructed from combinations of these simple native instructions, executed sequentially or as directed by control flow instructions.

[0082] The interaction between executable software instructions and hardware processors is structural. In other words, the instructions themselves are sequences of symbols and numbers. They do not inherently convey information. The processor, which is pre-configured by design to interpret the symbols and numbers, gives the instructions meaning.

[0083] The models used herein may be configured to run on a single machine at a single location, multiple machines at a single location, or multiple machines at multiple locations. When multiple machines are employed, each machine may be tailored to a specific task. For example, large code blocks and / or operations requiring significant processing power may be implemented on larger and / or stationary machines.

[0084] Additionally, certain embodiments relate to tangible and / or non-transitory computer-readable media or computer program products that contain program instructions and / or data (including data structures) for performing various computer-implemented operations. Examples of computer-readable media include, but are not limited to, semiconductor memory devices, phase-change devices, magnetic media such as disk drives and magnetic tape, optical media such as CDs, magneto-optical media, and hardware devices specially configured to store and execute program instructions, such as read-only memory devices (ROM) and random access memory (RAM). Computer-readable media may be directly controlled by an end user or indirectly controlled by an end user. Examples of directly controlled media include media located at a user's premises and / or media that is not shared with other entities. Examples of indirectly controlled media include media that a user can indirectly access via an external network and / or via a service that provides shared resources, such as the "cloud." Examples of program instructions include both machine code, such as produced by a compiler, and files containing higher-level code that a computer can execute using an interpreter.

[0085] In various embodiments, data or information employed in the disclosed methods and apparatus is provided in electronic form. Such data or information may include design layouts, fixed parameter values, floating parameter values, feature profiles, metrology results, etc. As used herein, data or other information provided in electronic form may be stored on a machine or transmitted between machines. Traditionally, data in electronic form is provided digitally and may be stored as bits and / or bytes in various data structures, lists, databases, etc. Data may be embodied electronically or optically, for example.

[0086] In certain embodiments, each machine learning model can be considered a form of application software that interfaces with a user and system software. System software typically interfaces with computer hardware and associated memory. In certain embodiments, system software includes operating system software and / or firmware, as well as any middleware and drivers installed on the system. System software provides basic, task-unspecific functionality for the computer. In contrast, modules and other application software are used to accomplish specific tasks. Each native instruction of a module is stored in a memory device and represented by a numerical value.

[0087] An example of a computer system 800 is shown in FIG. 7. As shown, computer system 800 includes an input / output subsystem 802 that may implement an interface for interacting with a human user and / or other computer systems, depending on the application. Embodiments of the present invention may be implemented in program code on system 800, with I / O subsystem 802 used to receive input program statements and / or data from a human user (e.g., via a GUI or keyboard) and display them back to the user. I / O subsystem 802 may include, for example, a keyboard, mouse, graphical user interface, touch screen, or other interface for input, and, for example, an LED or flat screen display, or other interface for output. Other elements of embodiments of the present disclosure, such as order engine 208, may be implemented using a computer system like computer system 800, but perhaps without I / O.

[0088] The program code may be stored in a non-transitory medium, such as persistent storage 810, memory 808, or both. One or more processors 804 read the program code from the one or more non-transitory mediums and execute the code to enable a computer system to perform methods performed by embodiments herein, such as those related to generating or using a process simulation model described herein. Those skilled in the art will appreciate that a processor may accept source code, such as statements for performing training and / or modeling operations, and interpret or compile the source code into machine code understandable at the processor's hardware gate level. A bus connects the I / O subsystem 802, the processor 804, the peripheral devices 806, the memory 808, and the persistent storage 810.

[0089] In various embodiments, the computer system 800 may be part of or connected to a controller employed to control process conditions during various etching and deposition operations. The controller typically includes one or more memory devices and one or more processors. The processor may include a CPU or computer, analog and / or digital input / output connections, a stepper motor controller board, etc.

[0090] The controller may control all activity of the deposition and / or etching equipment. The system controller executes system control software that includes instruction sets for controlling the timing, gas mixture, chamber pressure, chamber temperature, wafer temperature, radio frequency (RF) power levels, wafer chuck or pedestal position, and other parameters of a particular process. Other computer programs stored on memory devices associated with the controller may also be employed in some embodiments.

[0091] Typically, there may be a user interface associated with the controller, which may include a display screen, a graphical software representation of equipment and / or process conditions, and user input devices such as a pointing device, keyboard, touch screen, microphone, etc.

[0092] System control logic may be configured in any suitable manner. Generally, the logic may be designed or configured in hardware and / or software. Instructions for controlling the drive circuitry may be hard-coded or provided as software. The instructions may be provided by "programming." Such programming is understood to include any form of logic, including logic hard-coded into digital signal processors, application-specific integrated circuits, and other devices with specific algorithms implemented as hardware. Programming is also understood to include software or firmware instructions that may be executed on a general-purpose processor. System control software may be coded in a suitable computer-readable programming language.

[0093] The computer program code for controlling the seed flow, RF power, pedestal temperature, and other processes in the processing sequence can be written in any conventional computer-readable programming language, such as assembly language, C, C++, Pascal, Fortran, etc. The compiled object code or script is executed by a processor to perform the tasks specified in the program. As previously mentioned, the program code may also be hard-coded.

[0094] The controller parameters relate to process conditions such as, for example, process gas composition and flow rates, temperature, pressure, cooling gas pressure, substrate temperature, and chamber wall temperature. These parameters may be provided to a user in the form of a recipe and entered using a user interface. Signals for monitoring the process may be provided by analog and / or digital input connections of the system controller. Signals for controlling the process are output to analog and digital output connections of the deposition and / or etching tools.

[0095] The system software may be designed or configured in a variety of ways. For example, various chamber component subroutines or control objects may be written to control the operation of chamber components necessary to perform deposition and / or etch processes (and possibly other processes) in accordance with disclosed embodiments. Examples of programs or portions of programs for this purpose include substrate positioning code, process gas control code, pressure control code, and heater control code.

[0096] In some implementations, the controller is part of a system that may be part of the examples described above. Such a system may include semiconductor processing equipment, including one or more processing tools, one or more chambers, one or more platforms for processing, and / or specific processing components (such as a wafer pedestal, gas flow system, etc.). These systems may be integrated with electronics to control their operation before, during, and after semiconductor wafer or substrate processing. The electronics may be referred to as a "controller" that may control various components or subcomponents of one or more systems. Depending on the processing requirements and / or type of system, the controller 629 may be programmed to control any of the processes disclosed herein, including delivery of process gases, temperature settings (e.g., heating and / or cooling), pressure settings, vacuum settings, power settings, radio frequency (RF) generator settings in some systems, RF matching circuit settings, frequency settings, flow rate settings, fluid delivery settings, positioning and motion settings, and wafer transfer into and out of tools and other transfer tools and / or load locks connected or interfaced to a particular system.

[0097] Broadly speaking, a controller may be defined as electronic equipment having various integrated circuits, logic, memory, and / or software that receive instructions, issue instructions, control operations, enable cleaning operations, and enable endpoint measurements. The integrated circuits may include chips defined as firmware that store program instructions, digital signal processors (DSPs), application-specific integrated circuits (ASICs), and / or one or more microprocessors or microcontrollers that execute program instructions (e.g., software). The program instructions may be communicated to the controller in the form of various individual settings (or program files) and may define operational parameters for implementing a particular process on or for a semiconductor wafer or for a system. The operational parameters, in some embodiments, may be part of a recipe defined by a process engineer to accomplish one or more processing steps during the manufacture of one or more layers, materials, metals, oxides, silicon, silicon dioxide, surfaces, circuits, and / or dies of a wafer.

[0098] In some implementations, the controller may be part of, connected to, or a combination of a computer integrated with, connected to, or otherwise networked to the system. For example, the controller may be in the “cloud” or all or part of a fab host computer, thereby enabling remote access to wafer processing. The computer may provide remote access to the system to monitor the current progress of a manufacturing operation, examine the history of past manufacturing operations, examine trends or performance metrics from multiple manufacturing operations, modify parameters of a current process, configure processing steps to follow a current process, or initiate a new process. In some examples, a remote computer (e.g., a server) may provide process recipes to the system over a network, which may include a local network or the Internet. The remote computer may include a user interface that allows entry or programming of parameters and / or settings, which are communicated to the system from the remote computer. In some examples, the controller receives instructions in the form of data specifying parameters for each of the processing steps to be performed during one or more operations. It will be understood that these parameters are specific to the type of process being performed and the type of tool the controller is configured to interface with or control. Thus, as previously mentioned, the controller may be distributed, such as by including one or more separate controllers that are networked together and cooperate toward a common purpose, such as the processes and controls described herein. One example of a distributed controller for such purposes would be one or more integrated circuits on the chamber that communicate with one or more remotely located integrated circuits (either at the platform level or as remote computers) that together provide control for the chamber.

[0099] Non-limiting examples of systems include plasma etch chambers or modules, deposition chambers or modules, spin rinse chambers or modules, metal plating chambers or modules, cleaning chambers or modules, bevel edge etch chambers or modules, physical vapor deposition (PVD) chambers or modules, chemical vapor deposition (CVD) chambers or modules, atomic layer deposition (ALD) chambers or modules, atomic layer etch (ALE) chambers or modules, ion implantation chambers or modules, track chambers or modules, and other semiconductor processing systems that may be associated with or used in the manufacturing and / or production of semiconductor wafers.

[0100] As described above, depending on the process step or steps being performed by the tool, the controller may communicate with one or more of other tool circuits or modules, other tool components, cluster tools, other tool interfaces, adjacent tools, nearby tools, tools located throughout the factory, a main computer, another controller, or tools used in material transport to and from tool locations and / or load ports of wafers within a semiconductor fabrication factory.

[0101] conclusion In the foregoing description, numerous specific details are set forth in order to provide a thorough understanding of the present disclosure. The disclosed embodiments may be practiced without some or all of these specific details. In other instances, well-known process steps have not been described in detail in order to avoid unnecessarily obscuring the present disclosure. Although the disclosed embodiments have been described in connection with specific embodiments, it will be understood that these specific embodiments are not intended to limit the disclosed embodiments.

[0102] Unless otherwise indicated, the method operations and apparatus features disclosed herein include techniques and apparatus commonly used in metrology, semiconductor device manufacturing technology, software design and programming, and statistics, and are within the skill of the art.

[0103] Unless otherwise defined herein, all technical and scientific terms used herein have the same meaning as commonly understood by one of ordinary skill in the art. Various scientific dictionaries that include the terms used herein are well known and available to those skilled in the art. Although any methods and materials similar or equivalent to those described herein can be used in the practice or testing of the embodiments disclosed herein, several methods and materials are described.

[0104] Numerical ranges are inclusive of the numbers defining the range. Every maximum numerical limitation given throughout this specification is intended to include every lower numerical limitation, as if such lower numerical limitations were expressly written herein. Every minimum numerical limitation given throughout this specification includes every higher numerical limitation, as if such higher numerical limitations were expressly written herein. Every numerical range given throughout this specification includes every narrower numerical range that falls within such broader numerical range, as if such narrower numerical ranges were all expressly written herein.

[0105] The headings provided herein are not intended to limit the disclosure.

[0106] As used herein, singular terms such as "a," "an," and "the" include the plural unless the context clearly dictates otherwise. The term "or," as used herein, means both or either one, unless otherwise indicated.

Claims

1. 1. A method comprising: (a) receiving a first recipe for a semiconductor manufacturing operation, the first recipe including a plurality of steps, each step having one or more process parameters, each process parameter having a corresponding parameter value; (b) identifying steps of the first recipe; (c) performing the step multiple times, each execution using different parameter values ​​for one or more process parameters associated with the step; (d) identifying sensor data associated with each execution of said steps; (e) determining an optimal parameter value for at least one process parameter based on the sensor data; (f) associating the optimal parameter values ​​with the first recipe.

2. 10. The method of claim 1, further comprising, before step (b), providing the first recipe to one or more validation models, each validation model outputting a health indicator.

3. 3. The method of claim 2, wherein a first validation model outputs a first health indicator that exceeds a first threshold, the first threshold representing a threshold at which the first recipe can be stably executed.

4. 4. The method of claim 3, further comprising determining that the first recipe can be stably performed based on the optimal parameter values.

5. The method of claim 1 , further comprising updating the first recipe based on the optimal parameter values.

6. The method of claim 1 , wherein the optimal parameter values ​​represent recipe margins.

7. 10. The method of claim 1, (g) executing the first recipe based on the optimal parameter values, wherein during execution of the first recipe, a second health indicator exceeds a second threshold; and (h) generating a report indicating that the second health indicator has exceeded the second threshold.

8. 8. The method of claim 7, wherein the second health indicator represents a plurality of sensor data, and the report indicates one or more sensor data that most contributed to the second health indicator exceeding the second threshold.

9. 10. The method of claim 1, wherein the method is performed during approval of a process recipe.

10. 1. A method comprising: (a) receiving a recipe for a semiconductor manufacturing operation, the recipe including a plurality of steps, each step having one or more process parameters, each process parameter having a corresponding parameter value; (b) identifying a first step of the first recipe; (c) performing the first step using a manufacturing tool, wherein during the first step, one or more of the following cycles are performed: (i) identifying sensor data associated with performing the first step; (ii) determining one or more health indicators based on the sensor data; and (iii) modifying one or more process parameter values ​​of the first step based on the one or more health indicators and the sensor data; A method comprising:

11. The method of claim 10 , wherein the one or more health indicators each represent a plurality of sensor data.

12. The method of claim 10 , wherein the one or more cycles are performed until the health index converges to a maximum or minimum value.

13. 13. The method of claim 12, wherein the modified one or more process parameter values ​​are saved in the first recipe after the health indicators have converged.

14. 11. The method of claim 10, wherein the health index is also based on a baseline health index metric, the baseline health index metric being a health index associated with the first step for a previous execution of the first step.

15. 15. The method of claim 14, wherein the previous performance of the first step was by a manufacturing tool different from the manufacturing tool performing the first step.

16. 11. The method of claim 10, wherein modifying one or more process parameter values ​​of the first step is further based on the one or more health indicators exceeding a threshold.

17. 17. The method of claim 16, wherein modifying one or more process parameter values ​​of the first step is further based on the one or more health indicators exceeding the threshold for a predetermined period of time.

18. 11. The method of claim 10, wherein the one or more cycles are not performed during an initial period of performing the first step.

19. 11. The method of claim 10, further comprising generating a failure mode report for the first step of the recipe based on process parameters of the first step and sensor data collected during performance of the first step.

20. 20. The method of claim 19, wherein the first failure mode is indicative of one or more sensor data that contributed to the first health indicator exceeding a threshold.

21. 1. A system for optimizing a recipe, comprising: a process chamber; one or more processors, (a) receiving a recipe for a semiconductor manufacturing operation, the recipe including a plurality of steps, each step having one or more process parameters, each process parameter having a corresponding parameter value; (b) identifying a first step of the first recipe; (c) performing the first step in the process chamber, and during the first step, performing one or more of the following cycles: (i) identifying sensor data associated with performing the first step; (ii) determining one or more health indicators based on the sensor data; and (iii) modifying one or more process parameter values ​​of the first step based on the one or more health indicators and the sensor data; one or more processors configured to: A system including:

Images