PROCEEDINGS OF SPIE
`
`SPIEDigitalLibrary.org/conference-proceedings-of-spie
`
`Integration of the APC framework
`with AMD's Fab25 factory system
`
`Bushman, Scott, Campbell, William, Miller, Michael
`
`Scott Bushman, William Jarrett Campbell, Michael L. Miller, "Integration of the
`APC framework with AMD's Fab25 factory system," Proc. SPIE 3882,
`Process, Equipment, and Materials Control in Integrated Circuit Manufacturing
`V, (3 September 1999); doi: 10.1117/12.361323
`Event: Microelectronic Manufacturing '99, 1999, Santa Clara, CA, United
`States
`
`PDF Solutions v Ocean Semiconductor, IPR2022-01196
`PDF Exhibit 1006, Page 1 of 8
`
`

`

`Integration of the APC Framework with AMD's Fab25 Factory System
`Scott Bushman*, Jarrett Campbell, Michael Miller
`Advanced Process Control Group, Advanced Micro Devices, MS608, Austin, TX 78741
`ABSTRACT
`This paper discusses the integration and development of advanced process control technologies with AMD's Fab25 factory
`systems using the Advance Process Control Framework. The Framework is an open software architecture that allows the
`integration of existing factory systems, such as the manufacturing execution systems, configurable equipment interfaces,
`recipe management systems, metrology tools, process tools, and add-on sensors, into a system which provides advanced
`process control specific functionality.
`The Advanced Process Control Framework project was formulated to enable effective integration of Advanced Process
`Control applications into a semiconductor facility to improve manufacturing productivity and product yields. The main
`communication link between the factory system and the Framework is the Configurable Equipment Interface. It interfaces
`through a specialized component in the framework, the Machine Interface, which converts the factory system communication
`protocol, ISIS, to the Framework protocol, CORBA. The Framework is a distributed architecture that uses CORBA as a
`communication protocol between specialized components.
`A generalized example of how the Framework is integrated into the semiconductor facility is provided, as well as a
`description of the overall architecture used for process control strategy development. The main development language,
`Tcl/Tk, provides for increased development and deployment over traditional coding methods.
`Keywords: Advanced Process Control, CIM, APC Framework, Control Systems, Run-to-Run Control, Fault Detection and
`Classification, Systems Architecture, CORBA
`
`1. INTRODUCTION
`Advanced process control (APC) is the technique ofmanipulating recipe parameters in batch processing to achieve a desired
`target. In semiconductor manufacturing, the most common implementation is to perform run-to-run control on each batch, or
`lot, of wafers. AMD identified the need for a standard software integration solution to support APC in the facility, and so
`" 2,
`pursued a NIST ATP grant to facilitate the development of the Advanced Process Control Framework Initiative
`3, 4
`
`In Fab2S, the APC Framework has been used in several control projects, including run-to-run control ofoxide thickness after
`the chemical-mechanical planarization process and minimizing overlay errors in the photolithography module. It has also
`been used to emulate the controller used to control critical dimension in the polysilicon gate process. The framework
`capability can be extended through the use of plugin modules for third party packages such as Matlab and Mathematica,
`providing the control engineer the flexibility and capability of implementing advanced algorithms through a familiar
`interface. On the manufacturing side, an operator interface component is available to allow interaction with the factory floor
`via customizable dialog boxes.
`
`2. APCFI PROJECT
`The goals of the APCFI were outlined in the program proposal presented to NIST (National Institute for Standards and
`Technology) in October 1995. These goals were to: enable effective integration of "Advanced Process Control" applications
`into a semiconductor facility to improve manufacturing capital productivity, product consistency, and product yields;
`establish integration technology for multi-supplier "Plug-and-play" APC applications; and to demonstrate commercial
`viability of the APC Framework and its components. To sum up, the main goal of the APCFI projects was to develop a
`
`Correspondence: Email: scott.bushman@amd.com; Telephone: 512 602 0777; Fax: 512 602 2571
`
`Part of the SPIE Conference on Process, Egupment, and Materials Control
`in Inteqrated Circuit Manufacturing V. Santa Clara, California • September 1999
`SPIE Vol. 3882 . 0277-786X/99/$1 0.00
`
`55
`
`PDF Solutions v Ocean Semiconductor, IPR2022-01196
`PDF Exhibit 1006, Page 2 of 8
`
`

`

`system that would significantly reduce the time, cost, and integration efforts needed to deploy APC solutions. A conceptual
`view of the Framework's role in the facility is shown in Figure 1.
`
`Figure 1: Overview of the APC Framework in the MIS.
`In order to ensure compatibility with equipment in use today and in the future, the APC Framework is based on the
`SEMATECH CIM Framework specifications and allows for machine communications through the SEML'GEM
`Semiconductor Equipment Communication Standard (SECS). This feature of the APC Framework allows for easy
`integration with legacy manufacturing equipment.
`The scope of the APCFI projects includes support for Feed-forward and Feedback Run-to-Run control and Fault Detection
`applications spanning multiple processes and fabrication tools and utilizing 3rd..p control software, such as Modeiware®,
`Matlab®, Matlab Toolkits, Mathematica, and LabView®.
`Although the original NIST funded APC Framework Initiative has been completed, several other projects with multiple
`companies have been announced --including a second NIST project with National Instruments which will build on the APC
`Framework.
`
`3. OVERVIEW OF APC FRAMEWORK
`The APC Framework has been designed to work along with a factories' MES (Manufacturing Execution System --for
`example, WorkStream by Concilium) and Configurable Equipment Interface (CEI) to provide APC functionality. It is
`composed of not one large program, but a number of smaller, specialized pieces that work together in a distributed
`architecture. The "interchangeable parts" of the APC Framework are called components. These components are analogous to
`stereo components, where each component is
`I . An independently running entity
`2. Provides a subset ofthe overall APC Framework functionality
`3. May be provided by a different vendor
`The APC Framework standard describes the functionality, interface, and behavior of each component. The components of
`the APC Framework communicate via the CORBA protocol, and are shown in Figure 2.
`
`56
`
`PDF Solutions v Ocean Semiconductor, IPR2022-01196
`PDF Exhibit 1006, Page 3 of 8
`
`

`

`APC Framework Components
`
`I
`
`-
`
`APC Framework Services
`APC Framework Infrastructure
`
`I
`
`The main components ofthe framework include the Plan Execution Manager (PEM), Plan Manager (PM), Machine Interface
`(MI), Operator Interface (01), Plugin Management (PIM), and Data Store (DS). The PEM coordinates the execution of user-
`defmed process control pians among all the APC components for a given semiconductor machine. Its main responsibility is
`to interpret the Tcl/Tk commands in a given control script, performing the operation defmed by the script. Although the
`script can perform a number of different functions, in most cases they perform two main objectives: 1) generation of
`controlled settings for a processing tool, or 2) manipulation of data from a metrology tool. Each of these scripts can call
`other components in the framework, such as the plugin manager (PIM) or the operator interface (01) to perform a specialized
`function. It is also common for the script to store and retrieve data from the APC database, symbolized by the Data Store
`(DS) component.
`Other than the main components listed above, there are a number of components that serve as infrastructure for the CORBA
`services, such as the Naming service, the Registry, and the Signoff Manager.
`
`4. INTEGRATION WITH THE FACTORY
`In AMD's Fab2S, the main communication link between the equipment and the factory system is the Configurable Equipment
`Interface (CEI). Each of the factory systems, whether the Manufacturing Execution System, for example, Workstream, or the
`Recipe Management System (RMS), interact with the physical equipment in the facility through the CE!. The APC
`Framework system also communicates through the CE! through a specialized component called the machine interface (MI).
`The CE! makes two connections to the ISIS bus --one to support communications to Workstream and RMS, and the other to
`support interactions with the APC Framework, as shown in Figure 3. The function ofthe MI is to translate between the ISIS
`protocol used by the CE! and the CORBA protocol used by the rest of the APCFW. When the CEI wants to talk to the APC
`system, it communicates to the MI, and the MI relays the message on to the rest of the APC system. In a similar manner,
`when the APC system needs to send information to the CE!, it also must go through the MI.
`During the specification process for a process control strategy, the engineer specifies the data to be measured at metrology
`tool and the recipe parameters that will serve as manipulated variables for the processing tools. The standard CE! baseline
`code used at AMD contains the required support for communication with the APC Framework, and generally the only
`modifications which are required are changes to support receiving or setting the appropriate information on the tool, i.e.,
`implementing recipe modifications. To enable communication with the MI, a configuration variable is set to 'true' and the
`CE! is restarted. The name of the MI on the ISIS bus is given by <entity>MI. Once enabled, the standard interaction with the
`MI is performed through the 'run_apc' command.
`
`57
`
`PDF Solutions v Ocean Semiconductor, IPR2022-01196
`PDF Exhibit 1006, Page 4 of 8
`
`

`

`ISIS
`
`Other APC Framework Components
`
`Figure 3: TheCEI and MI Communication Path (ISIS Bus)
`Communication between the CEI and MI occurs after the recipe information has been retrieved from RMS, but before the
`process or metrology equipment is setup (step 0 and 1). The CEI then passes the contextand parameter set information to the
`MI with the 'run_apc' command, as shown in Figure 4. The MI passes the information to other APC components for action --
`either preparing to receive data from metrology equipment, or to calculate recipe parameters for processing equipment. The
`context information is used by the Plan Manager to determine which APC Plan will be used (step 2). The Plan Executor then
`runs the Tcl/Tk script defmed associated with that plan. The APC components return parameter set information tothe MI that
`is passed to the CEI through the 'apc_data' command (step 3), and also communicates when the APC system is prepared to
`receive data, if appropriate (steps 4 and 5). The CEI downloads the recipe to the processing tool with any parameter updates
`and begins processing (step 6). If data events are returned from the tool (step 7), they are communicated to the APC system
`through the MI.
`
`0. download
`execute
`
`6.
`
`4. setup/enable data
`5. setup/start machine
`
`Other APC
`Components
`Figure 4: Tnteraction Diagram between CE! and MI.
`In addition to the communication described above, interaction between the factory floor and the APC Framework can be
`performed through the Operator Interface (01) component. Part of the context information passed to the APC system
`contains the display ID for the X-Terminal used by the operator and the 0! can popup dialog boxes on the factory floor, if
`required, as in Figure 3.
`
`58
`
`PDF Solutions v Ocean Semiconductor, IPR2022-01196
`PDF Exhibit 1006, Page 5 of 8
`
`

`

`5. GENERAL CONTROL METHODOLOGY
`In order to validate the design and implementation of the APC Framework, a number of control projects were selected for
`early deployment into one of AMD's semiconductor facilities using initial versions of the APC Framework. Under the
`implementation in Fab25, the APC Framework has been used for mn-to-run control of oxide thickness after the chemical-
`mechanical planarization (CMP) process and minimizing overlay errors in the photolithography module. The Framework has
`also been used to emulate the existing controller used to control critical dimension in the polysilicon gate process. Figure 5
`shows the flow of information in the generic feed-forward/feedback controller implemented in Fab25, which can be used to
`control a process such as CMP.
`
`\VJp
`
`ProcessToo1
`Recipe Select with
`updated Recipe
`Parameters
`
`LIIIIFI:IIII:::::
`Metro1ogy
`Pre-Thickness
`1 Measurements
`
`_______
`Metrology L
`I Post-Thickness
`1 Measurements
`
`AR* 1
`
`'I,
`•Feedforwarddata compensates for incoming thickness variations
`•Feedback data compensates for tool/process drift
`
`t
`
`4
`
`Figure 5: Generalized Run-to-Run Control of Semiconductor Fabrication Unit Operation
`In this example, metrology information from a previous operation is feed-forward to the current operation, where it and the
`targets are used to determine the appropriate recipe settings for the processing tool. Post-metrology information is used for
`feedback to refme the model for the next lot to run on the entity. This control strategy has three-steps, pre-metrology,
`processing, and post-metrology:
`1 . Before the pre-metrology operation is performed, the CEI contacts the APC system with the context and parameters for
`the lot to be measured. The Plan Execution Manager, which "choreographs" the APC scripts, generates a Plan Executor
`which processes the metrology event. The script contains commands that are sent to the CEI to setup the metrology tool
`to measure the data required for the control strategy and to receive the data collected by the CEI after the metrology
`operation is complete. At this point, the script can contain code to force the metrology to be repeated if required or to
`filter the metrology data, if appropriate. The metrology data is then stored to the Data Store (DS) in the APC
`Framework.
`2. At the processing operation, the CEI communicates the context for the lot, including targets from the recipemanagement
`system, to the APC Framework. The Plan Execution Manager generates a Plan Executor to interpret the TcI/Tk script to
`process the event. The script can pull feed-forward data from the Data Store or pop-up an operator interface, if the data
`is not available for the context passed by the CEI. Other information, such as the current model parameters for therun-
`to-run control model are also stored in the database and are used to compute the recipe parameters for the current lot.
`The manipulated variables are downloaded to the tool through the CEI, either by over-writing the appropriate recipe
`parameter or by selecting a predefmed recipe on the processing tool.
`3. After processing, the material is re-measured for the process parameter of interest. The Plan Executor interprets the
`Tcl/Tk script that contains instructions on how to update the model parameters from the post-metrology data, and then
`stores the new model parameters to the database.
`
`59
`
`PDF Solutions v Ocean Semiconductor, IPR2022-01196
`PDF Exhibit 1006, Page 6 of 8
`
`

`

`To support the goals ofthe APCFI project, it was necessary to develop a system that would be flexible enough to support just
`about any supervisory-level (e.g. Run-to-Run) control application. To this end, rather than trying to pre-defme a generic
`sequence of system interactions that would be used at mn-time, the project chose to use a scripting approach to allow the
`maximum flexibility in how the system was used. The Plan Execution Manager (PEM or PE) component is the
`"choreographer" ofthe APC Framework. It is in charge ofdoing "APC" at runtime for a particular process or metrology tool.
`To do this, it has the ability to access all of the capabilities of each of the other components in the APC Framework. It
`executes, or interprets, APC Plans (a collection of Tcl scripts), which specify the actions to be taken before and/or after a lot
`is processed on a manufacturing tool.
`The Tcl scripts defme not only what the APC Framework does, but the sequence in which it carries these actions out. The
`main development language, Tcl/Tk, provides for increased development and deployment over traditional coding methods, as
`it is a relatively simple scripting language to learn. The Tcl scripts provide the capability to extend the Framework through
`the use of plugin modules for third party packages such as Matlab and Mathematica, providing the control engineer the
`flexibility and capability of implementing advanced algorithms through a familiar interface, as shown in Figure 6.
`
`Matlab Script
`
`Dynamically-Loadable
`Library (DLL)
`
`Plugin Definition
`
`rtafdc2.dII
`
`000
`
`C-Code
`Fig 6: Adding a Plugin to the APC Framework
`
`6. SUPPORT MODEL
`The support model for the APC Framework is the same as other factory systems in Fab25. If a problem is experienced in the
`fab with the system, the wafer fabrication technician opens a trouble ticket with the main Operations Center in Fab25. The
`Ops Center can restart CEI servers or APC components, as required --or if necessary, escalate the problem to the CEI
`Technicians in the Factory Systems group. This is the same escalation procedure as with other factory systems, and this
`provides a consistent support model to the Ops Center. The CEI Technicians have been trained to handle systems problems
`and have the authority to restart APC components or computer systems. Further up the escalation chain are CEI Engineers
`who have specialized training to isolate problems that may happen in the APC Framework systems from those in the
`Configurable Equipment Interface. If the engineer suspects that the problem is related to application specific configuration,
`such as script or plugin code, the problem is escalated to the appropriate person in the APC group is called to investigate the
`problem.
`
`60
`
`PDF Solutions v Ocean Semiconductor, IPR2022-01196
`PDF Exhibit 1006, Page 7 of 8
`
`

`

`7. SUMMARY
`The integration and implementation of the existing APC Framework in Fab25 has been extremely successful, and migration
`of the APCFW applications to other AMD fabs (SDC and Fab3O) is underway. In addition, Fab25 is making preparations to
`migrate to the commercial APC Framework product from ObjectSpace (Catalyst).
`The purpose of this paper has been to describe how the APC Framework has been integrated to the factory systems through
`the Configurable Equipment Interface. This interface allows access to the recipe management systems in Fab25 and details
`about using this interface will be provided. A summary of the benefits ofusing the framework, including increased speed in
`deployment over traditional coding methods, scalability to multiple process and metrology tools, open architecture system
`developed on standards-based components and compatibility with existing systems was presented.
`
`8. REFERENCES
`I . ScottHawker, SEMATECH Computer Integrated Manufacturing (CIM) Framework Architecture Concepts, Principles,
`and Guidelines, version 0. 7, Technology Transfer #96123214A-ENG, SEMATECH, 1996.
`2. Michael L. Miller, W. Jarrett Campbell, and Thomas F. Edgar, "Run-to-Run Control ofMulti-Product Processes,"
`AICHE 1998 Annual Meeting, November, 1998.
`3. W. Jarrett Campbell, Chris H. Raeder, Valerie Wenner, and Thomas F. Edgar, "Multivariate Run-to-Run Control of
`Arm-to-Arm Variations in Chemical Mechanical Planarization", SPIE Microelectronics Manufacturing, September,
`1998.
`4. Michael L. Miller and Srikumar Kareti, "Using Tcl to Script CORBA Interactions in a Distributed System," in The Sixth
`Annual Tcl/Tk Conference Proceedings, pp. 191-198, September, 1998.
`
`61
`
`PDF Solutions v Ocean Semiconductor, IPR2022-01196
`PDF Exhibit 1006, Page 8 of 8
`
`