Virtual semiconductor wafer factory environment

Abstract

Examples relating to a virtual semi-conductor factory environment are disclosed. An example provides a monitoring method that monitors a process performed on a substrate in a processing tool. The method includes obtaining runtime data from a sensor of a processing tool while executing a process in the processing tool. The method further includes performing a run-time simulation by simulating the digital twinning using the run-time data and the process recipe. The method also includes receiving a selection of a spatial viewpoint within the digital twin of the processing tool. The method further includes rendering an image of the virtual state of the processing tool using the run-time simulation and the spatial viewpoint, and outputting the image of the virtual state.

Description

Background Art

[0001] The semiconductor device manufacturing process may involve many steps of material deposition, patterning, and removal to form an integrated circuit on a substrate. Therefore, a semiconductor device manufacturing plant ("plant" or "factory") may have a large number of different processing tools for performing hundreds or even thousands of individual steps to form a semiconductor device. Summary of the invention

[0002] This summary is provided to introduce a selection of concepts in a simplified form, which will be further described in the following detailed description. This summary is not intended to identify key features or essential features of the claimed subject matter, nor is it intended to be used to limit the scope of the claimed subject matter. Furthermore, the claimed subject matter is not limited to implementations that address any or all of the disadvantages mentioned in any part of this disclosure.

[0003] Disclosed examples relate to a virtual semiconductor environment. One example provides a method for virtually monitoring a process that is performed on a substrate in a processing tool, the method comprising: obtaining runtime data from a sensor of the processing tool while the process is running in the processing tool. The method also includes: simulating a digital twin of the processing tool by using the runtime data and a recipe for the process to perform a runtime simulation. The method also includes: receiving a selection of a spatial viewpoint in the digital twin of the processing tool. The method also includes: rendering an image of a virtual state of the processing tool using the runtime simulation and the spatial viewpoint; and outputting the image of the virtual state.

[0004] In some such examples, receiving the selection of the spatial viewpoint in the digital twin alternatively or additionally includes: receiving selections of two or more spatial viewpoints, and wherein rendering the image of the virtual state of the processing tool alternatively or additionally includes: rendering a first image of the virtual state at a first spatial viewpoint, and rendering a second image of the virtual state at a second spatial viewpoint.

[0005] In some such examples, rendering the image of the virtual state of the processing tool alternatively or additionally includes changing one or more of a position, orientation, or field of view of a rendering camera within the digital twin.

[0006] In some such examples, rendering the image of the virtual state of the processing tool alternatively or additionally includes rendering a video depicting the evolution of the virtual state of the processing tool over time.

[0007] In some such examples, the image alternatively or additionally includes one or more of a simulated thermal image, a simulated visual image, a simulated density image, or a simulated field.

[0008] In some such examples, the method alternatively or additionally includes obtaining a substrate map of metrology data of the substrate processed in the processing tool using the process. In such examples, rendering the image of the virtual state of the processing tool alternatively or additionally includes superimposing a representation of the substrate map of the metrology data on a virtual substrate of the runtime simulation.

[0009] In some such examples, the run-time simulation is alternatively or additionally a first run-time simulation for a process including one or more anomalies, the virtual state is alternatively or additionally a first virtual state, and the run-time data is first run-time data. In such examples, the method alternatively or additionally includes: obtaining a second virtual state of the process tool from a second run-time simulation of the digital twin, the second run-time simulation simulated using second run-time data from a process without anomalies; comparing at least a portion of the first virtual state with a corresponding portion of the second virtual state; and outputting one or more differences based on the comparison.

[0010] Another example provides a computing device, comprising: a display subsystem; a logic subsystem; and a storage subsystem, comprising instructions executable by the logic subsystem. The instructions are executable to receive user input selecting a spatial viewpoint in a digital twin of a processing tool, receive user input selecting a set of runtime data obtained by the processing tool, and provide the user input selecting the spatial viewpoint and the user input selecting the set of runtime data to a simulation service of a virtual semiconductor factory environment. The instructions are also executable to receive data from a runtime simulation from the simulation service, the runtime simulation representing a virtual state of the processing tool using the digital twin; and display a rendered image of the virtual state from the selected spatial viewpoint.

[0011] In some such examples, the instructions for receiving the user input selecting the set of runtime data obtained by the processing tool alternatively or additionally include instructions executable to receive user input from multiple different spatial viewpoints, and the instructions executable to display the rendered image of the virtual state from the spatial viewpoint alternatively or additionally include instructions executable to display the rendered image from the multiple different spatial viewpoints.

[0012] In some such examples, the instructions are alternatively or additionally executable to receive input that changes one or more of the position, orientation, or field of view of a rendering camera within the digital twin, and to display an updated rendered image of the virtual state after changing one or more of the position, the orientation, or the field of view.

[0013] In some such examples, the computing device alternatively or additionally includes a head-mounted display device.

[0014] In some such examples, the instructions executable to receive the user input selecting the spatial viewpoint alternatively or additionally include instructions executable to receive user input through one or more of a head tracking camera or an eye tracking camera.

[0015] In some such examples, the virtual state alternatively or additionally includes a substrate map, and the instructions executable to display a rendered image of the virtual state include instructions executable to display the substrate map on a virtual substrate.

[0016] In some such examples, the instructions are alternatively or additionally executable to receive notification of an anomaly in the set of runtime data, and in response, display the notification.

[0017] Another example provides a computing system comprising: a logic subsystem comprising one or more processors; and a storage subsystem comprising instructions executable to operate a digital twin of a processing tool. The storage subsystem also includes instructions executable by the one or more processors to obtain runtime data from the processing tool. The runtime data includes data obtained by sensors of the processing tool while a process is running in the processing tool. The instructions are also executable to detect an abnormal condition in the runtime data; in response to detecting the abnormal condition, simulate the digital twin using one or more of the runtime data or a recipe for the process to perform a runtime simulation; and determine a possible cause of the abnormal condition using data from the runtime simulation.

[0018] In some such examples, the instructions may alternatively or additionally be executable to determine a recommended diagnostic procedure.

[0019] In some such examples, the instructions are alternatively or additionally executable to output one or more of an alert indicating the abnormal condition or the recommended diagnostic procedure.

[0020] In some such examples, the instructions are alternatively or additionally executable to render an image of a virtual state of the processing tool using the runtime simulation.

[0021] In some such examples, the image alternatively or additionally includes one or more of a simulated thermal image, a simulated visual image, a simulated density image, or a simulated field.

[0022] In some such examples, the runtime simulation is alternatively or additionally a first runtime simulation, and the runtime data is alternatively or additionally first runtime data. The instructions are alternatively or additionally executable to obtain a first virtual state of the processing tool from the first runtime simulation of the digital twin, the first runtime simulation of the digital twin using the first runtime data from the process for simulation; obtain a second virtual state of the processing tool from a second runtime simulation of the digital twin, the second runtime simulation of the digital twin using the second runtime data from the process without anomalies for simulation; compare at least a portion of the first virtual state with a corresponding portion of the second virtual state; and output one or more differences in the comparison. BRIEF DESCRIPTION OF THE DRAWINGS

[0023] Figure 1 A block diagram showing an exemplary use environment for a virtual semiconductor fab environment.

[0024] Figure 2 shows a block diagram showing the configuration in Figure 1 An exemplary computing system operating within a virtual semiconductor factory environment.

[0025] Figure 3 A flow chart of an exemplary method for monitoring a process using a virtual semiconductor fab environment is depicted.

[0026] Figure 4 An exemplary substrate map is schematically depicted.

[0027] Figure 5 An exemplary processing tool is schematically depicted.

[0028] Figures 6A-6C Schematically depicts an exemplary interaction of a user with a virtual state, the virtual state representing Figure 5 The process is performed in a processing tool.

[0029] Figure 7 A block diagram is shown illustrating exemplary capabilities of a virtual semiconductor fab environment.

[0030] Figure 8 A block diagram is shown illustrating exemplary security features of a virtual semiconductor factory environment.

[0031] Fig. 9 A block diagram is shown illustrating an exemplary architecture of a virtual semiconductor factory environment.

[0032] Figures 10A-10C A block diagram is shown illustrating exemplary virtual bays of a virtual semiconductor fab environment.

[0033] Fig.11 A block diagram is shown illustrating an exemplary management flow schedule for a virtual semiconductor fab environment.

[0034] Fig.12 A block diagram of an exemplary computing system is shown. DETAILED DESCRIPTION

[0035] The term "anomaly" and variations thereof generally refer to a deviation from one or more process conditions or substrate metrology detected during processing in a processing tool or after processing of a substrate.

[0036] The term "abnormal condition" generally refers to a state of a processing tool that results in abnormal process conditions and / or substrate metrology.

[0037] The term "deposition" and its variations generally refer to the process of forming a film on a substrate.

[0038] The term "digital twin of a process tool" generally refers to a computer-implemented virtual representation of a process tool. In some examples, the digital twin may represent a process tool at a tool level, a subsystem level, a component level, and / or a subcomponent level. Exemplary subsystems include a radio frequency (RF) power subsystem, a gas subsystem, a thermal subsystem, a mechanical subsystem, and a pedestal / electrostatic chuck subsystem. The digital twin may further represent a substrate being processed in the process tool, including feature-level details.

[0039] The term "etching" and its variations generally refer to the removal of material from a substrate.

[0040] The term "probable cause" generally refers to a source of an abnormal condition that is likely to occur during a process performed by a processing tool.

[0041] The term "processing chamber" generally refers to an enclosure in which processing is performed on a substrate.

[0042] The term "process model" generally refers to a computer-implemented model that simulates the evolution of a process over time. A process model may virtually represent a process that may be performed by a processing tool.

[0043] The term "processing tool" generally refers to a machine that includes a processing chamber, and other hardware configured to enable a process to be performed in the processing chamber.

[0044] The term "recipe" generally refers to a set of processing tool settings for performing a corresponding process on a substrate.

[0045] The term "recommended diagnostic procedures" generally refers to one or more sets of tasks to be performed to gather information related to an abnormal condition. The recommended diagnostic procedures may be performed manually by a technician or another user, or automatically using a computing system.

[0046] The term "reference run" generally refers to data from a process performed in a processing tool that produces a desired processed substrate. The reference run can be stored and used for later comparison with another process performed in the processing tool.

[0047] The term "runtime data" generally refers to information obtained from sensors while a processing tool is performing a process.

[0048] The term "run-time simulation" generally refers to a computer-implemented simulation of the time evolution of a digital twin of a processing tool performing a process.

[0049] The terms "semiconductor fab," "fab," and "plant" generally refer to a manufacturing facility for fabricating semiconductor devices on substrates.

[0050] The term "simulated process" generally refers to a computer-implemented model that simulates the evolution of a virtual substrate over time based on one or more of a recipe or runtime sensor data.

[0051] The term "simulation runtime data" generally refers to computer implemented data generated by a simulation process model.

[0052] The term "substrate" generally refers to any object on which a deposition or etching process may be performed.

[0053] The term "substrate map" generally refers to substrate parameter values ​​as a function of position on the substrate. A substrate map can render geometric / topological features of a substrate. A substrate map can also render the physical and / or chemical conditions to which the substrate is exposed based on metrology data.

[0054] The term "virtual semiconductor fab environment" generally refers to a computer-implemented model of a semiconductor fab using digital twins of the process tools in the semiconductor fab.

[0055] The term “virtual experimentation” generally refers to computer-implemented experiments performed on a digital twin of a process tool in a virtual semiconductor fab environment.

[0056] The term “virtual state” generally refers to the computer-implemented state of a digital twin of a process tool.

[0057] The term "virtual substrate" generally refers to a computer-implemented model of a substrate.

[0058] Semiconductor manufacturing processes are very complex and can involve performing hundreds or even thousands of steps, which may be performed on many different tools by different manufacturers. In addition, each tool may have hundreds or even thousands of critical components that may affect the substrate results. One of the main challenges in factories today is how to achieve target process results on hundreds of processing tools, and run hundreds of thousands of substrates per month in factories that may be far apart from each other. In addition, the cost of owning and maintaining processing tools can be high. The need to own such tools may pose a barrier to academia and / or startups, who may otherwise contribute more disruptive ideas to the field of semiconductor technology.

[0059] In addition, the need for users to work in a physical fab poses many challenges to process development. For example, current semiconductor process design and testing may involve running many substrates through one tool or multiple tools, such as single variable tests (SVTs) or experimental designs (DOEs). Users in the fab must wear appropriate cleanroom clothing and must physically touch the tools to run substrates in the tools. Users must also study maintenance procedures before entering the lab to work with the tools and manually track all lab activities.

[0060] Therefore, examples of virtual semiconductor factory environments are disclosed to help solve such problems. In short, a computing system is configured to operate a virtual semiconductor factory environment representing a physical semiconductor factory. The virtual semiconductor factory environment utilizes digital twins of one or more tools in a semiconductor factory. The digital twin of a processing tool may include a virtual representation of the tool, including its physical configuration, digital representations of various components and systems of the tool, and logic for simulating the process performed on the tool. Based on data received from sensors on the physical tool modeled by the digital twin, the digital twin can be updated in real time. The digital twin of the tool can be used for virtual troubleshooting, virtual experiments, and / or other suitable workflows.

[0061] Figure 1 A block diagram of an exemplary factory network 100 utilizing a virtual semiconductor factory environment 102 is shown. Factory network 100 includes a first semiconductor factory 104, a second semiconductor factory 106, and a computing system 108 connected to each other via a network 110, such as the Internet, a wide area network (WAN), a local area network (LAN), a virtual local area network (VLAN), another network, or a combination thereof. In some examples, computing system 108 may be implemented at least partially in a data center. Computing system 108 is configured to operate virtual semiconductor factory environment 102, as described with reference to FIG. Figure 2 Although two semiconductor fabs 104, 106 are shown for illustration purposes, the virtual semiconductor fab environment may include a fab network having any suitable number of semiconductor fabs.

[0062] The first semiconductor plant 104 includes a first tool 112. The first tool 112 may include a processing tool. Exemplary processing tools include an etching tool and a deposition tool. The first tool 112 may also represent another tool that may be executed in a semiconductor plant, such as a power system management tool, a substrate movement tool, etc. The first semiconductor plant 104 also includes a second tool 114 and a third tool 116. Although three tools are shown here, in other examples, the first semiconductor plant 104 may include less than or more than three tools. Large plants may include hundreds or even more tools, while academic laboratories may have a single tool. The first semiconductor plant 104 also includes a server 118 connected to the first tool 112, the second tool 114, and the third tool 116. Therefore, the server 118 is configured to operatively couple the first tool 112, the second tool 114, and the third tool 116 to each other and / or the network 110. In a similar manner, the plant network 100 also includes a second semiconductor plant 106, which includes a server 120 connected to the first tool 122, the second tool 124, and the third tool 126.

[0063] As shown, the factory network 100 also includes a first client 128 connected to the network 110. The first client 128 can represent any suitable computing device connected to the network 110. Examples include desktop computers, tablet computers, laptop computers, wearable devices, and smart phones. In some examples, the computing device may include a head-mounted device that is configured to provide an augmented reality (AR) or mixed reality (MR) experience. In some such examples, using the virtual semiconductor factory environment 102, a user of the first client 128 can interact with a virtual representation of a semiconductor factory and / or a processing tool.

[0064] A user of the first client 128 can use the virtual semiconductor factory environment 102 to control and / or monitor the processes and / or tools in the first semiconductor factory 104 and / or the second semiconductor factory 106. In addition, a user of the first client 128 can use the virtual semiconductor factory environment 102 to control and / or monitor the digital twin of the process and / or tool. Such control and monitoring functions can be implemented through a virtual semiconductor factory user interface. Such a configuration can help to achieve virtual interaction with the tools in the factory without actually appearing in the factory. Similarly, the factory network 100 also includes a second client 130 connected to the network 110. In some examples, the second client 130 may be located at a different location from the first client 128. Although two clients are shown, in other examples, the factory network 100 may have one or more than two clients. In this way, the factory network 100 can enable users on multiple clients in different locations to collaborate and use the virtual semiconductor factory environment 102 to perform operations and / or experiments in the semiconductor factory without the need for users to go to the semiconductor factory. Figure 1In other examples, plant network 100 may have another configuration in which one or more tools at one or more plants may be accessed remotely.

[0065] Figure 2 A block diagram of an exemplary computing system 200 configured to operate a virtual semiconductor factory environment is depicted. The computing system 200 may be connected to one or more networks (not shown). The virtual semiconductor factory environment may represent Figure 1 In various examples, one or more components of computing system 200 may be co-located, geographically distributed and connected via a network, or any combination thereof. Components of computing system 200 may be located in a factory, a cloud computing service (e.g., a data center), and / or other institutions, such as academic institutions.

[0066] The computing system 200 includes one or more processors 202 and a storage subsystem 204. The storage subsystem 204 includes instructions 206, which can be executed by the one or more processors 202 to perform various aspects of the virtual semiconductor factory environment. Examples include virtual troubleshooting and / or virtual experiments. The instructions 206 can also be executed to operate one or more digital twins 208 of corresponding processing tools. In some examples, different subsystems of the processing tool can have different digital twins, which are configured to operate as the digital twin 208 of the processing tool. Such a configuration helps to implement virtual troubleshooting and / or experiments at different subsystem levels.

[0067] Instruction 206 may also be executed to obtain runtime data from a processing tool. Herein, exemplary runtime data includes runtime data 1 210 to runtime data N 212, which indicates N-1 additional runtime data. Runtime data 1 210 to runtime data N 212 represent data obtained by sensors of a processing tool when running corresponding processes 1 to processes N. Exemplary sensors may include thermal sensors, pressure sensors, gas sensors, cameras, voltmeters, ammeters, ohmmeters, and / or other suitable process sensors. In addition, one or more of the sensors may include an in-situ metrology sensor, such as a camera (e.g., a multispectral camera, such as a hyperspectral camera). In some examples, one or more of the sensors may include a data collection rate in the range of 1 Hz (hertz) to several kHz (kilohertz). In other examples, one or more of the sensors may have a data collection rate outside this range.

[0068] Using runtime data 1 210 and recipe 1 214 for process 1, instructions 206 are executable to perform runtime simulation 216 by simulating digital twin 208 (e.g., using simulation service 217). In some examples, multiple runtime simulations 216 may be performed. Examples of runtime simulations include, but are not limited to, gas flow rate simulations, RF power simulations, pressure simulations, thermal simulations, plasma simulations, deposition simulations, etching simulations, and combinations thereof.

[0069] To provide visualization of the runtime simulation 216, the instructions 206 include a rendering module 218. The rendering module 218 is configured to render and output one or more images 220 of one or more virtual states of the processing tool using the one or more runtime simulations 216 and one or more spatial viewpoints 222. Each spatial viewpoint represents a viewing angle of a user-controllable rendering camera within the digital twin 208. The rendering camera is positioned by the user to have a selected position, orientation, and field of view within the digital twin 208. By changing the position, orientation, and / or field of view of the rendering camera, the user can visually explore within the digital twin of the processing tool by panning, zooming, moving, etc.

[0070] For example, the spatial viewpoint can be selected and manipulated by the user of the client device. Various visualizations can be used to represent virtual states. Exemplary visualizations include simulated thermal images (e.g., temperature maps of processing tools generated using digital twins), simulated visual images, simulated density images (e.g., plasma density, current density), and simulated fields (e.g., using streamlines to represent fluid flow fields, electric fields, etc.). As a more specific example, different colors or other different appearances can be used to present data values ​​of selected types of data to visualize the differences in data values. In one such example, runtime metric data (e.g., multispectral image data) can be used to determine (e.g., using machine learning techniques) the film thickness as a function of the substrate surface position in a deposition process. Then, the visualization of the thickness as a function of the surface position can be applied to render the substrate of the digital twin as a surface texture. In this way, the film thickness difference can be convenient for users to watch as a simulated visual image. Such a visualization can be referred to as a substrate map 224. The substrate map 224 typically represents the metric data as a function of the substrate surface position of the substrate processed using a process in a processing tool. The rendering module 218 may also be configured to render a sequence of virtual states of the processing tool to produce a video 226 that depicts the evolution of the virtual state of the processing tool over time.

[0071] The instructions 206 are further executable to perform various operations as part of the virtual troubleshooting process. For example, the instructions 206 are executable to compare corresponding portions of the virtual states of two or more runtime simulations 216. As a more specific example, the instructions 206 are executable to compare a first virtual state and a second virtual state, wherein the first virtual state is from a first runtime simulation of a process (the process includes one or more anomalies), and the second virtual state is from a second runtime simulation of a second process (the second process does not have anomalies). The comparison can help the processing tool operator understand the possible (multiple) causes of the anomaly by visualizing the differences between the first runtime and the second runtime simulation. In some examples, the second runtime simulation can be stored at the storage subsystem 204. For example, a runtime simulation of a process without anomalies can be performed in advance and stored in the reference run 228 for later use. This can reduce the time used to obtain a runtime simulation of a process without anomalies compared to performing additional runtime simulations during the troubleshooting phase.

[0072] Instructions 206 may also be executed to detect anomalies in the runtime data set. Therefore, instructions 206 also include an anomaly detector module 230 configured to detect abnormal conditions in runtime data 1 210 and / or any additional runtime data. Anomaly detector module 230 may be configured to use threshold 232 to determine the time of a situation in runtime data 1 210 that exceeds a threshold condition, thereby indicating an abnormal condition. As a specific example, the gas subsystem may have an abnormal condition including a pressure response error. In such an example, by using an error tolerance threshold, anomaly detector module 230 may compare the pressure response of runtime data 1 210 with the pressure response of reference operation 228. Alternatively or additionally, anomaly detector module 230 may be configured to use machine learning model 234 to identify when a condition in runtime data 1 210 is an abnormal condition. Machine learning model 234 may include one or more of a classification model, a regression model, or a deep learning model. In some examples, one or more deep learning models may also actively determine the probability that an abnormality may occur after the next N time steps. Herein, N is used to indicate any suitable number of subsequent steps to be performed. As a specific example, a recurrent neural network using 10 to 20 timestamp predictions with uncertainty can reduce the uncertainty window as it approaches a specific timestamp.

[0073] When an abnormal condition is detected, the anomaly detector module 230 can use data from the runtime simulation 216 to determine a possible cause of the abnormal condition. Additionally, the anomaly detector module 230 can be configured to determine a possible cause using anomaly data 236, which includes data from previously detected abnormal conditions. In the example of a pressure response error, the anomaly detector module 230 can use data from a runtime simulation with a pressure response error to determine a possible cause of the throttle valve being out of specification.

[0074] The anomaly detector module 230 can also be configured to determine a recommended diagnostic procedure 238, for example, from a list of diagnostic procedures 240. In the pressure response example, an example of a recommended diagnostic procedure 238 may include replacing a throttle valve. The anomaly detector module 230 can determine the recommended diagnostic procedure 238 in a variety of ways. In some examples, different diagnostic procedures in the list of diagnostic procedures can be mapped to a specific group of runtime data values. In other examples, a trained machine learning function can be used to predict a diagnostic procedure that may be effective given the runtime data. The anomaly detector module 230 can also be configured to output an alarm 242, which indicates an abnormal condition. In some examples, the alarm 242 can indicate a recommended diagnostic procedure 238.

[0075] The instructions 206 are further executable to implement a process simulator module 244. The process simulator module 244 is configured to perform a simulated process 246 by using a process model 248 to generate simulated run-time data 250. The process model 248 includes a computer-implemented model of a process performed in a processing chamber of the digital twin 208. The instructions 206 may also include additional process models 248 to perform additional simulated processes 246, and to generate additional simulated run-time data 250. Using the simulated run-time data 250 and the recipe for the simulated process 246, a run-time simulation 216 may be performed. Such a run-time simulation may be stored in a reference run 228 for later comparison with future run-time simulations. Alternatively or additionally, such a run-time simulation may be used for process design and / or other experiments.

[0076] As previously mentioned, a virtual semiconductor fab environment may be used to remotely operate and monitor process tools in a semiconductor fab. Figure 3A flow chart of an exemplary method 300 for remotely monitoring a process performed on a substrate in a processing tool is depicted. For example, the method 300 may be performed by the computing system 200. At step 302, the method 300 includes obtaining runtime data from a sensor of the processing tool while the process is running on the substrate in the processing tool and analyzing the runtime data. The processing tool may be an etching tool, a deposition tool, or other suitable tool. In some examples, the runtime data may be obtained in real time while the processing tool is running the process. Alternatively or additionally, in some examples, the runtime data may be stored while the processing tool is running the process, and then the runtime data may be obtained after the processing tool has run at least a portion of the process.

[0077] The runtime data may be analyzed while the process is running and / or after the process has been run. Analyzing the runtime data may include, for example, comparing the runtime data to a threshold value based on a process recipe, and / or inputting the runtime data into a trained machine learning model. In some examples, the trained machine learning model may include a feed-forward neural network. In such examples, the neural network may be trained using labeled training data indicating previously acquired and / or simulated runtime data for abnormal and non-abnormal conditions. In some examples, the labeled runtime data may include, for example, substrate data acquired using image data such as multispectral image data. Training may be performed using backpropagation and a suitable loss function. Exemplary loss functions include mean squared error, mean absolute error, and Huber loss.

[0078] Analyzing the runtime data can help identify abnormal conditions, as shown in step 304. For example, in the case of using a trained machine learning model to analyze the runtime data, the runtime data obtained during substrate processing can be input into the trained machine learning model. Based on the runtime data input into the machine learning model, the machine learning model can then output the probability of a number of abnormal conditions occurring. The probabilities can also include confidence values. Based on comparing the determined probabilities (and possible confidences) with threshold probabilities (and possible threshold confidences), abnormal conditions can be determined. This can help diagnose processing tool systems or components that may cause abnormal conditions. In other examples, the runtime data can be compared to a threshold to detect abnormal conditions. In either case, the detection of abnormal conditions can be used to determine and output recommended correction procedures to correct the detected abnormal operating conditions, as shown at step 306. In some examples, the abnormal conditions may include warnings.

[0079] As described below, using a digital twin of a processing tool, the runtime data may be used together with a recipe for a process to perform a runtime simulation, as shown in step 308. The runtime simulation produces a virtual state of a processing tool. The recipe for a process specifies tool operation settings for the process. The runtime simulation can be used to present a visualization of the process for display on a client device. For example, a runtime simulation can produce data representing physical and / or chemical conditions inside a processing tool during a process. The runtime simulation can also be used to simulate the evolution of a modeled substrate using a mechanical model of the process and substrate, which is affected by the conditions represented by the runtime data. Such data can then be used to produce a visualization of the processing conditions and / or the modeled substrate using a digital twin of the processing tool.

[0080] The virtual state of a processing tool represents any suitable information about the physical state of the processing tool, and the physical state is determined based on the runtime data. For example, the virtual state can represent the temperature, pressure, airflow, RF power / plasma condition, and / or other conditions in the processing chamber of the processing tool. The virtual state can also represent the condition of the processing tool outside the processing chamber. As an example, the virtual state can represent the vacuum / exhaust system state (e.g., the temperature and / or airflow in the front line of the exhaust system), the power condition, the open / closed state of the panel door, the mass flow controller information, the position and operating state of the robot that moves the substrate in the processing tool, and / or any other suitable information about the processing tool.

[0081] In some examples where the run-time simulation includes an abnormal condition, the method 300 may include comparing the run-time simulation with a different run-time simulation from a run without an abnormality at step 310. For example, a first virtual state of a processing tool may be compared with a second virtual state, wherein the first virtual state is determined according to the run-time simulation, and the second virtual state is determined according to a second run-time simulation representing a process without an abnormality. In some such examples, the second run-time simulation may be a reference run. The reference run may be a previous run without an abnormality on the same processing tool, or a previous run without an abnormality on a different processing tool of the same processing tool type. The reference run may further be a modeled process. After comparing at least a portion of the first virtual state with a corresponding portion of the second virtual state, one or more differences based on the comparison may be output to a client device. The method 300 may help engineers at different locations to monitor and / or troubleshoot processes performed in a process tool.

[0082] In an example of detecting an abnormal operating condition in a run-time simulation, method 300 may also include using data from the run-time simulation to determine a possible cause of the abnormal condition at step 312. In some examples, a trained machine learning model may be used to determine the possible cause. Exemplary machine learning functions and training methods are described above. In other examples, the possible cause may be mapped to a threshold value that defines an abnormal operating condition. For example, a threshold pressure that defines an abnormal pressure may be mapped to an exhaust system valve. Method 300 may also optionally include determining a recommended diagnostic procedure at step 314. Method 300 may additionally include outputting a diagnostic procedure and / or an alarm indicating an abnormal condition at step 316. The recommended diagnostic procedure may be computer-implemented, manually implemented, or any combination thereof.

[0083] As a more specific example, in the case of detecting an anomaly related to a vacuum system, a recommended diagnostic procedure may involve collecting infrared (IR) data of the front-end line of the vacuum system to see if the temperature may cause particle accumulation and clogging of the front-end line. Infrared sensors in the processing tool can be used to collect IR data. Alternatively or additionally, a technician can use a handheld infrared camera to collect infrared data. As another more specific example, in the case of detecting an abnormal condition (including a warning in the RF subsystem), the measurement data may indicate that the thickness value drift of the processed substrate is low. Run-time simulation of the digital twin of the RF subsystem can be used to determine the data generated by the misaligned nozzle to indicate that the modeled processed substrate has a similar low thickness value. Therefore, a recommended diagnostic procedure for adjusting the nozzle and performing a cleaning procedure can be output.

[0084] The virtual state of the processing tool determined from the run-time simulation using the digital twin can be visualized according to any selected viewpoint within the digital twin. Therefore, method 300 also includes receiving a selection of a spatial viewpoint within the digital twin of the processing tool at step 318. The selected spatial viewpoint represents the position, orientation, and field of view angle of a rendering camera used to render a visualization of the selected virtual state. The selection can be made, for example, by outputting a rendering of a model of the processing tool (e.g., a physical model of the tool from the digital twin), and receiving user input of a position within the rendering of the processing tool (e.g., by touch, mouse click, or other).

[0085] Computer graphics rendering methods can be used to render visualizations of the digital twin from a selected spatial viewpoint. The three-dimensional locations within the digital twin can represent the modeled physical structure of the processing tool. In addition, runtime simulation data can be mapped to three-dimensional locations within the digital twin for visual representation. In some examples, two or more viewpoints can be presented simultaneously, for example in different windows in a display user interface. Therefore, in such examples, receiving a selection of a spatial viewpoint within the digital twin includes receiving a selection of two or more spatial viewpoints, as shown in step 320.

[0086] Method 300 also includes rendering an image of the virtual state of the processing tool using the runtime simulation and the spatial viewpoint at step 322. In some examples, the image may include one or more of a simulated thermal image or a simulated visual image, as shown at 324. The simulated thermal image can visibly represent infrared data, which is obtained, for example, by an infrared or multispectral camera at different positions in the processing tool. The simulated thermal image can also represent the temperature sensed by other temperature sensors in the processing tool. For example, interpolation can be used to determine the temperature between sensor positions. The simulated visual image can represent the physical structure within the processing tool during the process. The image can also be rendered to represent other sensing conditions, such as pressure and airflow within the tool. Such an image representing the sensing condition can be presented as an overlay of the digital twin image or otherwise synthesized with the digital twin image. In such an example, different colors can be used to represent different values ​​of the sensing condition.

[0087] The user of the client device may also select the type of data to be visualized. For example, at step 326, method 300 may include obtaining a substrate map of metrology data for a substrate processed in a processing tool using the process. Method 300 may also include overlaying a representation of the substrate map of metrology data on a virtual substrate of a runtime simulation. Figure 4 An example of a substrate map 400 is schematically depicted in FIG. The substrate map 400 includes substrate-wide thickness information of a film deposited on a substrate. In the depicted example, the substrate map 400 also includes thickness anomalies 402, as will be described with reference to FIG. Figures 6A-6C The substrate map 400 may be generated using data from a processing tool that includes an image sensor configured to sense film thickness. Figure 5 An exemplary processing tool 500 including an image sensor is schematically depicted in FIG. The processing tool 500 includes a processing chamber 502 and a susceptor 504 within the processing chamber 502. The susceptor 504 is configured to support a substrate 506 disposed within the processing chamber 502. The processing tool 500 also includes a showerhead 510 in which a processing gas flows into the processing chamber 502.

[0088] The processing chamber 502 also includes an optical interface 526 disposed on a sidewall 524 of the processing chamber 502. The optical interface 526 is an interface that is capable of transmitting electromagnetic radiation of a desired wavelength band from the interior of the processing chamber 502 to a hyperspectral camera 528 located outside the processing chamber 502 while preventing gas from passing through. In the depicted example, the optical interface 526 includes an optically transparent window positioned in a hole formed in the sidewall 524 of the processing chamber 502. The processing tool 500 also includes a multispectral camera 528 (e.g., a hyperspectral camera) that is configured to capture a hyperspectral image of a substrate within the processing chamber 502 through the optical interface 526 of the processing chamber 502. Figure 5 In other examples, the processing tool can have other configurations.

[0089] Return to Figure 3 , the runtime multispectral image data can be input into a trained machine learning function that is trained to predict the film thickness at each image pixel of the multispectral image data. The predicted film thickness data at each image pixel can then be mapped to a corresponding color or other visually distinct effect. The color (or other effect) can then be used as a texture map in an image rendering of a substrate model in a tool digital twin to produce a substrate map (e.g., substrate map 400) showing the film thickness over the surface of a substrate (e.g., substrate 506).

[0090] A user of the client device can operate the client device to control the position, orientation, and / or field of view of a rendering camera within the digital twin, as shown in step 328. As a more specific example, the user can change the position and / or orientation of the rendering camera to visualize different components within the processing tool. The user can also change the field of view to control the magnification of the image at the spatial viewpoint. Referring to the above-mentioned film thickness substrate map example 400, the user 602 can use the processing tool digital twin 603 to understand the possible causes of the thickness anomaly 402 in the film thickness substrate map 400. Herein, the processing tool digital twin 603 is a digital twin of the processing tool 500. As a possible cause, a hollow cathode discharge in the nozzle outlet hole may cause the film thickness anomaly. However, due to the viewing angle of the camera (e.g., the multispectral camera 528), the interior of the nozzle outlet hole may be obscured from the camera view. Therefore, during the process of capturing runtime data, the user 602 can use the runtime data from the process (producing the thickness anomaly) to view the runtime simulation of the processing tool 500 (including the nozzle 510). More specifically, in Fig. 6A, a user 602 of a client device 604 (depicted herein as a head mounted display device having a display field of view 605) selects to view a virtual state of a sprinkler digital twin 610 within a process tool digital twin 603. The user selects a location by gazing at a target location with the eyes (represented by a virtual gaze line), in conjunction with a gesture to confirm the selection of the location, and redirecting the rendering camera to face upward at the selected location. Alternatively or additionally, the user 602 may select a location by using audio input (e.g., a voice command). In response, reference Figure 6B , the position of the rendering camera within the digital twin is updated based on the user input so that the sprinkler digital twin 610 is located in the field of view of the thickness anomaly. A user 602 of the client device 604 can then select a spatial viewpoint at the location of the thickness anomaly on the thickness map. In the depicted example, the user 602 selects a location 612 on the sprinkler digital twin 610 that corresponds to the location of the thickness anomaly 402 on the substrate map 400. In addition, the user 602 can change the field of view of the rendering camera to zoom in on an area of ​​the sprinkler digital twin 610 above the thickness anomaly 402, such as Figure 6C As shown. In this way, user 602 can view whether a hollow cathode discharge 614 within the outlet orifice of the sprinkler is visible in the virtual state of the sprinkler digital twin 610. In this way, based on runtime data (e.g., metric data, voltage / current data, or obtained by a visual camera), user 602 of client device 604 views a simulation of a hollow cathode discharge 614 within the outlet orifice of the digital twin of the sprinkler, which is located near an edge 616 of the digital twin of the sprinkler. This can provide an indication that the hollow cathode discharge 614 may indeed be the cause of the thickness anomaly 402. Although the client device is described as a head-mounted augmented reality or Figures 6A-6C In the embodiment of the present invention, the virtual reality display device in FIG. 1 is used, but in other examples, other types of client devices can be used. Examples include desktop computers, laptop computers, tablet computers, and smart phones.

[0091] As another example, continuing with the film thickness substrate map example, a user may first view a visualization of the entire substrate to view the thickness map of the substrate from a distance. The user may then zoom in on specific substrate regions to view those regions in more detail. In some examples, the user may zoom to the feature level of the substrate. This may allow the user to view the evolution of a film on the substrate at the substrate feature level through a run-time simulation. For example, this may be used to help understand the changes in feature shape as a function of feature location on the substrate.

[0092] Return to Figure 3, in an example of receiving a selection of two or more spatial viewpoints, method 300 includes rendering a first image of a virtual state at a first spatial viewpoint, and rendering a second image of the virtual state at a second spatial viewpoint, as shown in step 330. In such an example, a user can individually control each of the following: the first rendered image, the second rendered image, and any additional rendered images. This can be used to provide a side-by-side view of different locations in the digital twin for comparison. As a more specific example, one window can be used to visualize process gas flow within a process chamber, while another window can be used to visualize a vacuum system valve at the same point in time within the simulation. This can allow the use of runtime data simulated using the digital twin to observe the impact of valve performance on process chamber conditions.

[0093] The run-time simulation may be updated at any suitable frame rate. The updated run-time simulation may be mapped to the digital twin to produce a series of video image frames representing the evolution of the state of the process tool over time. Thus, the method 300 further includes rendering video data at step 332 depicting the evolution of the virtual state of the process tool over time. The video may utilize a single spatial viewpoint and / or a selection of spatial viewpoints that vary over time.

[0094] The method 300 also includes outputting an image (still or video) of the virtual state at step 334. The image can be displayed on one or more display devices. In this way, two or more engineers at different locations can view the image simultaneously and collaborate, thereby enabling engineers to solve problems without going to the semiconductor factory. In other examples, the image can be stored for later display. The method 300 can help engineers at different locations monitor and / or troubleshoot processes performed in a process tool.

[0095] In some examples, users of a virtual semiconductor plant environment can use virtual reality (VR) and / or augmented reality (AR) devices to present and interact with a virtual semiconductor plant environment to train a digital twin of a tool and / or perform tasks on the tool by interacting with the digital twin of the tool without physically contacting the tool. The VR device can take the form of a head-mounted device that presents an immersive, fully virtual experience to the user. The AR device may include a perspective display that allows a virtual image to be displayed on a view of the real world environment. A mixed reality (MR) device is an AR device that presents a virtual object that appears to physically exist in the user's environment. For example, an MR device can use stereoscopic imaging to display a virtual object with a real distance effect. In addition, the MR device can create a depth map of the environment using sensors on the device (e.g., one or more cameras configured to obtain a depth image), such as a mesh representation of a surface in the environment. This can allow a mixture of virtual objects and real objects to be displayed using a real occlusion effect.

[0096] As described above, a digital twin for processing tools can be provided in a virtual semiconductor factory environment. This can allow users to access the virtual semiconductor factory environment using AR or VR to virtually use the tools in the virtual semiconductor factory environment. Users can learn the physical configuration of the tool, interact with the tool using a virtual user interface, and / or run simulations using a digital twin. In addition, in the case where the digital twin is configured to receive real-time data about the tool, the user can use AR or VR and the digital twin to observe and control the real-time status of the tool. The digital twins of the various tool components (e.g., RF power generators, manipulators, and mass flow controllers) can be incorporated into the digital twin of the tool.

[0097] The digital twin of each tool can be incorporated into a virtual semiconductor plant environment, where the digital twin of different tools is spatially arranged in a three-dimensional virtual environment that models the physical semiconductor plant. In addition, each semiconductor plant can be set up as a plant network. This can allow the creation of an innovation ecosystem without boundaries and / or borders, which is full of virtual hardware, including an always-on virtual representation of each plant, each of which includes all tools (e.g., etching and / or deposition tools) at the system level and at the subsystem level, as well as representations of components, such as radio frequency power generators, mass flow controllers, and / or automatic devices. The digital twin representation tool in each physical plant allows each plant to be transformed into an innovation power center for data sharing, where breakthrough ideas can be obtained from anywhere. By interconnecting the innovation centers that use each plant on a large scale, semiconductor industry companies, start-ups, researchers, and / or students from all over the world can access equipment and conduct experiments without having to be present in person. This can promote creativity and problem solving by allowing unprecedented collaboration within the ecosystem, which is designed to provide disruptive technologies faster and more frequently. This can also save time and / or money by shortening development cycles and / or leveraging existing investments in existing infrastructure. These and other possible factors can facilitate brainstorming and rapid turnaround of proofs of concept, and / or reduce the time required to go from technology ideation to commercialization.

[0098] A virtual semiconductor factory including a digital twin of the tools in the corresponding physical factory can allow process simulations to be run to verify the processing strategy before entering the laboratory to run experiments. As described above, each digital twin is configured to implement a virtual process. Such virtual process modeling can help process researchers and designers understand what happens at the substrate level (the microscopic scale of the device construction on the chip). In physical process design, the real substrate will be physically moved from one specific processing reactor to another. However, using a digital twin configured to implement a virtual process, a manufacturing process involving a single tool or multiple tools can be simulated at the nanoscale to see how the structure in the (multiple) processing tools develops over time. Such simulations can allow research projects that used to cost millions of dollars to be carried out at a lower cost.

[0099] Using a complete virtual representation of the entire factory, the virtual semiconductor factory environment can model the factory output and yield of different tools. Given that semiconductor factories must operate under strict specifications, virtual modeling of hardware and processes can help factories replicate and maintain determined optimal processes.

[0100] The digital twin of the processing tool can also be used to facilitate the processing of the physical substrate in the tool. The virtual factory can provide a portal for the operator to digitally access the data of the physical tool represented by the digital twin in the virtual factory and control it. Such a portal can allow the user to schedule substrates, check the tool operation status, view the room, view a series of tools, etc. from one location. The tool group can represent dozens or hundreds of tools from the same family, which run the same process as part of the batch manufacturing of semiconductor equipment. In the example of a deposition tool, the grouping level of the deposition tool includes a module (for example, including 4 stations), a tool (for example, including 3 to 5 modules, depending on the configuration) and a tool group (for example, a tool of the same family). In a semiconductor factory, many tool groups are designed to perform the same process, such as many etching tools for an application or deposition tools for different applications. In addition, digital twins can use artificial intelligence to learn how process parameters affect process results. Such artificial intelligence can be used to provide programs to the user interface (UI) to simplify the step process. In addition, using digital twins to monitor and control tools can provide safety advantages. By allowing users to interact with the digital twin of the tools in a semiconductor fab using a virtual representation of the fab, human risk, human error, and environmental impact can be reduced. Additionally, in some examples, a blockchain substrate ledger can be used to maintain tool usage records.

[0101] Figure 7A block diagram is shown, which illustrates an exemplary capability of an exemplary virtual semiconductor factory environment 700. The virtual semiconductor factory environment 700 is an example of a virtual semiconductor factory environment 102. The virtual semiconductor factory environment 700 includes one or more communication applications 702, which provide communication modes such as text chat and proximity chat, among others. The virtual semiconductor factory environment 700 also includes one or more remote work applications 704. For example, a VR or AR headset application can connect to the virtual semiconductor factory environment 700 from a remote location using an Internet connection 706. In addition, the virtual semiconductor factory environment 700 includes a management scheduling application 708, in which a user can view an indicator 710 about tool status (e.g., tool uptime and / or progress). The management scheduling application 708 also includes a scheduler 712, which is configured to allow a user to schedule further processing when connected remotely. The virtual semiconductor factory environment 700 also includes a laboratory tool training capability 714. For example, a laboratory tool training application (described herein as a tool simulator 716) is configured to enable employees to train using a simulation of a tool to understand tool functions. In addition, users can meet virtually as a team to learn, plan, and strategize by using a virtual meeting space 718. The virtual semiconductor factory environment 700 also includes a problem predictor application 720, which is configured to warn 722 users of upcoming maintenance tasks. In addition, artificial intelligence 724 (e.g., a machine learning model) can be used to determine when a predictive maintenance routine is needed. Figure 7 In other examples, the virtual semiconductor fab environment may omit one or more of the components shown and / or include additional components.

[0102] Figure 8 A block diagram is shown, which illustrates an exemplary security feature of a virtual semiconductor factory environment 800. The virtual semiconductor factory environment 800 is an example of a virtual semiconductor factory environment 102. The virtual semiconductor factory environment 800 includes a server 802 located behind a facility virtual local area network (VLAN), where only authorized users 804 can access using a virtual private network (VPN) 806. In addition, a permitted login can be entered to gain access to a specific session. After granting access to the authorized user 804, the authorized user 804 can access one or more processing tools 808 through a data layer application platform interface (API) 810. As shown, unauthorized users 812 are not allowed to access the server 802. Figure 8 In other examples, the virtual semiconductor factory environment can use another configuration.

[0103] Fig. 9A block diagram is shown, which shows an exemplary architecture 900 of a virtual semiconductor factory environment 901. The virtual semiconductor factory environment 901 is an example of a virtual semiconductor factory environment 102. The virtual semiconductor factory environment 901 includes a factory server 902 operably coupled to a plurality of processing tools 904. A remote user 906 can connect to the factory server 902 to interact with one or more of the plurality of processing tools 904. In particular, using the illustrated architecture 900, one or more remote users 906 can automatically upgrade tool software and / or firmware without the technician having to operate the tool in person. This helps to facilitate "lights-out manufacturing / production" (e.g., fully automated production). The architecture 900 can shorten the installation turnaround time by utilizing updateable patches. The installation is more secure and can be customized. As shown, factory visitors / suppliers 908 cannot access the factory server 902. Fig. 9 In other examples, the virtual semiconductor factory environment may have another configuration.

[0104] Fig. 10A -C shows a block diagram illustrating an exemplary virtual cubicle of a virtual semiconductor fab environment. Virtual "work cubicles" can be created for different types of users. Fig. 10A In the example depicted, a first virtual compartment 1000 is configured to enable a remote user 1002 (e.g., an employee of a factory) to use a virtual semiconductor factory environment 1004. The virtual semiconductor factory environment 1004 includes a factory server 1006 and multiple digital twins. In the depicted example, the multiple digital twins represent a first processing tool 1008, a second processing tool 1010, a third processing tool 1012, and a fourth processing tool 1014. In other examples, the multiple digital twins may represent one, two, three, or more than four processing tools. In the depicted example, the remote user 1002 can access the first, second, third, and fourth processing tools 1008, 1010, 1012, and 1014 in the first virtual compartment 1000. Alternatively, a service provider can use the virtual semiconductor factory environment 1004 to remotely service physical tools. Virtual compartments can be created for specific service providers and can be used to grant only the permissions required to perform services on a selected tool or multiple tools, while denying access to other tools. In Fig. 10B 1014. In the embodiment of the present invention, the second virtual compartment 1016 is configured to be used by a supplier 1018. Here, the second virtual compartment 1016 is configured to allow the supplier 1018 to access the first processing tool 1008. In addition, the supplier cannot access the second, third and fourth processing tools 1010, 1012, 1014. Similarly, the third virtual compartment 1020 is configured to allow a tool technician 1022 to access the third processing tool 1012, as shown in FIG. Fig. 10C shown. Figures 10A-10CIn other examples, the virtual cubicle and / or virtual semiconductor factory environment may have another configuration.

[0105] Fig.11 A block diagram is shown illustrating an exemplary management flow schedule 1100 of a virtual semiconductor factory environment 1102. The virtual semiconductor factory environment 1102 includes a factory server 1104 connected to a scheduler 1106. The scheduler 1106 is configured to control a process tool 1108. The factory server 1104 is connected to a digital twin 1110 of a process tool 1112. In this example, a manager / master technician 1114 can manage the operation of process tools from multiple providers using the factory server 1104. In addition, the manager / master technician 1114 can view the status 1116 of the process tool 1108.

[0106] The virtual semiconductor factory environment system can provide many other possible applications to users. An exemplary application includes a conference portal that provides meeting room formats, scenario planning, and other activity locations. Another exemplary application includes a virtual semiconductor factory environment portal. The portal can have a factory room format. Permissions are controlled by an administrator, for example, an administrator can allow users to view tools as needed. Another exemplary application includes a tool browser. The tool browser can allow users to check tool components and connectivity (e.g., 3D model viewing), can perform machine learning (recipe optimization), can perform machine learning related to procedures / maintenance (preventive maintenance, predictive maintenance), and can provide real-time tool operation status and substrate scheduling functions. Another exemplary application includes a substrate ledger application that tracks tool-level and substrate-level information. Another exemplary application includes a virtual semiconductor factory environment management panel. The virtual semiconductor factory environment management panel can provide tools for setting automatic jobs to be run, and allows security configurations to be set and modified.

[0107] The user can connect to the virtual semiconductor factory in any suitable manner. For example, a user of a VR or AR headset (or other suitable computer device, such as a laptop, desktop computer, tablet computer, etc.) can connect to a local host (e.g., a laptop or desktop device), which can authenticate the user. The user then selects the virtual semiconductor factory client application, which opens a launcher, allowing the user to enter and experience the virtual semiconductor factory environment.

[0108] Compared with physically interacting with each tool in the factory, the virtual semiconductor factory environment can provide multiple advantages. For example, the use of the virtual semiconductor factory environment can allow for increased productivity, through user interaction and machine learning assistance, automatic substrate operation scheduling and delivery, pleasant work environment methods, and artificial intelligence (AI) for recipe optimization and predictive maintenance. The virtual semiconductor factory environment can also reduce costs. For example, the use of the virtual semiconductor factory environment can reduce employee travel time, reduce physical seats at the company's location, and reduce electricity consumption due to reduced facility occupancy. The disclosed virtual semiconductor factory environment can also reduce exposure to laboratory hazards. In addition, if a laboratory hazard alarm occurs, the number of people who need to be evacuated will be reduced or no personnel. For example, the number of employees who are responsible for clearing any alarms may be the only personnel during factory operations. In addition, other employees can continue to use the virtual semiconductor factory environment for remote work. The virtual semiconductor factory environment can also provide increased social interaction because employees can discuss and work in the same virtual space. This can narrow the communication gap for managers because managers and employees can enter the same workspace for discussion.

[0109] In some embodiments, the methods and techniques described herein may be bound to a computing system of one or more computing devices. Specifically, such methods and techniques may be implemented as a computer application or service, an application programming interface (API), a link library, and / or other computer program products.

[0110] Fig.12 A non-limiting embodiment of a computing system 1200 is schematically shown, which can perform one or more of the above methods and processes. The computing system 1200 is shown in a simplified form. The computing system 1200 can adopt one or more personal computers, server computers, tablet computers, home entertainment computers, network computing devices, gaming devices, mobile computing devices, mobile communication devices (e.g., smart phones), and / or other computing devices. The computing system 1200 can represent any computing system within a virtual semiconductor factory environment, including a computing system on a processing tool, a virtual semiconductor factory environment server located in a factory and / or a remote data center, and a user client device, such as an AR and VR device, which includes a user application for interacting with a virtual semiconductor factory environment. The computing system 200 and the client device 604 are examples of the computing system 1200.

[0111] The computing system 1200 includes a logic subsystem 1202 and a storage subsystem 1204. The computing system 1200 may optionally include a display subsystem 1206, an input subsystem 1208, a communication subsystem 1210, and / or Fig.12 Other parts not shown.

[0112] Logic subsystem 1202 includes one or more physical devices configured to execute instructions. For example, the logic machine can be configured to execute instructions as part of one or more applications, services, programs, routines, libraries, objects, components, data structures, or other logical constructs. Such instructions can be implemented to perform tasks, implement data types, transform the state of one or more components, achieve technical effects, or otherwise achieve desired results.

[0113] The logic machine may include one or more processors configured to execute software instructions. Additionally or alternatively, the logic machine may include one or more hardware or firmware logic machines configured to execute hardware or firmware instructions. The processor of the logic machine may be single-core or multi-core, and the instructions executed thereon may be configured for sequential, parallel and / or distributed processing. The various components of the logic machine may optionally be distributed in two or more separate devices that may be remotely located and / or configured for coordinated processing. Various aspects of the logic machine may be virtualized and executed by a remotely accessible networked computing device configured in a cloud computing configuration.

[0114] The storage subsystem 1204 includes one or more physical devices configured to store instructions that can be executed by a logic machine to implement the methods and processes described herein. When such methods and processes are implemented, the state of the storage subsystem 1204 can be transformed—for example, to store different data.

[0115] The storage subsystem 1204 may include removable and / or built-in devices. The storage subsystem 1204 may include optical storage (e.g., CD, DVD, HD-DVD, Blu-ray disc, etc.), semiconductor storage (e.g., RAM, EPROM, EEPROM, etc.), and / or magnetic storage (e.g., hard disk drive, floppy disk drive, tape drive, MRAM, etc.). The storage subsystem 1204 may include volatile, non-volatile, dynamic, static, read / write, read-only, random access, sequential access, location addressable, file addressable, and / or content addressable devices.

[0116] It should be understood that storage subsystem 1204 includes one or more physical devices. However, alternatively, aspects of the instructions described herein may be propagated via a communication medium (eg, electromagnetic signals, optical signals, etc.) that is not held by a physical device for a limited duration.

[0117] Aspects of logic subsystem 1202 and storage subsystem 1204 may be integrated together into one or more hardware logic components. For example, such hardware logic components may include field programmable gate arrays (FPGAs), program and application specific integrated circuits (PASIC / ASICs), program and application specific standard products (PSSP / ASSPs), systems on chips (SOCs), and complex programmable logic devices (CPLDs).

[0118] When included, display subsystem 1206 can be used to present a visual representation of the data stored by storage subsystem 1204. This visual representation can take the form of a graphical user interface (GUI). Since the methods and processes described herein change the data held by the storage machine, and therefore change the state of the storage machine, the state of display subsystem 1206 can also be converted to visually represent the change of the underlying data. Display subsystem 1206 can include one or more display devices using almost any type of technology. Such a display device can be combined with the logic subsystem 1202 and / or storage subsystem 1204 in a shared cabinet (a shared enclosure), or such a display device can be a peripheral display device.

[0119] When included, the input subsystem 1208 may include or may interact with one or more user input devices (e.g., a keyboard, mouse, touch screen, or game controller). In some embodiments, the input subsystem may include or interact with selected natural user input (NUI) components. Such components may be integrated or peripheral, and the conversion and / or processing of input actions may be processed on-board or off-board. Exemplary NUI components may include microphones for speech and / or voice recognition, and infrared, color, stereo, and / or depth cameras for machine vision and / or gesture recognition; head trackers, eye trackers, accelerometers, and / or gyroscopes for movement detection and / or intent recognition; and electric field sensing components for assessing brain activity.

[0120] When included, the communication subsystem 1210 can be configured to communicatively couple the computing system 1200 with one or more other computing devices. The communication subsystem 1210 can include wired and / or wireless communication devices compatible with one or more different communication protocols. As non-limiting examples, the communication subsystem can be configured to communicate via a wireless telephone network, or a wired or wireless local area network or wide area network. In some embodiments, the communication subsystem can allow the computing system 1200 to send messages to other devices and / or receive messages from other devices via a network such as the Internet.

[0121] It should be understood that the configuration and / or method described herein is exemplary in nature, and these specific one or more embodiments should not be considered as restrictive, because many variations are possible. The specific routine or method described herein can represent one or more of any number of processing strategies. Therefore, the various actions shown and / or described can be performed in the order shown and / or described, in other orders, in parallel or omitted. Similarly, the order of the above-mentioned process can be changed.

[0122] The subject matter of the present disclosure includes all novel and nonobvious combinations and subcombinations of the various processes, systems and configurations, and other features, functions, acts, and / or properties disclosed herein, as well as any and all equivalents thereof.

Claims

1. A method of monitoring a process performed on a substrate in a processing tool, the method comprising: obtaining runtime data from sensors of the processing tool while the process is running in the processing tool; performing a runtime simulation by simulating a digital twin using the runtime data and a recipe for the process; receiving a selection of a spatial viewpoint in the digital twin of the processing tool; rendering an image of a virtual state of the processing tool using the runtime simulation and the spatial viewpoint; as well as The image of the virtual state is output.

2. The method of claim 1 , wherein receiving the selection of the spatial viewpoint in the digital twin comprises: A selection of two or more spatial viewpoints is received, and wherein rendering the image of the virtual state of the processing tool includes rendering a first image of the virtual state at a first spatial viewpoint and rendering a second image of the virtual state at a second spatial viewpoint. 3 . The method of claim 1 , wherein rendering the image of the virtual state of the processing tool comprises changing one or more of a position, orientation, or field of view of a rendering camera within the digital twin. 4 . The method of claim 1 , wherein rendering the image of the virtual state of the processing tool comprises rendering a video depicting an evolution of the virtual state of the processing tool over time.

5. The method of claim 1, wherein the image comprises one or more of a simulated thermal image, a simulated visual image, a simulated density image, or a simulated field.

6. The method according to claim 1 also includes obtaining a substrate map of metrology data of the substrate processed using the process in the processing tool, and wherein rendering the image of the virtual state of the processing tool also includes superimposing a representation of the substrate map of the metrology data on the virtual substrate of the runtime simulation.

7. The method of claim 1 , wherein the runtime simulation is a first runtime simulation for a process including one or more anomalies, the virtual state is a first virtual state, the runtime data is a first runtime data, and the method further comprises: obtaining a second virtual state of the processing tool from a second runtime simulation of the digital twin, the second runtime simulation simulated using second runtime data from a process without anomalies; comparing at least a portion of the first virtual state to a corresponding portion of the second virtual state; as well as One or more differences are output based on the comparison.

8. A computing device comprising: Display subsystem; Logical subsystem; as well as A storage subsystem comprising instructions executable by the logic subsystem to receiving user input selecting a spatial viewpoint in the digital twin of a processing tool, receiving user input selecting a set of runtime data obtained by the processing tool, providing the user input selecting the spatial viewpoint and the user input selecting the set of runtime data to a simulation service of a virtual semiconductor fab environment, receiving, from the simulation service, data from a runtime simulation representing a virtual state of the process tool using the digital twin, and A rendered image of the virtual state is displayed from the selected spatial viewpoint.

9. A computing device according to claim 8, wherein the instructions for receiving the user input selecting the group of runtime data obtained by the processing tool include instructions executable to receive user input from multiple different spatial viewpoints, and wherein the instructions executable to display the rendered image of the virtual state from the spatial viewpoint include instructions executable to display the rendered image from the multiple different spatial viewpoints.

10. The computing device of claim 8, wherein the instructions are further executable to receive input that changes one or more of a position, orientation, or field of view of a rendering camera within the digital twin, and to display an updated rendered image of the virtual state after changing one or more of the position, orientation, or field of view.

11. The computing device of claim 8, wherein the computing device comprises a head mounted display device.

12. The computing device of claim 11, wherein the instructions executable to receive the user input selecting the spatial viewpoint include instructions executable to receive user input via one or more of a head tracking camera, a microphone, or an eye tracking camera.

13. The computing device of claim 8, wherein the virtual state comprises a substrate map, and wherein the instructions executable to display the rendered image of the virtual state comprise instructions executable to display the substrate map on a virtual substrate.

14. The computing device of claim 8, wherein the instructions are further capable of executing receiving notification of an anomaly in the set of runtime data, and In response, the notification is displayed.

15. A computing system comprising: a logic subsystem including one or more processors; as well as A storage subsystem comprising instructions executable to operate a digital twin of a processing tool, the storage subsystem further comprising instructions executable by the one or more processors to obtaining runtime data from the processing tool, the runtime data comprising data obtained by sensors of the processing tool while a process is running in the processing tool, detecting anomalies in the runtime data, In response to detecting the abnormal condition, simulating the digital twin using one or more of the runtime data or a recipe for the process to perform a runtime simulation, and A probable cause of the abnormal condition is determined using data from the runtime simulation.

16. The computing system of claim 15, wherein the instructions are further executable to determine a recommended diagnostic procedure.

17. The computing system of claim 16, wherein the instructions are further executable to output one or more of an alert indicating the abnormal condition or the recommended diagnostic procedure.

18. The computing system of claim 15, wherein the instructions are further executable to render an image of a virtual state of the processing tool using the runtime simulation.

19. The computing system of claim 18, wherein the image comprises one or more of a simulated thermal image, a simulated visual image, or a simulated density image, or a simulated field.

20. The computing system of claim 15, wherein the runtime simulation is a first runtime simulation, the runtime data is first runtime data, and the instructions are further executable to: obtaining a first virtual state of the process tool from the first runtime simulation of the digital twin, the first runtime simulation of the digital twin simulated using the first runtime data from the process; obtaining a second virtual state of the process tool from a second runtime simulation of the digital twin, the second runtime simulation of the digital twin simulated using second runtime data from a process without anomalies; comparing at least a portion of the first virtual state to a corresponding portion of the second virtual state; as well as One or more differences in the comparison are output.

Images