TWI495970B - Method and arrangement for detecting in-situ fast transient event - Google Patents

Description

Method and device for detecting in-situ fast transient event

The present invention claims priority to US Provisional Patent Application No. 61/222,102, entitled "Methods and Systems for Advance Equipment Control/Advance Process Control for Plasma Processing Tools", filed on June 30, 2009, inventor Venugopal The entire text is incorporated herein by reference.

This is a continuation of the U.S. Patent Application Serial No. 12/555,674, which is entitled "Arrangement for Identifying Uncontrolled Events at the Process Module Level and Methods Thereof", invented by Huang et al. On September 8, the U.S. Patent Application No. 61/222,024, the name of which is "Arrangement for Identifying Uncontrolled Events at the Process Module Level and Methods Thereof", the inventor is Huang et al. The application was filed on June 30, 2009, and the aforementioned two cases are hereby incorporated by reference.

This invention relates to plasma processing, and more particularly to methods and apparatus for detecting rapid transient events within a processing chamber during substrate processing.

Advances in plasma processing have brought growth to the semiconductor industry. To be more competitive, manufacturers must be able to handle substrates into high-quality semiconductor devices. Process parameters are often tightly controlled to achieve satisfactory results during substrate processing. When process parameters (eg, RF power, pressure, bias voltage, ion flow, plasma density, etc.) exceed a predetermined window, undesired processing results may be caused (eg, poor etch profile, low selectivity, Damage to the substrate, damage to the processing chamber, etc.). Therefore, in the semiconductor device process, it is important to recognize the ability to condition when the process parameters exceed a predetermined interval.

Certain uncontrollable events that may damage the substrate and/or cause damage to the process chamber components may occur during substrate processing. In order to identify these uncontrollable events, data can be collected during substrate processing. Materials associated with various process parameters (eg, bias voltage, reflected power, pressure, etc.) may be collected during substrate processing using a detection device (eg, an inductor). As used herein, an inductor means a device that can be used to detect the condition and/or signal of a plasma processing component. For convenience of description, the term "component" will be used to refer to an atom or multiple components in a processing chamber.

In recent years, the types of data and the amount of data collected by sensors have increased. By analyzing the data collected by the sensor related to the process module data and the processing content data (processing room event data), parameters exceeding the predetermined interval can be identified. Thus, corrective actions (e.g., recipe adjustments) can be provided to stop uncontrollable events, thereby further preventing damage to the substrate and/or process chamber components.

The present invention provides a method for detecting in-situ fast transient events that occurs during processing in a processing chamber during substrate processing. The method includes a set of sensors for comparing a data set with a set of standard values (in-situ fast transient events) to determine if the first data set contains potential in-situ fast transient events. If the first data set contains potential in-situ fast transient events, the method also includes storing electronic signatures that occur during the occurrence of a potential in-situ fast transient event. This method also includes comparing the electronic signature with a set of stored arc signatures. If the determination is met, the method further includes classifying the electronic signature as the first in-situ fast transient event, and determining the severity of the first in-situ fast transient event based on a predetermined set of threshold ranges.

The invention will be described in detail with reference to some embodiments shown in the accompanying drawings. In the following description, numerous specific details are set forth to provide a complete understanding of the invention. It will be appreciated by those skilled in the art, however, that the present invention may be practiced without some or all of the specific details. In other instances, well known process steps and/or structures are not described in detail in order not to obscure the invention.

Several embodiments are described below, including methods and techniques. It should be borne in mind that the present invention may also encompass an article of manufacture including a computer readable medium having computer readable instructions stored thereon for performing embodiments of the present technology. The computer readable medium can comprise, for example, a semiconductor, magnetic, magneto-optical, optical, or other form of computer readable medium for storing computer readable code. Furthermore, the invention may also encompass apparatus for carrying out embodiments of the invention. Such devices may include dedicated and/or programmable circuitry to perform the operations associated with embodiments of the present invention. Examples of such devices include general purpose computers and/or suitably programmed special purpose computing devices, and may include dedicated/programmable circuits and computer/computing device combinations for various operations associated with embodiments of the present invention. .

As noted above, in order to be competitive, manufacturers must be able to effectively and efficiently address issues that may arise during substrate processing. Troubleshooting often involves analyzing excess data collected during processing. To aid in the description, Figure 1 shows a prior art general logic diagram of an interconnect tool environment with a host analytics server.

Consider the situation, for example, the manufacturer may have more than one group tool (such as etching tools, cleaning tools, stripping tools, etc.). Each group tool can have a plurality of process modules, each of which is used for more than one specific process. Each group tool can be controlled by a group tool controller (CTC), such as CTC 104, CTC 106, and CTC 108. Each group tool controller can interact with more than one process module controller (PMC), such as PMCs 110, 112, 114, and 116. To simplify the description, examples related to PMC 110 will be provided.

In order to identify conditions that may require intervention, sensors may be used during substrate processing to collect data on process parameters (sensing data). In one example, during substrate processing, a plurality of inductors (eg, inductors 118, 120, 122, 124, 126, 128, 130, 132, 134, 136, 138, and 140) may interact with the process module controller Role to collect information about more than one process parameter. The type of sensor available can depend on the type of data that can be collected. For example, sensor 118 can be configured to collect voltage data. In another example, the sensor 120 can be configured to collect pressure data. In general, the sensors that can be used to collect data from the process modules can be of different brands, styles, and/or styles. Therefore, one sensor and another sensor can have little or no interaction.

Typically, sensors are configured to collect measurement data for more than one specific parameter. Since most of the sensors are not used to perform processing, each sensor can be connected to a computing module (eg, computer, user interface, etc.). A computing module is typically configured to process analog data and convert raw analog data to a digital format.

In an example, the inductor 118 collects voltage data from the PMC 110 via the inductor cable 144. The analog voltage data received by the inductor 118 is processed by the computing module 118b. The data collected by the sensor is transmitted to a host analytics server (eg, data box 142). Before the data is forwarded to the data box 142 via the network connection, the data is converted from the analog format to the digital format by the computing module. In one example, computing module 118b converts the analog data collected by sensor 118 into a digital format prior to transmitting the data to data cartridge 142 via network path 146.

The data box 142 can be a central analysis server for collecting, processing, and analyzing data from a plurality of sources, including sensors and process modules. Typically, a data cartridge can be used to process data collected by all group tools of a single manufacturer during substrate processing.

The actual amount of data that can be transferred to the data box 142 can be significantly less than the amount of data collected by the sensor. Typically, sensors collect large amounts of data. In one example, the sensor can collect data at a rate of up to 1 million bits per second. However, only a portion of the data collected by the sensor is transmitted to the data box 142.

One reason for not transmitting the entire data stream collected by the sensor to the data box 142 is due to network bandwidth limitations when using a cost effective commercial communication protocol. The network route to the data box 142 may not be processed from a plurality of sources (eg, sensors 118, 120, 122, 124, 126, 128, 130, 132, 134, 136, 138, and 140) to a single receiver (eg, A large amount of information in the data box 142). In other words, when the data cartridge 142 attempts to receive a large amount of data from all of the sensor devices, the network path between the sensor devices (sensors and computing modules) and the data cartridge 142 may experience large traffic congestion. As can be seen from the above, if the data box 142 cannot process the incoming traffic, the data packet in the transmission may be interrupted or needs to be retransmitted, thus placing an additional burden on the network route that has been severely blocked.

In addition, data box 142 may not be able to process large amounts of incoming data from multiple sources while performing other important functions, such as processing and analyzing data. As noted above, for example, the data box 142 is not only used to receive incoming packets, but is also used to process and analyze all incoming data streams. Since the data box 142 is an analysis server for different data streams in the collection, the data box 142 requires sufficient processing power to perform analysis on the excess data stream.

Since the processing resources of the data box 142 are limited, only some of the data collected from the respective sensors is transmitted to the data box 142. In one example, among the thousands of items that can be collected by a single sensor, only 10 to 15 items of items between 1 and 5 Hz can be sent to the data box 142. In an example, only a summary of the data collected by sensor 118 can be transmitted to data box 142.

In addition to receiving data from a plurality of sensors, the data box 142 can also receive data from the process module controller. In one example, process module data and process content data (process room event data) may be collected by each process module controller and sent to a data box 142. To simplify the description, the process module data and processing content data can also be referred to as process module and processing room data. For example, process module data and processing content data may be collected by PMC 110 and transmitted to CTC 104 via path 148. The CTC 104 not only manages data from the PMC 110, but also processes data from other process module controllers (e.g., PMC 112, PMC 114, and PMC 116) within the group tool.

The data collected by the group tool controller is then transmitted to the fab host 102 via a semiconductor device communication standard/general device module (SECS/GEM) interface. In one example, the CTC 104 transmits the data collected from the PMCs 110, 112, 114, and/or 116 to the fab host 102 via the path 150 through the SECS/GEM 156. For example, fab host 102 can receive data not only from CTC 104, but also from other group tool controllers (e.g., CTCs 106 and 108). The data collected by the fab host 102 is then sent to the data box 142 via path 158. Due to the sheer volume of data collected, not all of the data transmitted to the fab host 102 will be sent to the data box 142. In many instances, only a summary of the data can be transferred to the data box 142.

The data box 142 can process, analyze, and/or correlate the data collected by the sensors and process module controllers. For example, if an anomaly is identified, the data box 120 can then determine the source of the problem, such as a parameter that is inconsistent with the recipe steps performed in the PMC 110. Once the source of the problem has been identified, the data box 142 can transmit an interception message of the Ethernet message format to the fab host 102. After receiving this message, the fab host 102 can send a message to the CTC 104 via the SECS/GEM 156. The group tool controller can then transfer the message to the predetermined process module controller (PMC 110 in this example).

Unfortunately, blocked messages are usually not provided on the fly. Rather, the block message is typically received by the intended process module after the affected substrate has been processed or even after the entire substrate batch has left the process module. Thus, not only has the substrate/substrate batch been compromised, but more than one of the process chamber components may have been adversely affected, thereby increasing waste and increasing the cost of ownership.

One reason for the delay is due to the sheer volume of data received from excess sources. Even though the data box 142 can be configured with a fast processor and has sufficient memory to process a large volume of data, the data box 142 may still take time to process, correlate, and/or analyze all of the collected data.

Another reason for delaying the receipt of the block message by the process module is due to the incompleteness of the data stream received via the data box 142. Since the data box 142 will receive data from an excessive source, the actual data transmitted to the data box 142 will be significantly less than the collected data. In one example, instead of transmitting a 1 GHz data stream collected by the sensor 118, only a portion of the data (about 1-5 Hz) is actually transmitted. Therefore, even if the data box 142 receives a large amount of data from all its sources, the received data is usually incomplete. Therefore, in view of the fact that the data box 142 may not be able to access a complete data set from all sources, determining an uncontrollable event may be time consuming.

In addition, the path through which data is transferred to the data box 142 may vary. In one example, after the analog data has been converted to digital data, the data is transmitted directly from the sensor device (ie, the sensor and its computing module). Instead, the data collected by the process module is transmitted over a longer network path (at least via the group tool controller and the fab host). Therefore, the data box 142 does not complete its analysis until all relevant data streams have been received.

Not only is the network path between the process module and the data box 142 long, but the data stream transmitted through this path usually faces at least two bottlenecks. The first bottleneck is in the group tool controller. Since the data collected by the process modules in the group tool is transferred to the single group tool controller, the first bottleneck is generated because the data stream from each process module must be processed via a single group tool controller. In view of the large amount of data that can be transferred from each process module, the network path to the group tool controller typically experiences severe traffic congestion.

Once the group tool controller has received the data, this data is transmitted to the fab host 102. The second bottleneck may occur at the fab host 102. In view of the fact that the fab host 102 can receive data from various group tool controllers, traffic entering the fab host 102 can also experience congestion due to the large amount of data being received.

Since the data box 142 requires data from different sources to determine uncontrollable events, the flow conditions between the process module and the data box 142 can impede the timely delivery of data to the data box 142. Therefore, valuable time is wasted before the data box 142 has collected all the necessary data to perform the analysis. Furthermore, once it is ready to be blocked, the block message must be transmitted back to the affected process module through the same lengthy path before it can be used to perform the corrective action.

Another factor contributing to the delay is the challenge of associating data from various sources. Since the data stream received by data box 142 is typically a summary of the data collected from each sensor and/or process module, as such data streams may be acquired at different time intervals, correlating such data becomes challenging. task. In one example, the data stream selected by sensor 118 for transmission to data cartridge 142 may be spaced apart by one second while the data stream from PMC 110 may be spaced for two seconds. Therefore, it may take time to correlate the data stream before the uncontrollable event can be finally determined.

Another challenge with associating data is the different paths that pass through the data to the data box 142. When transferring data through different computers, servers, etc., the data may be exposed to computer drift, network latency, network load, and so on. Therefore, the data box 142 may be difficult to correlate data from various sources. In view of the need for tight correlation to quickly identify uncontrollable events, it may be necessary to perform more analysis before the uncontrollable events can be correctly identified.

Another disadvantage of the solution provided in Figure 1 is the cost of ownership. In addition to maintaining the cost of the group tool system, the additional cost is related to the sensor device. Since each sensor can be of a different brand/type/style, each sensor device typically includes a sensor and a computing module. Physical space is typically required to place each sensor device. Therefore, the cost of placing the sensor device can become very high, especially in areas with high real estate prices.

In order to reduce the actual time delay between the actual occurrence of uncontrollable events within the process module and the blocked recipe of the process module, the present invention provides a group hierarchy analysis server. 2 shows a simple block diagram of an interconnect tool environment with a group tool hierarchy solution for associating data between the sensor and the process module controller.

Similar to FIG. 1, the group tool can include a plurality of process module controllers (eg, PMCs 210, 212, 214, and 216). In order to collect data for analysis, each process module controller can be coupled to a plurality of sensors (eg, sensors 218, 220, 222, 224, 226, 228, 230, 232, 234, 236, 238, and 240). . Each sensor can interact with its corresponding process module controller via an inductor cable (eg, sensor cable 244) to collect process parameter data. The data collected by the sensor can be in analog format. A computing module (e.g., computing module 218b) can process and convert the data into a digital format prior to transmitting the data via path 246 to a group analytics server (e.g., remote controller 242).

Similar to Figure 1, each process module controller can also transfer data (such as process module data and process content data) to group tool controllers (e.g., CTCs 204 and 206). In an example, the data collected by the PMC 210 can be transmitted to the CTC 204 via path 248. In addition to receiving data from the PMC 210, the CTC 204 can also receive data from other process module controllers (e.g., PMCs 212, 214, and 216). The data received by the group tool controller is then sent to the fab host 202 via path 250.

Between the fab host 202 and the CTC 204, a sequence tap can be coupled to the network path 250 to replicate the data sent to the fab host 202. In one example, the sequence tap 208 can intercept data sent by the CTC 204 to the fab host 202. This material will be copied and a copy of the data stream will be transmitted to remote controller 242 via path 254. If the fab host is connected to more than one group tool controller, the dedicated remote controller will be associated with the group tool controller for each group tool controller. In one example, the data transmitted from the CTC 206 to the fab host 202 via the path 252 is intercepted by another sequence tap (256). This material is copied and transmitted via path 258 to the remote controller (260), which is different from the remote controller (242) associated with the CTC 204.

Thus, multiple remote controllers can be utilized to process data from various group tools, replacing a single data box for processing all of the data from each group tool. In other words, each group tool is associated with the remote controller it owns. Since each remote controller will process data from a small number of data sources, such as process module controllers and sensors coupled to a single group tool, each remote controller can handle a larger amount from each source. data. In one example, instead of 30-100 data items in the transmission, each remote controller can now receive data items of approximately 40 kB to 100 kB at 10 Hz.

The data received from the sensor and the process module controller is analyzed by the remote controller. If a problem is identified, the remote controller can send a block message to the group tool controller. In an example, remote controller 242 identifies a problem within PMC 210. The blocked message is transmitted to the CTC 204 via the sequence tap 208 via paths 254 and 250. Upon receipt of the blockade message, the CTC 204 sends a block message to the intended process module controller (in this example, it is PMC 210).

Since the remote controller is only responsible for processing data from a group tool rather than from multiple group tools (as done by data box 142), more data can be analyzed and better between different data sets. Relevance. As a result, the remote controller can perform better and faster analysis, thus providing more timely intervention to correct uncontrollable events within the process module. In one example, instead of receiving an unblocked message to prevent an uncontrolled event from occurring in the next substrate batch (e.g., a blocked message provided by data box 142), for example, the blocking message transmitted by remote controller 242 can cause the process engineer to save at least A portion of the substrate batch that is scheduled to be processed.

While the remote controller solution is better than the data box solution, the remote controller solution still depends on the summary data to perform its analysis. Therefore, problems that may occur during substrate processing may remain unclear. Furthermore, the path between the process module and the remote controller is still not a direct path. As a result, computer bias, network latency, and/or network load can cause time differences that can make it difficult for the remote controller to correlate data from the sensor with data from the process module.

Therefore, even if the remote controller solution has increased the timeliness of blocking messages, the remote controller solution is still inadequate. At best, this blockade message prevents problems experienced by the affected substrate from occurring during the next substrate processing. In markets where the cost needs to be minimized to the extreme, waste due to damage to the substrate and/or downtime due to damage to the processing chamber may translate into market losses. Therefore, an immediate solution to identify uncontrollable events is a must.

According to an embodiment of the present invention, a process-level troubleshooting architecture (PLTA) is provided, wherein the troubleshooting is performed at a process module level. Embodiments of the present invention include a process level troubleshooting architecture that provides instant analysis with instant blocking messages. Embodiments of the present invention further include means for balancing load and fault tolerance between inductors.

In an embodiment of the invention, the process level troubleshooting structure is a network system in which an analysis server communicates with a single process module and its corresponding sensor. In one embodiment, the data exchanged in the network is bidirectional. In one example, the analysis server can continuously receive process data from the process module and the inductor. Conversely, the sensor can receive data from the process module and the process module can receive commands from the analysis server.

Consider the situation in which, for example, a substrate is being processed. Multiple data may be collected during substrate processing. In one example, information about pressure is collected every 100 milliseconds. If this process takes one hour, 36,000 items of information about the pressure parameters will be collected. However, in addition to the pressure data, a plurality of other process data (eg, voltage bias, temperature, etc.) may be collected. Therefore, when the substrate processing is completed, a considerable amount of data is collected.

In the prior art, data is transmitted to an analysis server (e.g., remote controller 242 of Figure 2) that can be used to process data collected from a plurality of process modules, or is transmitted to be available for processing from a plurality of group tools. An analysis server for the collected data (e.g., data box 142 of Figure 1). Since the data stream comes from multiple sources, it takes time to analyze and/or correlate this data. Furthermore, since the prior art analysis server may not be able to process and analyze all of the collected data, only a portion of the data collected from various sources will be transmitted to the analysis server. Therefore, the complex task of coordinating, processing, correlating, and/or analyzing data streams requires time that is not necessarily easy to obtain.

In one aspect of the invention, the inventors have learned here that if there is more granular data for analysis, a more accurate and faster analysis can be performed. In order to analyze more information from a single source, the analytics server must analyze data from fewer sources. In one embodiment, means are provided at the process module level to process and/or analyze data. In other words, a process module analytic server is provided to perform analysis on each process module and its corresponding sensor.

In one embodiment, the process module analytics server includes a shared memory backbone that can have more than one processor. Each processor can be used to interact with more than one sensor. In one example, the data collected by the sensor 1 can be processed by the processor 1 while the data collected by the sensor 2 is processed by the processor 2.

Unlike prior art, these processors can share their processing power with each other to perform load balancing and fault tolerance. In the prior art, a computing module is configured to process the data collected by the sensor. Since each computing module is an individual unit and typically does not interact with each other, load balancing is typically not performed. Different from the prior art, the processor group in the process module analytic server can perform load balancing. In one example, processor 2 can be used to assist processor 1 to process data from sensor 1 if processor 1 experiences data overload while processor 2 receives little or no data.

Moreover, in the prior art, since the computing modules tend to be different brands/types/styles, if one computing module fails, other computing modules cannot take over the processing performed by the faulty computing module. The present invention differs from the prior art in that the workload between processors can be redistributed if needed. For example, if processor 2 is unable to perform its function, this workload can be reassigned to other processors until processor 2 is repaired. It can be seen from the above that the processor of the present invention eliminates the need for individual computing modules and therefore reduces the physical space required to place the computing module.

In one embodiment of the invention, the processor can be divided into two types of processors: a primary processor and a secondary processor. Both the primary and secondary processors are configured to process the data from the sensors. In an example, if the secondary processor 1 is coupled to the sensor 1, the secondary processor 1 typically only processes the data from the sensor 1. Similarly, if the secondary processor 2 is coupled to the sensors 2 and 3, the secondary processor 2 typically only processes the data from the two sensors (2 and 3).

In an embodiment, the shared memory backbone may include more than one primary processor. The primary processor group can be used not only to process data from the sensor but also to process data from the process module. In addition, a primary processor group is configured to correlate data between various sources, such as sensors and process modules. If a message needs to be blocked, the primary processor group can be used to transmit the blocking message to the process module controller.

The features and advantages of the present invention will become more apparent from the description and appended claims.

3 shows a simplified logical summary of a process level troubleshooting architecture in one embodiment of the invention. While a manufacturer may have more than one group tool, a single group tool is used to illustrate one embodiment of the present invention. Although the group tool can have a different number of process modules, the example shown in Figure 3 includes a single group tool with four process modules.

The data collected by each process module is collected by its corresponding process module controllers (PMC 306, PMC 308, PMC 310, and PMC 312) and is connected via group 338, group tool controller (CTC) 304, and The link 340 is transmitted to the fab host 302. The data that can be transmitted by the PMC can be of the same type as the data that has been transmitted in the prior art (process module data and processing content data). Unlike prior art, the information transmitted to the fab host 302 does not rely on the process module to perform troubleshooting. Instead, this material can be archived and used for future analysis.

In one embodiment, a process module analytics server (APECS 314) is provided to perform the analysis required for troubleshooting. Consider the condition of etching the substrate in the PMC 308. Sensors 316, 318, and 320 collect data from PMC 308 during substrate processing. In one example, configuration sensor 316 collects voltage bias data from PMC 308. Analog data collected from PMC 308 is transmitted to inductor 316 via inductor cable 328. Similarly, sensors 318 and 320 can collect data via sensor cables 330 and 332, respectively. The data collected by the sensors can then be transmitted to APECS 314 via one of paths 322, 324, and 326 for processing and/or analysis.

Unlike prior art, the data collected by the sensor does not need to be pre-processed (eg, digested) before being transmitted to the analysis server (APECS 314). In one embodiment, instead of processing the data with a computing module, each sensor can include a simple data converter that can be used to convert analog data to digital data prior to transmitting the data to APECS 314. Alternatively, in an embodiment, a data converter, such as a field-programmable gate array (FPGA), may be built into APECS 314. In one example, each processor may include a data converter algorithm that converts the data into a digital format as part of its processing functionality. As can be seen from the above, by removing the need for a computing module, less physical space is required to place the group tool and its hardware. Therefore, the cost of ownership can be reduced.

Since APECS 314 is dedicated to processing data from only one process module and its corresponding sensors, APECS 314 is capable of processing a higher amount of data from a single source. In other words, instead of having to reduce the amount of data transferred from each sensor, APECS 314 is configured to process most, if not all, of the data collected by each sensor. In one example, instead of transmitting only 10 to 15 data items for analysis, more than 2,000 data items from each sensor can now be analyzed by APECS 314. Therefore, the data stream that can be used for APECS 314 for processing and analysis is a more complete data set.

In one embodiment, APECS 314 is also used to process data from the process module. Unlike prior art (where the data stream is received by an analytics server (such as a data cartridge or remote controller), it passes through a lengthy data through various servers (eg, group tool controllers, fab hosts, etc.) The path is transmitted. The data collected by the process module is directly transmitted to APECS 314 without going through other servers. In an example, process module data can be transferred from PMC 308 to APECS 314 via path 334. If an uncontrollable event is identified, the block message can be transmitted directly to the PMC 308 via path 336 without first passing through other servers.

Figure 4 provides further details regarding the process module analytics server. 4 shows a simplified functional diagram of a process module hierarchy analysis server in an embodiment of the present invention. A process module analytic server (eg, APECS 400) can be assigned to each process module. The APECS 400 is a two-way server and is used to process incoming data and to send blocking messages when an uncontrollable event is identified.

Sources can come from two main sources: data collected by sensors and data collected by process modules. In an embodiment, APECS 400 is used to receive incoming data from a plurality of sensors (sensors 410, 412, 414, 416, 420, 422, 424, and 426). In view of the fact that some group tool owners may have invested considerable money in traditional sensor devices (sensors with computing modules), APECS 400 can be used from traditional sensor devices and improved sensors (no computing modules required) The sensor) both receive data.

In an embodiment, APECS 400 may include an interface, such as Ethernet switch 418, for interfacing with conventional sensor devices (eg, sensors 410, 412, 414, and 416). In one example, the data collected by the sensor 410 is first converted from the analog format to the digital format by the computing module 410b prior to transferring the digital data to the APECS 400 (via path 430, 432, 434, or 436). The Ethernet switch 418 is configured to interact with a conventional sensor device to receive the data stream. The data stream is then transmitted (via path 446, 448, 450 or 452) to one of the processors (402, 404, 406, and 408) within APECS 400 for processing.

Instead of using conventional sensor devices to measure process parameters, an improved sensor (which does not have a computing module) can be used. Since the collected data does not need to be summarized, the computing module is no longer needed for processing. Rather, in one embodiment, the improved sensor can include a data converter (not shown), such as a low cost FPGA, for converting data from an analog format to a digital format. Alternatively, instead of setting the data converter in the sensor, a data converter (not shown) may be provided in the APECS 400. The removal of the computing module saves the cost of ownership of the group tool, whether or not the data converter is placed externally or internally to the APECS 400. In one example, the cost of purchasing, placing, and maintaining a computing module is substantially eliminated.

In one embodiment of the invention, APECS 400 includes a set of processors (402, 404, 406, and 408) to process incoming data. This processor group can be an entity processing unit, a virtual processor, or a combination thereof. Each processor is responsible for processing the data stream from the source associated with this processor. In one example, the flow of data flowing from sensor 422 via path 440 is processed by processor 404. In another example, the data stream collected by sensor 424 is transmitted to processor 406 via path 442 for processing.

The number of processors and their relationship to the sensors may depend on the configuration of the user. In one example, even though Figure 4 shows only a one-to-one relationship between the processor and the sensor, other relationships may exist. In one example, the processor can be configured to process data from more than one source. In another example, more than one processor can be configured to process the data stream from one of the sensors.

In one embodiment, each processor shares a shared memory backbone 428. Therefore, load balancing can be performed when more than one processor is overloaded. In one example, if the data stream flowing from sensor 426 via path 444 exceeds the processing power of processor 408, other processors can be used to assist in reducing the load on processor 408.

In addition to load balancing, the shared memory backbone also provides a fault-tolerant environment. In other words, if one of the processors is not functioning properly, the processing previously supported by the processor of this failure is reassigned to the other processor. In one example, if processor 406 is not functioning properly and cannot process the data stream from sensor 424, processor 404 can be instructed to process the data stream from sensor 424. Therefore, the ability to redistribute the workload allows the processor that is not functioning properly to be replaced without causing the entire server to shut down.

In an embodiment, there may be two processors within the APECS 400. The first type of processor is a secondary processor (e.g., processor 404, 406 or 408). Each secondary processor is configured to process the data stream received from its corresponding sensor. Moreover, in one embodiment, each processor is used to analyze the data and identify any potential problems with its corresponding sensor.

The second type of processor is referred to as a primary processor (402). Although Figure 4 shows only one primary processor, the number of primary processors may depend on the configuration of the user. In an embodiment, a primary processor can be configured to process data streams from more than one sensor. In one example, the data stream collected by sensor 420 is transmitted via path 438 to primary processor 402 for processing.

Another source of information for the primary processor is the process module. In other words, the process module data and processing content data collected by the process module are processed by the primary processor. In one example, the data collected by the process module is transmitted to the APECS 400 via the process control bus via path 454. This data passes through the Ethernet switch 418 before flowing into the primary processor 402 via path 446.

In addition to processing data, the primary processor can also be used to analyze data from multiple sources. In an example, data correlation between data streams from sensors 422 and 424 is performed by primary processor 402. In another example, primary processor 402 also performs data association between data streams from more than one sensor and data streams from a process module.

Since the data path to each data source is now about the same length, the associative data is much simpler than the challenges experienced by prior art. In one example, since the data does not need to go through other servers (such as the group tool controller and/or the fab host) to flow from the process module to the APECS 400, the data flow from the process module does not go through the computer. And/or changes in network conditions (such as computer skew, network latency, network load, etc.) that must pass through other servers (such as group tool controllers, fab hosts, etc.) When it is transmitted, it will be generated (as shown in Figures 1 and 2). In addition, the latency of receiving all relevant data streams required to perform correlation and analysis is now greatly reduced. Therefore, when the external situation (such as computer deviation, network delay, network load, etc.) has been substantially removed, the association of data from different sources is greatly simplified.

In addition to the data path, faster and more accurate analysis can be performed because a larger amount of data from a single source with better granularity provides more data points to perform associations. In the prior art, the association between data sources is often difficult because the information available for analysis is often incomplete (since the conventional analysis server is unable to process high data volumes from excess data sources). Unlike prior art, each analysis server is now only responsible for analyzing data from a limited number of sources (process modules and sensors connected to the process module), significantly reducing the number of data sources. Since the number of data sources has been greatly reduced, the analytics server has the ability to handle larger amounts of data from a single source. In view of the finer detail provided, better correlation between data streams from various sources can be achieved.

If a problem is identified (eg, an uncontrollable event), the primary processor can be used to transmit a blocking message to the process module. In one embodiment, the blockade message is transmitted from the APECS 400 to the process module using the direct digital output line 456. With the digital output line between the two devices, the blocked message does not need to be converted to an Ethernet message before it can be transmitted. Therefore, the time required to properly format the blocked message and then convert it back is substantially eliminated. Therefore, APECS 400 can provide instant blocking messages or close to instant blocking messages to the process module to handle uncontrollable events.

In an embodiment, the primary processor and other devices may also be configured to interact via path 458. In an example, if the group tool controller transmits a request to APECS 400, the request can be communicated via path 458 and processed by primary processor 402. In another example, the notification to the fab host can be communicated via path 458 and the group tool controller. In one or more embodiments, APECS 400 can be coupled to a user interface (UI) via path 458.

It can be understood from more than one embodiment of the present invention that the present invention provides a process level troubleshooting structure. By locating the analysis server at the process module level, data fineness is provided for analysis, resulting in faster and more accurate analysis. By having a similar data path for each data source, there is a better correlation between the individual data streams. With faster and more accurate analysis, troubleshooting can be performed on a more timely basis with the timely provision of blocked messages to provide uncontrollable events that can be used to prevent damage to the next substrate and to repair damaged substrates. Correct the action to save the affected substrate from damage. As a result, a smaller number of substrates are wasted and the damage to the process chamber components can be substantially reduced.

In another aspect of the present invention, the inventors of the present invention have learned that fast transient events (eg, micro-arc (micro-arc) can be identified and managed by a process level troubleshooting structure capable of performing timely, rapid, and accurate analysis. Arcing) Instant, in-situ detection of events, dechucking events, spiking events, etc. As described herein, a fast transient event means an event that can occur quickly during substrate processing and that typically lasts for a short period of time (eg, a micro-arc event, a release event, a spike event, etc.). Due to the speed and short duration that each event can be maintained, if it is entirely possible, after processing the entire batch of substrates, the task of identifying fast transient events is typically performed offline.

In one example, for example, an optical metrology tool can be used to inspect more than one substrate. Unfortunately, this check did not provide timely detection. Rather, for example, when a micro-arc event occurring on the substrate has been identified, not only the substrate has been damaged, but the remaining substrate batch may have been damaged. In addition, damage to the hardware components within the processing chamber may also result.

In recent years, fast transient sensors have been developed that capture fast transient electronic signatures (which are the result of fast transient events). However, most fast transient sensors do not have the ability to classify electronic signatures. In other words, fast transient sensors may be able to collect data, but fast transient sensors typically do not have the ability to classify this material into meaningful electronic signatures that can be used to identify potentially harmful events.

In view of the conditions therein, for example, during the etching process, electric charges may be accumulated to cause micro-arc generation. As described herein, micro-arcing refers to an event that occurs when power is quickly removed and the cancellation action causes damage to the pattern on the substrate (eg, breaking a layer of material, breaking a pattern, melting a layer, etc.). Information on micro-arc can be collected by using a VI probe. However, most fast transient sensors (such as VI probes) lack the ability to interpret data and identify when fast transient events (such as micro-arc events) have occurred.

Instead, the data collected by the fast transient sensor may have to be analyzed by a third party (eg, by a user or by a software program). In one example, the user may need to analyze the excess data and determine (based on his expertise) whether a fast transient event has occurred during substrate processing. The analysis of the data may not take weeks or hours. Even if data analysis is performed by a software program, it may take time to analyze tens of thousands of data samples. Damage to more than one substrate batch and/or to the hardware components of the processing chamber may have occurred while identifying the problem.

Since micro-arc events are usually not a predictable phenomenon, detecting fast transient events (such as micro-arc events) can be a difficult task. In other words, for example, micro-arcing does not always occur on each substrate. In one aspect of the invention, the inventors herein have learned that even though the time of the micro-arc event is unpredictable, the electronic signature of the micro-arc event is predictable. In other words, each micro-arc event can be represented by a unique signature.

Figure 5 shows a simple graph of a micro-arc event (curve 502). As seen by curve 502, when a micro-arc event on the wafer occurs, the voltage and current signals experience a steep drop (504) at the same time. Then, as the voltage and current signals gradually rise to the plateau (506), the voltage and current signals experience a reverse dip, while the plateau (506) can be at different heights from where the two signals fall.

In accordance with an embodiment of the present invention, methods and apparatus are provided for processing fast transient events (e.g., micro-arc events) within a processing chamber of a plasma processing system. Embodiments of the invention include methods for detecting fast transient events, such as micro-arcs. Embodiments of the present invention also include methods for classifying fast transient electronic signatures by performing a comparison of known signatures with known fast transient signatures (e.g., arc signatures). Embodiments of the present invention further include methods for classifying the severity of fast transient events. Embodiments of the present invention further include methods for managing fast transient events to minimize damage during an immediate manufacturing environment.

In the present case, various embodiments may be described using micro-arc as an example. However, the invention is not limited to micro-arcing, and may include any fast transient events that may occur during substrate processing. Instead, the description of the present invention is for illustrative purposes, and the invention is not limited to the embodiments presented.

In one embodiment of the invention, methods and apparatus are provided to detect potential micro-arc events. As noted above, during substrate processing, a fast transient sensor (eg, a VI probe) capable of performing high sampling rates (eg, collecting millions or hundreds of millions of data points per second) can be used to collect data. In one embodiment, for example, during substrate processing, a fast sampling transient detection algorithm can be performed while the VI probe collects data. In an embodiment, the fast sampling transient detection algorithm may include a standard value used to define a potential fast transient electrical signal. In one example, to identify potential micro-arc events on a wafer, a fast sampling transient detection algorithm can retrieve events in which both voltage and current signals drop simultaneously. In another example, to identify potential processing chamber micro-arc events, a fast sampling transient detection algorithm can be used to retrieve events in which both voltage and current signals are peaked.

In one embodiment, a fast sampling transient algorithm is performed by an inductor controller (eg, a VI probe controller), and a computing module coupled to a sensor (eg, a VI probe) is configured to provide a pair of sensors ( For example, the VI probe) interface and receiving data from sensors such as VI probes. In another embodiment, the fast sampling transient algorithm is performed by a computing module that interacts with an inductor controller (eg, a VI probe controller). In yet another embodiment, the fast sampling transient algorithm is performed by an analysis module that interacts directly with an inductor (eg, a VI probe).

If a potential micro-arc event is identified by a sensor (eg, a VI probe) or by a computing module that interacts with a sensor (eg, a VI probe), then in one embodiment, approximately at the time of the event The resulting voltage and current signal waveforms (eg, electronic signatures) can be stored and sent to an analysis module (eg, a process module analytic server (eg, APECS 314)) for analysis. In other words, by performing detection at the sensor level, only data about potentially fast transient electronic signatures (eg, micro-arc) will be forwarded to the analysis module for further analysis. Therefore, filtering can be performed to reduce the amount of data traffic transmitted along the data path, instead of transmitting all of the data to the analysis module for analysis, thereby reducing bandwidth requirements and reducing the processor power of the analysis module.

However, if an analysis module that interacts directly with an inductor (e.g., a VI probe) identifies a potential micro-arc event, then in one embodiment, no filtering of the data is required. Instead, an analysis module (such as APECS 314) that is part of the process level troubleshooting structure can have a fast processor that can process large amounts of data. With the special process level troubleshooting structure of the present invention, general data traffic congestion that may occur in other types of analysis structures can be substantially eliminated. Therefore, the analysis module of the present invention is capable of analyzing tens of thousands of data samples quickly and efficiently.

In an embodiment of the invention, the classification of potential fast transient electronic signatures can be performed. In one example, once the analysis module receives a waveform of a potential fast transient event, the analysis module can compare the potential fast transient electronic signature with a set of fast transient signatures (eg, a set of arc signatures). In one embodiment, various known waveforms that may be used as examples of fast transient events (e.g., micro-arc) may be stored in a database.

In one embodiment, if the potential fast transient electronic signature matches one of the fast transient signature groups stored in the database, then the severity of the fast transient event can be determined. In one example, a fast transient event may have little or no effect on the substrate being processed. Therefore, this event can be classified as an event with a low degree of severity. In another example, a fast transient event may have damaged the substrate currently being processed. Therefore, this fast transient event can be classified as having a high degree of severity.

By identifying the severity of a fast transient event, it can be determined how best to handle this fast transient event. In an embodiment of the invention, the predetermined operational procedure may be provided depending on the severity of the fast transient event. In one example, a fast transient event with a low severity can cause a warning, while a fast transient event with a high severity can cause the etch process to be terminated, for example.

To aid in the description, FIG. 6A shows a simplified block diagram of a processing environment in one embodiment of the invention. Processing system 600 can include a processing chamber 602 in which substrate 604 is processed. During substrate processing, a gas (not shown) may interact with power (provided through a set of RF boxes 606 via a set of match boxes 608) to produce a plasma to etch the substrate.

During the processing of the substrate, if a rapid transient event occurs due to charge buildup, this data may be collected by the VI probe 610 and identified by the fast sampling transient detection algorithm module 616. In one embodiment, the fast sampling transient detection algorithm module 616 can include standard values for defining fast transient events. In an embodiment, the fast sampling transient detection algorithm module can be executed during substrate processing.

In an embodiment, the collected data can be sent to the VI probe controller 612 along a set of paths 614. The VI probe controller 612 is at least used to manage the VI probe 610. In an embodiment, the VI probe controller 612 can also include a fast sampling transient detection algorithm module 616.

In another embodiment, the fast sampling transient detection algorithm module 616 can be a stand-alone computing module that can communicate with the VI probe controller 612. In other words, the data collected by the VI probe 610 can be transmitted to the fast sampling transient detection algorithm module 616 via the VI probe controller 612. By having the fast sampled transient detection algorithm module 616 a stand-alone module, the VI probe controller 612 need not be modified if the VI probe controller 612 is unable to operate additional processing.

In another embodiment, the data can be directly transmitted from the VI probe 610 via the path 650 to the analysis module 618 (as shown in FIG. 6B) instead of transmitting the data to the VI probe controller 612. The fast sampling transient detection algorithm module 616 is accommodated. By transmitting the data directly to the analysis module 618, the data collected by the VI probe 610 need not be pre-processed. Additionally, a computing module (eg, VI probe controller 612) can be eliminated to reduce the cost of real estate. Instead, an analysis module 618 can be employed to identify potential fast transient electronic signatures.

Once the potential fast transient electronic signature has been detected based on the predetermined standard value, the potential fast transient electronic signature can be classified by the analysis module 618 (eg, the process module hierarchy analysis server (eg, APECS 314)). In an embodiment, the analysis module 618 can perform the signature ratio by comparing the potential fast transient electronic signature with a set of fast transient signatures (eg, a set of arc signatures) stored in the database. Correct. If a match is identified, a fast transient event has occurred.

In one embodiment, analysis module 618 is configured to determine the severity of a fast transient event. Those skilled in the art will appreciate that fast transient events can have varying degrees of severity (e.g., intensity). Therefore, an algorithm is provided to determine the severity of each fast transient event. In an embodiment, the degree/threshold range of severity may be predetermined and configurable by the user. As an example, a greater than 4 dB drop in current or voltage signals and a duration longer than 15 microseconds (defined as the time from descent to recovery) can be considered as appropriate thresholds for detecting damage on the wafer.

Once the severity of the fast transient event has been categorized, an action procedure can be taken. In an embodiment, the action program can be predetermined and can be associated with a severity level/threshold range. In an embodiment, the action program can be configured by the user. In one example, a fast transient electronic signature (eg, micro-arc) with a small voltage and current drop can be considered harmless and may only require a notification to be communicated to the operator. In another example, a fast transient electronic signature with a large voltage and current drop can be considered an event of high severity and can trigger termination of substrate processing.

7 shows, in an embodiment of the invention, a simple flow diagram illustrating a method for detecting instant fast transient events in a manufacturing environment, wherein the fast sampling transient detection algorithm is not a component of the analysis module. Share.

In a first step 702, substrate processing is initiated. In view of the conditions therein, for example, the substrate 604 is processed within the processing chamber 602.

In the next step 704, substrate processing within the processing chamber is detected. At step 704a, a fast transient sensor (eg, a VI probe) can detect electrical parameters (eg, voltage and current signals, fundamentals, and harmonics at different stages). At approximately the same time, at step 704b, a fast sampling transient detection algorithm can be performed.

In the next step 706, it is determined if a potential fast transient event exists. In other words, for example, a fast sampling transient detection algorithm may include a standard value to define a potential fast transient event (eg, a micro-arc). If the data collected by the VI probe does not meet the standard values defined by the fast sampling transient detection algorithm, no potential fast transient events occur and the VI probe continues to detect substrate processing (step 704).

However, if a potential fast transient event is identified, then in a next step 708, voltage and current waveforms near the time the potential fast transient event occurs can be stored.

In the next step 710, the stored waveform is transmitted to the analysis module. In one embodiment, only data related to the occurrence of a potential fast transient event is stored and transmitted. Data loss can be minimized by transmitting only potentially fast transient electronic signatures. In addition, since the sensor controller (eg, the VI probe controller) has performed pre-processing, the analysis module may not need to include a fast processor to analyze the data and quickly classify and determine the action program for potentially fast transient events.

In the next step 712, the signature comparison is performed by the analysis module. In one embodiment, the analysis module can compare a potentially fast transient electronic signature with a set of fast transient signatures. In an embodiment, the set of fast transient signatures can be stored in a database. In an embodiment, this database may also contain non-fast transient signatures to enable associations to be performed.

In the next step 714, a category of potential fast transient electronic signatures is determined. If the result of the signature comparison is that no match is identified, then the potentially fast transient electronic signature is not classified as a fast transient electronic signature of interest (step 716). In an embodiment, this potentially fast transient electronic signature can be discarded. In another embodiment, the potential fast transient electronic signature can be added to the database as a new fast transient electronic signature (step 718).

However, if the result of the signature comparison is to identify a fast transient electronic signature, then in a next step 720, the severity of the fast transient event is determined. In one example, the severity can be distributed from low to high. In an embodiment, the severity may be based on a predetermined set of threshold ranges. In an embodiment, a fast transient electronic signature may be added to the database (step 718). Step 718 is an optional step and is not required to detect an immediate fast transient event.

In the next step 722, an action program is determined. Once the severity level has been determined, an action procedure can be performed. In an embodiment, an action program can be scheduled. In one example, a fast transient electronic signature with a low severity can trigger an operator notification. In another example, a fast transient electronic signature with a medium severity level can trigger a warning. In yet another example, a fast transient electronic signature with a high degree of severity can initiate termination of substrate processing. From the above, it can be seen that the user can configure the severity level and the action procedure associated with the severity level.

FIG. 7 illustrates an embodiment of a method of detecting an instant fast transient event within a manufacturing environment. In another example, the method can also be used to detect real-time fast transient events, wherein the fast sampling transient detection algorithm is part of an analysis module (in an embodiment). In such an environment, a fast sampling transient detection algorithm can be performed by an analysis module (eg, APECS 314) instead of a VI probe controller. In one embodiment, the analysis module is a fast processing computing module capable of processing a large amount of data. In an embodiment, the analysis module is directly connected to the inductor. Therefore, the data is collected by the sensor and transmitted directly to the analysis module.

From the foregoing, it will be appreciated that the present invention provides an apparatus and method for detecting in-situ transient fast transient events. In the prior art, fast transient event detection is typically performed after substrate processing of a substrate batch has been completed. Furthermore, sophisticated metrology tools may be required to determine if a fast transient event exists. Since the presence or absence of a fast transient event is unpredictable, it may be necessary to measure each substrate in a batch of substrates to determine potential damage that may have occurred.

In contrast to the prior art, embodiments of the present invention provide for rapid transient event detection during substrate processing, thereby minimizing damage to the remaining substrate batches and/or processing chambers. Moreover, unlike prior art, this detection process is an automated process that requires little or no human intervention. Instead, the system can be used to automatically detect fast transient events once the condition/standard value/threshold that can be configured by the user has been defined.

In view of the ability to instantly identify fast transient events (such as micro-arc events) in a manufacturing environment, the delay between the actual occurrence of an event and the action taken to manage the event can be reduced. In the prior art, this delay may take hours or even weeks. However, with the method and/or apparatus described herein, this delay can be reduced to only a few milliseconds, thereby reducing the total cost of ownership.

While the invention has been described in terms of several preferred embodiments, modifications and Although several examples are provided herein, these examples are for illustrative purposes and are not intended to limit the invention.

Moreover, the names and abstracts of the present disclosure are hereby provided for convenience, and are not intended to be used in the scope of the claims. Furthermore, the abstract is written in a highly simplified form and is provided for convenience, and thus is not intended to limit or limit the invention as a whole. If the word "group" is used herein, it is intended to mean a mathematical meaning that is generally understood to include zero, one, or more. It should also be appreciated that there are many other ways to implement the methods and apparatus of the present invention. Therefore, the scope of the appended claims should be construed as including all the changes, modifications and equivalents in the true spirit and scope of the invention.

102. . . Fab host

104. . . Group Tool Controller (CTC)

106. . . Group Tool Controller (CTC)

108. . . Group Tool Controller (CTC)

110. . . Process Module Controller (PMC)

112. . . Process Module Controller (PMC)

114. . . Process Module Controller (PMC)

116. . . Process Module Controller (PMC)

118. . . sensor

118b. . . Computing module

120. . . sensor

122. . . sensor

124. . . sensor

126. . . sensor

128. . . sensor

130. . . sensor

132. . . sensor

134. . . sensor

136. . . sensor

138. . . sensor

140. . . sensor

142. . . Data box

144. . . Sensor cable

146. . . path

148. . . path

150. . . path

156. . . Semiconductor Equipment Communication Standard / General Equipment Module (SECS/GEM)

158. . . path

202. . . Fab host

204. . . Group Tool Controller (CTC)

206. . . Group Tool Controller (CTC)

208. . . Sequence tap

210. . . Process Module Controller (PMC)

212. . . Process Module Controller (PMC)

214. . . Process Module Controller (PMC)

216. . . Process Module Controller (PMC)

218. . . sensor

218b. . . Computing module

220. . . sensor

222. . . sensor

224. . . sensor

226. . . sensor

228. . . sensor

230. . . sensor

232. . . sensor

234. . . sensor

236. . . sensor

238. . . sensor

240. . . sensor

242. . . Remote controller

244. . . Sensor cable

246. . . path

248. . . path

250. . . path

252. . . path

254. . . path

256. . . Sequence tap

258. . . path

260. . . Remote controller

302. . . Fab host

304. . . Group Tool Controller (CTC)

306. . . Process Module Controller (PMC)

308. . . Process Module Controller (PMC)

310. . . Process Module Controller (PMC)

312. . . Process Module Controller (PMC)

314. . . Process Module Analytic Server (APECS)

316. . . sensor

318. . . sensor

320. . . sensor

322. . . path

324. . . path

326. . . path

328. . . Sensor cable

330. . . Sensor cable

332. . . Sensor cable

334. . . path

336. . . path

338. . . Link group

340. . . link

400. . . Process Module Analytic Server (APECS)

402. . . processor

404. . . processor

406. . . processor

408. . . processor

410. . . sensor

410b. . . Computing module

412. . . sensor

414. . . sensor

416. . . sensor

418. . . Ethernet switch

420. . . sensor

422. . . sensor

424. . . sensor

426. . . sensor

428. . . Shared memory backbone

430. . . path

432. . . path

434. . . path

436. . . path

438. . . path

440. . . path

442. . . path

444. . . path

446. . . path

448. . . path

450. . . path

452. . . path

454. . . path

456. . . Digital output line

458. . . path

502. . . curve

504. . . Steep down

506. . . Plateau area

600. . . Processing system

602. . . Processing room

604‧‧‧Substrate

606‧‧‧A group of RF generators

608‧‧‧A set of matchers

610‧‧‧VI probe

612‧‧‧VI probe controller

614‧‧‧ Path

616‧‧‧Fast sampling transient detection algorithm module

618‧‧‧Analysis module

650‧‧‧ Path

702‧‧‧Starting substrate processing

704‧‧‧Detecting substrate processing

704a‧‧‧Detector detection electrical parameters

704b‧‧‧ Perform fast sampling transient detection algorithm

706‧‧‧ Is there a potential fast transient event?

708‧‧‧ Snapshot of stored voltage and current waveforms

710‧‧‧Transfer waveforms to the analysis module

712‧‧‧ Execution of signature comparison

714‧‧‧ Is it consistent?

716‧‧‧ Identifying fast transit electronic signatures that are not of interest

718‧‧‧Add to the database

720‧‧‧Determination of severity

722‧‧‧Determining and executing operational procedures

The present invention is illustrated by way of example and not by way of limitation.

1 shows a general logic diagram of an interconnect tool environment having a host hierarchy analysis server in the prior art;

Figure 2 shows a simplified block diagram of an interconnect tool environment with a group tool level solution, where the solution is used to correlate data between the sensor and the process module controller;

3 shows a simple logical overview of a process level troubleshooting structure in an embodiment of the present invention;

4 shows a simple action diagram of a process module hierarchical analysis server in an embodiment of the present invention;

Figure 5 shows a simple graph of a micro-arc event;

6A and 6B show a simplified block diagram of a processing environment in an embodiment of the present invention;

7 shows a simplified flow diagram of a method for detecting instant fast transient events in a manufacturing environment in an embodiment of the invention, wherein the fast sampling transient detection algorithm is not part of the analysis module .

302. . . Fab host

304. . . Group Tool Controller (CTC)

306. . . Process Module Controller (PMC)

308. . . Process Module Controller (PMC)

310. . . Process Module Controller (PMC)

312. . . Process Module Controller (PMC)

314. . . Process Module Analytic Server (APECS)

316. . . sensor

318. . . sensor

320. . . sensor

322. . . path

324. . . path

326. . . path

328. . . Sensor cable

330. . . Sensor cable

332. . . Sensor cable

334. . . path

336. . . path

338. . . Link group

340. . . link

Claims (10)

A method for detecting an in-situ fast transient event, the event occurring in a processing chamber of a plasma processing system during substrate processing, the method comprising: receiving an indication using a fast transient sensor operating at a high sampling rate Information of an electronic condition in the processing chamber, wherein the fast transient sensor includes an inductor controller that performs a fast sampling transient algorithm simultaneously with receiving the data, wherein the fast sampling temporary The state algorithm identifies a potential in-situ fast transient event in the received data based on applying a predetermined standard value, wherein the predetermined standard value includes a simultaneous voltage and current spike in the received data; Receiving, by the sensor controller, a potential in-situ fast transient event in the received data, extracting an electronic signature corresponding to the potential in-situ fast transient event from the received data, wherein the capturing is performed by the electronic signature The fast sampling transient algorithm is implemented and executed during a period of time during which the potential in-situ fast transient event occurs; by being independent of the fast An analysis module of the transient sensor receives the electronic signature directly from the fast transient sensor, wherein the analysis module is a server for hierarchical analysis of the process module, and is used for a process module and The process module is coupled with a set of fast transient sensors to perform analysis; the analysis module analyzes the received electronic signature, wherein the analysis comprises signing the received electronic signature with a set of stored arc signatures Comparing; when the received electronic signature meets one of the stored arc signatures of the group, by the analysis module, the received electronic signature is classified into a first in-situ fast transient event; when received The electronic signature does not comply with one of the arc signatures stored in the group, and the received electronic signature is added to a database as a non-fast transient event by the analysis module; and the analysis module is Determining a severity of the first in-situ fast transient event based on a predetermined set of threshold ranges. The method for detecting an in-situ fast transient event as described in claim 1 further includes determining an action procedure based on the severity of the first in-situ fast transient event. The method for detecting an in-situ fast transient event according to claim 1, wherein the first in-situ fast transient event is a micro-arc event. An apparatus for detecting an in-situ rapid transient event, the event occurring in a processing chamber of a plasma processing system, wherein the processing chamber includes a plurality of sensors for collecting data during substrate processing, the apparatus comprising: A fast transient sensor operating at a high sampling rate for receiving data indicative of an electronic condition within the processing chamber, wherein the fast transient sensor includes an inductor controller that receives and receives The data simultaneously implements a fast sampling transient algorithm, wherein the fast sampling transient algorithm identifies a potential in-situ fast transient event in the received data based on applying a predetermined standard value, wherein the predetermined standard value is included in the data. a simultaneous voltage and current spike in the received data; wherein the sensor controller is configured to identify a potential in-situ fast transient event in the received data by the sensor controller The fast sampling transient algorithm extracts an electronic signature corresponding to the potential in-situ fast transient event from the received data, wherein the retrieval system is executed In a period of time during which the potential in-situ fast transient event occurs; and an analysis module, independent of the fast transient sensor, is configured to receive the electronic signature directly from the fast transient sensor, wherein the analysis The module is a server for hierarchical analysis of the process module, and is used for performing analysis on a process module and a set of fast transient sensors connected to the process module; wherein the analysis module is further constructed by: Comparing the received electronic signature with a set of stored arc signatures, analyzing the received electronic signature; when the received electronic signature meets the set of stored arc signatures One, classifying the received electronic signature as a first in-situ fast transient event; adding the received electronic signature when the received electronic signature does not conform to one of the stored arc signatures of the group A non-fast transient event in a database; and determining a severity of the first in-situ fast transient event based on a predetermined set of threshold ranges. The apparatus for detecting an in-situ rapid transient event as described in claim 4, further comprising a database, wherein the database is used to store the stored arc signatures. The apparatus for detecting an in-situ fast transient event according to claim 5, wherein the database is used for storing a non-fast transient signature. The apparatus for detecting an in-situ fast transient event according to claim 4, wherein the analysis module is configured to directly perform an action program when the fast transient event is recognized during the substrate processing Transfer to a process module controller. The apparatus for detecting an in-situ fast transient event according to claim 4, wherein the analysis module is further configured to determine an action program based on the severity of the fast transient event. The apparatus for detecting an in-situ fast transient event according to claim 4, wherein the fast transient event is a micro-arc event. The apparatus for detecting an in-situ fast transient event according to claim 4, wherein the fast sampling transient algorithm is controlled by the analysis module, and the analysis module is configured to be used with the plurality of sensing The devices interact directly.