Protecting data sources from different entities for semiconductor yield-related applications

Abstract

A method and system are provided for performing functions using protected data sources from different entities. One system includes a virtual system 116 coupled to real systems 110, 112, thereby receiving output generated by the real systems 110, 112 for physical versions of the specimens while the specimens are located within the real systems 110, 112. The virtual system 116 includes at least a computer system and a storage medium. The virtual system 116 is not capable of locating the physical versions of the specimens. The virtual system 116 is configured to perform one or more functions on the specimens using two or more protected data sources, each from two or more different entities. The virtual system 116 is also configured to execute virtual versions of processes that can be performed by the real systems 110, 112 for the physical versions of the specimens.

Description

[Technical Field]

[0001] The present invention generally relates to methods and systems for performing one or more functions using secured data sources from different entities. [Background technology]

[0002] The following descriptions and examples are not admitted to be prior art by virtue of their inclusion in this section.

[0003] The fabrication of semiconductor devices, such as logic and memory devices, typically involves processing a substrate, such as a semiconductor wafer, using multiple semiconductor manufacturing processes to form the various functions and multiple layers of the semiconductor device. For example, lithography is a semiconductor manufacturing process that involves transferring a pattern from a reticle to a resist that is disposed on the semiconductor wafer. Further examples of semiconductor manufacturing processes include, but are not limited to, chemical mechanical polishing (CMP), etching, deposition, and ion implantation. Multiple semiconductor devices can be fabricated on a single semiconductor wafer and then separated into individual semiconductor devices.

[0004] Inspection processes are used at various steps during the semiconductor manufacturing process to detect defects on specimens in order to increase the yield of the manufacturing process and thereby increase profits. Inspection has always played an important role in the manufacture of semiconductor devices. However, as the dimensions of semiconductor devices shrink, inspection becomes even more important to the successful manufacture of qualified semiconductor devices because smaller defects can cause device failures.

[0005] Defect review typically involves redetecting defects detected by the inspection process and generating additional information about the defects at higher resolution using either a high-magnification optical system or a scanning electron microscope (SEM). Thus, defect review is performed at discrete locations on the specimen where defects were detected by inspection. The higher-resolution data about the defects generated by defect review is better suited to determining defect attributes, such as profile, topography, or more precise size information. Defects can generally be more accurately classified into multiple defect types based on information determined by defect review than by inspection.

[0006] Metrology processes are also used at various steps during semiconductor manufacturing processes to monitor and control the process. Metrology processes differ from inspection processes in that, unlike inspection processes in which defects are detected on a specimen, metrology processes are used to measure one or more characteristics of the specimen that cannot be determined using currently used inspection tools. For example, a metrology process may be used to measure one or more characteristics of the specimen, such as the dimensions (e.g., linewidth, thickness, etc.) of features formed on the specimen during the process, thereby allowing the performance of the process to be determined from the one or more characteristics. Furthermore, if one or more characteristics of the specimen are unacceptable (e.g., outside a predetermined range of characteristics), the measurements of the one or more characteristics of the specimen may be used to modify one or more parameters of the process so that additional specimens produced by the process have acceptable characteristics.

[0007] The metrology process also differs from the defect review process in that, unlike defect review, defects detected by inspection are revisited during defect review, and the metrology process can be performed at locations where no defects have been detected. In other words, unlike defect review, the location at which the metrology process is performed on the specimen can be independent of the results of the inspection process performed on the specimen. In particular, the location at which the metrology process is performed can be selected independent of the inspection results. Additionally, unlike defect review, where the location on the specimen at which the defect review is performed cannot be determined until the inspection results of the specimen are generated and available, because the location on the specimen at which the metrology is performed can be selected independent of the inspection results, the location at which the metrology process is performed can be determined before the inspection process is performed on the specimen.

[0008] The goal of semiconductor manufacturers is to repeatably produce wafers, chips, packages, subsystems, etc. that predictably fulfill their intended end use while minimizing waste by maximizing yield at every step in the value chain. The ultimate measure of success is the electrical behavior of the circuit (determined by solid-state physics) over time (reliability under operating conditions) (functionality within performance specifications).

[0009] The root of the problems with current semiconductor manufacturing methods and systems is the fragmentation of the semiconductor value chain, which has been essential to the industry's economic growth. The revolutionary separation of design and manufacturing that took place in the early 1980s led to the current economic segments of foundry, fabless, electronic design automation (EDA), and semiconductor manufacturing equipment. As a result, each segment can largely optimize its economies based on market forces. Since its inception, the semiconductor value chain has evolved into a complex, multinational network of specialized subsegments, each with its own shareholder value optimization mandate. This segmentation has inevitable implications for intellectual property (IP) protection at the boundaries between companies, each of which is mandated to maximize its own shareholder value. As a result, there is a great deal of "friction" (and in many cases, outright obstruction) in the flow of data technically required to monitor, diagnose, optimize, and control the complex, numerous process steps involved in creating semiconductor-based products. Further complicating the situation, the limits of process, metrology, and inspection physics are being challenged as Moore's Law advances. [Prior art documents] [Patent documents]

[0010] [Patent Document 1] U.S. Patent Application Publication No. 2020 / 0273156 [Patent Document 2] U.S. Patent Application Publication No. 2018 / 0359259 Summary of the Invention [Problem to be solved by the invention]

[0011] It would therefore be advantageous to develop a system and / or method for performing one or more functions using secured data sources from different entities that does not have one or more of the above disadvantages. [Means for solving the problem]

[0012] The following description of various embodiments is not to be construed in any way as limiting the subject matter of the appended claims.

[0013] One embodiment relates to a system configured to perform one or more functions using protected data sources from different entities. The system includes a virtual system coupled to a real system, thereby receiving output generated by the real system for a physical version of the specimen while the specimen is located within the real system. The virtual system includes at least a computer system and a storage medium. The virtual system is not capable of having the physical version of the specimen located therein. The virtual system is configured to perform one or more functions on the specimen using two or more protected data sources from two or more different entities. The virtual system is also configured to execute a virtual version of a process that can be executed by the real system for the physical version of the specimen. The system may be further configured as described herein.

[0014] Another embodiment relates to a computer-implemented method for performing one or more functions using protected data sources from different entities. The method includes performing one or more functions on a specimen using two or more protected data sources from two or more different entities, respectively. The method also includes executing a virtual version of a process that can be performed by the real system using output generated by the real system for a physical version of the specimen while the specimen is located in the real system. The one or more functions and the virtual version of the process are executed by a virtual system that is coupled to the real system and thereby receives output generated by the real system for the physical version of the specimen. The virtual system comprises at least a computer system and a storage medium. The virtual system is not capable of having a physical version of the specimen located therein.

[0015] The method may be performed as further described herein. In addition, the method may include any other step(s) of any other method(s) described herein. Furthermore, the method may be performed by any of the systems described herein.

[0016] Further embodiments relate to a non-transitory computer-readable medium storing program instructions executable on a computer system for performing one or more functions using protected data sources from different entities. The computer-implemented method includes the method steps described above. The computer-readable medium may be further configured as described herein. The steps of the computer-implemented method may be performed as further described herein. In addition, the computer-implemented method on which the program instructions are executable may include any other steps of any other method described herein.

[0017] Other objects and advantages of the present invention will become apparent upon reading the following detailed description and upon reference to the accompanying drawings. [Brief explanation of the drawings]

[0018] [Figure 1] FIG. 1 is a schematic diagram showing a side view of one embodiment of a system configured as described herein. [Figure 2] FIG. 1 is a block diagram illustrating one embodiment of a system configured as described herein. [Figure 3] 10 is a flow chart illustrating an embodiment in which secured data sources from different entities are used to perform one or more functions on a specimen and / or to perform a virtual version of a process on a specimen. [Figure 4] 10 is a flow chart illustrating an embodiment in which secured data sources from different entities are used to perform one or more functions on a specimen and / or to perform a virtual version of a process on a specimen. [Figure 5]10 is a flow chart illustrating an embodiment in which secured data sources from different entities are used to perform one or more functions on a specimen and / or to perform a virtual version of a process on a specimen. [Figure 6] 10 is a flow chart illustrating an embodiment in which secured data sources from different entities are used to perform one or more functions on a specimen and / or to perform a virtual version of a process on a specimen. [Figure 7] 10 is a flow chart illustrating an embodiment in which secured data sources from different entities are used to perform one or more functions on a specimen and / or to perform a virtual version of a process on a specimen. [Figure 8] 10 is a flow chart illustrating an embodiment in which secured data sources from different entities are used to perform one or more functions on a specimen and / or to perform a virtual version of a process on a specimen. [Figure 9] FIG. 1 is a block diagram illustrating one embodiment of a non-transitory computer-readable medium storing program instructions executable on a computer system to perform one or more of the computer-implemented methods described herein. DETAILED DESCRIPTION OF THE INVENTION

[0019] While the invention is susceptible to various modifications and alternative forms, specific embodiments thereof have been shown by way of example in the drawings and are herein described in detail. It should be understood, however, that the drawings and detailed description are not intended to limit the invention to the particular forms disclosed, but on the contrary, are intended to cover all modifications, equivalents, and alternatives falling within the spirit and scope of the invention as defined by the appended claims.

[0020] The terms "design" and "design data," as used herein, generally refer to the physical design (layout) of an IC and data derived from the physical design through complex simulations or simple geometric and Boolean operations. Additionally, images of a reticle acquired by a reticle inspection system and / or derivatives thereof can be used as a "proxy" or "proxies" for the design. Such reticle images or derivatives thereof can serve as substitutes for the design layout in any embodiment described herein that uses a design. The design can include any other design data or design data proxies described in commonly owned U.S. Patent No. 7,570,796, issued to Zafer et al. on August 4, 2009, and U.S. Patent No. 7,676,077, issued to Kulkarni et al. on March 9, 2010, both of which are incorporated herein by reference as if fully set forth herein. Additionally, design data can be standard cell library data, integrated layout data, design data for one or more layers, derivatives of design data, and full or partial chip design data.

[0021] However, design information or data generally cannot be generated by imaging a wafer with a wafer inspection system. For example, design patterns formed on a wafer may not accurately represent the wafer's design, and wafer inspection systems may not be able to generate images of design patterns formed on a wafer with sufficient resolution so that information about the wafer's design can be determined using the images. Therefore, design information or design data typically cannot be generated using a physical wafer. Additionally, "design" and "design data," as used herein, refer to information and data generated by a semiconductor device designer in the design process and, therefore, usable in the embodiments described herein, well in advance of printing the design on any physical wafer.

[0022] Turning now to the drawings, it should be noted that the figures are not drawn to scale. In particular, the scale of some of the elements in the figures may be greatly exaggerated to emphasize the characteristics of the elements. It should also be noted that the figures are not drawn to the same scale. Elements shown in multiple figures that may be similarly configured are indicated using the same reference numerals. Unless otherwise stated herein, any of the elements described and illustrated may include any suitable commercially available elements.

[0023] One embodiment relates to a system configured to perform one or more functions using protected data sources from different entities. The novelty of the embodiments described herein is that they are configured, at least in part, to mitigate the concerns of stakeholders of protected data sources who are required to collaborate to make their data available for use in the functions further described herein. Data security is ensured by the embodiments described herein through a combination of physical, electronic, and algorithmic techniques.

[0024] In one embodiment, the specimen comprises a wafer. The wafer can include any wafer known in the semiconductor art. Although some embodiments may be described herein with respect to one or more wafers, the embodiments are not limited to the specimens with which they may be used. For example, the embodiments described herein may be used with specimens such as reticles, flat panels, personal computer (PC) boards, and other semiconductor specimens.

[0025] The system comprises a virtual system that is coupled to the real system, thereby receiving output generated by the real system for a physical version of the specimen while the specimen is located within the real system. Generally, a "real system," as the term is used herein, refers to a system that performs a process on or with an actual physical specimen, i.e., a real process. In contrast, a "virtual system," as the term is used herein, refers to a system that performs a process on a specimen, i.e., a virtual process, that does not use or interact with the actual physical specimen.

[0026] The system may or may not include a real system configured to perform one or more processes on the specimen while the specimen is placed in the real system, thereby generating output for the specimen. Typically, the one or more processes performed on the specimen by the real system are yield-control related processes, such as inspection, probing, metrology, and testing. The processes performed by the real system are not intended to include processes performed by reticle or wafer manufacturing tools that alter one or more characteristics of the reticle or wafer. For example, a wafer removed from a wafer inspection tool will have substantially the same characteristics as when it was placed in the wafer inspection tool (unless, of course, something significantly wrong occurs). However, while there may be some instances in which a yield-control related process may alter one or more characteristics of the specimen, the altered characteristics are not intended to alter the functionality of a device formed on or using the specimen. For example, intentional "burns" may be left by a scanning electron microscope (SEM) to aid in subsequent relocation of specific points. In contrast, a wafer removed from a manufacturing tool will typically (again, unless some significant problem occurs, such as a process failure) have different properties (physical, chemical, etc.) than they had when placed in the manufacturing tool, thereby altering the properties of devices formed on or using the specimen.

[0027] Because a real system performs one or more processes on a specimen while the specimen is located within the real system, the real system will include some type of specimen handling device or subsystem (such as a stage, a motor that drives the stage, a wafer or reticle handling robot, etc.). The specimen handling device or subsystem typically controls the position of the specimen within the real system. In this manner, the real systems described herein are configured to perform processes on the physical specimen itself, which is in contrast to the virtual systems described further herein, which do not interact with the physical specimen despite being capable of performing one or more functions on it.

[0028] Performing one or more processes on a specimen using a real system typically results in some output (e.g., an image, data, image data, signal, image signal, etc.) being generated by the real system. For example, during a process, a detector or sensor of the real system may generate one or more images of the specimen. The real system may also include one or more computer subsystems that perform some function, algorithm, or method on the output generated by the one or more detectors or sensors of the real system. For example, the computer subsystem of the real system may perform defect detection for the specimen using the output generated by the detectors of the real system. The results of the defect detection, or any other function, method, or algorithm, may also be output from the real system as described further herein. Thus, the real systems described herein may generate a wide variety of outputs, all or only some of which may be received by a virtual system as described further herein.

[0029] A virtual system can be coupled to only one real system or to two or more real systems. When a virtual system is coupled to two or more real systems, the real system can include two of the same systems. For example, as shown in FIG. 1 , a system can include two real systems 100 and 102. Each of the two real systems includes a light source 104 configured to generate light. The real systems also include a beam splitter 106 configured to direct light from the light source to a specimen 108. The specimen 108 is supported within each of the real systems by a stage 110. Light reflected, scattered, diffracted, or otherwise returned from the specimen can be transmitted by the beam splitter 106 to a detector 112 included in each of the real systems. The detector is configured to generate an output, such as an image, image data, a signal, or any other suitable output, in response to the light detected by the detector.

[0030] The detector outputs can be received by a computer subsystem 114 included in each of the real systems. The computer subsystem 114 can be coupled to each of the detectors in any suitable manner. The computer subsystem can be configured to use the detector outputs to determine one or more properties of the specimen. The one or more properties determined by the computer subsystem vary depending on the configuration of the real system in which the actual process is being performed and the specimen.

[0031] Thus, the real systems shown in FIG. 1 may have the same configuration and thus be the same type of system. However, a real system may include two systems with different configurations. For example, any of the elements of the real systems shown in FIG. 1 may be selected to be different. In one such example, the real systems may have different types of light sources, may be configured to perform one or more processes on different samples, may have different detectors, etc. In general, the real systems coupled to a virtual system may include any number and combination of real systems of any type. In addition, the real systems may each be configured as physically separate systems, which may be coupled by other hardware or software as further described herein.

[0032] 1 is provided to broadly illustrate one configuration of a real system that can be coupled to a virtual system in the embodiments described herein. Clearly, the real system configuration described herein can be modified to optimize the performance of the real system, as is typically performed when designing a yield control-related system for a specimen described herein. In addition, the system described herein can be implemented using an existing real system (e.g., by adding the functionality described herein to an existing real system), such as tools commercially available from KLA Corp., Milpitas, California, USA. Alternatively, the real system described herein can be designed "from scratch" to provide an entirely new real system.

[0033] When a virtual system is coupled to two or more real systems, the real systems that generate the output received and used by the virtual system in the embodiments described herein can include different combinations of real systems. For example, the real systems can include at least one inspection tool and at least one other tool, such as a defect review tool, a different inspection tool, an electrical tester, or a combination of two or more of the defect review tool, the different inspection tool, the electrical tester, etc. These embodiments can be configured as further described herein.

[0034] As shown in FIG. 2 , the real system can include a reticle inspection tool 200 and / or a reticle defect review tool 202. The reticle inspection and defect review tools can be optical-based and / or electron-beam-based tools. Furthermore, the same real system can be configured as both a reticle inspection tool and a reticle defect review tool. The reticle inspection and / or defect review tool can include any suitable commercially available system. Additionally, the reticle inspection and / or defect review tool can be configured to perform any type of inspection and / or review. The reticle inspection and / or defect review tool can be configured to generate output, e.g., images or data, for the reticle in one or more imaging modes.

[0035] Additionally or alternatively, the real system may include at least one wafer inspection tool and / or wafer defect review tool. The wafer inspection and wafer defect review tools may be optical-based tools. For example, as shown in FIG. 2, the real system may include optical wafer inspection system 204 and / or optical wafer defect review system 206. In addition, the same real system may be configured as both a wafer inspection tool and a wafer defect review tool. The optical-based wafer inspection and / or defect review tool may include any suitable commercially available system, such as the Puma system, 29xx and 39xx systems, and the SPx, Surfscan, and Surfimage systems, commercially available from KLA. In addition, the optical-based wafer inspection and / or defect review tool may be configured to perform any type of inspection and / or review, such as dark-field (DF) laser scattering, narrowband bright-field (BF), broadband BF, etc. The optical-based wafer inspection and / or defect review tool may also include any suitable light source, such as a broadband plasma (BBP)-based light source. Wafer inspection and / or defect review tools can be configured to generate output (eg, images or data) for the wafer in one or more imaging modes.

[0036] The wafer inspection tool and / or wafer defect review tool may alternatively be configured as an electron beam-based tool. For example, as shown in FIG. 2, a system may include electron beam wafer inspection tool 208 and / or electron beam wafer defect review tool 210. In addition, the same physical system may be configured as both a wafer inspection tool and a wafer defect review tool. The electron beam-based wafer inspection and / or defect review tool may include any suitable commercially available system, such as the eDRxxxx systems commercially available from KLA.

[0037] A real system can include at least one metrology tool. For example, as shown in FIG. 2 , the real system can include metrology tool 212. The metrology tool can include any suitable commercially available metrology tool. The metrology tool can be configured to measure or determine any one or more characteristics of any of the specimens described herein. For example, the metrology tool can be configured as a scatterometry system configured to measure or determine critical dimensions or critical dimension uniformity of features patterned on a wafer. Metrology tools differ from inspection tools in that metrology tools typically do not scan across a wafer or reticle and generate output at each scan location. Instead, metrology tools often perform measurements at one or a limited number of measurement spots on a wafer or reticle in a move-acquire-measure type scenario. In some cases, the metrology tool can perform measurements based on the output or results of another real system described herein. For example, the metrology tool can be used to measure one or more characteristics of defects detected by inspection. Control of the metrology tool in this manner can be further performed as described herein.

[0038] 2, the production system may further include at least one electrical tester, such as electrical tester 214. The electrical tester may include any suitable commercially available electrical test system. The electrical tester may be a contact system in which one or more elements of the system contact one or more device structures formed on a specimen, such as a wafer, to establish an electrical connection between the wafer and the tester. Alternatively, the electrical tester may be a non-contact system in which none of the elements contact the wafer during testing.

[0039] Although a wide variety of specific tools that can be real systems are described herein, the present invention is not limited to these specific tools. For example, it is contemplated that a real system can include any real system configured to perform one or more processes on a wafer, reticle, or other specimen described herein. In one such example, a real system can also include a failure analysis tool and / or a material analysis tool. In addition, a real system is not limited to optical and electron beam-based tools. For example, a real system can include ion beam-based tools such as commercially available focused ion beam (FIB) systems, helium ion microscope (HIM) systems, and secondary ion mass spectrometry (SIMS) systems.

[0040] As described above, a system includes a virtual system that is coupled to a real system and thereby receives output generated by the real system. For example, as shown in FIG. 1, real systems 100 and 102 are coupled to virtual system 116. In one embodiment, detector 112 of the real system can be coupled to the virtual system such that the detector's output can be sent directly to the virtual system. In this manner, the virtual system can receive the detector's raw output (i.e., output unaltered by any data, signal, or other processing). Additionally or alternatively, computer subsystem 114 of the real system can be coupled to the virtual system such that the computer subsystem can send the detector's output and / or any other information generated by the computer subsystem to the virtual system. The virtual system can also be coupled to the computer subsystem, detector, and any other elements of the real system. As further described herein, the virtual system can be coupled to any component of the real system. For example, virtual system 116 can be coupled to computer subsystem 114, as indicated by the dashed line in FIG. 1, by any suitable transmission medium, which may include any suitable wired and / or wireless transmission medium known in the art. Virtual system 216 can be coupled in any of the same ways to any or all of the real systems shown in FIG.

[0041] As discussed above, the real system can include a wide variety of different real systems in various combinations. Thus, the output received from the real systems can be different and can vary depending on the configuration of the real systems and / or the real processes performed on the specimens by the real systems. For example, the output can include mapping of spatially continuous data (such as may be generated by a scanning real system), spatially discrete data (such as may be generated by a moving-acquisition-measurement system), metrology data, point defect detection data, etc.

[0042] A virtual system comprises at least a computer system and a storage medium. The term "computer system" is used interchangeably herein with the term "computer subsystem." Each of the computer subsystems or systems described herein can take various forms, including a personal computer system, an image computer, a mainframe computer system, a workstation, a network appliance, an internet appliance, or other device. In general, the term "computer system" can be broadly defined to encompass any device with one or more processors that executes instructions from a memory medium. A computer subsystem or system can also include any suitable processor known in the art, such as a parallel processor. In addition, a computer subsystem or system can include a computer platform with high-speed processing and software, whether a stand-alone or network-connected tool. The storage medium can include any suitable storage medium known in the art or further described herein.

[0043] Although the virtual system is depicted in the figures as having a particular computer configuration, it is understood that the virtual system can have any suitable computer-like configuration. For example, the virtual system depicted in FIG. 1 can be formed only from the virtual system's processor, memory, and input / output components, rather than any components capable of accepting user input (e.g., keyboard, mouse, screen, etc.). In this manner, the virtual system may not include all of the components that typically constitute a self-contained, fully functional computer system. However, in other examples, the virtual system can resemble a fully functional computer system in that a user can directly use the virtual system to perform one or more functions using any of the data stored therein. In addition, two or more workstations or users can access the virtual system simultaneously, remotely, and / or wirelessly. For example, as depicted in FIG. 1, multiple workstations 118 and 120 can be simultaneously coupled to the virtual system. In this manner, multiple users can access the virtual system, or the data stored in the virtual system, and use the virtual system to perform one or more of the functions described further herein.

[0044] A virtual system does not have a physical version of a specimen located within it. For example, a virtual system may be configured to perform one or more functions on a specimen, but the virtual system is not configured to perform one or more functions on the specimen. Instead, one or more functions for the specimen may be performed on data or other output generated by a real process performed on the specimen by a real system. Thus, unlike the real systems described herein, a virtual system may not have any specimen handling capabilities, such as a stage, motors coupled to a stage, specimen handling devices, or robots. Additionally, while a virtual system may be configured to control one or more real systems such that the real systems perform processes on real specimens, the virtual system itself cannot perform any real processes on real specimens. In one such embodiment, the virtual system may be configured as a virtual inspector (VI or VIVA). A VI can generally be defined as a computer system capable of storing a large amount of output generated on a specimen by an inspection subsystem, so that this output can be "played back" to mimic real-time acquisition of the output, while a virtual inspection can be performed on the specimen using only the stored output.

[0045] The virtual and real systems are disclosed in U.S. Patent Nos. 8,126,255 issued to Bhaskar et al. on February 28, 2012, 9,222,895 issued to Duffy et al. on December 29, 2015, 9,816,939 issued to Duffy et al. on November 14, 2017, and 9,916,965 issued to Bhaskar et al. on March 13, 2018. Nos. 10,402,461, issued September 3, 2019, to Karsenti et al., 10,416,088, issued September 17, 2019, to Duffy et al., 10,539,612, issued January 21, 2020, to Duffy, and 10,551,827, issued February 4, 2020, which are incorporated herein by reference as if fully set forth herein.

[0046] The virtual system is configured to perform one or more functions on a specimen using two or more secured data sources from two or more different entities, respectively. In this manner, the embodiments described herein provide benefits for semiconductor process control by eliminating "barriers of distrust" by enabling "adversarial collaboration." For example, the VI concept has evolved over time from its original concept of large-scale image capture and playback (inspector emulation). This evolution is represented by the patents incorporated by reference above. Nevertheless, practical application of applications enabled by the body of VI innovation can be significantly enhanced by protected data access, as further described herein, in accordance with intellectual property (IP) protection policies among multiple companies that possess the necessary data sources. Embodiments of one or more functions performed by a virtual system with two or more secured data sources are further described herein.

[0047] The term "entity," as used herein, is defined as any entity that protects a data source, particularly a protected data source related to the semiconductor field, from another entity. Accordingly, the term "distinct entities," as used herein, is defined as any entities that separately protect distinct data sources from one another. These entities may include individuals and groups of individuals, but are more likely to be different companies, corporations, organizations, academic institutions, consortia, joint ventures, etc. that create and protect IP related in some way to the manufacturing of semiconductor devices. In this manner, an entity can include any legally recognized entity that has rights to some IP that it is interested in protecting from another legally recognized entity. A distinct entity could also be an "adversary," such as a shareholder associated with a different corporate entity that has a fiduciary responsibility to the stakeholders of the respective entity.

[0048] The term "protected data source," as used herein, is defined as any IP that a legally recognized entity has an interest in preventing from being disseminated to the public. A protected data source as described herein may include information classified by the entity as a trade secret, but is not necessarily required for purposes of the embodiments described herein. In other words, regardless of any protection that may or may not be required by the entity, legally or otherwise, a data source may be considered "protected" for purposes described herein if the data source is not intended to be disseminated outside the entity in an uncontrolled manner, or even in a controlled manner, as the case may be.

[0049] The term "data source," as used herein, is defined as any information from any source stored in any manner. For example, a data source may be a computer-aided design (CAD) for a semiconductor device, although the design may take any form and be stored in any suitable data structure. Other examples of data sources that may be utilized in the embodiments described herein include other types of design data, real and / or simulated images of the specimen, test results of the specimen, information about the manufacturing process used to produce some portion of a device on the specimen, and any other information source, particularly those related to the design, manufacturing, and yield control of semiconductor devices.

[0050] Examples of the characteristics of technology fields that may be involved in solving critical problems in the semiconductor industry and thus generate protected data sources that may be used in or by the embodiments described herein further include, but are not limited to: ·Design features: Work products, including but not limited to chips, masks, packages, and subsystems The goal involves converting electrical intent into physical intent for manufacturing. ○Computationally executed Design IP ownership is typically separate from the manufacturing capability ecosystem Inserting sensors and test functions (e.g., Design for Test (DFT)) into the circuit to aid in verification and diagnostics Tools are sourced from an ecosystem of electronic design automation (EDA) and technical computer-aided design (TCAD) suppliers ·Manufacturing capabilities: ○Reticle -designed for wafer fabrication (e.g., the pattern must be compatible with the intended lithography and etching processes, which depend on the material properties of the film and doping, etc.) -Designed for reticle manufacturing (e.g., the pattern must be compatible with the exposure equipment and subsequent processing steps) Wafers, Packages, and Subsystems -An ecosystem of fabs, equipment, software, and material suppliers -Equipment suppliers can specialize in more than one area Measuring and testing equipment In-line electrical testing In-line material and failure analysis -Control software (Manufacturing Execution System (MES), Advanced Process Control (APC), Fault Detection and Classification (FDC), etc.) -Analysis software with independent IP protection rights Testing capabilities: Conformity to electrical intent at wafer, chip, package, and subsystem steps; Based on knowledge of the intended static and dynamic behavior of the chip under test, performed using equipment that physically handles the wafer / device under test,  It is carried out using complex programs.

[0051] Further examples of protected data sources that can be provided to and used by a trusted virtualization system in a secure manner include all of the following: Testing programs, A physical TCAD model (typically from a representative set of regions of the chip), Electrical TCAD models (e.g., associated with the physical models mentioned above), Measurement data, Physical failure analysis, A fully annotated netlist, Fully annotated place and route maps.

[0052] The virtual system is configured to perform a virtual version of a process that can be performed by a real system on a physical version of the specimen. As described above, the virtual system can be configured as any type of virtual system, such as a VI. The virtual version of a process performed by the virtual system can include any virtual process that can vary depending on the configuration of the virtual system and the real system coupled to it. For example, if a real inspection system is coupled to the virtual system, the virtual process can be a virtual inspection process performed using outputs generated by the real inspection system. If a real measurement system is coupled to the virtual system, the virtual process can be a virtual measurement process performed using outputs generated by the real measurement system. Such a virtual process can be performed as further described herein, possibly in coordination with one or more other functions performed by the virtual system. For example, results of one or more functions performed by the virtual system can be input to the virtual process. Results of one or more functions performed by the virtual system can determine certain parameters of how the virtual process is performed. Results of the virtual process can be input to one or more functions performed by the virtual system. Further details of such embodiments are described further herein.

[0053] Thus, the virtualization system described herein can be configured as a trusted virtualization system, such as a VI with adversarial collaboration capabilities. The trusted virtualization system described herein was created to enable powerful process control and diagnostic applications for the semiconductor industry, including those described in U.S. Pat. No. 9,916,965 to Bhaskar et al., issued March 13, 2018, which is incorporated herein by reference in its entirety, in a manner that can coexist with high-performance computing (HPC)-style virtualization system software and computer infrastructure, such as that described in U.S. Pat. No. 8,126,255 to Bhaskar et al., issued February 28, 2012, which is incorporated herein by reference in its entirety. The embodiments described herein enable a decision maker's risk calculation to shift toward enabling the use of high-value IP with multiple owners processed within a trusted virtualization system. One reason the embodiments described herein are particularly useful at this time is that as process dimensions shrink, devices become more complex in the z-direction (perpendicular to the wafer surface), resulting in less transparent in-process observability of the state of wafers, packages, subsystems, etc. Therefore, the industry is increasingly relying on virtualization (often called "digital twin") methods and the application of artificial intelligence (AI), more specifically, physics-based AI techniques, to infer the state of work in progress (WIP).

[0054] In one embodiment, the virtual system is coupled to the real system by a local network. The local network may be configured such that the virtual system is connected to the real system by some hardware element, such as a wired transmission medium configured to transmit information, images, instructions, output, etc., between the two systems. In general, however, any suitable local network configuration may be used in the embodiments described herein. The networking of the embodiments described herein may also benefit from infrastructure computing platforms and / or secure networking hardware commercially available from NVIDIA Corp., Santa Clara, Calif., USA, such as the NVIDIA BlueField-3 Data Processing Unit (DPU) and / or Mellanox Firmware Tools (MFT).

[0055] One reason why it makes sense for the embodiments described herein for a virtual system to be coupled to a real system by a local network is the sheer size of image data that may need to be handled by the virtual system for some of the functions described herein. For example, it may not be practical or even possible to perform some of the functions described herein on a cloud or hybrid cloud-based system because the network is generally not fast enough. New data sources and applications described herein, which may be used or run in conjunction with large amounts of image data from a real system, may also be part of the virtual system, regardless of where the computation occurs. A determining factor may be (near) real-time interaction between various aspects of the embodiments described herein. For example, AI techniques naturally enable data-driven learning and / or improvement of models for defect detection, thereby favoring their use on hardware, such as the virtual systems described herein, connected to actual high-volume image generation and / or storage. There are also advantages to the in-the-loop learning provided by running such simulations in a virtual system such as the one described herein (e.g., updating training data with simulation results for a detection deep learning (DL) network, which can then be quickly used for improved inference on stored wafer images). Therefore, what constitutes a virtual system configured as described herein can become somewhat ambiguous in the cloud computing era. The advantage of close proximity between virtual systems and real systems in a local network is that the functions described herein are generally "data-intensive" operations (high network costs) and "computation-intensive," so it makes sense to utilize computers for multiple functions. In other words, a virtual system can function as a local cloud. However, the reason a virtual system is not "in the cloud" is because the functions described herein generate and use such large amounts of image data.

[0056] Although the functionality and data sources described herein make connecting virtual and real systems over a local network most practical, certain functionality described herein may be performed or configured in a cloud-based manner. For example, embodiments described herein may utilize state-of-the-art cloud cybersecurity capabilities enabled in products such as the Azure cloud platform, available from Microsoft Corp. of Redmond, Washington, USA, and AWS Cloud Security, available from Amazon Web Services (AWS), Seattle, Washington, USA. Additionally, embodiments described herein may utilize cloud collaboration capabilities in products such as the Azure cloud platform and software available from AWS and Synopsys, Inc. of Mountain View, California, USA, such as the Static Application Security Testing (SAST) product. Embodiments described herein may also utilize secure computing system hardware and / or software available from defense contractors and consultants, such as IBM Research, Yorktown Heights, New York, USA.

[0057] In some embodiments, the virtualization system is configured to receive two or more protected data sources over two or more respective encrypted, separate data paths and store the two or more protected data sources in two or more respective encrypted, separate portions of a storage medium. In this manner, the embodiments described herein can be configured to separate data paths (for storage and networking). For example, FIG. 3 illustrates one embodiment of a trusted virtualization system, which can be a trusted VI. As shown in FIG. 3, Entity 1 (300), Entity 2 (302), ..., and Entity N (304) can protect Protected Data Source 1 (306), Protected Data Source 2 (308), ..., and Protected Data Source N (310), respectively, separately from each other.

[0058] While Figure 3 depicts more than two different entities, the number of different entities that provide protected data sources to the virtual system is virtually unlimited. Additionally, although Figure 3 depicts each different entity providing one protected data source to the virtual system, each different entity may send any number of protected data sources to the virtual system.

[0059] Different entities can input their respective protected data sources into the virtual system simultaneously or at different times. For example, a function performed by the virtual system for a sample can be performed using two different protected data sources from two different entities, and the function can be performed after both protected data sources are received, whether they are received at different times or simultaneously.

[0060] Each of the entities may input or allow input of their respective protected data sources into different isolated data paths of the trusted virtual system. For example, protected data source 1 may input into encrypted and isolated data path 1 (312), protected data source 2 may input into encrypted and isolated data path 2 (314), ..., protected data source N may input into encrypted and isolated data path N (316). The data paths may be encrypted and isolated in any suitable manner known in the art.

[0061] The virtual system can then store each of the protected data sources in a respective encrypted and isolated portion of the virtual system's storage medium. For example, protected data source 1 received via encrypted and isolated data path 1 can be stored in encrypted and isolated storage 1 (318), protected data source 2 received via encrypted and isolated data path 2 can be stored in encrypted and isolated storage 2 (320), ... protected data source N received via encrypted and isolated data path N can be stored in encrypted and isolated storage N (322). The storage medium portions can be encrypted and isolated in any suitable manner known in the art. For example, security of the virtual system's storage medium and any protected data sources stored thereon can be ensured using a commercially available product, such as the Multi-Layered Security (MLS) solution for Luster, available from DDN, Chatsworth, California, USA, or another similarly configured product, which can be used to provide user and data isolation.

[0062] Any of the protected data sources stored in any of the encrypted and separated storage portions, alone or in any combination, can be input to virtual system computing 324. Virtual system computing 324 can include performing any one or more of the functions described herein, which can be performed using any one or more of the protected data sources, possibly in combination with real system output 326, which can be any result or output generated by a real system for a physical version of a specimen. For example, real system output 326 can include output from an actual inspection system.

[0063] The primary IP protection currently available for VI is encryption of bulk image data. Any protected data sources fed into the virtual system described herein can be the same data already available in the actual tool being emulated by the VI. The data sources required for an optimal process control solution (AI-based or not) almost always cross one or more IP protection boundaries. To the extent that protected data is shared, possible mechanisms for protection include, but are not limited to: · the reputation and credibility that a company or individual has gained over time; Encryption, such as when large amounts of image data are stored in a VI · legal agreements, including but not limited to non-disclosure agreements; · Information segmentation within and between participating companies; · Simple prevention of information disclosure.

[0064] In another embodiment, the virtual system is configured to perform one or more functions using homomorphic encryption. For example, the virtual system computing 324 can include homographic computing or homographic HPC. Other forms of cryptographic computing can also be used in the embodiments described herein. Homographic encryption is typically defined in the art as a type of encryption that allows a calculation to be performed on encrypted data without any decryption. The resulting calculation is performed in encrypted form and can then be decrypted to produce an output that is the same as if the calculation had been performed on unencrypted data. Homomorphic encryption can then be used to allow those not privileged to the data to process the data while it remains encrypted. Thus, homomorphic encryption is particularly well-suited for the embodiments described herein. For example, homomorphic encryption can be used by an inspection tool operator to set up an inspection process based on encrypted design data from a fabless customer without the need to decrypt the design data. While homomorphic cryptographic computing is particularly advantageous for the embodiments described herein, any other commercially available technology that allows functions to be performed based on one or more encrypted data sources without decrypting the data sources may be used in the same manner to perform the functions described herein.

[0065] Although inputs to a nominally trusted virtualization system may contain highly guarded confidential information, the output of application software programs integrated with the system is generally expected to often closely resemble currently used tool outputs and therefore may pose a much lower threat to stakeholders. For example, an inspection recipe generated by a virtualization system using a protected data source from a first entity, such as a semiconductor device designer, can typically be provided to a second entity, such as an inspection tool operator, without a threat to data security, because the protected data source is typically not included in the inspection recipe or is identifiable from the inspection recipe. Nevertheless, trusted virtualization systems can provide IP protection for inputs and outputs.

[0066] In one embodiment, the virtual system is configured to generate output of one or more functions and provide the output to a first of two or more distinct entities without exposing any of the two or more protected data sources that are not from the first of the two or more distinct entities. For example, virtual system computing 324 can generate multiple different outputs that can vary depending on the function performed by the virtual system using the received protected data sources. As shown in FIG. 3 , virtual system computing 324 can generate a protected data source neutral output 334, an output using protected data source 1 (328), an output using protected data source 2 (330), ..., and an output using protected data source N (332). Each of these outputs may be generated by a single function performed by the virtual system, or one or more of the outputs may be generated by different functions performed by the virtual system. If a virtual system performs one function using one protected data source and another, separate function using a different protected data source, generating output that preserves the security of the protected data source should be relatively simple, especially if the output generated by any one function goes solely to the entity that provided the protected data source used for that function.

[0067] Protecting data sources at virtual system output can be more complicated when two different protected data sources from two different entities are used in combination for a single function and / or when the results of a function performed using a protected data source from a first entity are sent to a second entity without compromising the protected data source from the first entity. One way to do this is to ensure that any output generated by the virtual system includes only protected data sources from the entity receiving the output. In this way, the output generated by the virtual system for any one function performed by the virtual system can include one or a combination of the outputs shown in FIG. 3, depending on which entity is receiving the output and which protected data sources were used. In any case, the virtual system can generate separate outputs from a single function (or two or more functions) that include only the protected data sources of the entity receiving the output. In particular, as shown in FIG. 3, output using protected data source 1 can be sent only to entity 1, output using protected data source 2 can be sent only to entity 2, ..., output using protected data source N can be sent only to entity N.

[0068] One reason a virtual system may generate a neutral output that is agnostic to protected data sources is when an entity that does not own any of the protected data sources used to perform a function on a sample is to receive the output of that function. For example, a virtual system may perform a single function using protected data sources 1, 2, ..., and N, and entity N+1 (not shown) may be the recipient of that output. Thus, the output generated and sent to entity N+1 should not include the protected data sources of any of entities 1, 2, ..., and N.

[0069] In any event, the virtual system is configured to generate output in a manner that does not violate current customer / supplier norms in terms of contract, regardless of the function being performed and the protected data sources used for that function, preferably legitimate customer-proprietary data from supplier tools.

[0070] In some embodiments, the virtualization system is configured to securely dispose of two or more protected data sources after performing one or more functions. For example, the virtualization system is preferably configured to make extrapolation of the proprietary data impossible and may be configured to irrecoverably destroy the data once its use is over. In this way, entities that provide their protected data sources to the virtualization system can ensure that their data does not remain within the system, thereby reducing the risk of accidental exposure or transmission. The virtualization system may be configured to render the protected data sources irrecoverable in any suitable manner known in the art.

[0071] In further embodiments, the virtualization system is configured to restrict control of hardware encryption keys for two or more protected data sources to only two or more distinct entities, respectively. For example, the embodiments described herein can be configured for stakeholder control of hardware encryption keys (e.g., for storage, networking, and computing). The hardware encryption keys can be configured in any suitable manner known in the art, and the embodiments described herein can be configured to restrict control of these keys in any suitable manner.

[0072] In another embodiment, the virtualization system is configured for third-party verification of the security of two or more protected data sources within at least the virtualization system's computer systems and storage media. For example, the embodiments described herein can be configured for a hardware and software topology that is "secure by design" with trusted third-party verifiability. Third-party verifiability can be enabled using any suitable commercially available software and / or hardware known in the art.

[0073] In further embodiments, the virtual system is configured to enforce storage security via the Rust programming language. For example, the embodiments described herein can be configured to use memory-secure software (e.g., using the Rust software language).

[0074] In one embodiment, performing the one or more functions includes performing a first function of the one or more functions using at least two of the two or more protected data sources. In this manner, one of the functions can be performed using any combination of the two or more protected data sources. A function can be performed using all of the two or more protected data sources stored in or available to the virtual system. However, a single function may be performed using fewer than all of the two or more protected data sources stored in or available to the virtual system.

[0075] One such embodiment is shown in FIG. 4. In this embodiment, a virtual system can receive protected data source 1 (306), protected data source 2 (308), ..., and protected data source N (310) from entities 1, 2, ..., and N, respectively, as shown in FIG. 3. The virtual system can then perform function 400 using at least two of the protected data sources, e.g., protected data source 1 and N or protected data sources 1, 2, ..., and N. In some embodiments, input to the function can also include real system output 326, which can include any output generated by any of the real systems described herein, including, but not limited to, inspection system images, metrology measurements, etc. Function 400 can include any of the functions described herein. For example, a function such as simulating the performance of an inspection system may require two or more protected data sources, such as a semiconductor device design, a 3D specimen model, and an inspection system model, each of which can be from a different entity. Nevertheless, the embodiments described herein are designed to ensure the safety and security of such protected data sources throughout the process.

[0076] Output generated by executing function 400 may include output using protected data source 1 (402), output using protected data source 2 (404), ..., output using protected data source N (406), which may be generated and configured as further described herein. Additionally, as shown in FIG. 4 , output using protected data source 1 may be sent only to entity 1, output using protected data source 2 may be sent only to entity 2, ..., output using protected data source N may be sent only to entity N. In this manner, entities do not receive output from other entities that exposes any of the protected data sources. As further shown in FIG. 4 , function 400 may generate protected data source-agnostic neutral output 408, which may be generated as further described herein. In this manner, output of function 400 may be provided to entities that do not have authorization to receive any of the protected data sources input to function 400.

[0077] In another embodiment, performing the one or more functions includes performing a first function of the one or more functions using only a first protected data source of the two or more protected data sources and performing a second function of the one or more functions using only a second protected data source of the two or more protected data sources. In this manner, different functions can be performed using different protected data sources. For example, a first function can be performed using a first protected data source, a second function can be performed using a second protected data source, and so on.

[0078] One such embodiment is shown in Figure 5. In this embodiment, the virtual system can receive protected data source 1 (306), protected data source 2 (308), ..., and protected data source N (310) from entities 1, 2, ..., and N, respectively. These are shown in Figure 3. The virtual system can then perform function 1 (500) using only protected data source 1, function 2 (502) using only protected data source 2, ..., and function N (504) using only protected data source N. In some embodiments, inputs to one or more of the functions performed by the virtual system can also include real system output 326, which can include any output generated by any of the real systems described herein, including, but not limited to, inspection system images, metrology measurements, etc. Function N+1 (506) can be performed using only protected data source N in combination with real system output 326. In this manner, different functions may be performed using different secured data sources, but the input to any of the functions may include any other information described herein. Functions 500, 502, 504, and 506 may include any of the functions described herein.

[0079] Even if a function is being performed by a virtualization system using only one protected data source from one entity, other protected data sources from other entities may be received, stored, and / or used by the virtualization system while the function is being performed. In other words, regardless of which protected data source is being used for any function being performed at any time, any other protected data source may be simultaneously received, stored, and / or processed by the virtualization system in other functions that may or may not be running simultaneously. In any such situation, the embodiments described herein are designed to ensure the safety and security of such protected data sources throughout the process.

[0080] The output generated by executing function 500 can include an output using protected data source 1 (508), the output generated by executing function 502 can include an output using protected data source 2 (510), ..., the output generated by executing function N can include an output using protected data source N (512), and the output generated by executing function N+1 can include a second output using protected data source N (514), which can be generated and configured as further described herein. Additionally, as shown in FIG. 5 , the output using protected data source 1 can be sent only to entity 1, the output using protected data source 2 can be sent only to entity 2, ..., the output using protected data source N and the second output can be sent only to entity N. In this way, entities do not receive output from other entities that exposes any of the protected data sources. Although not shown in FIG. 5 , any of functions 500, 502, 504, and 506 can generate protected data source-agnostic neutral outputs, which can be generated as further described herein. In this way, the output of any of these functions can be provided to entities that do not have permission to receive the protected data source that was input to that function.

[0081] Additionally or alternatively, a first function can be performed using a first combination of protected data sources, a second function can be performed using a second combination of protected data sources, and so on, where the protected data sources included in each combination may or may not be mutually exclusive. In other words, a single protected data source may not be included in two or more combinations and therefore may not be used for two or more functions. However, a single protected data source may be included in two or more combinations and therefore may be used for two or more functions. In this manner, not all protected data sources stored in or available to a virtual system may be used for any one function performed by the virtual system.

[0082] In a further embodiment, the virtualization system is configured to execute a virtual version of a process using the output of at least one of the one or more functions. One such embodiment is shown in Figure 6. In this embodiment, the virtualization system may receive protected data source 1 (306), protected data source 2 (308), ..., and protected data source N (310) from entities 1, 2, ..., and N, respectively, as shown in Figure 3. The virtualization system may then execute function 600 using at least two of the protected data sources. Function 600 may include any of the functions described herein.

[0083] The output generated by executing function 600 may be input to a virtual process 602. Virtual process 602 may be a virtual version of a process that can be performed by a real system on a physical version of the specimen. For example, the virtual process may be a virtual inspection process, a virtual metrology process, a virtual electrical test process, etc. In one such example, the output of function 600 may be an inspection process recipe selected for the specimen based on the simulated performance of the inspection system, and both the inspection process recipe selection and the inspection system performance simulation may be performed in function 600 as further described herein. Virtual process 602 may then include a virtual inspection process performed by applying the selected inspection process recipe to images of the physical version of the specimen generated by a real inspection tool and stored in the virtual system.

[0084] The output generated by executing virtual process 602 can include one or more of output using protected data source 1 (604), output using protected data source 2 (606), ..., output using protected data source N (608), which can be generated and configured as further described herein. Additionally, as shown in FIG. 6 , output using protected data source 1 can be sent only to entity 1, output using protected data source 2 can be sent only to entity 2, ..., output using protected data source N can be sent only to entity N. In this manner, entities do not receive output from other entities that exposes any of the protected data sources. As further shown in FIG. 6 , virtual process 602 can generate protected data source-agnostic neutral output 610, which can be generated as further described herein. In this manner, output of virtual process 602 can be provided to entities that do not have permission to receive any of the protected data sources input to function 600 and / or virtual process 602.

[0085] Another such embodiment is shown in FIG. 7. In this embodiment, a virtual system can receive protected data source 1 (306), protected data source 2 (308), ..., and protected data source N (310) from entities 1, 2, ..., and N, respectively. These are shown in FIG. 3. The virtual system can then perform function 1 (700) using only protected data source 1, function 2 (702) using only protected data source 2, ..., and function N (704) using only protected data source N. Functions 700, 702, and 704 can include any of the functions described herein. In some embodiments, inputs to one or more of the functions performed by the virtual system can also include real system outputs (not shown in FIG. 7), which can include any output generated by any of the real systems described herein, including, but not limited to, inspection system images, metrology measurements, etc. Function N+1 (not shown in FIG. 7) can be performed using only one of the protected data sources in combination with the real system outputs.

[0086] In this manner, different functions may be performed using different protected data sources, but the input to any of the functions may include any other information described herein. Additionally, even if a function is performed by a virtualization system using only one protected data source from one entity, other protected data sources from other entities may be received, stored, and / or used by the virtualization system while the function is being performed. In other words, regardless of which protected data source is being used for any function being performed at any time, any other protected data source may be received, stored, and / or processed by the virtualization system in other functions that may or may not be running simultaneously. In any such situation, the embodiments described herein are designed to ensure the safety and security of such protected data sources throughout the process.

[0087] The output generated by executing function 700 can be input to virtual process 1 (706), the output generated by executing function 702 can be input to virtual process 2 (708), ..., the output generated by executing function 704 can be input to virtual process N (710). Each of virtual processes 706, 708, and 710 can be any of the virtual processes described herein. In addition, each of virtual processes 706, 708, and 710 can be the same virtual process, e.g., the same virtual inspection process. Alternatively, one or more of virtual processes 706, 708, and 710 can be different virtual processes. For example, virtual processes 706 and 708 can be different virtual inspection processes, or virtual process 706 can be a virtual inspection process, virtual process 708 can be a virtual metrology process, and virtual process 710 can be a virtual defect review process.

[0088] The output generated by executing virtual process 706 may include an output using protected data source 1 (712), the output generated by executing virtual process 708 may include an output using protected data source 2 (714), ..., the output generated by executing virtual process 710 may include an output using protected data source N (716), which may be generated and configured as further described herein. Additionally, although not shown in FIG. 7 , the output using protected data source 1 may be sent only to entity 1, the output using protected data source 2 may be sent only to entity 2, ..., the output using protected data source N may be sent only to entity N. In this way, entities do not receive output from other entities that exposes any of the protected data sources. As further shown in FIG. 7 , any of virtual processes 706, 708, and 710 may generate a protected data source-agnostic neutral output (not shown), which may be generated as further described herein. In this way, the output of any of these functions can be provided to entities that do not have permission to receive the protected data source that was input to that function.

[0089] In some embodiments, performing one or more functions includes performing a first of the one or more functions on the specimen using at least one of two or more protected data sources in combination with results generated by executing a virtual version of the process. For example, any of the functions described herein can be performed using inputs that include protected data sources with any other information further described herein, including results generated by executing a virtual inspection process, a virtual metrology process, a virtual electrical test process, a virtual defect review process, etc. One example of a function that can be performed using a protected data source and the results of a virtual process is simulating the electrical characteristics of a specimen by inputting the results of the virtual inspection process into an electrical model that is a protected data source. Of course, this is only one of many possible functions that can be performed by the embodiments described herein using such inputs. It is important to note that the embodiments described herein enable the safe and secure use of protected data sources with any other data sources, protected or unprotected, to perform one or more semiconductor-related functions. By lowering the barriers to using protected data sources, the embodiments described herein provide many benefits to the entire semiconductor manufacturing ecosystem, some examples of which are described further herein.

[0090] In one embodiment, the one or more functions include generating a three-dimensional (3D) physical representation of a physical version of the specimen. For example, as shown in FIG. 8 , the virtualization system can generate the 3D physical representation of the specimen in step 802 using secured data sources 800, which may include any of the secured data sources described herein, such as semiconductor device design information and / or 3D models. The 3D physical representation of the physical version of the specimen is not a simulation of how the specimen would appear to any one tool or system, such as a metrology tool or system. Instead, the 3D physical representation is a simulation of how the specimen would appear in specimen space (e.g., if a complete 3D image of the specimen could be formed in a strictly accurate manner, which is clearly not possible given the practical physical limitations of practical imaging systems).

[0091] Generating the 3D physical representation of the physical version of the specimen can be performed using any model known in the art. One example of an empirically trained process model that can be used to generate the 3D physical representation of the physical version of the specimen includes SEMulator 3D, available from Coventor, Inc. of Cary, New York, USA. An example of a rigorous lithography simulation model is Prolith, available from KLA, which can be used in conjunction with the SEMulator 3D product. However, the 3D physical representation can be generated using any suitable model of any of the processes involved in generating the actual specimen from design data.

[0092] One advantage of the embodiments described herein is that a 3D physical representation of a specimen can be generated by a virtualization system using a model that is a protected data source, e.g., a proprietary model, without exposing the protected data source. For example, as described further herein, the virtualization system can receive a model of a manufacturing process that is a protected data source from a first entity, input a semiconductor device design that is a protected data source from a second entity into the model, and thereby generate a 3D physical representation of a physical version of the specimen on which the semiconductor device design is formed. As described further herein, each step of data handling / processing, from receiving and storing to computing and output, can be performed such that one entity's protected data source is not shared with a different entity. In the above example, the generated 3D physical representation can be provided to a semiconductor device designer, a manufacturing process model developer, and / or another entity in different ways and with different information, such that the manufacturing process model developer does not receive the semiconductor device design, and vice versa. Additionally or alternatively, the 3D physical representation can be output so that it can be used by an inspection tool operator to generate an inspection process for a physical version of the specimen without having to access or use a semiconductor device design and / or manufacturing process model. The same is true for other types of tools, such as metrology tools, defect review tools, etc.

[0093] In one such embodiment, the 3D physical representation is a 3D TCAD physical representation at specimen scale of a physical version of the specimen. For example, one application enabled by the trusted virtual system described herein is generating a 3D TCAD physical representation at wafer scale of a physical wafer. TCAD is generally defined in the art as the use of computer simulation to develop and optimize semiconductor process technologies and devices. Generating such a 3D physical representation of the specimen can be performed using 3D engineering modeling with TCAD software commercially available from Synopsys, Mountain View, California, USA, and Silvaco, Santa Clara, California, USA. One advantage of the embodiments described herein over other systems and methods is that, due to the virtual system configuration, they enable 3D physical representation generation at specimen scale (as opposed to only being able to simulate a substantially small portion of the specimen), but the embodiments described herein can be used to generate a 3D physical representation of any pre-selected portion of the specimen (e.g., only a portion of a semiconductor device fabricated on the specimen).

[0094] In addition to generating a 3D physical representation of a specimen at specimen scale (i.e., for the entire specimen), other functions described herein can be performed at specimen scale. The specimen scale characteristics of a function can be enabled by the specimen scale characteristics of the 3D physical representation (e.g., when used as input to another function). However, the embodiments described herein enable a function to be performed at specimen scale regardless of the input. For example, a virtual system can be configured to perform virtual inspection of a specimen at specimen scale using specimen scale images generated by a real inspection system. In this manner, the embodiments described herein provide a virtual system that enables closed-loop, digital twin experiments at specimen scale.

[0095] In another embodiment, the one or more functions include injecting defects into the 3D physical representation, as shown in step 804 of FIG. 8 . For example, another application enabled by the trusted virtualization system described herein is defect injection into the 3D TCAD physical representation described above. The defect injection can be performed as described in U.S. Patent No. 10,599,951, issued March 24, 2020 to Bhaskar et al., which is incorporated herein by reference as if fully set forth herein. The defect injection into the 3D physical representation can be performed by modifying the design data input in step 802, and modifying the design data to inject the defect can be performed as described in the above-referenced patent. Additionally or alternatively, the defect injection into the 3D physical representation can be performed by modifying the 3D physical representation itself in the same manner as images are modified in the above-referenced patent to inject the defect. The types and characteristics of the defects to be injected into the 3D physical representation may be determined in any manner, for example, based on knowledge of the types of defects expected or known to be formed in a particular device having certain characteristics and / or by a particular process having certain process characteristics. Information for the injected defects may be obtained from multiple sources, including, but not limited to, semiconductor device designers and semiconductor manufacturers.

[0096] Defect injection capabilities are one of the primary motivations for the embodiments described herein. For example, the creation and use of DL-based inspection (defect and classification) models is an area of ​​great interest for inspection tool customers and manufacturers. These models require hundreds of defect examples to train and run (as in bootstrapping) before they can detect defects in real specimens. Today, it can take weeks to obtain real examples of a single defect scenario in a single feature. Thus, the goal is to provide examples that are 1000 times faster. Part of what can be done is to artificially inject synthetic defects into 3D models of specimens that the inspection tool customer may already have. Until now, inspection tool customers have typically been unwilling to share 3D models of specimens with inspection tool manufacturers or operators, and such information has not been available for creating synthetic defects for DL ​​model training or bootstrapping. However, with embodiments described herein configured to ensure the safety of protected data sources in all aspects from receipt, storage, use, and even output, an entity can safely and securely make a 3D physical representation of a specimen available to inspection tool setup functions, thereby enabling better DL inspection and / or classification models to be generated for inspection. Creating better inspection recipes clearly enables better inspection results, which is beneficial to all involved in creating and using the end-result semiconductor device.

[0097] In a further embodiment, the one or more functions include substituting dimensions of one or more features in the 3D physical representation, as shown in step 806 of FIG. 8 . For example, an additional application enabled by the trusted virtualization system described herein is the substitution of dimensions in the form of design of experiments (DOE). In one such example, the substituted dimension can be any dimension of any feature of a semiconductor device and / or specimen that is of interest to a semiconductor designer and / or manufacturer, including those typically measured in metrology processes. Such dimensions include, but are not limited to, line widths, contact hole diameters, alignment or spacing between features on one or more layers of the specimen, and film thicknesses. The degree to which the dimensions of any of the features are substituted can vary depending on multiple factors, including the semiconductor design itself and the process used to fabricate it on the specimen. In this manner, the substitution of dimensions can be performed based on input from a semiconductor device designer and / or semiconductor manufacturer, which can be provided to the virtualization system as one or more protected data sources. These protected data sources can then be handled in a secure and safe format, as further described herein.

[0098] Permuting the dimensions of one or more features in a 3D physical representation can be useful for multiple applications, such as examining how variations affect the inspection of a specimen and how they may manifest as defects. For example, AI techniques such as DL networks allow for the inclusion of potential sources of variation that may not have a clear causal relationship at first glance. Much of the work in inspection is identifying aspects of the manufacturing process that need to be better measured and controlled in order to eliminate the source of the defect mechanism. Systematic defect sources typically have multiple dependencies on physical parameters that need to be better controlled. Part of the value of the "digital twin" functionality provided by virtual systems is predicting multivariate process marginalities and, in turn, how these will appear to the inspector. Similar in concept to "Bayesian priors," this functionality's strength is that it allows for proactive searching for signatures in optical (or other inspector) data that would otherwise be ignored. In this way, a 3D physical representation of a specimen with permuted feature dimensions can be input into the simulation functionality described further herein.

[0099] In a further embodiment, the one or more functions include simulating the performance of an inspection system based on the 3D physical representation, as shown in step 808 of FIG. 8. For example, a further application enabled by the trusted virtualization system described herein is defect inspection tool simulation, which takes a 3D physical model as input. Thus, such a simulating step can use the inspection system manufacturer's protected data sources as input. For example, information about the inspection system, such as optical transfer functions, can be used as input to the simulation of inspection system performance.

[0100] Simulating the performance of the inspection system can also be performed using a model of the imaging performed by the inspection system. In other words, performance can be simulated using a physics-based or forward simulation model of the inspection system. Simulating the performance of the inspection system can also include simulating images that can be generated by the inspection system using a model such as WINsim, available from KLA, which can closely model the inspector response using an electromagnetic (EM) wave solver. Such simulations can be performed using any other suitable software, algorithm, method, or system known in the art.

[0101] However, simulating the performance of the inspection system may also or alternatively be performed in a generative manner using DL-type models or networks. For example, simulating the performance of the inspection system may include simulating images that can be generated by the inspection system using a generative adversarial network (GAN) or a variational Bayesian method. In one such example, a GAN or a variational Bayesian method may be used to create realistic images that simulate the performance of the inspection system. A GAN or a variational Bayesian method may be implemented as described in U.S. Patent No. 10,599,951, issued March 24, 2020 to Bhaskar et al., which is incorporated herein by reference as if fully set forth herein. The embodiments described herein may be further configured as described in this patent.

[0102] Embodiments described herein are incorporated by reference in their entirety as if fully set forth herein, including U.S. Patent Application Publication Nos. 2009 / 0080759 to Bhaskar et al., published March 26, 2009, 2014 / 0241610 to Duffy et al., published August 28, 2014, and U.S. Patent Nos. 7,676,077 to Kulkarni et al., published March 9, 2010, and 7,676,077 to Kulkarni et al., published January 25, 2011. Nos. 7,877,722 to Duffy et al., 8,194,968 to Park et al., issued June 5, 2012, 8,611,639 to Kulkarni et al., issued December 17, 2013, and 9,183,624 to Karsenti et al., issued November 10, 2015. The embodiments described herein may be further configured as described in these publications and patents.

[0103] Simulating the performance of an inspection system based on a 3D physical representation is another practical example of how the embodiments described herein provide significant improvements and advantages over currently used systems. For example, today, inspection tool manufacturers, owners, operators, etc. do not have a 3D physical model of the specimen being inspected as input to the inspector simulation. Engineers can make guesses with the help of some select input from the semiconductor device design owner, but this can take weeks or even months and can be iterative. However, the embodiments described herein provide a system and method for securing a semiconductor device designer's protected data sources, such as a 3D physical model, and then modifying it for simulation, thereby eliminating the current "wasteful" work of inspection tool manufacturers, owners, operators, etc., of creating incorrect versions of the model.

[0104] In some cases, simulating the performance of an inspection system can involve simulating only the imaging portion of the inspection process, i.e., simulating what the images of the specimen generated by the inspection system would look like under one or more sets of imaging hardware parameters. Such simulations can enable a kind of Bayesian inspector concept. For example, given some metrology data for the specimen, a virtual system can infer what an expected 3D TCAD representation of the specimen will be. The 3D TCAD representation can then be used to generate a simulation of an expected inspector image. In some examples, the expected inspector image can be used as a reference for comparison with actual acquired and / or stored images of the wafer from a virtual or real inspector. Thus, such predicted inspector images can be used as reference images, and this type of image comparison can be performed for die-to-database type defect inspection.

[0105] Additionally or alternatively, the simulated inspector image may be used to set up one or more parameters of the inspection process. For example, simulated images generated for different modes of an actual inspection tool (defined by one or more different imaging parameters of the system other than the location on the specimen where the image is generated) can be generated by a virtual system based on the 3D TCAD representation of the specimen and used to determine which mode is best for inspecting the specimen as performed by the real system. Such simulations can also be performed to determine which tool is best for inspecting the specimen. The simulated image can also be used to select one or more parameters of a defect detection method used to detect defects in the image. Such parameters of the defect detection method can include, but are not limited to, which defect detection algorithm is used for inspection, which parameters, such as thresholds, are used for inspection, etc. In this manner, all aspects of the actual inspection process performed by the actual inspection system can be set up based on simulated inspector images generated from the 3D TCAD representation.

[0106] In some embodiments, the one or more functions include simulating the performance of a metrology system based on a 3D physical representation, as shown in step 810 of FIG. 8 . For example, another application enabled by the trusted virtualization system described herein is metrology tool simulation that takes a 3D physical model as input. An example of how a virtualization system can simulate the performance of a metrology system is described in U.S. Patent No. 10,496,781 to Fang et al., issued November 13, 2017, which is incorporated herein by reference as if fully set forth herein. The embodiments described herein can be configured as described in this patent. The embodiments described herein can also be configured to set up a metrology process as described in U.S. Patent No. 10,267,746 to Duffy et al., issued April 23, 2019, which is incorporated herein by reference as if fully set forth herein.

[0107] In another embodiment, the one or more functions include simulating the performance of a process tool based on the 3D physical representation, as shown in step 812 of FIG. 8 , where the process tool is configured to perform a process on a physical version of the specimen that intentionally alters one or more properties of the physical version of the specimen. For example, an additional application enabled by the trusted virtualization system described herein is process tool simulation that takes a 3D physical model as input. Simulating the performance of a process tool can be performed using any model currently used in the art, including physics-based forward simulation models and generative DL models. Generally, the process tool model can be a protected data source from the process tool manufacturer. The process tool model can be provided to the virtualization system by the process tool manufacturer, who can ensure that the process tool model will be received, stored, used, and discarded in a safe and secure manner by the virtualization system embodiments described herein. Process tools whose performance can be simulated by the embodiments described herein can include any process tool configured to intentionally alter one or more properties of a specimen, such as a deposition tool, an ion implantation tool, a chemical-mechanical polishing tool, a lithography tool, an etch tool, etc.

[0108] Process tool performance can be simulated at various points in the manufacturing process for a number of different reasons. For example, once a semiconductor device is designed, it is useful to know whether it can be successfully manufactured. Thus, before manufacturing begins, embodiments described herein can be used to simulate process tool performance by inputting semiconductor device design information into a model of the process tool (either directly or via one or more other functions, such as generating a 3D physical representation from the design information). In this manner, different protected data sources from different entities may be required for such applications, and embodiments described herein are configured to obtain and use these protected sources in a safe and secure manner.

[0109] Even after determining that a semiconductor device design can be successfully manufactured, it may be useful to determine how variations in the process affect the semiconductor device. In this manner, a process window for the process that will produce a semiconductor device with acceptable characteristics can be established. For example, a process tool simulation can be performed using different values ​​of one or more parameters of the process (such as lithography exposure and dose) to determine one or more physical properties of the specimen that will be produced at the different values. These properties can be analyzed to determine which values ​​produce acceptable device characteristics. Such modeling can be combined with electrical analysis, as described further herein, to determine not only which process parameter values ​​produce acceptable physical properties, but also or alternatively, to determine which process parameter values ​​produce acceptable electrical device characteristics. Thus, such analysis may require one or more protected data sources in addition to the semiconductor device design and process tool model, all of which safety and security can be ensured in the same manner by the embodiments described herein.

[0110] In one embodiment, the one or more functions include extracting a netlist for a device formed on a physical version of the specimen based on the 3D physical representation, as shown in step 814 of FIG. 8. For example, one application enabled by the trusted virtualization system described herein is netlist extraction from a 3D TCAD representation of a wafer. Extracting a netlist for a device can be performed using any commercially available or currently used method or system. In one such example, a netlist extraction method can be provided to an embodiment described herein as a protected data source, and the 3D physical representation can be input to such method.

[0111] In a further embodiment, the one or more functions include generating an electrical representation of the netlist, as shown in step 816 of FIG. 8. In one such embodiment, the electrical representation of the netlist is a wafer-scale TCAD electrical representation of the netlist. For example, one application enabled by the trusted virtualization system is generating a wafer-scale TCAD electrical (e.g., SPICE) representation of a netlist extracted from a generated 3D TCAD physical representation. Generating the electrical representation of the netlist can be performed using any commercially available or currently used method or system, such as SPICE open source software. However, an electrical representation generation method can also be provided to the embodiments described herein as a protected data source, and the netlist can be input to such a method.

[0112] In another such embodiment, the one or more functions include substituting one or more electrical parameters of the electrical representation, as shown in step 818 of FIG. 8 . For example, another application enabled by a trusted virtualization system is the substitution of electrical parameters by DOE. In one such example, the virtualization system can perform fault modeling, fault coverage, design of tests, fault injection, etc. using protected data sources, such as information about a test program. The test program information can include information about parameters of tests that are or will be performed on a semiconductor device being manufactured, such as where and how the tests will be performed. This information can then be used by semiconductor device designers, owners, manufacturers, etc. to infer locations of concern where failures may occur. Based on that information, the electrical representation of the specimen can be modified in one or more different ways to substitute the electrical parameters of the electrical representation. One way to make such modifications is to use a structural model to modify one or more structural characteristics of the physical representation, thereby modifying one or more electrical parameters of the electrical representation. In one such example, one or more structural parameters can be modified to artificially create a connection between two structures that results in a short in the device. Another way to make such changes is to use a functional model to change one or more functional characteristics of the physical or electrical representation, thereby changing one or more electrical parameters of the electrical representation.

[0113] Therefore, substituting electrical parameters for electrical representations can be considered the inverse of substituting physical properties for physical representations. In particular, the physical structure of a semiconductor device is designed to meet electrical specifications. The physical tolerances of the semiconductor structure are constrained by the acceptable variations in the resulting electrical parameters. Therefore, while physical parameters can be varied to predict electrical parameters, the reverse is also true: electrical parameters can be varied to predict physical parameters. In this way, once the correspondence between physical and electrical parameters (TCAD model) is known, for example, one can reverse the direction of inference by describing the physical properties that may cause a given electrical function.

[0114] Clearly, there are many different commercially available models of semiconductor devices that can be used to replace one or more electrical parameters of the electrical representation in the embodiments described herein, and the virtualization system described herein can be configured to use any of them to perform the replacement of the electrical representation. The virtualization system described herein provides value beyond simply being able to execute a model in that it can perform functions that utilize protected data sources from different entities in a secure and safe manner. In one such example, the electrical representation replaced by the virtualization system can be generated from, or even include protected data from, a semiconductor device designer. The virtualization system can replace the electrical representation with the electrical representation in combination with a fault model, which can be or include protected data from a different entity. The replaced electrical representation can then be used to generate additional information that can be output in a manner that protects the data of the first two entities. For example, the virtualization system can generate a test program for the semiconductor device based on the replaced electrical representation using information from another entity regarding an electrical tester. The test program may not include any information about the electrical representation or substituted electrical representation, thereby enabling an electrical tester operator to test a semiconductor device without having or needing access to protected data sources from semiconductor device designers and fault model developers. In this manner, the embodiments described herein may overcome domain boundaries that typically exist for practical reasons in addition to IP reasons.

[0115] As described elsewhere herein, one or more functions performed by a virtual system using two or more protected data sources can be performed in addition to or in combination with a virtual version of a process performed by a real system. Thus, the embodiments described herein can extend the functionality and usefulness of virtual systems, such as virtual inspectors, by leveraging the trusted properties of the embodiments described herein. For example, electrical failures can be functional failures (typically caused by defects) or parametric failures (typically due to variations found in metrology). Many inspection systems currently on the market are primarily interested in how the specimen appears in an image, thereby looking for defects that may or may not cause actual problems in the functionality of the semiconductor device. By extending the functionality of a virtual inspector beyond simple inspection to include functionality related to electrical failure review / inspection of semiconductor devices, embodiments can generate and provide important information not only about how the specimen looks, but also about how devices formed on or using the specimen function electrically. The functionality of other systems described herein, such as virtual metrology systems and real metrology systems, can be similarly extended. Thus, the embodiments described herein bridge the physical and electrical spaces by allowing multiple protected data sources from different entities to be used separately or in combination in a single system in a secure and safe manner.

[0116] The trusted virtual system embodiments described herein enable design-engineering co-optimization (DTCO) experiments to be conducted in research and development environments. Today, these activities are compartmentalized, but the embodiments described herein enable digital twin virtual inspection of specimens along with real specimen readings, allowing for real-time experiments of the entire DTCO flow to be performed that would otherwise take weeks / months to perform physically.

[0117] Accordingly, the embodiments described herein can provide benefits to many of the parties in the semiconductor device manufacturing ecosystem. By allowing their protected data to be used in the virtual systems described herein without concern for data safety and security, semiconductor device designers can better learn what works and what doesn't, thereby enabling designers to develop better future designs. Inspection tool manufacturers can create better inspection processes and tools based on information from other parties, such as semiconductor device designers, thereby increasing the value of their contribution to the manufacturing process and potentially developing better systems and methods for future tools. In a similar manner, manufacturers of process tools, metrology tools, and electrical test tools can produce better tools and processes. The yield of existing tools and processes can be improved in this way, and the deployment of new tools and processes can be easier, faster, and cheaper, with a higher chance of success. In this way, by eliminating barriers that currently prevent different entities from enabling other entities to use their protected data sources, the embodiments described herein can provide benefits and improvements to nearly every sector of the semiconductor manufacturing ecosystem.

[0118] In a further embodiment, one or more functions include injecting faults into the electrical representation, as shown in step 820 of FIG. 8. For example, an additional application enabled by a trusted virtualization system is fault injection into this representation (e.g., using SPICE models of the faults). In one such example, the virtualization system can perform fault injection using a protected data source, such as information about the test program. The virtualization system can perform fault injection in the same manner as described above with respect to the substitution of electrical parameters.

[0119] In some embodiments, the one or more functions include generating a virtual static test of the electrical representation to find static faults, as shown in step 822 of FIG. 8. For example, a further application enabled by a trusted virtualization system is virtual static testing of the electrical representation to find static (DC) faults. In one such example, the virtualization system can perform fault modeling, fault coverage, etc., using protected data sources, such as information about the test program. In this manner, the virtualization system can, in some embodiments, be a virtual tester with the correct inputs.

[0120] In another embodiment, the one or more functions include generating virtual functional testing of the electrical representation to find parametric faults, as shown in step 824 of FIG. 8. For example, another application enabled by a trusted virtualization system is virtual functional testing of the electrical representation to find parametric (AC) faults. In one such example, the virtualization system can perform fault modeling, fault coverage, etc., using protected data sources, such as information about the test program. In this manner, the virtual system can, in some embodiments, be a virtual tester with correct inputs.

[0121] All embodiments described herein can be configured to store results of one or more steps performed by the embodiment in a computer-readable storage medium. The results can include any of the results described herein and can be stored in any manner known in the art. The storage medium can include any of the storage media described herein or any other suitable storage medium known in the art. After the results are stored, they can be accessed in the storage medium, used by any of the method or system embodiments described herein, formatted for display to a user, used by another software module, method, or system, etc.

[0122] Such functionality includes, but is not limited to, modifying a process, such as a manufacturing process or step, that has been or will be performed on a specimen in a feedback or feedforward manner. For example, the virtualization system can be configured to identify one or more modifications to a process that has been performed on a specimen inspected as described herein and / or that will be performed on a specimen based on detected defects. The modifications to a process can include any suitable modifications to one or more parameters of the process. The virtualization system preferably identifies modifications that can reduce or prevent failures in other specimens on which the modified process is performed; defects can be corrected or eliminated on the specimen in another process performed on the specimen; defects can be compensated for in another process performed on the specimen; etc. The virtualization system can determine such modifications in any suitable manner known in the art.

[0123] These changes can then be transmitted to a semiconductor manufacturing system (not shown) or storage medium (not shown) accessible to the virtual system and the semiconductor manufacturing system. The semiconductor manufacturing system may or may not be part of the system embodiments described herein. For example, the virtual system can be coupled to the semiconductor manufacturing system via one or more common elements, such as, for example, a housing, a power supply, a specimen handling device or mechanism, etc. The semiconductor manufacturing system can include any semiconductor manufacturing system known in the art, such as a lithography tool, an etch tool, a chemical-mechanical polishing (CMP) tool, a deposition tool, etc.

[0124] Each of the embodiments of each of the above systems can be combined into a single embodiment.

[0125] Another embodiment relates to a computer-implemented method for performing one or more functions using protected data sources from different entities. The method includes performing one or more functions on a specimen using two or more protected data sources from two or more different entities, respectively. The method also includes executing a virtual version of a process that can be performed by the real system using output generated by the real system for a physical version of the specimen while the specimen is located in the real system. The one or more functions and the virtual version of the process are executed by a virtual system that is coupled to the real system and thereby receives output generated by the real system for the physical version of the specimen. The virtual system comprises at least a computer system and a storage medium. The virtual system is not capable of having a physical version of the specimen located therein.

[0126] Each of the method steps can be performed as further described herein. The method can also include any other steps that can be performed by the system embodiments described herein. In addition, the method described above can be performed by any of the system embodiments described herein.

[0127] A further embodiment relates to a non-transitory computer-readable medium storing program instructions executable on a computer system for performing one or more functions with protected data sources from different entities. One such embodiment is shown in Figure 9. In particular, as shown in Figure 9, a non-transitory computer-readable medium 900 includes program instructions 902 executable on a computer system 904. The computer-implemented method may include any step of any of the methods described herein.

[0128] Program instructions 902 for performing methods as described herein may be stored on a computer-readable medium 900. The computer-readable medium may be a storage medium such as a magnetic or optical disk, magnetic tape, or any other suitable non-transitory computer-readable medium known in the art.

[0129] The program instructions may be implemented in any of a variety of ways, including procedure-based, component-based, and / or object-oriented techniques, among others. For example, the program instructions may be implemented using ActiveX controls, C++ objects, JavaBeans, Microsoft Foundation Classes ("MFC"), SSE (Streaming SIMD Extensions), or other technologies or ways, as desired.

[0130] The computer system 904 may be configured according to any of the embodiments described herein.

[0131] Further modifications and alternative embodiments of various aspects of the invention will be apparent to those skilled in the art upon consideration of this specification. For example, methods and systems for performing functions using secured data sources from different entities are provided. Accordingly, this specification is to be construed as merely illustrative and is intended to teach those skilled in the art the general manner of carrying out the invention. It is understood that the forms of the invention depicted and described herein are presently preferred embodiments. Elements and materials may be substituted for those illustrated and described herein, components and processes may be reversed, and certain features of the invention may be utilized independently, all of which will be apparent to those skilled in the art having the benefit of this specification of the invention. Changes may be made in the components described herein without departing from the spirit and scope of the invention, as set forth in the following claims.

Claims

1. 1. A system configured to perform one or more functions using secured data sources from different entities, comprising: a virtual system coupled to a real system, whereby while a specimen is placed in the real system, it receives output generated by the real system for a physical version of the specimen, the virtual system including at least a computer system and a storage medium, the virtual system being unable to place the physical version of the specimen therein, the virtual system: performing one or more functions on the sample using two or more secured data sources from two or more different entities respectively; executing a virtual version of a process that can be performed by the real system on the physical version of the specimen; A virtual system configured to A system comprising:

2. 10. The system of claim 1, wherein the virtual system is further configured as a virtual inspector.

3. 2. The system of claim 1, wherein the virtual system is further coupled to the real system by a local network.

4. 2. The system of claim 1, wherein the virtual system is further configured to receive the two or more protected data sources over two or more respective encrypted, separate data paths and to store the two or more protected data sources in two or more respective encrypted, separate portions of the storage medium.

5. 10. The system of claim 1, wherein the virtual system is further configured to perform the one or more functions using homomorphic encryption.

6. 2. The system of claim 1, wherein the virtual system is further configured to generate an output of the one or more functions and provide the output to the first of the two or more distinct entities without exposing any of the two or more protected data sources that are not from the first of the two or more distinct entities.

7. 2. The system of claim 1, wherein the virtualization system is further configured to securely dispose of the two or more protected data sources after performing the one or more functions.

8. 2. The system of claim 1, wherein the virtualization system is further configured to restrict control of hardware encryption keys for the two or more protected data sources to only the two or more different entities, respectively.

9. 2. The system of claim 1, wherein the virtual system is further configured to perform third-party verification of the security of the two or more protected data sources within at least the computer system and the storage medium of the virtual system.

10. 10. The system of claim 1, wherein the virtual system is further configured to enforce security of the storage medium via the Rust programming language.

11. 2. The system of claim 1, wherein performing the one or more functions includes performing a first of the one or more functions using at least two of the two or more secured data sources.

12. 2. The system of claim 1, wherein performing the one or more functions includes performing a first function of the one or more functions using only a first protected data source of the two or more protected data sources, and performing a second function of the one or more functions using only a second protected data source of the two or more protected data sources.

13. 2. The system of claim 1, wherein the virtual system is further configured to execute the virtual version of the process using an output of at least one of the one or more functions.

14. 2. The system of claim 1, wherein performing the one or more functions includes performing a first of the one or more functions on the specimen using at least one of the two or more secured data sources in combination with results generated by executing the virtual version of the process.

15. 10. The system of claim 1, wherein the one or more functions include generating a three-dimensional physical representation of the physical version of the specimen.

16. 16. The system of claim 15, wherein the three-dimensional physical representation is a specimen-scale, three-dimensional, engineered, computer-aided design physical representation of the physical version of the specimen.

17. 16. The system of claim 15, wherein the one or more functions further include one or more of: injecting defects into the three-dimensional physical representation; permuting dimensions of one or more features in the three-dimensional physical representation; simulating performance of an inspection system based on the three-dimensional physical representation; simulating performance of a metrology system based on the three-dimensional physical representation; and simulating performance of a process tool based on the three-dimensional physical representation, wherein the process tool is configured to perform a process on the physical version of the specimen that intentionally alters one or more properties of the physical version of the specimen.

18. 16. The system of claim 15, wherein the one or more functions further include extracting a netlist of devices formed on the physical version of the specimen based on the three-dimensional physical representation.

19. 20. The system of claim 18, wherein the one or more functions further include generating an electrical representation of the netlist.

20. 20. The system of claim 19, wherein the electrical representation of the netlist is a sample-scale engineering computer-aided design electrical representation of the netlist.

21. 20. The system of claim 19, wherein the one or more functions further include one or more of: substituting one or more electrical parameters of the electrical representation; injecting faults into the electrical representation; generating a virtual static test of the electrical representation to find static faults; and generating a virtual functional test of the electrical representation to find parametric faults.

22. A non-transitory computer-readable medium storing program instructions executable on a computer system for performing one or more functions with protected data sources from different entities, the computer-implemented method comprising: performing one or more functions on the sample using two or more secured data sources from two or more different entities respectively; executing a virtual version of a process capable of being executed by a real system using output generated by the real system for a physical version of the specimen while the specimen is located within the real system, wherein the one or more functions and the virtual version of the process are executed by a virtual system coupled to the real system and thereby receiving the output generated by the real system for the physical version of the specimen, the virtual system including at least the computer system and a storage medium, the virtual system not capable of having the physical version of the specimen located therein; 1. A non-transitory computer-readable medium comprising:

23. 1. A computer-implemented method for performing one or more functions using secured data sources from different entities, comprising: performing one or more functions on the sample using two or more secured data sources from two or more different entities respectively; executing a virtual version of a process capable of being executed by a real system using output generated by the real system for a physical version of the specimen while the specimen is located within the real system, wherein the one or more functions and the virtual version of the process are executed by a virtual system coupled to the real system and thereby receiving the output generated by the real system for the physical version of the specimen, the virtual system including at least a computer system and a storage medium, the virtual system not capable of having the physical version of the specimen located therein; A method comprising:

Images