Practical issues in the deployment of
`a run-to-run control system in a
`semiconductor manufacturing facility
`
`Stefani, Jerry, Anderson, Mike
`
`Jerry A. Stefani, Mike Anderson, "Practical issues in the deployment of a run-
`to-run control system in a semiconductor manufacturing facility," Proc. SPIE
`3742, Process and Equipment Control in Microelectronic Manufacturing, (23
`April 1999); doi: 10.1117/12.346250
`Event: Microelectronic Manufacturing Technologies, 1999, Edinburgh, United
`Kingdom
`
`Downloaded From: https://www.spiedigitallibrary.org/conference-proceedings-of-spie on 22 Jun 2021 Terms of Use: https://www.spiedigitallibrary.org/terms-of-use
`
`PROCEEDINGS OF SPIE
`
`SPIEDigitalLibrary.org/conference-proceedings-of-spie
`
`Applied Materials, Inc. Ex. 1017
`Applied v. Ocean, IPR Patent No. 6,836,691
`Page 1 of 14
`
`

`

`Downloaded From: https://www.spiedigitallibrary.org/conference-proceedings-of-spie on 22 Jun 2021
`Terms of Use: https://www.spiedigitallibrary.org/terms-of-use
`
`Practical issues in the deployment of a run-to-run control system in a
`semiconductor manufacturing facility
`Jerry A. Stefania d Mike Andersonb
`
`l'exas Instruments, Inc., MS 3701 , Dallas, Texas 75243 USA
`bAdvt Control Technologies, Inc., Dallas, Texas 75243USA
`
`ABSTRACT
`
`Run-to-run feedback process control for semiconductor manufacturing uses process models to relate the equipment
`settings to the wafer-state responses of interest. Engineers specify processes in terms of their desired wafer-state effects (the
`targets), and process models transform these targets into machine settings. To account for drifts and shifts in process
`behavior, the models are updated to match the current state of the equipment. These tuned, or adapted, models are used to
`calculate process adjustments to keep the wafer-state responses for subsequent wafers on target. Automatic recipe
`adjustments reduce wafer processing complexity, increase processing efficiency, and improve processing quality.
`
`Configuring an optimal control strategy for a particular process on a specific tool is fundamental to implementing
`run-to-run control in a semiconductor manufacturing environment. However, there is a significant effort involved to move
`from a standalone controller for a single process on a single tool to the deployment of a run-to-run control system across an
`entire area of the fab or across an entire fab. Some of the key issues include 1) communication between the run-to-run
`controller and existing factory systems and tool automation, 2) controlling multiple processes per tool and multiple
`chambers/tools per process, 3) handling non-production runs, and 4) non-constant data sampling due to metrology delays.
`
`ProcessWORKS, a factory-level run-to-run control architecture, originally developed at Texas Instruments and now
`a product of Adventa Control Technologies, can treat complex control problems in an automated, predictable, and repeatable
`fashion. ProcessWORKS is compatible with different techniques for data acquisition and analysis, model adjustment and
`feedback, and model optimization. ProcessWORKS is also designed to deal with practical implementation issues in the fab.
`In this talk we will review the benefits of ProcessWORKS run-to-run control. We will discuss some practical problems in the
`deployment of run-to-run control in the fab, and we will show how ProcessWORKS deals with these issues. Examples from
`the deployment of ProcessWORKS at Texas Instruments on state of the art semiconductor technologies will be given.
`
`Keywords: ProcessWORKS, run-to-run process control, advanced process control, model-based process control,
`semiconductor manufacturing, factory-level advanced process control
`
`1. INTRODUCTION
`
`Advanced process control (APC) has been recognized as an enabling technology for meeting the increased
`processing efficiency and product quality demands which will drive the future profitability of semiconductor manufacturing
`facilities. The building blocks of an advanced control system are industrial-quality APC methods, sensor and diagnostic
`technologies, and integration tools. The introduction of new sensors and process diagnostic tools, the maturation of existing
`technologies in these areas, and the development of integration tools and methodologies are making the application of APC
`methodologies a reality for the industry. One focus area for the application of APC techniques is run-to-run (RtR) model-
`based process control'8. RtR process control is in the final development stage, with initial results demonstrating significant
`improvement in wafer processing efficiency and product quality (in terms of increased process capability, decreased product
`scrap, test wafer savings, reduced machine downtime, and increased wafer throughput).
`
`Semiconductor processing is usually done with equipment-dependent, fixed recipes. The resulting wafer-state
`measurables are typically tracked using statistical process control (SPC) techniques. SPC detects deviations in the process
`above the noise in the system which are due to a sustained anomalous behavior of the equipment. When SPC discovers an
`"out-of-control" situation, the process is re-centered via engineering intervention, or the hardware is cleaned up and
`
`52
`
`Part of the EUROPTO Conference on Process and Epuiment Control in Microelectronic
`Manufacturing • Edinburgh. Scotland • May 1999
`SPIE Vol. 3742 . 0277-786X/99/$1O.OO
`
`Applied Materials, Inc. Ex. 1017
`Applied v. Ocean, IPR Patent No. 6,836,691
`Page 2 of 14
`
`

`

`Downloaded From: https://www.spiedigitallibrary.org/conference-proceedings-of-spie on 22 Jun 2021
`Terms of Use: https://www.spiedigitallibrary.org/terms-of-use
`
`recommissioned in hopefully the original in-spec state. By eliminating the option of control actions, however, SPC excludes
`opportunities for reducing the variability in the output of a process. Indeed, such control actions are sometimes so clearly
`needed that they are practiced together with SPC, but in an ad hoc manner. Examples are the retuning of a process after a
`maintenance operation and adjusting for gradual drifts in the process such as those caused by the aging of reactor components
`and consumables. It would be better to monitor the process on a run to run basis and make small adjustments to the
`equipment settings to keep the wafer-state responses on target. These process adjustments, or feedback control, increase
`machine uptime by producing more good product prior to an "out-of-control" condition. Simultaneously, process capability is
`increased.
`
`RtR feedback process control uses process models to relate the equipment settings to the wafer-state responses of
`interest. Engineers specify processes in terms of their desired wafer-state effects (the targets, such as film thickness), and
`process models transform these targets into machine settings (e.g., deposition time). The models are updated to track drifts
`and shifts in process behavior. These tuned, or adapted, models are used to calculate process adjustments to keep the wafer-
`state responses for subsequent wafers on target. In the old paradigm fixed machine settings resulted in higher variability in
`product quality while maintaining minimum variability in operating conditions. In the new paradigm the variability in output
`quality is reduced at the cost of increased variability in operating conditions.
`
`RtR process control often results in reduced wafer processing complexity, increased processing efficiency, and
`improved processing quality. The reduced complexity arises because the controller separates the process and machine
`dependencies, thereby allowing the operators the freedom from monitoring these differences themselves. The process model
`captures the process dependency, and model tuning captures the machine dependency. The increased efficiency is due to the
`decreased number of test runs required to effectively control a process. Model tuning is accomplished with data from
`production-based monitors, eliminating the need for test runs. Reduced test runs and inspection time result in increased
`equipment availability and decreased manufacturing cycle time. Finally, the separation of process variation from machine
`variation allows the controller to better estimate the machine state and utilize this information to increase the product quality.
`Increased product quality is associated with improved process performance, such as process capability, or Cpk.
`
`The ProcessWORKS advanced process control system, a product from Adventa Control Technologies, Inc.,
`performs run-to-run model-based process control for semiconductor manufacturing equipment. Over the last five years, the
`ProcessWORKS system has evolved from isolated implementations of RtR process control in Texas Instruments wafers fabs
`to a solution for advanced process control across TI. The primary thrust of ProcessWORKS deployment in TI wafers fabs
`now is as a factory-level tool, integrated with our existing manufacturing execution system (MES).
`
`Configuring an optimal control strategy for a particular process on a specific tool is fundamental to implementing
`RtR control in the wafer fab. However, there is a significant effort involved to move from a standalone controller for a single
`process on a single tool to the deployment of a RtR control system across an entire area of the fab or across an entire fab.
`Some of the key issues that have arisen include integration with existing factory equipment and MES, comprehending
`multiple processes/machines/products, working with different equipment configurations such as multi-chamber, single wafer
`tools, and comprehending non-production runs, measurement delays, and data correction. Satisfactory resolution of these
`issues is critical to the success of a RtR control system. Along the way, ProcessWORKS has incorporated the lessons learned
`form the deployment of a run-to-run control system in production wafer fabs at TI. ProcessWORKS is now a market-ready
`semiconductor solution for advanced process control.
`
`In this paper, we will cover practical implementation issues for a RtR process control system in a production wafer
`fab. In Section 2 we provide a brief explanation of RtR model-based process control and its benefits. This explanation leads
`to a description of the ProcessWORKS advanced process control system. We then discuss in Section 3 practical issues for the
`deployment of ProcessWORKS in wafer fabs. Examples from the deployment of ProcessWORKS at Texas Instruments on
`state of the art semiconductor technologies will be given in Section 4.
`
`53
`
`Applied Materials, Inc. Ex. 1017
`Applied v. Ocean, IPR Patent No. 6,836,691
`Page 3 of 14
`
`

`

`Downloaded From: https://www.spiedigitallibrary.org/conference-proceedings-of-spie on 22 Jun 2021
`Terms of Use: https://www.spiedigitallibrary.org/terms-of-use
`
`2. EXPLANATION OF RUN-TO-RUN PROCESS CONTROL AND ITS BENEFITS
`
`2.1 Run to run feedback process control defined
`
`Supervisory control of film thickness using time as the manipulated variable is the most common example of RtR
`process control for semiconductor processing. Its popularity is due to a general lack of real-time process endpointing sensors
`for deposition processes. In addition, film thickness metrology is widespread and relatively fast. The control may or may not
`be automated, e.g., it may be equations written in a lab operations book for the operator to transact on a calculator. The goal
`of RtR process control is to automate these existing control methods.
`
`Figure 1 shows measured film thickness (optical) versus time for a representative oxidation process used to grow
`films of various thicknesses. To control this process, an engineer typically maintains an estimate of the oxidation time for
`each target. Process times are adjusted to account for equipment disturbances. Monitor wafers are usually measured to keep
`track of the process behavior at each target. Depending on the frequency of wafer starts at each target thickness, test runs are
`often required to keep times updated. Test runs are expensive and time-consuming. RtR process control can automate the
`procedure and eliminate test runs.
`
`0
`
`ii
`
`..
`
`0•
`
`130
`
`•-
`
`-
`
`- —---....-
`
`120
`
`110
`
`..
`100
`
`90
`
`.c
`I,-
`4)
`•D
`0 8O-i-
`!
`.
`703
`
`60
`
`50
`
`a
`
`U
`U
`
`5
`
`10
`
`15
`
`20
`
`30
`25
`35
`Oxidation Time (mm)
`
`40
`
`45
`
`50
`
`55
`
`Figure 1. Measured oxide thickness (A) versus oxidation time (minutes) for furnace oxidation.
`
`Figure 2 provides a simple illustration of RtR model-based process control for a linear system with no noise and no
`model mismatch (i.e., the slope of the original model equals the slope of the true model). The solid line is the original (un-
`tuned) model (Output (y) = m.x + b, where x is a setting.) The model is solved to determine which value of x will give an
`output equal to the target value of 12 (x = (12-b)/m = 2.3). Wafers are run at this input value. Suppose the measured output
`is lower than the expected value (target) due to machine aging which occurred subsequent to model creation. The model is
`then updated by adjusting b, the constant term, so that the model would predict the output values measured (Tuned output =
`m.x + tuned b, i.e., the dashed line in Fig. 2.) The model is re-solved, and wafers are run at the new setting. Now the
`measured output is on target. While Fig. 2 is a simplistic example, this method has been extensively demonstrated to work for
`the situation of non-linearity, noise, and model mismatch. It is the constant term which is assumed to need tuning in Fig. 2.
`In more complicated model-based control methods, some of the other coefficients, or gains (e.g., the slope), may also be
`tuned.
`
`54
`
`Applied Materials, Inc. Ex. 1017
`Applied v. Ocean, IPR Patent No. 6,836,691
`Page 4 of 14
`
`

`

`Downloaded From: https://www.spiedigitallibrary.org/conference-proceedings-of-spie on 22 Jun 2021
`Terms of Use: https://www.spiedigitallibrary.org/terms-of-use
`
`Original Model
`
`Adapted Model
`
`Original Recipe
`
`Re-solved
`
`Output (Measured Value)
`18
`
`16
`
`14
`Target 12
`10
`
`8 6 4 2 0
`
`0
`
`1
`
`2
`
`3
`
`4
`
`5
`
`6
`
`input (Setting on Machine)
`
`Figure 2. Illustration of model-based process control.
`
`Figure 3 shows an architecture for a model-based RtR controller. At the center of this architecture is the process
`model itself. The model is optimized to meet desired goals based upon a chosen solution strategy (e.g., tradeoffs between
`different goals, input step size between runs, etc.) and any feedforward data (the results from earlier processes). The
`predictions are compared to the measured data, and the model is tuned in accordance with an adaptation strategy. For any
`run, if the controller cannot solve within an acceptability range, or tune within an allowable range, or the data is not compliant
`with expected behavior, then the controller takes appropriate action (email/page engineer, shut down tool, etc.). The strategy
`of how to solve the model, what algorithms to use for data reduction, when to tune the model, how to tune the model, what
`
`Disturbance(s)
`
`New Model Parameter
`(offset)
`
`Figure 3. Model-based process control architecture.
`
`55
`
`Applied Materials, Inc. Ex. 1017
`Applied v. Ocean, IPR Patent No. 6,836,691
`Page 5 of 14
`
`

`

`Downloaded From: https://www.spiedigitallibrary.org/conference-proceedings-of-spie on 22 Jun 2021
`Terms of Use: https://www.spiedigitallibrary.org/terms-of-use
`
`other tests to perform, and all the various parameters involved in these methods, are all selected based upon the control
`system goals as decided by the engineer and the event for which control is needed. Fig. 3 forms the basis for the
`ProcessWORKS RtR process control system.
`
`2.2 Benefits of RtR process control
`
`The fitting of a model to the process data in Fig. 1 combined with process model updating in Fig. 2 offer a number of
`benefits in addition to reducing variability in the processing results (improves Ck). First, a single process model estimates the
`tool setting for all targets within a specified range. The result is that one model applies to all baseline targets as well as all
`non-standard targets. A process model, which describes the process dependency, eliminates the need for test runs at new
`baseline and new non-standard targets, resulting in increased equipment availability.
`
`Second, the process model is tuned using data for any target. Again, test runs can be eliminated because the process
`model is now always up to date. So even if wafers have not been run at one particular target for an extended time, the process
`model comprehends any process shifts or drifts during that time and will recommend an optimal setting for the next run. Non-
`standard targets are typically run infrequently. However, updating the process model eliminates the need for test runs for non-
`standard targets, as well.
`
`Another benefit of a model-based process control approach is that on tool requalification, only one test run is
`required to update the process model and return the tool to production. Only one test run is required because only one data
`point is needed to estimate the model offset in Fig. 2. Since a test run is now not required per target, a significant number of
`test runs can be saved and tool requal time is reduced.
`
`Operationally, with a RtR control system, manufacturing specialists in the wafer fab no longer have to make
`decisions on how to manually tweak process recipes, eliminating errors. Process engineers spend less time monitoring a large
`number of SPC charts and instead focus on a few charts to track process model performance, freeing up their time to do more
`important work.
`
`In addition, RtR process control reduces the overhead associated with tool recipes, MES specifications, etc. For a
`single process covering a range of targets, multiple tool recipes (which may differ only by a single setting value) have been
`replaced by a single recipe which applies to all targets. The new recipe now contains a parameter, instead of a value, for each
`controlled setting. The RtR control system provides an updated value of each controlled parameter, e.g. deposition time, at
`run time. Further time is saved for non-standard targets because not only is a new tool recipe not required for every new
`target, a new MES specification may not need to be written. As the process model allows the selection of any target across
`the model range, we have found that it makes sense to replace multiple MES specifications, one each for each non-standard
`target, by a single specification that covers all non-standard targets.
`
`3. PROCESSWORKS RUN-TO-RUN PROCESS CONTROL SYSTEM
`
`3.1 Software
`
`ProcessWORKS provides advanced process control for semiconductor manufacturing equipment. ProcessWORKS
`is a product of Adventa Control Technologies, Inc., which was formed as a spin-off of Texas Instruments in 1998. Advanced
`process control in ProcessWORKS is an umbrella that encompasses RtR process control and fault detection and classification
`(FDC). FDC can take many forms in ProcessWORKS, from traditional process monitoring techniques such as statistical
`process control (SPC) to advanced multivariate analysis based on trace data. To date, the primary thrust of ProcessWORKS
`RtR process control deployment has been as a factory-level tool, integrated with TI's existing factory MES system. As a RtR
`control system, ProcessWORKS' architecture is a proven success. ProcessWORKS is also now being integrated with
`ControlWORKS and other tool controllers to provide APC at the equipment level, which will enable wafer-to-wafer process
`control and FDC based on large amounts of data.
`
`56
`
`Applied Materials, Inc. Ex. 1017
`Applied v. Ocean, IPR Patent No. 6,836,691
`Page 6 of 14
`
`

`

`Downloaded From: https://www.spiedigitallibrary.org/conference-proceedings-of-spie on 22 Jun 2021
`Terms of Use: https://www.spiedigitallibrary.org/terms-of-use
`
`supports a variety of deployment configurations to meet specific factory user needs related to hardware (isolated versus
`networked), system integration (stand-alone versus integrated with other systems or equipment), and operational mode
`(manual versus automated). While the ideal might be integration down at the tool level, there are issues raised regarding
`communication with factory-level systems to achieve feedforward and feedback control across different areas in the fab, for
`instance between etch and photolithography. A reasonable approach is to provide many integration options to choose from.
`
`ProcessWORKS allows various modes of operation ranging from a stand-alone implementation to full integration
`with current automation systems and processing tools. The software supports a variety of architectures and configurations
`which helps ease the implementation process. For example, one option is to install ProcessWORKS on a factory network
`which makes the application available to a large number of users, and many pieces of equipment can be controlled by a single
`ProcessWORKS server. Engineers utilize ProcessWORKS at their desks to create, optimize, and validate new control
`strategies, as well as maintain existing strategies, and view processing results. Operators in the wafer fab use ProcessWORKS
`to view recommended process settings, collect process run data, and view process control results in the form of charts and
`reports. No interfacing to other fab equipment or systems is required. This configuration is the most basic. It allows quick
`start-up and evaluation of ProcessWORKS features and benefits without reliance on interfacing to other systems. This
`configuration presents minimal risk and disruption to existing manufacturing operations and material. The trade-off
`associated with this implementation compared to a more sophisticated deployment is that data collection and control actions
`must be implemented manually by the user.
`
`The integration solution for a run-to-run control system in TI wafers fabs, Figure 4, starts with a server system
`running ProcessWORKS networked to multiple ProcessWORKS clients as in the prior scenario. TI wafer fabs also possess a
`robust integration environment which automates the transfer of data back and forth between the process equipment, metrology
`equipment, and the components of the factory MES. Combined with the necessary level of logical integration with these other
`systems, the networked ProcessWORKS configuration interacts with the factory MES during material processing to establish
`runtime context (machine and material identifiers, process targets, etc.), and the equipment to automatically deliver the recipe
`with settings calculated by ProcessWORKS. Fab personnel no longer edit tool recipes to adjust controlled settings, reducing
`errors (all controller parameters are protected by user-defined limits). After the material has been processed, ProcessWORKS
`obtains process feedback in the form of run data from the process tool and wafer-state measurements from a downstream
`metrology tool.
`
`• System Config
`• Create/Maintain
`Control
`Strategies
`• View results
`
`ProcessWORKS
`Server/Database
`
`Process
`Tool
`
`Metrology
`Tool
`
`Figure 4. Integrated run-to-run process control at Texas Instruments.
`
`57
`
`Applied Materials, Inc. Ex. 1017
`Applied v. Ocean, IPR Patent No. 6,836,691
`Page 7 of 14
`
`

`

`Downloaded From: https://www.spiedigitallibrary.org/conference-proceedings-of-spie on 22 Jun 2021
`Terms of Use: https://www.spiedigitallibrary.org/terms-of-use
`
`3.2 ProcessWORKS primary functions
`
`To initiate RtR process control, an engineer begins by setting up the control strategy. The control strategy is defined
`via the configuration user interface. Feedforward control is based on the material or machine history. Feedback control relies
`on a data collection mechanism. A built-in optimizer supports multi-input, multi-output models. Generally, models are
`adjusted every production run using a weighted average of the measured drift in the process starting from some known model
`state. This technique is commonly referred to as EWMA (exponentially-weighted moving-average). The EWMA controller
`effectively smoothes out the past data every run in order to best estimate the current process state. ProcessWORKS allows
`engineers to customize their controller by designing their own tuning expressions (for more advanced approaches).
`
`Once the control strategy has been configured, an Engineering Change Notice (ECN) system in ProcessWORKS
`provides a formal mechanism for the review and signoff of changes to controller configurations, which reduces the risk to
`production when changes are made. ECNs are required to obsolete or modify existing control strategies. ProcessWORKS
`provides full storage of revision histories.
`
`Prior to control strategy activation, the ProcessWORKS Model Solver can be used to test the strategy to ensure that
`ProcessWORKS will solve for the controlled settings as expected. Modifications to the strategy may need to be made at this
`point to achieve the desired behavior. In addition to verifying the model, the ProcessWORKS Simulator allows the control
`strategy to be run in test mode to try model tuning strategies before putting them on-line, reducing the risk to production
`operations. The simulator accepts user-specified run data or data generated based on user-specified parameters (noise, gain,
`offset, etc.). Simulation results are viewed with charts and reports.
`
`Once simulations have been completed, the control strategy is ready for production. ProcessWORKS supports data
`collection via graphical user interface, and automated data collection via CORBA, HSMS, and Adventa's own AutoShell.
`Batch and time series data are accepted. Flexible charting and reporting allows easy creation and display of charts and reports
`showing actual run data which assists engineers in monitoring the process and investigating process history. The charting and
`reporting capability in ProcessWORKS provides line, scatter, step, and Box-and-Whiskers charts, histograms, query on run
`attributes, highlighting of chart points based on run attributes, point-and-click to see detailed run summary, and data export to
`external analysis systems (Excel, SAS, RS/1, etc.). In addition to charts and reports, ProcessWORKS provides an advanced
`analysis tool called Overseer which tests model parameters for a single machine or across a group of machines and identifies
`trends, or patterns, in model adjustments over long periods of time. Overseer gives warnings if the model is approaching
`unacceptable limits, thereby giving the process engineer early indications of problems in the equipment or in the process
`model.
`
`4. IMPLEMENTATION ISSUES
`
`There are a number of hurdles to overcome to successfully deploy a run-to-run controller such as ProcessWORKS
`across a wafer fab. In this section we discuss some of these barriers. We also present solutions to these issues within the
`architecture of the ProcessWORKS advanced process control system.
`
`4.1 Factory integration of a RtR control system
`
`Perhaps the single biggest concern in the deployment of a run-to-run controller is the integration of the control
`system with the existing factory equipment and manufacturing execution system. The RtR controller must communicate with
`the factory equipment and MES to perform the following tasks:
`.
`Download the process goals from the MES to the controller,
`• Download the computed settings to the equipment,
`• Upload process information from the tool, e.g., actual setting, to the controller,
`• Upload wafer-state responses from metrology tool data to the controller.
`
`The integration of the RtR controller with the factory can take on many different looks depending on the level of
`integration between the process equipment and the components of the factory MES. A production-worthy RtR control system
`
`58
`
`Applied Materials, Inc. Ex. 1017
`Applied v. Ocean, IPR Patent No. 6,836,691
`Page 8 of 14
`
`

`

`Downloaded From: https://www.spiedigitallibrary.org/conference-proceedings-of-spie on 22 Jun 2021
`Terms of Use: https://www.spiedigitallibrary.org/terms-of-use
`
`The ProcessWORKS Application Programming Interface (API) is available in three protocols: CORBA (Common
`Object Request Broker Architecture), HSMS (High-Speed SECS Messaging Service), and Adventa's own AutoShell.
`AutoShell is built on top of AutoNet. Both AutoNet and AutoShell were developed at Texas Instruments for use in their
`semiconductor wafer factories for integrating processing equipment and host computers.
`
`4.2 Multiple processes/machines and ProcessWORKS partitioning
`
`4.2.1 Run partitioning
`
`After the run-to-run control system has been integrated satisfactorily into the wafer fab, a number of other important
`issues related to configuring the controller arise immediately. First, semiconductor processes typically run on more than one
`tool. And even though each tool may be represented by the same model form, e.g., y =m.x + b, each machine will behave
`somewhat differently in the short and long term. That is, the model coefficients will be different over time for two different
`tools. Thus, it is important that each machine running the process be controlled separately. Not only does a single process
`run on multiple tools, but multiple processes can run on one machine. Again, each process on a machine may also have to be
`controlled separately. In general, the RtR control system must be able to handle multiple processes running on multiple tools.
`
`ProcessWORKS is designed to solve control problems for large numbers of similar tools in the fab each running
`multiple processes. The problem of controlling one process running on multiple tools can be handled with a single control
`strategy in ProcessWORKS. Two powerful features of ProcessWORKS are partitioning and indexing. Control strategies in
`ProcessWORKS are organized by reference indices. For instance, a silicon nitride LPCVD furnace process might have a
`control strategy with indices Machine - FurnaceOl, Material - Nitride, and Action - LPCVD. Assume the same process is also
`used to run wafers on FurnaceO2 and FurnaceO3. ProcessWORKS allows a single control strategy with indices Machine -
`FurnaceOl, FurnaceO2, FurnaceO3, Material - Nitride, and Action — LPCVD.
`
`Suppose the three furnaces above have slightly different starting values for the model parameter b. It also makes
`sense that the long-term process dynamics will differ for each furnace. ProcessWORKS uses control histories to store
`material processing events, or runs. A control strategy's history can be partitioned by Machine to enable independent tracking
`of the model parameters for each of the three furnaces that use that control strategy (Figure 5). That is, the value of the model
`parameters are updated independently from one another using in each case only run data specific to that furnace. At run time,
`the appropriate value of the model parameter to use to compute process settings are identified by the value of Machine passed
`to ProcessWORKS. In this way, regardless of the number of tools that run a specific process, control is maintained within a
`single ProcessWORKS document. New tools that run the same process that are brought on line later can easily be added to
`the existing control strategy by simply adding a new Machine index to the list, and the system will automatically create a new
`run partition the first time the new machine is used at runtime.
`
`4.2.2 Tuning partitioning
`
`In the example above for silicon nitride LPCVD, the system creates a separate control history partition for each
`furnace. In ProcessWORKS, control histories do not share data across run partitions. That is, data used to tune the process
`model for FurnaceOl cannot be used to update the process model for FurnaceO2. Consider another example, though, where
`we do want to share data across multiple process models. Suppose nitride LPCVD is done at 600°C and 700°C on FurnaceOl.
`And assume that we know that a shift of in the 600°C process model on FurnaceOl results in an equal shift in the 700°C
`process model on Furnace02, and vice versa. ProcessWORKS can tune multiple process models within one control strategy
`simultaneously.
`
`Adjustments to model parameters, or tuning events, are stored in tuning histories associated with the model
`parameter. Model parameter tuning histories can be partitioned similar to control histories. In our example we could
`partition the tuning history for a model parameter by a general purpose index called Group that would represent the two
`different processes, 600°C and 700°C. ProcessWORKS allows tuning across model parameter tuning partitions, so that a
`single run, of either process, could generate an adjustment for both processes. Fig. 5 shows a tuning history partitioned by
`Group for the 600°C and 700°C processes.
`
`59
`
`Applied Materials, Inc. Ex. 1017
`Applied v. Ocean, IPR Patent No. 6,836,691
`Page 9