Protecting data sources from different entities for semiconductor yield related applications

Abstract

Methods and systems are provided for performing functions with protected data sources from different entities. A system includes a virtual system coupled to an actual system to thereby receive an output generated by the actual system for a physical version of a sample when the sample is disposed within the actual system. The virtual system includes at least a computer system and a storage medium. The virtual system cannot have the physical version of the sample disposed therein. The virtual system is configured to perform one or more functions on the sample with two or more protected data sources from two or more different entities, respectively. The virtual system is also configured to execute a virtual version of a process that can be performed by the actual system on the physical version of the sample.

Description

Technical Field

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

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

[0003] The manufacture of semiconductor devices such as logic and memory devices typically involves processing a substrate such as a semiconductor wafer using a number of semiconductor processes to form various features and multiple levels of the semiconductor device. For example, photolithography is a semiconductor process that involves transferring a pattern from a mask to a photoresist disposed on a semiconductor wafer. Additional examples of semiconductor processes include, but are not limited to, chemical mechanical polishing (CMP), etching, deposition, and ion implantation. Multiple semiconductor devices may be arranged and 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 samples to facilitate a higher yield of the process and therefore a higher profit. Inspection has always been an important part of manufacturing semiconductor devices. However, as the size of semiconductor devices decreases, inspection becomes more important to the successful manufacture of acceptable semiconductor devices because smaller defects can cause device failure.

[0005] Defect review typically involves re-inspecting defects detected by an inspection process and generating additional information about the defects at a higher resolution using, for example, a high magnification optical system or a scanning electron microscope (SEM). Defect review is thus performed at discrete locations on a sample where a defect has been detected by inspection. The higher resolution data of a defect generated by defect review is more suitable for determining properties of the defect, such as contour, roughness, more accurate size information, etc. Defects can generally be more accurately classified into defect types based on the 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 sample, metrology processes are used to measure one or more characteristics of a sample that cannot be determined using inspection tools currently in use. For example, a metrology process is used to measure one or more characteristics of a sample (e.g., dimensions of features formed on the sample (e.g., line width, thickness, etc.)) during a process so that the performance of the process can be determined from the one or more characteristics. Additionally, if one or more characteristics of a sample are unacceptable (e.g., outside a predetermined range of characteristics), the measurement of the one or more characteristics of the sample can be used to change one or more parameters of the process so that additional samples made by the process have acceptable characteristics.

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

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

[0009] The root of the problems with currently used methods and systems related to semiconductor manufacturing is the disintegration of the semiconductor value chain that has been important to the economic growth of the industry. The revolution that decoupled design from manufacturing that began in the early 1980s gave way to the economic foundry, fabless, electronic design automation (EDA), and semiconductor fixed asset segments that exist today. As a result, each segment can be economically optimized to a large extent based on market forces. Since its inception, the semiconductor value chain has developed into a complex multinational network of specialized sub-segments, each with its own shareholder value optimization obligations. The natural result of this fragmentation related to intellectual property (IP) protection occurs at the boundaries of companies that have respective obligations to maximize their own shareholder value. As a result, there is a lot of "friction" (and often complete blockage) in the data flow required to technically monitor, diagnose, optimize, and control the various complex process steps involved in manufacturing semiconductor-based products. Further complicating matters, as Moore's Law advances, the barriers of process, metrology, and verification physics are challenged.

[0010]

[0006] Therefore, it would be advantageous to develop a system and / or method for performing one or more functions with protected data sources from different entities that does not have one or more of the above-mentioned disadvantages. Summary of the invention

[0011] The following description of various embodiments should in no way be construed as limiting the subject matter of the appended claims.

[0012] One embodiment relates to a system configured to perform one or more functions with protected data sources from different entities. The system includes a virtual system coupled to an actual system to thereby receive output generated by the actual system for a physical version of the sample when the sample is placed within the actual system. The virtual system includes at least a computer system and a storage medium. The virtual system is unable to have the physical version of the sample placed therein. The virtual system is configured to perform one or more functions on the sample with 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 performed by the actual system on the physical version of the sample. The system may be further configured as described herein.

[0013] Another embodiment relates to a computer-implemented method for performing one or more functions with protected data sources from different entities. The method includes performing one or more functions on a sample with two or more protected data sources, respectively, from two or more different entities. The method also includes executing a virtual version of a process performed by an actual system with output generated by the actual system for a physical version of the sample when the sample is placed within the actual system. The one or more functions and the virtual version of the process are performed by a virtual system, which is coupled to the actual system to thereby receive the output generated by the actual system for the physical version of the sample. The virtual system includes at least a computer system and a storage medium. The virtual system is incapable of having the physical version of the sample placed therein.

[0014] The method may be performed as further described herein. In addition, the method may include any other steps of any other method described herein. In addition, the method may be performed by any of the systems described herein.

[0015] Additional embodiments relate to a non-transitory computer-readable medium storing program instructions executable on a computer system to perform one or more functions with protected data sources from different entities. A computer-implemented method includes the steps of the above method. The computer-readable medium may be further configured as described herein. The steps of the computer-implemented method may be executed as further described herein. In addition, the computer-implemented method executable by the program instructions may include any other steps of any other method described herein. BRIEF DESCRIPTION OF THE DRAWINGS

[0016] Other objects and advantages of the present invention will become apparent upon reading the following detailed description and referring to the accompanying drawings, in which:

[0017] Figure 1is a schematic diagram illustrating a side view of an embodiment of a system configured as described herein;

[0018] Figure 2 is a block diagram illustrating an embodiment of a system configured as described herein;

[0019] Figures 3 to 8 is a flow chart illustrating an embodiment of performing one or more functions on a sample using a protected data source from a different entity and / or performing a virtual version of a process on the sample; and

[0020] Fig. 9 is a block diagram illustrating one embodiment of a non-transitory computer-readable medium storing program instructions that may be executed on a computer system to perform one or more of the computer-implemented methods described herein.

[0021] Although the present invention is susceptible to various modifications and alternative forms, specific embodiments thereof are shown by way of example in the drawings and will be described in detail herein. However, it should be understood that the drawings and detailed description thereof are not intended to limit the invention to the specific forms disclosed, but on the contrary, are intended to cover all modifications, equivalents and alternatives falling within the spirit and scope of the invention defined by the appended claims. DETAILED DESCRIPTION

[0022] As used herein, the terms "design" and "design data" generally refer to the physical design (layout) of an IC and data derived from the physical design by complex simulations or simple geometric and Boolean operations. In addition, an image of a mask acquired by a mask inspection system and / or derivatives thereof may be used as one or more "proxies" for a design. This mask image or its derivatives may serve as a substitute for the design layout in any embodiment described herein using a design. A design may include any other design data or design data proxies described in the following: commonly owned U.S. Pat. No. 7,570,796, issued on August 4, 2009 to Zafar et al. and U.S. Pat. No. 7,676,077, issued on March 9, 2010 to Kulkarni et al., both of which are incorporated herein by reference as if set forth in their entirety. In addition, the design data may be standard cell library data, integrated layout data, design data for one or more layers, derivatives of the design data, and all or part of the chip design data.

[0023] However, in general, design information or data cannot be generated by imaging a wafer with a wafer inspection system. For example, a design pattern formed on a wafer cannot accurately represent the design of the wafer and a wafer inspection system cannot generate an image of the design pattern formed on a wafer with sufficient resolution so that the image can be used to determine information about the design of the wafer. Therefore, in general, design information or design data cannot be generated using a physical wafer. In addition, the "design" and "design data" described herein refer to information and data generated by a semiconductor device designer during the design process and can therefore be used in the embodiments described herein long before the design is printed on any physical wafer.

[0024] Turning now to the drawings, it should be noted that the drawings are not drawn to scale. In particular, the proportions of some elements of the drawings are significantly exaggerated to highlight the characteristics of the elements. It should also be noted that the drawings are not drawn to the same scale. Elements shown in more than one figure that may be similarly configured have been indicated using the same element numbers. Unless otherwise specified herein, any of the elements described and shown may include any suitable commercially available elements.

[0025] One embodiment is directed to a system configured to perform one or more functions with protected data sources from different entities. The novelty of the embodiments described herein is at least in part that they are configured to alleviate the concerns of protected data source stakeholders, whose cooperation is required 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, electrical, and computational techniques.

[0026] In one embodiment, the sample comprises a wafer. The wafer may comprise any wafer known in semiconductor technology. Although some embodiments are described herein with respect to one or more wafers, the embodiments are not limited to the samples with which they may be used. For example, the embodiments described herein may be used for samples such as photomasks, flat panels, personal computer (PC) boards, and other semiconductor samples.

[0027] The system includes a virtual system coupled to a real system to thereby receive output generated by the real system for a physical version of the sample when the sample is placed within the real system. Generally speaking, the term "real system" as used herein refers to a system that performs a process (i.e., a real process) on or using a real physical sample. In contrast, the term "virtual system" as used herein refers to a system that performs a process (i.e., a virtual process) on a sample without using or interacting with the real physical sample.

[0028] The system may or may not include an actual system that is configured to perform one or more processes on the sample while the sample is placed within the actual system to thereby generate an output for the sample. Generally speaking, the one or more processes performed by the actual system on the sample are yield control related processes, such as inspection, review, measurement, testing, and the like. The processes performed by the actual system are not meant to include processes performed by a mask or wafer manufacturing tool that alter one or more characteristics of the mask or wafer. For example, a wafer removed from a wafer inspection tool will have characteristics that are substantially the same as the characteristics it had when placed within the wafer inspection tool (unless, of course, a serious problem occurs). However, there may be some examples where a yield control related process may alter one or more characteristics of a sample, but the altered characteristics do not imply altering the functionality of a device formed on or having the sample. For example, a scanning electron microscope (SEM) may intentionally leave "burn marks" to assist in the subsequent repositioning of a particular point. In contrast, a wafer removed from a fabrication tool typically has properties (physical, chemical, and the like) that are different from those it had when placed within the fabrication tool (again, unless problems such as process failures occur), which will alter the properties of a device formed on or with the sample.

[0029] Since a real system performs one or more processes on a sample while the sample is positioned within the real system, the real system will include some kind of sample handling device or subsystem (e.g., a stage, a motor to drive the stage, a wafer or reticle handling robot, etc.). The sample handling device or subsystem will generally control the position of the sample within the real system. In this way, the real systems described herein are configured to perform processes on the physical samples themselves, in contrast to the virtual systems described further herein, which do not interact with the physical samples, even though they may perform one or more functions on the physical samples.

[0030] Performing one or more processes on a sample with an actual system will generally cause the actual system to generate some output (e.g., image, data, image data, signal, image signal, etc.). For example, during a process, a detector or sensor of the actual system may generate one or more images of the sample. The actual system may also include one or more computer subsystems that perform some functions, algorithms, or methods on the outputs generated by the one or more detectors or sensors of the actual system. For example, a computer subsystem of the actual system may perform defect detection on the sample using the outputs generated by the detectors of the actual system. The results of the defect detection or any other function, method, or algorithm may also be output from the actual system, as further described herein. Thus, the actual system described herein may generate various outputs, all or only part of which may be received by the virtual system, as further described herein.

[0031] A virtual system can be coupled to only one real system or to more than one real system. If a virtual system is coupled to more than one real system, then the real system may include two identical systems. Figure 1 , the system may include two actual systems 100 and 102. Each of the two actual systems includes a light source 104 configured to generate light. The actual system also includes a beam splitter 106 configured to direct light from the light source to a sample 108. The sample 108 is supported by a stage 110 within each of the actual systems. Light reflected, scattered, diffracted, or otherwise returned from the sample may be transmitted by the beam splitter 106 to a detector 112, which is included in each of the actual 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.

[0032] The output of the detectors may be received by a computer subsystem 114 included in each of the actual systems. The computer subsystem 114 may be coupled to each of the detectors in any suitable manner. The computer subsystem may be configured to use the output of the detectors to determine one or more characteristics of the sample. The one or more characteristics determined by the computer subsystem will vary depending on the configuration of the actual system and the sample on which the actual process is performed.

[0033] therefore, Figure 1 The actual systems shown in have the same configuration and thus may be systems of the same type. However, an actual system may include two systems with different configurations. For example, Figure 1 Any element of the actual system shown in may be selected to be different. In one such example, the actual system 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 actual system coupled to the virtual system may include any number and combination of any type of actual systems. In addition, the actual systems may each be configured as physically separate systems, which may be coupled by other hardware or software described further herein.

[0034] This article provides Figure 1 1 to generally illustrate one configuration of an actual system that may be coupled to a virtual system in the embodiments described herein. Obviously, the actual system configuration described herein may be altered to optimize the performance of the actual system, as is typically performed when designing a yield control-related system for the samples described herein. In addition, the system described herein may be implemented using an existing actual system (e.g., by adding the functionality described herein to an existing actual system), such as tools available from KLA Corp., Milpitas, Calif.). Alternatively, the actual system described herein may be designed "from scratch" to provide an entirely new actual system.

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

[0036] The actual system may include a mask inspection tool 200 and / or a mask defect review tool 202, such as Figure 2 . The reticle inspection and defect review tool may be an optical-based tool and / or an electron beam-based tool. Furthermore, the same actual system may be configured as a reticle inspection tool and a reticle defect review tool. The reticle inspection and / or defect review tool may include any suitable commercially available system. Additionally, the reticle inspection and / or defect review tool may be configured to perform a variety of inspections and / or reviews. The reticle inspection and / or defect review tool may be configured to generate output, such as an image or data, for the reticle in one or more imaging modes.

[0037] The actual system may also or alternatively include at least one wafer inspection tool and / or wafer defect inspection tool. The wafer inspection and wafer defect inspection tools may be light-based tools. For example, Figure 2 As shown in , the actual system may include an optical wafer inspection system 204 and / or an optical wafer defect inspection system 206. In addition, the same actual system may be configured as both a wafer inspection tool and a wafer defect inspection tool. The light-based wafer inspection and / or defect inspection tool may include any suitable commercially available system, such as the Puma system, 29xx and 39xx systems, and SPx, Surfscan, and Surfimage systems available from KLA-Tencor. In addition, the light-based wafer inspection and / or defect inspection tool may be configured to perform various inspections and / or inspections, such as dark field (DF) laser scattering, narrow band bright field (BF), broadband BF, etc. The light-based wafer inspection and / or defect inspection tool may also include any suitable light source, such as a broadband plasma (BBP) based light source. The wafer inspection and / or defect inspection tool may be configured to generate output (e.g., image or data) for the wafer in one or more imaging modes.

[0038] The wafer inspection tool and / or the wafer defect review tool may alternatively be configured as an electron beam based tool. Figure 2, the system may include an electron beam wafer inspection tool 208 and / or an electron beam wafer defect review tool 210. Additionally, the same actual system may be configured as both a wafer inspection tool and / or 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 system available from KLA-Tencor Corporation.

[0039] A real system may contain at least one measurement tool. For example, Figure 2 , an actual system may include a metrology tool 212. The metrology tool may include any suitable commercially available metrology tool. The metrology tool may be configured to measure or determine any one or more characteristics of any of the samples described herein. For example, the metrology tool may be configured as a scatterometry system that is configured to measure or determine the critical dimension or critical dimension uniformity of patterned features on a wafer. The metrology tool is generally different from the inspection tool in that the metrology tool does not scan the wafer or mask to produce an output at each position scanned. Instead, the metrology tool typically performs measurements at one or a limited number of measurement points on the wafer or mask in a move-acquire-measurement type scenario. In some examples, the metrology tool may perform measurements based on the output or results of another actual system described herein. For example, the metrology tool can be used to measure one or more characteristics of a defect detected by the inspection. Controlling the metrology tool in this manner can be further performed as described herein.

[0040] The actual system may further include at least one electrical tester, such as electrical tester 214, as shown in FIG. Figure 2 The electrical tester may include any suitable commercially available electrical test system. The electrical tester may be a contact-type system in which one or more elements of the system contact one or more device structures formed on a sample (e.g., a wafer) to establish an electrical connection between the wafer and the tester. Alternatively, the electrical tester may be a non-contact-type system in which no element contacts the wafer during testing.

[0041] Although various specific tools that may be actual systems are described herein, the present invention is not limited to these specific tools. For example, it is contemplated that any actual system configured to perform one or more processes on a wafer, a mask, or other sample described herein may be included in an actual system. In one such example, an actual system may also include a failure analysis tool and / or a material analysis tool. Additionally, an actual system is not limited to light and electron beam based tools. For example, an actual system may include ion beam based tools such as commercially available focused ion beam (FIB) systems, helium ion microscope (HIM) systems, and secondary ion mass spectrometer (SIMS) systems.

[0042] As mentioned above, the system includes a virtual system coupled to an actual system to thereby receive output generated by the actual system. Figure 1 , actual systems 100 and 102 are coupled to a virtual system 116. In one embodiment, a detector 112 of the actual system may be coupled to the virtual system so that the output of the detector may be sent directly to the virtual system. In this way, the virtual system may receive the raw output of the detector (i.e., the output that has not been altered by any data, signal, or other processing). Additionally or alternatively, a computer subsystem 114 of the actual system may be coupled to the virtual system so that the computer subsystem may send the output of the detector and / or any other information generated by the computer subsystem to the virtual system. The virtual system may also be coupled to the computer subsystem, detector, and any other element of the actual system. The virtual system may be coupled to any component of the actual system, as further described herein. For example, the virtual system 116 may be coupled to the computer subsystem 114 via any suitable transmission media (which may include any suitable wired and / or wireless transmission media known in the art), such as Figure 1 The virtual system 216 can be coupled to any of the Figure 2 Any or all of the actual systems shown in .

[0043] As described above, the actual system may include various different actual systems in various combinations. Therefore, the output received from the actual system may be different and vary depending on the configuration of the actual system and / or the actual process performed by the actual system on the sample. For example, the output may be a mapping of spatially continuous data (such as may be produced by a scanning actual system), spatially discrete data (such as may be produced by a move-acquire-measure system), metrology data, point defect detection data, etc.

[0044] The actual system includes at least a computer system and a storage medium. The term "computer system" is used interchangeably with the term "computer subsystem" herein. Each of the computer subsystems or systems described herein can take various forms, including personal computer systems, image computers, host computer systems, workstations, network devices, Internet devices, or other devices. In general, the term "computer system" can be broadly defined to cover any device with one or more processors that execute instructions from a storage medium. The computer subsystem or system may also include any suitable processor known in the art, such as a parallel processor. In addition, the computer subsystem or system may include a computer platform with high-speed processing and software as a stand-alone or networked tool. The storage medium may include any suitable storage medium known in the art or further described herein.

[0045] Although the virtual system is shown in the figure as having a specific computer configuration, it should be understood that the virtual system can have any suitable type of computer configuration. Figure 1The virtual system shown in may be formed by only a processor, memory, and input / output components of the virtual system, rather than any components that can accept user input (e.g., keyboard, mouse, screen, etc.). In this way, the virtual system may not include all of the components that would normally make up a stand-alone, fully functional computer system. However, in other examples, the virtual system may be similar to a fully functional computer system in that a user may directly use the virtual system to perform one or more functions using any of the data stored therein. In addition, more than one workstation or user may access the virtual system simultaneously, remotely, and / or wirelessly. For example, if Figure 1 , multiple workstations 118 and 120 can be coupled to the virtual system at the same time. In this way, multiple users can access the virtual system or data stored in the virtual system and use the virtual system to perform one or more of the functions further described herein.

[0046] The virtual system cannot place the physical version of the sample therein. For example, although the virtual system is configured to perform one or more functions on the sample, the virtual system cannot be configured to perform one or more functions on the sample. On the contrary, one or more functions of the sample can be performed on the data or other outputs generated by the actual process performed by the actual system on the sample. Therefore, unlike the actual system described herein, the virtual system does not have any sample handling capabilities, such as a carrier, a motor coupled to the carrier, a sample handling device or a robot or the like. In addition, although the virtual system can be configured to control one or more of the actual system so that the actual system performs a process on the actual sample, the virtual system itself cannot perform any actual process on the actual sample. In one such embodiment, the virtual system can be configured as a virtual tester (VI or VIVA). VI can generally be defined as a computer system that can store a large amount of output generated by the inspection subsystem for the sample, so that the output is "played back" in a manner that simulates the real-time acquisition of the output, during which only the stored output can be used to perform virtual inspection on the sample.

[0047] The virtual system and the actual system may be further configured as described in: U.S. Patent No. 8,126,255 issued on February 28, 2012 to Bhaskar et al., U.S. Patent No. 9,222,895 issued on December 29, 2015 to Duffy et al., U.S. Patent No. 9,816,939 issued on November 14, 2017 to Duffy et al., U.S. Patent No. 9,916,939 issued on March 13, 2018 to Bhaskar et al. No. 65, U.S. Patent No. 10,402,461 issued by Karsenti et al. on September 3, 2019, U.S. Patent No. 10,416,088 issued by Duffy et al. on September 17, 2019, U.S. Patent No. 10,539,612 issued by Duffy on January 21, 2020, and U.S. Patent No. 10,551,827 issued by Duffy on February 4, 2020, which are incorporated herein by reference as if set forth in their entirety.

[0048] The virtual system is configured to perform one or more functions on a sample with two or more protected data sources respectively from two or more different entities. In this way, the embodiments described herein provide the benefits of controlling a semiconductor process by enabling "cooperation between adversaries" to address the "distrust barrier". For example, the VI concept has evolved over time from the initial concept of large-scale image capture and playback (verifier simulation). This evolution is represented by the patents incorporated by reference above. However, according to the intellectual property (IP) protection policies between multiple companies that own the required data sources, the specific implementation of the application implemented by the VI innovation subject can be greatly enhanced by the protected data access further described herein. An embodiment of one or more functions performed by a virtual system with two or more protected data sources is further described herein.

[0049] As used herein, the term "entity" is defined as any entity that protects a data source, particularly a protected data source related to semiconductor technology, from another entity. Thus, as used herein, the term "different entities" is defined as any entity that individually protects different data sources from each other. An entity may include an individual or a group of individuals, but more likely the different entities will be different businesses, companies, organizations, academic institutions, consortiums, joint ventures, etc. that generate and protect IP that is related to the manufacture of semiconductor devices to some extent. In this way, an entity may include any legally recognized entity that has rights to certain IP that is interested in protecting it from infringement by another legally recognized entity. Different entities may also be "adversaries," such as shareholders associated with different corporate entities that have fiduciary responsibilities to the shareholders of the respective entities.

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

[0051] As used herein, the term "data source" is defined as any information from any source stored in any manner. For example, the data source may be a computer-aided design (CAD) of a semiconductor device, but the design may be in any format and stored in any suitable data structure. Other examples of data sources that can be used in the embodiments described herein include other types of design data, real and / or simulated images of samples, test results of samples, information about the process used to produce some portion of the device on the sample, and any other source of information, particularly relevant to the design, manufacture, and yield control of semiconductor devices.

[0052] Examples of features of the technical field involved in solving key problems in the semiconductor industry and which may thus produce protected data sources that may be used in or by the embodiments described herein further include (but are not limited to):

[0053] ●Design function:

[0054] ○Work products, including (but not limited to) chips, masks, packages, subsystems

[0055] ○ The goal involves converting electrical intent into physical intent for manufacturing

[0056] ○Calculation completed

[0057] ○ Design IP ownership is often separated from the manufacturing functional ecosystem

[0058] ○ Insert sensors and test functions (such as design for test (DFT)) into the circuit to assist verification and diagnosis

[0059] ○ Tools are sourced from an ecosystem of electronic design automation (EDA) and technical computer-aided design (TCAD) vendors

[0060] ●Manufacturing function:

[0061] ○Mask

[0062] ■ Designed for wafer fabrication (e.g., the pattern must be compatible with the intended lithography and etching processes, which further depends on material properties such as thin films and doping)

[0063] ■ Designed for mask manufacturing (e.g., the pattern needs to be compatible with exposure equipment and subsequent processing steps)

[0064] ○Chip, packaging and subsystems

[0065] ■ Ecosystem of factories (chip factories), equipment, software and material suppliers

[0066] ■Equipment suppliers can focus on one or more areas

[0067] ●Measuring and testing equipment

[0068] ●Online electrical test

[0069] ●Online material and failure analysis

[0070] ■Control software (manufacturing execution system (MES), advanced process control (APC), fault detection and classification (FDC), etc.)

[0071] ■Analysis software, all with independent IP protection benchmark

[0072] ●Testing function: Meet the electrical intent of wafer, chip, package, subsystem steps

[0073] ○ Based on knowledge of the expected static and dynamic behavior of the chip under test

[0074] ○Performed by equipment that physically handles the wafer / device under test

[0075] ○Execute with complex programs

[0076] Additional examples of protected data sources that can be provided to and used by a trusted virtual system in a secure manner include all of the following:

[0077] ●Testing procedures

[0078] ● Physical TCAD model (usually from a set of representative areas of the chip)

[0079] ● Electrical TCAD model (e.g., associated with the physical model above)

[0080] Metrics

[0081] ●Physical failure analysis

[0082] ●Fully annotated netlist

[0083] ●Fully labeled layout and wiring diagram

[0084] The virtual system is configured to execute a virtual version of a process that can be executed by an actual system on a physical version of a sample. As described above, the virtual system can be configured as any type of virtual system, such as VI. The virtual version of the process executed by the virtual system may include any virtual process, which may vary depending on the configuration of the virtual system and the actual system coupled to the virtual system. For example, if the actual inspection system is coupled to the virtual system, the virtual process may be a virtual inspection process executed with the output generated by the actual inspection system. If the actual measurement system is coupled to the virtual system, the virtual process may be a virtual measurement process executed with the output generated by the actual measurement system. Such virtual processes may be executed as further described herein, possibly in coordination with one or more other functions executed by the virtual system. For example, the results of one or more functions executed by the virtual system may be input to the virtual process. The results of one or more functions executed by the virtual system may determine certain parameters of how the virtual process is executed. The results of the virtual process may be input to one or more functions executed by the virtual system. Additional details of such embodiments are further described herein.

[0085] Thus, the virtual systems described herein may be configured as trusted virtual systems, such as VIs with adversarial cooperation features. The trusted virtual systems described herein are created to enable powerful process control and diagnostic applications for the semiconductor industry, including those described in U.S. Pat. No. 9,916,965, issued on March 13, 2018, by Bhaskar et al., which is incorporated herein by reference as if fully set forth, in a manner that can coexist with high performance computing (HPC) style virtual system software and computer infrastructure (such as described in U.S. Pat. No. 8,126,255, issued on February 28, 2012, by Bhaskar et al., which is incorporated herein by reference as if fully set forth). The embodiments described herein enable decision makers to shift their risk calculations toward allowing the use of high-value IP by multiple owners to be processed within a trusted virtual system. One reason why the embodiments described herein are particularly useful at this time is that as process dimensions shrink, devices become more complex in the z-direction (normal to the wafer surface) and the resulting process observability of the state of the wafer, package, subsystem, etc. becomes more opaque. As a result, the industry has become increasingly reliant on the application of virtualization methods (often referred to as “digital twins”) and artificial intelligence (AI), more precisely, physics-based AI techniques for inferring the state of work-in-progress (WIP).

[0086] In one embodiment, the virtual system is coupled to the actual system via a local network. The local network can be configured so that the virtual system is connected to the actual system by some hardware elements (such as wired transmission media) configured to transmit information, images, instructions, outputs, etc. between the two systems. However, in general, any suitable local network configuration can be used in the embodiments described herein. The networking of the embodiments described herein can also benefit from infrastructure computing platforms and / or secure networking hardware, such as NVIDIA BlueField-3 data processing units (DPUs) and / or Mellanox firmware tools (MFTs), which can be purchased from NVIDIA Corp., Santa Clara, Calif., in Santa Clara, California.

[0087] One reason that virtual systems coupled to real systems via local networks make sense for the embodiments described herein is the sheer size of image data that the virtual systems must handle for some of the functions described herein. For example, it is impractical or even impossible to perform some of the functions described herein on a cloud or hybrid cloud type system because the network is generally not fast enough. New data sources and applications described herein that can be used or executed in cooperation with large amounts of image data from real systems can also be part of the virtual system, regardless of where the operations are completed. A determining factor can be the (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 making them advantageously usable on hardware such as virtual systems described herein, which are actually connected to large amounts of image generation and / or storage. There are also benefits provided by performing such simulations on virtual systems such as the virtual systems described herein in the learning loop (e.g., updating training data with simulation results of detection deep learning (DL) networks, which can then be used in real time for improved inference of storage wafer images). Therefore, in the era of cloud computing, what constitutes a virtual system configured as described herein can be somewhat vague. The benefit of close proximity between virtual systems and real systems on a local network is that the functions described herein are generally "data-heavy" operations (high network costs) and "compute-heavy" operations, so it makes sense to use a computer for multiple functions. In other words, the virtual system can act as a local cloud. But the reason the virtual system is not "in the cloud" is because the functions described herein generate and use this large amount of image data.

[0088] Even though the functions and data sources described herein make it most practical to connect virtual and real systems through a local network, certain functions described herein may also be performed or configured in a cloud-based manner. For example, the embodiments described herein may utilize state-of-the-art cloud network security features implemented by products such as the Azure cloud platform commercially available from Microsoft Corp., Redmond, WA, and AWS cloud security available from Amazon Web Services (AWS), Seattle, WA. In addition, the embodiments described herein may utilize cloud collaboration features of products such as the Azure cloud platform and software such as static application security testing (SAST) products available from AWS and Synopsys, Inc., Mountain View, Calif. The embodiments described herein may also utilize secure computing system hardware and / or software, such as hardware and / or software available from defense contractors and consultants such as IBM Research, Yorktown Heights, NY.

[0089] In some embodiments, the virtual system is configured to receive two or more protected data sources on two or more encrypted and isolated data paths and store two or more protected data sources on two or more encrypted and isolated portions of storage media. In this way, the embodiments described herein can be configured for isolation of data paths (for storage and networking). For example, Figure 3 An embodiment of a trusted virtual system (which may be a trusted VI) is shown. Figure 3 As shown in , entity 1 (300), entity 2 (302) ... and entity N (304) can independently protect protected data source 1 (306), protected data source 2 (308) ... and protected data source N (310) respectively from each other.

[0090] although Figure 3 Although three or more different entities are shown, the number of different entities that can provide protected data sources to the virtual system is virtually unlimited. Figure 3 Each distinct entity is shown providing one protected data source to the virtual system, but each distinct entity may send any number of protected data sources to the virtual system.

[0091] Different entities may input their respective protected data sources into the virtual system at the same time or at different times. For example, a function performed by the virtual system on a sample may be performed using two different protected data sources from two different entities, and the function may be performed after receiving the two protected data sources, whether at different times or at the same time.

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

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

[0094] Any of the protected data sources stored in any of the encrypted and isolated storage portions may be input to virtual system operations 324, alone or in any combination. Virtual system operations 324 may include any one or more of the functions described herein, which may be performed using any one or more of the protected data sources, in conjunction with actual system output 326, which may be any result or output produced by an actual system for a physical version of a sample. For example, actual system output 326 may include output from an actual inspection system.

[0095] The main IP protection that can currently occur on VIs is the encryption of large amounts of image data. Any protected data source fed into the virtual system described herein can be identical to the data that would have been allowed on the actual tool 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. In terms of protected data sharing, possible protection mechanisms include (but are not limited to):

[0096] ●The reputation and credibility that a company or individual has earned over time

[0097] ● Encryption, as in the case of large amounts of image data stored on VI

[0098] ● Legal agreements, including (but not limited to) confidentiality agreements

[0099] ● Participate in the division of information within and between companies

[0100] ●Easy to prevent information disclosure

[0101] In another embodiment, the virtual system is configured to perform one or more functions using homomorphic encryption. For example, the virtual system operation 324 may include homomorphic operations or homomorphic HPC. Other forms of encrypted operations may also be used in the embodiments described herein. Homomorphic encryption is generally defined in the art as a type of encryption that allows operations to be performed on encrypted data without any decryption. The resulting operation is performed in an encrypted form, which can then be decrypted to produce an output that will be the same as the output when the operation is performed on unencrypted data. Homomorphic encryption can then be used to allow parties who do not have privileges to the data to process the data while the data remains encrypted. Therefore, homomorphic encryption is particularly suitable 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 having to decrypt the design data. Although homomorphic encryption operations are 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 any decryption of the data source can be used in the same manner to perform the functions described herein.

[0102] Nominally, while the inputs to a trusted virtual system may contain highly confidential information, the outputs of the application software processes integrated with the system generally pose a much lower threat to stakeholders because they are typically expected to be very similar to the outputs of currently used tools. For example, an inspection plan generated by a virtual 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 any threat to data security because the protected data source is typically not included in or discernible from the inspection plan. Nevertheless, a trusted virtual system can provide IP protection for inputs as well as outputs.

[0103] In one embodiment, the virtual system is configured to generate outputs of one or more functions and provide the outputs to a first of two or more different entities without exposing any of the two or more protected data sources that are not from the first of the two or more different entities. For example, the virtual system operation 324 may generate a number of different outputs that may vary depending on the functions performed by the virtual system using the received protected data sources. Figure 3 As shown in FIG. 3 , virtual system operation 324 may generate a protected data source neutral output 334, an output with protected data source 1 (328), an output with protected data source 2 (330) ... and an output with protected data source N (332). Each of these outputs may have been 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 the virtual system performs one function with one protected data source and another separate function with a different protected data source, then it should be relatively simple to generate outputs that ensure the security of the protected data sources, especially when the output generated by any function goes only to the entity that provides the protected data source for that function.

[0104] Protecting the data source in the output of a virtual system can become more complex when two different protected data sources from two different entities are combined for a single function and / or when the result of a function performed with a protected data source from a first entity is to be sent to a second entity without compromising the protected data source from the first entity. To this end, one approach is to ensure that any output produced by the virtual system contains only protected data sources from the entity receiving the output. In this way, the output produced by the virtual system for any function performed by the virtual system can contain Figure 3 , depending on which entity is receiving the output and which protected data sources are used. In either case, the virtual system can generate separate outputs from a single function (or more than one function) containing only protected data sources for the entity receiving the output. In particular, Figure 3 As shown in , output with protected data source 1 can be sent only to entity 1, output with protected data source 2 can be sent only to entity 2, ..., and output with protected data source N can be sent only to entity N.

[0105] One reason a virtual system may generate protected data source neutral outputs is to assume that entities that do not own any of the protected data sources used to perform a function on a sample will receive the output of that function. For example, a virtual system may use protected data sources 1, 2 ..., and N to perform a single function, 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.

[0106] In either case, regardless of the functions performed and the protected data sources used for the functions, the virtual system is preferably configured to produce output according to the contractual content of the legitimate customer-owned data from the supplier's tools in a manner that does not violate current customer / supplier specifications.

[0107] In some embodiments, the virtual system is configured to safely dispose of two or more protected data sources after performing one or more functions. For example, the virtual system is preferably configured so that proprietary data cannot be exported and may be configured to destroy the data in an irrecoverable manner after its use is complete. In this way, entities that provide their protected data sources to the virtual system can be assured that their data does not remain in the system, thereby mitigating the risk of accidental exposure or transmission. The virtual system may be configured to render the protected data sources irrecoverable in any suitable manner known in the art.

[0108] In another embodiment, the virtual system is configured to restrict control of hardware encryption keys for two or more protected data sources to two or more different entities, respectively. For example, the embodiments described herein may be configured for shareholder control of hardware encryption keys (e.g., for storage, networking, and computing). Hardware encryption keys may be configured in any suitable manner known in the art, and the embodiments described herein may be configured to restrict control of the keys in any suitable manner.

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

[0110] In additional embodiments, the virtual system is configured to enforce security of storage media via the Rust programming language.For example, the embodiments described herein may be configured to use memory security software (eg, using the Rust software language).

[0111] In one embodiment, performing one or more functions includes using at least two of the two or more protected data sources to perform a first of the one or more functions. In this way, one of the functions can be performed using some combination of two or more protected data sources. The function can be performed using all two or more protected data sources stored in or available to the virtual system. However, a single function can be performed using a non-owner of two or more protected data sources stored in or available to the virtual system.

[0112] Figure 4 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, such as Figure 3 . The virtual system may then use at least two of the protected data sources (e.g., protected data sources 1 and N or protected data sources 1, 2 ... and N) to perform function 400. In some embodiments, the input to the function may also include actual system output 326, which may include any output produced by any of the actual systems described herein, including (but not limited to) inspection system images, metric measurements, and the like. Function 400 may include any of the functions described herein. For example, a function as performed by a simulated inspection system requires two or more protected data sources, such as a semiconductor device design, a 3D sample model, and an inspection system model, each of which may be from a different entity. However, the embodiments described herein have been designed to ensure the security and reliability of such protected data sources throughout the process.

[0113] The output generated by executing function 400 may include an output with protected data source 1 (402), an output with protected data source 2 (404) ... and an output with protected data source N (406), which may be generated and configured as further described herein. Figure 4 As shown in , output with protected data source 1 can be sent only to entity 1, output with protected data source 2 can be sent only to entity 2, ..., and output with protected data source N can be sent only to entity N. In this way, entities do not receive output from other entities that expose any of the protected data sources. Figure 4 As further shown in , function 400 can generate protected data source neutral output 408, which can be generated as further described herein. In this way, the output of function 400 can be provided to entities that do not have the right to receive input to any of the protected data sources of function 400.

[0114] In another embodiment, executing one or more functions includes executing the first of the one or more functions using only the first of the two or more protected data sources and executing the second of the one or more functions using only the second of the two or more protected data sources. In this way, different functions can be executed using different protected data sources, respectively. For example, the first function can be executed using the first protected data source, the second function can be executed using the second protected data source, and so on.

[0115] Figure 5In 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, ..., N, respectively, such as Figure 3 . The virtual system may 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, the input to one or more functions performed by the virtual system may also include actual system output 326, which may include any output produced by any of the actual systems described herein, including (but not limited to) inspection system images, metric measurements, and the like. Function N+1 (506) may be performed using only a combination of protected data source N and actual system output 326. In this way, although different functions may be respectively performed with different protected data sources, the input to any function may include any other information described herein. Functions 500, 502, 504, and 506 may include any of the functions described herein.

[0116] Even if a function is performed by a virtual system using only one protected data source from one entity, other protected data sources from other entities may also be received by, stored on, and / or used by the virtual system when performing the function. In other words, no matter which protected data source(s) are used for any function being performed at any time, any other protected data source(s) may be simultaneously received by, stored on, and / or processed by the virtual system in other functions that may or may not be performed simultaneously. In any such scenario, the embodiments described herein have been designed to ensure the security and reliability of such protected data sources throughout the process.

[0117] The output generated by executing function 500 may include an output with protected data source 1 (508), the output generated by executing function 502 may include an output with protected data source 2 (510), ..., the output generated by executing function N may include an output with protected data source N (512), and the output generated by executing function N+1 may include an output with protected data source N (514), which may be generated and configured as further described herein. In addition, as Figure 5 As shown in , output with protected data source 1 can be sent only to entity 1, output with protected data source 2 can be sent only to entity 2, ..., and output with protected data source N can be sent only to entity N. In this way, entities do not receive output from other entities that expose any of the protected data sources. Figure 5500, 502, 504, and 506 may generate a protected data source neutral output, which may be generated as further described herein. In this way, the output of any of the functions may be provided to an entity that does not have the rights to receive input to the protected data source of the function.

[0118] Additionally or alternatively, a first function may be performed with a first combination of protected data sources, a second function may be performed with a second combination of protected data sources, and so on, and each of the protected data sources included in each of the combinations may or may not be mutually exclusive. In other words, a protected data source may not be included in more than one combination and therefore may not be used for more than one function. However, a protected data source may be included in two or more combinations and therefore may be used for more than one function. In this way, 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.

[0119] In another embodiment, the virtualization system is configured to execute a virtual version of a process using an output of at least one of the one or more functions. Figure 6 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, ..., N, respectively, such as Figure 3 The virtual system may then use at least two of the protected data sources to perform function 600. Function 600 may include any of the functions described herein.

[0120] 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 an actual system on a physical version of a sample. For example, the virtual process may be a virtual inspection process, a virtual metrology process, a virtual electrical test process, and the like. In one such example, the output of function 600 may be an inspection process solution selected for the sample based on the simulated performance of the inspection system, and the inspection process solution selection and inspection system performance simulation may be performed in function 600 and as further described herein. Virtual process 602 may then include a virtual inspection process that is executed and stored in a virtual system by applying the selected inspection process solution to an image of a physical version of the sample generated by an actual inspection tool.

[0121] The output generated by executing virtual process 602 may include one or more of an output with protected data source 1 (604), an output with protected data source 2 (606) ... and an output with protected data source N (608), which may be generated and configured as further described herein. Figure 6As shown in , output with protected data source 1 can be sent only to entity 1, output with protected data source 2 can be sent only to entity 2, ..., and output with protected data source N can be sent only to entity N. In this way, entities do not receive output from other entities that expose any of the protected data sources. Figure 6 As further shown in , virtual process 602 can generate protected data source neutral output 610, which can be generated as further described herein. In this way, the output of virtual process 602 can be provided to entities that do not have the right to receive input to function 600 and / or any protected data source of virtual process 602.

[0122] Figure 7 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, such as Figure 3 . The virtual system may 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 may include any of the functions described herein. In some embodiments, the input to one or more functions performed by the virtual system may also include actual system outputs ( Figure 7 ), which may include any output produced by any of the actual systems described herein, including but not limited to inspection system images, metric measurements, and the like. Function N+1( Figure 7 ) may be performed using only one of the protected data sources in combination with the actual system output.

[0123] In this way, although different functions may be performed with different protected data sources, respectively, the input to any function may include any other information described herein. In addition, even if a function is performed by a virtual system using only one protected data source from one entity, other protected data sources from other entities may also be received by the virtual system, stored on the virtual system, and / or used by the virtual system when performing the function. In other words, no matter which protected data source(s) are used for any function performed at any time, any other protected data source may be received by the virtual system, stored on the virtual system, and / or processed by the virtual system in other functions that may or may not be performed simultaneously. In any such scenario, the embodiments described herein have been designed to ensure the security and reliability of such protected data sources throughout the process.

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

[0125] The output generated by executing virtual process 706 may include an output with protected data source 1 (712), the output generated by executing virtual process 708 may include an output with protected data source 2 (714), ..., and the output generated by executing virtual process 710 may include an output with protected data source N (716), which may be generated and configured as further described herein. Figure 7 As shown in , output with protected data source 1 can be sent only to entity 1, output with protected data source 2 can be sent only to entity 2, ..., and output with protected data source N can be sent only to entity N. In this way, entities do not receive output from other entities that expose any of the protected data sources. Figure 7 706, 708, and 710 may generate a protected data source neutral output, which may be generated as further described herein. In this way, the output of any of the functions may be provided to an entity that is not permitted to receive input to the protected data source of the function.

[0126] In some embodiments, performing one or more functions includes performing a first of the one or more functions on a sample using a combination of at least one of two or more protected data sources and a result generated by executing a virtual version of a process. For example, any of the functions described herein may be performed with an input that includes a protected data source and any other information further described herein, including a result generated by executing a virtual inspection process, a virtual metrology process, a virtual electrical test process, a virtual defect inspection process, etc. An example of a function that can be performed with a protected data source and the result of a virtual process is to simulate the electrical characteristics of a sample by inputting the result 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 protected data sources and any other data sources (protected or unprotected) to be used securely and reliably to perform one or more semiconductor-related functions. By reducing barriers to using protected data sources, the embodiments described herein provide many advantages to the entire semiconductor manufacturing ecosystem, some examples of which are further described herein.

[0127] In one embodiment, one or more functions include generating a three-dimensional (3D) physical representation of a physical version of the sample. Figure 8 8, a virtual system may use protected data source 800 (which may include any of the protected data sources described herein, such as semiconductor device design information and / or a 3D model) to generate a 3D physical representation of the sample in step 802. The 3D physical representation of the physical version of the sample is not how the sample would look to a simulation of any tool or system, such as a metrology tool or system. Rather, the 3D physical representation is a simulation of how the sample would look in the sample space (e.g., if a perfect 3D image of the sample could be formed in a completely accurate manner, which is obviously impossible given the practical physical limitations of actual imaging systems).

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

[0129] One advantage of the embodiments described herein is that a 3D physical representation of a sample can be generated by a virtual system using a model (e.g., a dedicated model) as a protected data source, without exposing the protected data source. For example, as further described herein, a virtual system can receive a model of a process as a protected data source from a first entity and an input of the model as a semiconductor device design from a protected data source from a second entity to thereby generate a 3D physical representation of a physical version of the sample having the semiconductor device design formed thereon. As further described herein, each step of data handling / processing from receiving and storing to computing and outputting can be performed in a manner such that the protected data source of one entity is not shared with a different entity. In the above examples, the generated 3D physical representation can be provided to a semiconductor device designer, a process model developer, and / or another entity in different manners and contain different information such that the process model developer does not receive the semiconductor device design, and vice versa. Additionally or alternatively, the 3D physical representation can be output in a manner such that it can be used by an inspection tool operator for an inspection process to generate a physical version of the sample without having to access or use the semiconductor device design and / or process model. The same applies to other types of tools such as metrology tools, defect inspection tools, etc.

[0130] In one such embodiment, the 3D physical representation is a sample-level 3D, TCAD physical representation of a physical version of the sample. For example, one application enabled by the trusted virtual system described herein is to generate a wafer-level 3D, TCAD physical representation of a physical wafer. TCAD is generally defined in the art as the use of computer simulations to develop and optimize semiconductor process technologies and devices. Generating this 3D physical representation of the sample can be performed using 3D technology modeling and TCAD software available from Synopsys, Mountain View, Calif., and Silvaco, Santa Clara, Calif. Although one advantage of the embodiments described herein over other systems and methods is due to their virtual system configurations that can generate sample-level 3D physical representations (rather than only being able to simulate a relatively small portion of the sample), the embodiments described herein can be used to generate a 3D physical representation of any preselected portion of the sample (e.g., only a portion of a semiconductor device fabricated on the sample).

[0131] In addition to generating a 3D physical representation of a sample at the sample level (i.e., for the entire sample), other functions described herein may also be performed at the sample level. The sample-level properties of a function may be implemented by the sample-level properties of the 3D physical representation (e.g., when it is used as an input to another function). However, the embodiments described herein are capable of performing functions at the sample level regardless of the input. For example, a virtual system may be configured to perform a virtual inspection of a sample at the sample level using a sample-level image generated by an actual inspection system. In this way, the embodiments described herein provide a virtual system that implements a sample-level closed-loop digital twin experiment.

[0132] In another embodiment, one or more functions include injecting defects into the 3D physical representation, such as Figure 8 804. For example, another application implemented by the trusted virtual system described herein is to inject defects into the above-mentioned 3D TCAD physical representation. Defect injection can be performed as described in U.S. Patent No. 10,599,951, issued by Pascal et al. on March 24, 2020, which is incorporated herein by reference as if set forth in its entirety. Injecting defects into the 3D physical representation can be performed by changing the design data input to step 802, and changing the design data to inject defects can be performed as described in the patent cited above. In addition or alternatively, injecting defects into the 3D physical representation can be performed by changing the 3D physical representation itself to inject defects in the same way as the image is changed in the patent cited above. The type and characteristics of the defects injected into the 3D physical representation can be determined in any manner, such as based on knowledge of the type of defects expected or known to be formed in certain devices with certain characteristics and / or by certain processes with certain process characteristics. Information on the injected defects can be obtained from several sources, including (but not limited to) semiconductor device designers and semiconductor manufacturers.

[0133] Defect injection functionality is a major motivation 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 to inspection tool customers and manufacturers. These models require hundreds of defect instances to train and run the model (such as in bootstrapping) before it can detect defects on real samples. Today, it takes weeks to find a real instance of a single defect scenario on a single geometry. Then, the goal is to provide this instance 1000 times faster. Part of the way this can be done is to artificially inject synthetic defects into a 3D model of a sample that the inspection tool customer may already have. Until now, inspection tool customers have generally been reluctant to share 3D models of samples with inspection tool manufacturers or operators, and this information was not available for creating synthetic defects for DL ​​model training or bootstrapping. However, using the embodiments described herein that are configured to ensure the security of protected data sources in all aspects from receiving, storing, using, and even outputting, entities can safely and reliably make a 3D physical representation of a sample available to the inspection tool setup function, thereby enabling the generation of better DL inspection and / or classification models for inspection. Creating better inspection schemes will obviously lead to better inspection results, which benefits everyone involved in making and using the resulting semiconductor devices.

[0134] In additional embodiments, one or more functions include displacing the size of one or more features in the 3D physical representation, such as Figure 8 806 . For example, an additional application enabled by the trusted virtual system described herein is the permutation of dimensions in the form of a design of experiments (DOE). In one such example, the permuted dimensions may be any dimensions of any feature of a semiconductor device and / or sample of interest to a semiconductor designer and / or manufacturer, including dimensions typically measured in a metrology process. Such dimensions include, but are not limited to, line widths, contact hole diameters, alignment or spacing between features on one or more layers of a sample, and film thickness. The degree to which any feature has its dimensions permuted may vary depending on many factors, including the semiconductor design itself and the process used to manufacture it on the sample. In this way, the permutation of dimensions may be performed based on input from a semiconductor device designer and / or semiconductor manufacturer, which may be provided to the virtual system as one or more protected data sources. The protected data sources may then be handled in a reliable and secure manner as further described herein.

[0135] Permuting the dimensions of one or more features in a 3D physical representation can be used for many applications, such as examining how changes affect the inspection of a sample and how they may manifest as defects. For example, AI techniques such as DL networks are able to include potential sources of variation that may not have an obvious causal relationship at first glance. Much of the work in inspection is identifying aspects of the process that need better measurement and control to eliminate sources of defect mechanisms. Systematic defect sources often have multiple dependencies on physical parameters that need better control. Part of the value of the "digital twin" functionality provided by the virtual system is to predict multivariate process marginals and in turn predict how these will look like an inspector. Conceptually similar to a "Bayesian prior", the power of this function is that it can actively look for signatures in optical (or other inspector) data that would otherwise be ignored. In this way, a 3D physical representation of a sample with permuted feature dimensions can be input to the simulation function further described herein.

[0136] In another embodiment, one or more functions include simulating the performance of the inspection system based on the 3D physical representation, such as Figure 8 808 of . For example, another application enabled by the trusted virtual system described herein is a defect inspection tool simulation that takes a 3D physical model as input. Thus, this simulation step can use a protected data source of the inspection system manufacturer as input. For example, information about the inspection system, such as an optical transfer function, can be used as input for a simulation of the inspection system performance.

[0137] Simulating the performance of the inspection system may also be performed using a model of the imaging performed by the inspection system. In other words, the performance may be simulated using a physics-based or forward simulation model of the inspection system. Simulating the performance of the inspection system may also include simulating images that may be produced by the inspection system using a model such as WINsim, which is commercially available from CLA and which may use an electromagnetic (EM) wave solver to rigorously model the response of the inspector. Such simulations may be performed using any other suitable software, algorithm, method, or system known in the art.

[0138] However, simulating the performance of the inspection system may also or alternatively be performed in a generative manner using a DL-type model or network. For example, simulating the performance of the inspection system may include simulating images that may be produced 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 a realistic-looking image of the performance of the simulated inspection system. The GAN or variational Bayesian method may be performed as described in U.S. Patent No. 10,599,951, issued on March 24, 2020 by Pascal et al., which is incorporated herein by reference as if set forth in its entirety. The embodiments described herein may be further configured as described in such patent.

[0139] The embodiments described herein may also be configured to set up and / or perform an inspection process, such as disclosed in U.S. Published Patent Application No. 2009 / 0080759, published on March 26, 2009, by Bhaskar et al., and U.S. Published Patent Application No. 2014 / 0241610, published on August 28, 2014, by Duffy et al., and U.S. Patent No. 7,676,077, issued on March 9, 2010, by Kulkarni et al., and U.S. Patent No. 7,676,077, issued on January 2, 2011, by Duffy et al. No. 7,877,722 issued on June 5, 2012, No. 8,194,968 issued on June 5, 2012, No. 8,611,639 issued on December 17, 2013, and No. 9,183,624 issued on November 10, 2015 by Kalsandy et al., which are incorporated herein by reference as if fully set forth. The embodiments described herein may be further configured as described in these publications and patents.

[0140] 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. are unable to use a 3D physical model of the sample to be inspected as an input to the inspection tool simulation. Engineers are left guessing with some selective input from the semiconductor device design owner, which takes weeks or even months and can be iterative. However, the embodiments described herein provide systems and methods that ensure the security of a protected data source for semiconductor device designers, such as a 3D physical model, which can then be modified for simulation to thereby eliminate the current "wasted" work of inspection tool manufacturers, owners, operators, etc. to manufacture incorrect versions of the model.

[0141] In some cases, simulating the performance of the inspection system may include simulating only the imaging portion of the inspection process, i.e., simulating what an image of a sample produced by the inspection system would look like under one or more sets of imaging hardware parameters. Such simulations may implement a Bayesian inspector concept. For example, given some metrology data for a sample, the virtual system may infer what an expected 3D TCAD representation of the sample would be. The 3D TCAD representation may then be used to generate a simulation of an expected inspector image. In some examples, the expected inspector image may be used as a reference to compare with an actual acquired and / or stored image (virtual or actual) of a wafer from the inspector. Thus, this expected inspector image may be used as a reference image, and this type of image comparison may be performed for die-to-database type defect inspection.

[0142] The simulated inspector images may also or alternatively be used to set 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 rather than the position on the sample in which the image is generated) may be generated by a virtual system based on a 3D TCAD representation of the sample and used to determine which mode is best suited for sample inspection performed by the actual system. Such simulations may also be performed for different actual systems to determine which tool is best suited for sample inspection. The simulated images may also be used to select one or more parameters of a defect detection method for detecting defects in the image. Such parameters of the defect detection method may include (but are not limited to) which defect detection algorithm to use for inspection, which parameters such as thresholds to use for inspection, and the like. In this way, all aspects of the actual inspection process performed by the actual inspection system may be set based on the simulated inspector images generated from the 3D TCAD representation.

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

[0144] In another embodiment, one or more functions include simulating the performance of a process tool based on a 3D physical representation, such as Figure 8, and the process tool is configured to perform a process of intentionally changing one or more characteristics of the physical version of the sample on the physical version of the sample. For example, an additional application implemented by the trusted virtual system described herein is a process tool simulation that takes a 3D physical model as input. The performance of the simulated process tool can be performed using any model currently used in the field, including physics-based, forward simulation models, and generated DL models. In general, the process tool model can be a protected data source for the process tool manufacturer. The process tool model can be provided to the virtual system by the process tool manufacturer, and the process tool manufacturer can ensure that the process tool model will be received, stored, used, and discarded in a safe and reliable manner by the virtual system embodiments described herein. The process tools whose performance can be simulated by the embodiments described herein may include any process tools configured to intentionally change one or more characteristics of the sample, such as deposition tools, ion implantation tools, chemical mechanical polishing tools, lithography tools, etching tools, and the like.

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

[0146] Even after determining that a semiconductor device design can be successfully manufactured, it may be useful to determine how changes in the process will affect the semiconductor device. In this way, a process window for a process that will produce a semiconductor device with acceptable characteristics can be established. For example, a process tool simulation can be performed with different values ​​of one or more parameters of the process (such as lithography exposure and dose) to determine one or more physical characteristics of a sample that will be produced at different values. The characteristics can be analyzed to determine which values ​​produce acceptable device characteristics. This modeling can be combined with the electrical analysis further described herein to determine not only which process parameter values ​​will produce acceptable physical characteristics but also or alternatively which process parameter values ​​will produce acceptable electrical device characteristics. Therefore, this analysis requires one or more protected data sources and semiconductor device design and process tool models, all of which security and reliability can be ensured in the same manner by the embodiments described herein.

[0147] In one embodiment, one or more functions include extracting a netlist of devices formed on a physical version of the sample based on the 3D physical representation, such as Figure 8814. For example, one application enabled by the trusted virtual system described herein is netlist extraction from a 3D TCAD representation of a wafer. Extracting the netlist of a device may be performed using any commercially available or currently used method or system. In one such example, a netlist extraction method may be provided as a protected data source to the embodiments described herein, and a 3D physical representation may be input to such method.

[0148] In another embodiment, one or more functions include generating an electrical representation of a netlist, such as Figure 8 816. In one such embodiment, the electrical representation of the netlist is a sample-level, TCAD electrical representation of the netlist. For example, one application implemented by the trusted virtual system is to generate a wafer-level 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 (e.g., SPICE open source software). However, the electrical representation generation method can also be provided as a protected data source to the embodiments described herein, and the netlist can be input to this method.

[0149] In another such embodiment, one or more functions include replacing one or more electrical parameters of the electrical representation, such as Figure 8 818 of . For example, another application implemented by a trusted virtual system is to replace electrical parameters according to a DOE. In one such example, a virtual system can use a protected data source such as information about a test program to perform fault modeling, fault coverage, test design, fault injection, and the like. The test program information may include information about the parameters of the tests to be performed on the manufactured semiconductor device, such as where and how the tests are performed. This information can then be used to infer where semiconductor device designers, owners, manufacturers, etc. are concerned about possible failures. Based on the information, the electrical representation of the sample can be modified in one or more different ways to replace the electrical parameters of the electrical representation. One way to perform such a modification is to use a structural model to modify one or more structural characteristics of the physical representation to thereby modify one or more electrical parameters of the electrical representation. In one such example, one or more structural parameters can be modified to artificially cause a connection between two structures, which will cause a short circuit in the device. Another way to perform such a modification is to use a functional model to modify one or more functional characteristics of a physical or electrical representation to thereby modify one or more electrical parameters of the electrical representation.

[0150] Therefore, replacing the electrical parameters of the electrical representation can be considered as the reversal of replacing the physical properties of the physical representation. In particular, the physical structure of the semiconductor device is designed to meet the electrical specifications. The physical tolerances of the semiconductor structure are constrained by the acceptable variation of the resulting electrical parameters. Therefore, the physical parameters can be varied to predict the electrical parameters, but vice versa, the electrical parameters can also be varied to predict the physical parameters. In this way, once the correspondence between the physical and electrical parameters is known (TCAD model), the direction of inference can be reversed, for example, by explaining for a given electrical function what the physical properties that can lead to this are.

[0151] Obviously, there may be many different commercially available semiconductor device fault models that can be used to replace one or more electrical parameters of the electrical representation in the embodiments described herein, and the virtual system described herein may be configured to use any of them to perform the replacement of the electrical representation. The virtual system described herein provides more than just the value of being able to run the model, because it can perform functions that utilize protected data sources from different entities in a reliable and secure manner. In one such example, the electrical representation replaced by the virtual system can be generated from protected data from a semiconductor device designer and may even contain the protected data. The virtual system can use the combination of the electrical representation and the fault model (which may be or include protected data from different entities) to replace the electrical representation. The replacement 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 virtual system can use information about an electrical tester from another entity to generate a test program for a semiconductor device based on the replacement electrical representation. The test program may not include any information about the electrical representation or the replacement electrical representation, thereby enabling the electrical tester operator to test the semiconductor device without having access to or needing to access protected data sources from semiconductor device designers and fault model developers. In this way, the embodiments described herein may overcome domain boundaries that are typically in place for both practical and IP reasons.

[0152] As mentioned elsewhere herein, one or more functions performed by a virtual system with two or more protected data sources may be performed in addition to or in conjunction with a virtual version of a process performed by an actual system. The embodiments described herein may therefore extend the functionality and use of virtual systems, such as virtual inspectors, by leveraging the trusted properties described herein. For example, electrical failures may be functional (usually caused by defects) or parametric (usually attributed to changes found with measurements). Many inspection systems currently on the market are primarily concerned with how a sample looks in an image to thereby find defects that may or may not cause actual problems with the functionality of a semiconductor device. By extending the functionality of a virtual inspector beyond just inspection to include functionality related to electrical failure considerations / inspections of semiconductor devices, embodiments may generate and provide important information not only about how a sample looks but also about how a device formed on or with a sample works electrically. The functionality of other systems described herein, such as virtual and actual metrology systems, may be extended in the same manner. The embodiments described herein thereby bridge the physical and electrical spaces by enabling multiple protected data sources from different entities to be used individually or in combination on a single system in a reliable and secure manner.

[0153] The trusted virtual system described herein enables Design Technology Co-Optimization (DTCO) experiments to be conducted in research and development environments. While these activities are compartmentalized today, the embodiments described herein enable virtual inspection of digital twins of samples as well as real sample records and can run real-time experiments of the entire DTCO process, which would otherwise take weeks / months to conduct physically.

[0154] The embodiments described herein can therefore benefit multiple parties in the semiconductor device manufacturing ecosystem. Semiconductor device designers can better understand what is working or not working by allowing their protected data to be used in the virtual system described herein without worrying about the security and reliability of their data, 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 process and developing better systems and methods for future tools. In the same way, process tool, metrology tool and electrical test tool manufacturers can produce better tools and processes. The yield of existing tools and processes can be improved in this way and the development of new tools and processes can be made easier, faster and cheaper with a greater chance of success. Then, in general, by eliminating the barriers that currently prevent different entities from allowing other entities to use their protected data sources, the embodiments described herein can provide advantages and improvements for almost every part of the semiconductor manufacturing ecosystem.

[0155] In additional embodiments, one or more functions include injecting faults into the electrical representation, such as Figure 8820. For example, an additional application enabled by the trusted virtual system is fault injection into this representation (e.g., using a SPICE model of the fault). In one such example, the virtual system may perform the fault injection using a protected data source such as information about the test program. The virtual system may perform the fault injection in the same manner as described above with respect to the replacement electrical parameters.

[0156] In some embodiments, one or more functions include generating a virtual static test of an electrical representation to find static faults, such as Figure 8 822 of . For example, another application implemented by a trusted virtual system is virtual static testing of electrical representations to find static (DC) faults. In one such example, the virtual system can use a protected data source such as information about the test program to perform fault modeling, fault coverage, and the like. In this way, in some embodiments, the virtual system can be a virtual tester with correct inputs.

[0157] In another embodiment, one or more functions include generating virtual functional tests of electrical representations to find parameter failures, such as Figure 8 824 of . For example, another application implemented by a trusted virtual system is virtual functional testing of electrical representations to find parameter (AC) faults. In one such example, the virtual system can use a protected data source such as information about the test program to perform fault modeling, fault coverage, and the like. In this way, in some embodiments, the virtual system can be a virtual tester with correct inputs.

[0158] All embodiments described herein may be configured to store the results of one or more steps performed by the embodiments in a computer-readable storage medium. The results may include any of the results described herein and may be stored in any manner known in the art. The storage medium may include any storage medium described herein or any other suitable storage medium known in the art. After the results are stored, the results may be accessed in the storage medium and 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, and the like.

[0159] Such functions include, but are not limited to, altering a process, such as a recipe or step, that is or is to be performed on a sample in a feedback or feedforward manner. For example, the virtual system may be configured to determine one or more changes to a process performed on a sample inspected as described herein and / or to a process that is to be performed on a sample based on a detected defect. The change in process may include any suitable change in one or more parameters of the process. The virtual system preferably determines the change so that the defect can be reduced or prevented on other samples on which the corrective process is performed, the defect on the sample can be corrected or eliminated in another process performed on the sample, the defect can be compensated for in another process performed on the sample, and so on. The virtual system may determine such changes in any suitable manner known in the art.

[0160] The changes may then be sent to a semiconductor manufacturing system (not shown) or a 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 may be coupled to the semiconductor manufacturing system, such as via one or more common elements, such as a housing, a power supply, a sample handling device or mechanism, etc. The semiconductor manufacturing system may include any semiconductor manufacturing system known in the art, such as a lithography tool, an etching tool, a chemical mechanical polishing (CMP) tool, a deposition tool, and the like.

[0161] Each of the embodiments of each of the above systems may be combined together into a single embodiment.

[0162] Another embodiment is directed to a computer-implemented method for performing one or more functions with protected data sources from different entities. The method includes performing the one or more functions on a sample with two or more protected data sources, respectively, from two or more entities. The method also includes executing a virtual version of a process that can be performed by the real system with output generated by the real system for a physical version of the sample when the sample is placed in the real system. The one or more functions and the virtual version of the process are performed by the virtual system, which is coupled to the real system to thereby receive output generated by the real system for the physical version of the sample. The virtual system includes at least a computer system and a storage medium. The virtual system cannot have the physical version of the sample placed therein.

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

[0164] Additional embodiments are directed to a non-transitory computer-readable medium storing program instructions executable on a computer system to perform one or more functions with protected data sources from different entities. Fig. 9One such embodiment is shown in FIG. Fig. 9 , non-transitory computer readable medium 900 includes program instructions 902 executable on a computer system 904. The computer-implemented method may include any of the steps of any of the methods described herein.

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

[0166] Program instructions may be implemented in any of a variety of ways, including process-based technology, component-based technology, and / or object-oriented technology, etc. For example, program instructions may be implemented using ActiveX controls, C++ objects, JavaBeans, Microsoft Foundation Classes ("MFC"), SSE (Streaming SIMD Extensions), or other technologies or methods as needed.

[0167] Computer system 904 may be configured according to any of the embodiments described herein.

[0168] Those skilled in the art will understand further modifications and alternative embodiments of various aspects of the present invention in light of the specific embodiments. For example, methods and systems for performing functions with protected data sources from different entities are provided. Therefore, the specific embodiments should be interpreted as being illustrative only and for the purpose of teaching those skilled in the art the general manner of implementing the present invention. It should be understood that the forms of the present invention shown and described herein should be considered as currently preferred embodiments. Those skilled in the art will understand after having benefited from the specific embodiments of the present invention that elements and materials may replace the elements and materials illustrated and described herein, parts and processes may be reversed, and certain features of the present invention may be utilized independently. Changes may be made to the elements described herein without departing from the spirit and scope of the present invention described in the appended claims.

Claims

1. A system configured to perform one or more functions using protected data sources from different entities, comprising: a virtual system coupled to an actual system to thereby receive output generated by the actual system for a physical version of the sample when the sample is placed within the actual system, wherein the virtual system comprises at least a computer system and a storage medium, wherein the virtual system is unable to have the physical version of the sample placed therein, and wherein the virtual system is configured to: performing one or more functions on the sample using two or more protected data sources, respectively from two or more different entities; and A virtual version of a process that can be performed by the actual system on the physical version of the sample is executed. 2 . The system of claim 1 , wherein the virtual system is further configured as a virtual checker.

3. The system of claim 1, wherein the virtual system is further coupled to the actual system via a local network.

4. The system of claim 1 , wherein the virtual system is further configured to receive the two or more protected data sources on two or more encrypted and isolated data paths, respectively, and to store the two or more protected data sources on two or more encrypted and isolated portions of the storage medium, respectively.

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

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

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

8. The system of claim 1, wherein the virtual 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. The system of claim 1, wherein the virtual system is further configured for secure third-party authentication of the two or more protected data sources within at least the computer system and the storage medium of the virtual system.

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

11. The system of claim 1, wherein performing the one or more functions comprises using at least two of the two or more protected data sources to perform a first of the one or more functions.

12. A system according to claim 1, wherein executing the one or more functions includes using only a first of the two or more protected data sources to execute the first of the one or more functions and using only a second of the two or more protected data sources to execute the second of the one or more functions.

13. 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. The system of claim 1, wherein performing the one or more functions comprises performing a first of the one or more functions on the sample using a combination of at least one of the two or more protected data sources and a result produced by executing the virtual version of the process.

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

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

17. A system according to claim 15, wherein the one or more functions further include one or more of the following: injecting defects into the three-dimensional physical representation; displacing the dimensions of one or more features in the three-dimensional physical representation; simulating the performance of an inspection system based on the three-dimensional physical representation; simulating the performance of a metrology system based on the three-dimensional physical representation; and simulating the performance of a process tool based on the three-dimensional physical representation, and wherein the process tool is configured to perform a process on the physical version of the sample that intentionally changes one or more characteristics of the physical version of the sample.

18. The system of claim 15, wherein the one or more functions further comprises extracting a netlist of a device formed on the physical version of the sample based on the three-dimensional physical representation.

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

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

21. The system of claim 19, wherein the one or more functions further comprise one or more of: permuting 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 parameter faults.

22. A non-transitory computer readable medium storing program instructions executable on a computer system to perform one or more functions with protected data sources from different entities, wherein a computer-implemented method comprises: performing one or more functions on the sample using two or more protected data sources, each from two or more different entities; and Executing a virtual version of a process that can be executed by the actual system when the sample is placed in an actual system with output generated by the actual system for a physical version of the sample, wherein the one or more functions and the virtual version of the process are performed by a virtual system, the virtual system is coupled to the actual system to thereby receive the output generated by the actual system for the physical version of the sample, wherein the virtual system includes at least the computer system and a storage medium, and wherein the virtual system is incapable of having the physical version of the sample placed therein.

23. A computer-implemented method for performing one or more functions using protected data sources from different entities, comprising: performing one or more functions on the sample using two or more protected data sources, each from two or more different entities; and Executing a virtual version of a process that can be executed by the actual system when the sample is placed in an actual system with output generated by the actual system for a physical version of the sample, wherein the one or more functions and the virtual version of the process are performed by a virtual system, the virtual system is coupled to the actual system to thereby receive the output generated by the actual system for the physical version of the sample, wherein the virtual system includes at least a computer system and a storage medium, and wherein the virtual system is incapable of having the physical version of the sample placed therein.

Images