Parallel mask rule checking on evolving mask shapes in optical proximity correction flow

Abstract

Embodiments of the present disclosure relate to parallel mask rule checking of evolving mask shapes in an optical proximity correction (OPC) flow for integrated circuit design. Systems and methods are disclosed that perform mask (manufacturing) rule checking (MRC) in parallel, share information to maintain symmetry when violations are corrected. In embodiments, the shared information is also used to minimize changes to the geometry of the proposed mask shape caused by OPC. In contrast to conventional systems, MRC is performed in parallel on multiple edges, sharing information between different edges to encourage symmetry. In embodiments, all edges can be adjusted in parallel to reduce mask edge traversal bias.

Description

Background Technology

[0001] As integrated circuit geometry has shrunk, computational lithography has been developed to ensure that masks used to fabricate circuits result in optimal chip yield and short manufacturing turnaround times. An initial (desired) layout of the target integrated circuit design is processed to calculate a wafer image (e.g., using a photomask to fabricate circuits “printed” on the wafer). Computational lithography (also known as inverse lithography (ILT) or optical proximity correction (OPC)) compensates for optical lithography effects (e.g., diffraction) that cause mismatches between the actual wafer image and the initial layout. In other words, OPC compensates for errors caused by lithography effects. Examples of errors include narrowing or widening of lines, rounding of corners, and shortening of line ends. OPC generates suggested mask shape variations that will closely approximate the target integrated circuit design layout.

[0002] After the proposed mask shape variations are determined by OPC, a Mask (Manufacturing) Rule Check (MRC) is performed to ensure that the desired yield can be met when manufacturing integrated circuits using the wafer images (with the proposed mask shape variations) generated from these masks. Mask rules define a set of context-dependent geometric constraints for the mask shape (e.g., minimum edge-to-edge interior and exterior, corner-to-corner, polygonal regions, etc.). MRC is performed for each iteration of OPC. The result of OPC is the proposed edge segmentation shift, and the MRC algorithm varies the amount of edge segmentation shift such that the resulting mask shape is manufacturable.

[0003] When performing conventional MRC, the list of edges defining the mask shape is traversed, and each edge that violates a rule is adjusted to remove or reduce the violation. However, removing one violation may introduce a new one. The edge list is traversed in the same order until a violation is removed. Because the edges are traversed in the same order each time and each adjustment is determined independently, conventional MRC techniques often introduce mask edge traversal bias. For example, moving the first edge away from the second edge to correct a violation can asymmetrically increase the width of the polygon. Ideally, each correction should be as symmetrical as possible. For example, the first and second edges should both be moved by equal amounts to symmetrically increase the width of the polygon. These problems and / or other issues associated with the prior art need to be addressed. Summary of the Invention

[0004] Embodiments of this disclosure relate to parallel mask rule checking of evolving mask shapes within an optical proximity correction (OPC) stream. Systems and methods are disclosed for performing mask (manufacturing) rule checks in parallel and sharing information to maintain symmetry as violations are corrected. In embodiments, the shared information is also used to minimize changes in the geometry of the proposed mask shape caused by OPC.

[0005] Compared to conventional systems (such as those described above), MRC is performed on multiple edges in parallel, thereby sharing information among different edges to promote symmetry. In an embodiment, all edges are adjusted in parallel to reduce mask edge traversal bias. In an embodiment, the list of edges defining the mask shape is reorganized into a tree structure before identifying MRC violations. The tree structure provides an effective structure for determining which other edges in the mask shape have dependent violations associated with edges included in the same mask shape or that define adjacent mask shapes.

[0006] In one embodiment, the method includes receiving a set of edges that define a mask shape for manufacturing an integrated circuit and identifying at least one mask manufacturing rule violation corresponding to these mask shapes. Adjustments are computed in parallel to reduce or remove the set of edges that violate at least one mask manufacturing rule. At least one edge in the set of edges is adjusted according to the calculated adjustments to produce an adjusted set of edges. In this embodiment, the mask shape includes both an initial shape, proposed variations, and a final variation of the mask shape. Attached Figure Description

[0007] The system and method for parallel mask rule checking of evolved mask shapes in an optical proximity correction flow are described in detail below with reference to the accompanying drawings, wherein:

[0008] Figure 1A illustrates the multi-edge dependency of a mask edge according to the prior art.

[0009] Figure 1B A flowchart is shown of a computational lithography method suitable for implementing some embodiments of the present disclosure.

[0010] Figure 1C Some embodiments suitable for implementing this disclosure are shown. Figure 1B The flowchart of the parallel MRC steps is shown.

[0011] Figure 2A shows an example initial mask shape and a suggested mask shape variation according to the prior art.

[0012] Figure 2B illustrates the manufacturing rules and potential violations based on existing technology.

[0013] Figure 2C An adjusted mask shape, adjusted using a parallel MRC stream according to an embodiment, is shown.

[0014] Figure 2D The mask shape is shown according to the manufacturing rules and parallel MRC flow adjustment according to the embodiment.

[0015] Figure 2EThe initial mask shape according to the embodiment, the proposed mask shape variation, and the mask shape adjusted by the parallel MRC flow are shown.

[0016] Figure 2F shows a mask shape modified using conventional MRC flow according to existing technology.

[0017] Figure 3 Example parallel processing units suitable for implementing some embodiments of this disclosure are shown.

[0018] Figure 4A Some embodiments suitable for implementing this disclosure are shown. Figure 3 An example of a general-purpose processing cluster within a parallel processing unit.

[0019] Figure 4B Some embodiments suitable for implementing this disclosure are shown. Figure 3 An example memory partition cell for a parallel processing unit.

[0020] Figure 4C Some embodiments suitable for implementing this disclosure are shown. Figure 4A An example of streaming multiprocessors.

[0021] Figure 5A This is a conceptual diagram of a processing system implemented using the PPU of FIG4, suitable for implementing some embodiments of the present disclosure.

[0022] Figure 5B Exemplary systems in which various architectures and / or functions of various prior embodiments can be implemented are shown.

[0023] Figure 5C Components of an exemplary system that can be used to train and utilize machine learning in at least one embodiment are shown.

[0024] Figure 6 An exemplary streaming system suitable for implementing some embodiments of this disclosure is shown. Detailed Implementation

[0025] A system and method relating to parallel mask rule checking of an evolving mask shape in an optical proximity correction (OPC) stream are disclosed. Mask (manufacturing) rule checking (MRC) is performed in parallel on multiple edges, sharing information among different edges to accelerate MRC value measurement, violation identification, and / or mask shape edge adjustment. In embodiments, all edges are adjusted in parallel to reduce mask edge traversal bias. In embodiments, the list of edges defining the mask shape is reorganized into a tree structure before identifying MRC violations. The tree structure provides an efficient structure for determining which other edges in the mask shape have dependent violations. In embodiments, mask shape edges are adjusted to promote symmetry. In embodiments, mask shape edges are adjusted to minimize changes in the mask shape geometry of the proposed mask shape caused by OPC.

[0026] As integrated circuit geometry has shrunk, computational lithography (OPC) has evolved to ensure that masks used in manufacturing integrated circuits result in target chip yields and desired manufacturing turnaround times. OPC processes the initial layout of the target integrated circuit design to calculate a wafer image (e.g., "printing" the manufactured circuitry onto the wafer using a photomask). Compensation is then provided for lithographic effects (e.g., diffraction) that cause mismatches between the actual wafer image and the initial layout. In other words, OPC compensates for errors caused by lithographic effects. Examples of these errors include line narrowing or widening, rounding of corners, and shortening of line ends.

[0027] OPC generates suggested mask shape variations that, when applied to the initial layout, compensate for lithographic effects, ensuring that the fabricated mask is patterned on the wafer as closely as possible to the target design. The suggested mask shape variations may include additional mask shapes (e.g., polygons) and / or modifications to existing mask shapes. OPC may also generate auxiliary features, decorations, or annotations that are not incorporated into the mask shape but can be used to guide mask fabrication. For example, auxiliary features can control the depth of focus of the illumination angle for a particular mask shape. After the suggested mask shape variations are determined by OPC, MRC is performed to ensure that the desired yield is met when fabricating integrated circuits using the wafer image generated from these masks (with the suggested mask shape variations). Fabrication mask rules that ensure the mask shape is manufacturable define a set of context-dependent geometric constraints (e.g., minimum edge-to-edge interior and exterior, corner-to-corner, polygonal regions, etc.).

[0028] Figure 1A illustrates multi-edge dependency for mask edges according to the prior art. Manufacturing mask rule 101 defines the minimum edge spacing distance between the outer edges of adjacent mask shapes. Arrows indicate suggested edge variations generated by OPC. Note that the application of suggested edge variations may result in violations of one or more manufacturing mask rules. Manufacturing mask rule 102 defines the minimum corner spacing distance between the outer corners of adjacent mask shapes. Manufacturing mask rule 103 defines a minimum indentation length for a mask shape. Manufacturing mask rule 104 defines the minimum edge spacing distance between the outer edges of adjacent mask shapes. Manufacturing mask rule 105 defines the minimum corner spacing distance between the outer corners of adjacent mask shapes. Manufacturing mask rules 106 and 107 each define a minimum micro-motion length for the mask shape. One or more suggested edge variations may result in at least one new violation, an increase in the violation value, and / or a decrease in the violation value.

[0029] Manufacturing mask rules 109 and 110 each define the minimum edge-to-edge spacing distance between adjacent mask shapes. Manufacturing mask rule 111 defines the minimum corner-to-corner spacing distance between adjacent mask shapes. Manufacturing mask rules 108 and 112 each define the minimum edge-to-edge distance within a mask shape. Manufacturing mask rules 113 and 114 each define the minimum micro-motion length of a mask shape. Manufacturing mask rule 115 defines the minimum corner-to-corner spacing distance within a mask shape. Manufacturing mask rule 116 defines the minimum length of the notch in a mask shape.

[0030] When performing conventional MRC, the list of edges defining the mask shape is traversed, and each edge that violates a rule is adjusted to remove or reduce the violation. However, removing one violation may introduce a new one. The edge list is traversed in the same order until a violation is removed. Because the edges are traversed in the same order each time, and each adjustment is determined independently to remove a specific violation, conventional MRC techniques often introduce mask edge traversal bias. For example, applying the proposed change 117 to the first edge results in a new violation of manufacturing mask rule 110. To remove the new violation and avoid violating manufacturing mask rule 116, the second edge 119 and the third edge 118 may each be adjusted to the left. Adjusting the second edge 119 and the third edge 118 asymmetrically changes the width of the mask shape defined by the second edge 119 and the third edge 118. Ideally, each correction should be as symmetrical as possible, meaning that equal adjustments should be made in opposite directions. For example, the second edge 119 and the third edge 118 should both be moved by an equal amount to increase or decrease the width of the mask shape (polygon) symmetrically defined by the second edge 119 and the third edge 118.

[0031] Figure 1BA flowchart of a computational lithography method 120 suitable for implementing some embodiments of the present disclosure is shown. Each block of the method 120 described herein includes a computational process that can be performed using any combination of hardware, firmware, and / or software. For example, various functions can be implemented by a processor executing instructions stored in memory. The method can also be embodied as computer-usable instructions stored on a computer storage medium. The method can be provided by a standalone application, service, or managed service (standalone or in combination with other managed services), or a plug-in to another product, to name just a few. However, this method can be additionally or alternatively performed by any system or any combination of systems, including (but not limited to) the systems described herein. Furthermore, those skilled in the art will understand that any system performing method 120 is within the scope and spirit of the embodiments of the present disclosure.

[0032] In step 125, the mask shape of the integrated circuit design layers is divided into multiple tiles. Note that a large design is subdivided into multiple tiles, and one or more tiles can be processed in parallel or serially. Note that the mask shape can be linear, as shown in Figure 1A. In embodiments, the mask shape is not limited to a linear shape and can include polygons with 45° edges, edges with arbitrary angles, and / or curved edges.

[0033] In step 130, an image on the wafer is calculated for each patch. In this embodiment, images are calculated for multiple manufacturing process points. In step 135, photoresist and etching profiles are calculated, estimating the photoresist and etching profiles to be manufactured using a mask corresponding to the image for each patch. In step 140, OPC error is calculated for each patch. The OPC error calculation is based on specified lithography targets and tolerances.

[0034] In step 145, it is determined whether the OPC error of each tile is within a predetermined tolerance. When the OPC error of each tile is within the predetermined tolerance, in step 165, the results of the tiles are combined to provide the mask shape of the layer. Otherwise, tiles with OPC errors that are not within the predetermined tolerance proceed to step 150.

[0035] In step 150, OPC errors are corrected based on the proposed mask shape variation. In step 155, the OPC-corrected mask shape for each tile with OPC errors is processed by parallel MRC, which adjusts the mask shape of each tile to remove or reduce mask manufacturability violations. MRC is performed in parallel on multiple edges, thereby sharing information among different edges to promote symmetry. In an embodiment, all edges are adjusted in parallel to reduce mask edge traversal bias. In an embodiment, the list of edges defining the mask shape is reorganized into a tree structure before identifying MRC violations. The tree structure provides an efficient structure for determining which other edges in the mask shape have dependent violations. Details of step 155 are combined. Figure 1C The process is described below. The adjusted mask shape for each tile with OPC error is provided to step 130 to repeat the process until the OPC error of all tiles is within a predetermined tolerance.

[0036] Further illustrative information regarding the various optional architectures and features that the aforementioned framework can utilize, depending on the user's expectations. It should be strongly noted that the following information is presented for illustrative purposes and should not be construed as limiting in any way. Any of the following features may be optionally combined with, or not exclude, other features described.

[0037] Enforcing manufacturability rules related to mask edge length is challenging due to periodic conflicts arising from dynamic changes in mask shape, the order in which connected edges are stored in the input polygon dataset of the integrated circuit design versus the tree node dependency order in which edges are stored for processing, and the periodic dependency between mask edge length and the movement of mask edges in dynamically changing neighborhoods. Compared to conventional OPC and MRC techniques, the parallel MRC method ensures no inherent bias in MRC enforcement due to the sequence of mask edges traversed within the OPC stream.

[0038] Figure 1C Some embodiments suitable for implementing this disclosure are shown. Figure 1BThe flowchart for step 155 is shown. In step 156, a search tree is constructed using the (OPC-corrected) mask shape for all tiles. In an embodiment, the tree structure enables parallel search, and the tree can be constructed as a quadtree, KD-tree, R-tree, boundary volume hierarchy, etc. In an embodiment, each edge, point, and polygon defining the mask shape is associated with a leaf node of the tree. This tree is an efficient data structure for storing and querying mask shape attributes. In an embodiment, mask shape attributes include state data for each edge, including but not limited to MRC violation type and size, the maximum possible adjustment without introducing new MRC violations or worsening existing MRC violations, and the ideal adjustment for removing MRC violations and correcting OPC errors.

[0039] In this embodiment, the indexing scheme that preserves the input order of mask edges in the polygon dataset (required for connecting adjacent edge information to enforce edge length dependency rules) maintains a separate list for edge position dependency sorting. This separate list can be updated in-situ within the tree indexing algorithm to prevent any redundant copies of the input polygon dataset. The tree traversal scheme associated with the indexing framework employs a tree traversal routine that uses edge position dependency sorting to locate nearest neighbors and the associated attribute and state information.

[0040] In step 158, an MRC value is measured for each edge within a tile. In an embodiment, each tile is assigned to a processing core and each edge is assigned an execution thread for parallel MRC processing by the processing core. The measured MRC value may indicate that an edge is not associated with an MRC violation or that an edge is associated with one or more MRC violations. In an embodiment, the measured MRC values ​​are stored in a tree as edge state information. In an embodiment, the region of the mask shape is measured and stored as state information. In an embodiment, the region is measured using a Gaussian method or Green's theorem, which can be parallelized by the number of polygons and / or edges. In an embodiment, using a GPU processor and a tree structure to compute region measurements in parallel for the design is 968 times faster than computing region measurements using a conventional CPU processor.

[0041] In one embodiment, MRC values ​​are measured in parallel for one or more edges by traversing the tree to locate neighboring elements for each input edge, checking the edge properties (parallelism and overlap) of each edge with its adjacent edges, and calculating the signed distance between edges (positive for outer edges and negative for inner edge-to-edge interactions). In this embodiment, parallel edge-to-edge and corner-to-corner measurement computations performed in parallel using a GPU processor and tree structure are up to 120 times faster than similar computations performed using a CPU processor. Corner-to-corner measurements require checking that the four edges forming two corners do not overlap and are in opposite quadrants. Therefore, edge connections (the next or previous edge forming the corner) need to be known to perform the measurement. Parallel corner-to-corner (inner and outer) measurement computations can be specifically optimized to minimize the use of unquantized memory accesses and large amounts of floating-point operations, and to eliminate redundant edge-to-point measurements.

[0042] In step 160, edge state information is calculated for each edge. In an embodiment, edge state information is calculated in parallel for one or more edges within one or more tiles. In an embodiment, edges within a tile are included in a set of edges. MRC values ​​can be used to identify MRC mask rule violations within a mask shape or between different mask shapes. In an embodiment, a predetermined threshold number of violations or violation values ​​are applied to determine whether a particular edge or tile has a violation. In an embodiment, edge state information includes MRC compliance adjustments to remove or reduce MRC violations at edges. In one embodiment, adjustments to one or more edges may correspond to a move without edges. In an embodiment, a range of flexibility can be calculated and stored as edge state information for each MRC violation, enabling adjustments to remove or reduce MRC violations at one or more edges.

[0043] In step 162, tiles without MRC violations can proceed to step 130. Tiles with at least one MRC violation proceed to step 164. In step 164, the edge state information calculated in step 160 is shared with adjacent edges. Sharing the state information enables collaboration between adjacent edges when adjusting each edge. Sharing the state information also enables the prediction of interactions between edges that may introduce new violations. In this embodiment, adjustments are calculated in parallel for at least a portion of the 'edges' in the tile to reduce or eliminate MRC violations.

[0044] In step 166, one or more edges within one or more tiles are adjusted in parallel based on shared edge state information and constraints. In an embodiment, the edges are adjusted to correct MRC violations, while also considering mask manufacturability rules between the edge and at least one other edge. The edge and at least one other edge may define a single polygon or may define different polygons or non-Manhattan shapes. In addition to removing and reducing MRC violations, constraints affecting the adjustment may include, but are not limited to, minimizing or limiting changes in the mask shape geometry between the adjusted mask shape and the proposed mask shape, minimizing or limiting the difference between the adjusted mask shape and the initial mask shape, and maintaining mask shape symmetry for a symmetrical initial mask shape.

[0045] Parallel MRC 155 can be performed in multiple passes, where each pass performs a measurement for each mask edge of a neighboring element with a mask edge, and computes a conservative MRC-compatible adjustment across different rules. Sharing state information between adjacent mask edges during each pass allows for the extraction of edge flexibility by considering the state information of multiple mask edges that contribute to MRC violations and / or multiple MRC violations associated with mask edges. After one or more passes through parallel MRC 155, convergence is adjusted to remove MRC violations.

[0046] Furthermore, the parallel MRC algorithm can improve OPC convergence by utilizing the geometric flexibility offered by transitions between corner-to-corner and edge-to-edge mask shapes, and vice versa. In an embodiment, sub-passes (within each pass of parallel MRC 155) are used to identify mask shapes that may transition between edge-to-edge (E2E) and corner-to-corner (C2C) configurations when mask edges are adjusted. Additional sub-passes may perform horizontal and vertical scans to resolve conflicts arising from the simultaneous movement of mask edges involved in such transitions and interactions between different categories or types of manufacturing rules, such as intra- and / or inter-polygon E2E, C2C, and notch rules. Parallel MRC can also preemptively predict interactions between mask shapes that were not initially edge-to-edge or corner-to-corner but may potentially become MRC violations due to large edge adjustments in intermediate passes. Potential MRC violations can be stored as state information and considered during edge adjustments to ensure MRC consistency for large adjustments.

[0047] In another embodiment, adjusting the mask edges to produce the final MRC-clean mask shape expresses MRC compliance as a Boolean satisfiability (SAT) problem, wherein each manufacturability constraint involving several relevant mask edges is cast as a Boolean clause that needs to be solved in conjunction with other constraints.

[0048] Figure 2A illustrates example initial mask shapes 201, 202, 203, 204, and 205 according to the prior art, and proposed mask shape variations (dashed shapes). The proposed mask shape for initial mask shape 202 is consistent with initial mask shape 202. The proposed mask shape variations are generated by OPC and may introduce one or more MRC violations.

[0049] Figure 2B illustrates manufacturing rules 200, 206, 207, 208, 209, and 210 according to the prior art, as well as potential violations. MRC value 206 can identify external corner-to-corner violations. Manufacturing rules 207, 208, 209, and 210 can each identify external edge-to-edge violations. Manufacturing rule 200 can identify internal edge-to-edge violations. As shown in Figure 2B, the measured MRC value between the suggested mask shapes for initial mask shapes 202 and 203 is greater than that of external edge-to-edge manufacturing rule 208. The measured MRC value of the suggested mask shape for initial mask shape 204 is less than that of internal edge-to-edge manufacturing rule 200.

[0050] Figure 2C Adjusted mask shapes 211, 213, 214, and 215, adjusted using a parallel MRC stream according to an embodiment, are shown. In this embodiment, the parallel MRC stream adjusts the proposed mask shape to produce adjusted mask shapes 211, 213, 214, and 215. The adjusted mask shape of the initial mask shape 202 is consistent with the initial mask shape 202. Note that the adjusted mask shapes 211, 213, 214, and 215 (thick dashed shape) differ from the proposed mask shape (thin dashed shape). The adjusted mask shape 214 is defined by symmetrically adjusting the relative horizontal edges of the proposed mask shape relative to the initial mask shape 204. The adjusted mask shape 213 has a geometric region larger than that of the initial mask shape 203 and close to the geometric region of the proposed mask shape relative to the initial mask shape 203. Furthermore, the adjusted mask shapes 213 and 215 are defined by symmetrically adjusting the vertical edges of the mask shapes suggested for the initial mask shapes 203 and 205 to symmetrically increase the spacing between the adjusted mask shapes 213 and 215. Similarly, the adjusted mask shapes 211 and 213 are defined by symmetrically adjusting the vertical edges of the mask shapes suggested for the initial mask shapes 201 and 203 to symmetrically increase the spacing between the adjusted mask shapes 211 and 213.

[0051] Figure 2DThe manufacturing rules 200, 206, 207, 208, 209, and 210 according to embodiments, and the mask shapes 211, 213, 214, and 215 adjusted for parallel MRC flow, are shown. The adjusted mask shapes 211, 213, 214, and 215 are the result of completing at least one pass of the parallel MRC flow. The adjusted mask shapes 211, 213, 214, and 215 do not violate any of the manufacturing rules 200, 206, 207, 208, 209, and 210, and are therefore MRC-cleaning mask shapes.

[0052] Figure 2E The initial mask shapes 201, 202, 203, 204, and 205 according to embodiments are shown, along with proposed mask shape variations and mask shapes 221, 222, 223, 224, and 225 adjusted by parallel MRC flow. Mask shapes 221, 222, 223, 224, and 225 correspond to the initial mask shapes 201, 202, 203, 204, and 205.

[0053] Figure 2F illustrates mask shapes 231, 232, 233, 234, and 235 modified using conventional MRC flow according to prior art. While mask shapes 231, 232, 233, 234, and 235 are also MRC cleaned, they are not modified in a manner that maintains geometric symmetry compared to the initial mask shapes 201, 203, 204, and 205, respectively. Specifically, the vertical edge of mask shape 233 moves toward the opposite vertical edge of mask shape 235, which remains stationary compared to the vertical edge of the initial mask shape 205. Similarly, the vertical edge of mask shape 233 moves away from the opposite vertical edge of mask shape 231, such that the two opposite edges of the two different mask shapes move in the same direction but asymmetrically. In both cases, the distance between the two vertical edges is modified asymmetrically. The horizontal edge of mask shape 234 is defined to move in the same direction, thus modifying the initial shape 204 asymmetrically.

[0054] When performing conventional MRC, the list of edges defining the mask shape is traversed, and each edge that violates a rule is sequentially adjusted to remove or reduce the violation. The edge list is traversed in the same order until the violation is removed. Because the edges are traversed in the same order each time, and each adjustment fails to account for moving multiple edges simultaneously, conventional MRC techniques often introduce mask edge traversal bias and fail to maintain geometric symmetry. For example, moving the first edge away from the second edge to correct a violation can increase the width of a polygon or the asymmetrical spacing between two polygons. Ideally, each correction should be as symmetrical as possible.

[0055] Parallel MRC streams adjust multiple edges in parallel, thereby sharing information among different edges to encourage symmetry. In one embodiment, all edges are adjusted in parallel to reduce mask edge traversal bias. In another embodiment, the list of edges defining the mask shape is reorganized into a tree structure before identifying MRC violations. The tree structure provides an efficient structure for determining which other edges in the mask shape have dependent violations. In yet another embodiment, adjustments minimize the variation in the geometry of the proposed mask shape.

[0056] Parallel processing architecture

[0057] Figure 3 A parallel processing unit (PPU) 300 according to one embodiment is shown. The PPU 300 can be used to implement... Figure 1B The computational lithography method 120 and / or shown Figure 1C One or more steps of the parallel MRC 155 shown. In one embodiment, a processor such as a PPU 300 can be configured to implement a neural network model. The neural network model can be implemented as software instructions executed by the processor, or in other embodiments, the processor can include a matrix of hardware elements configured to process a set of inputs (e.g., electrical signals representing values) to generate a set of outputs that can represent activations of the neural network model. In other embodiments, the neural network model can be implemented as a combination of processing and software instructions executed by the hardware element matrix. Implementing a neural network model can include determining a set of parameters for the neural network model through, for example, supervised or unsupervised training of the neural network model, and, alternatively, performing inference using that parameter set to process new sets of inputs.

[0058] In one embodiment, PPU 300 is a multi-threaded processor implemented on one or more integrated circuit devices. PPU 300 is a latency-hidden architecture designed to process many threads in parallel. A thread (e.g., an execution thread) is an instantiation of an instruction set configured to be executed by PPU 300. In one embodiment, PPU 300 is a graphics processing unit (GPU) configured to implement a graphics rendering pipeline for processing three-dimensional (3D) graphics data to generate two-dimensional (2D) image data for display on a display device such as a liquid crystal display (LCD). In other embodiments, PPU 300 may be used to perform general-purpose computing. While an exemplary parallel processor is provided herein for illustrative purposes, it should be specifically noted that such a processor is illustrated for illustrative purposes only, and any processor may be employed to complement and / or replace this processor.

[0059] One or more PPU 300s can be configured to accelerate thousands of high-performance computing (HPC), data center, cloud computing, and machine learning applications. PPU 300s can be configured to accelerate numerous deep learning systems and applications used in autonomous vehicles, simulations, computational graphics such as ray or path tracing, deep learning, high-precision speech, image, and text recognition systems, intelligent video analytics, molecular simulations, drug discovery, disease diagnosis, weather forecasting, big data analytics, astronomy, molecular dynamics simulations, financial modeling, robotics, factory automation, real-time language translation, online search optimization, and personalized user recommendations, among others.

[0060] like Figure 3 As shown, PPU 300 includes an input / output (I / O) unit 305, a front-end unit 315, a scheduler unit 320, a job allocation unit 325, a hub 330, a crossbar (Xbar) 370, one or more general purpose processing clusters (GPCs) 350, and one or more memory partitioning units 380. PPU 300 can be connected to a host processor or other PPU 300 via one or more high-speed NVLink 310 interconnects. PPU 300 can be connected to a host processor or other peripheral devices via interconnect 302. PPU 300 can also be connected to local memory 304, which includes multiple memory devices. In one embodiment, local memory may include multiple dynamic random access memory (DRAM) devices. The DRAM devices may be configured as a high-bandwidth memory (HBM) subsystem, in which multiple DRAM dies are stacked within each device.

[0061] The NVLink 310 interconnect enables the system to expand and include one or more PPUs 300 in conjunction with one or more CPUs, supporting cache coherency between the PPUs 300 and the CPU, as well as CPU master control. Data and / or commands can be sent from or from the NVLink 310 to other units of the PPU 300 via hub 330, such as one or more copy engines, video encoders, video decoders, power management units, etc. (not explicitly shown). Figure 5A A more detailed description of the NVLink 310.

[0062] I / O unit 305 is configured to send and receive communications (e.g., commands, data, etc.) from a host processor (not shown) via interconnect 302. I / O unit 305 may communicate directly with the host processor via interconnect 302, or via one or more intermediate devices such as memory bridges. In one embodiment, I / O unit 305 may communicate with one or more other processors, such as one or more PPUs 300, via interconnect 302. In one embodiment, I / O unit 305 implements a Peripheral Component Interconnect High Speed ​​(PCIe) interface for communication via a PCIe bus, and interconnect 302 is a PCIe bus. In alternative embodiments, I / O unit 305 may implement other types of known interfaces for communication with external devices.

[0063] I / O unit 305 decodes data packets received via interconnect 302. In one embodiment, the data packets represent commands configured to cause PPU 300 to perform various operations. I / O unit 305 transmits the decoded commands to various other units of PPU 300 that these commands may specify. For example, some commands may be transmitted to front-end unit 315. Other commands may be transmitted to hub 330 or other units of PPU 300, such as one or more copy engines, video encoders, video decoders, power management units, etc. (not explicitly shown). In other words, I / O unit 305 is configured to route communication between and among the various logical units of PPU 300.

[0064] In one embodiment, a program executed by the host processor encodes a command stream in a buffer that provides a workload for processing to the PPU 300. The workload may include instructions and data to be processed by those instructions. The buffer is an area of ​​memory accessible (e.g., read / write) by both the host processor and the PPU 300. For example, I / O unit 305 may be configured to access a buffer in system memory connected to interconnect 302 via a memory request transmitted through interconnect 302. In one embodiment, the host processor writes a command stream to the buffer and then transmits a pointer to the start of the command stream back to the PPU 300. Front-end unit 315 receives pointers to one or more command streams. Front-end unit 315 manages the one or more streams, reads commands from these streams, and forwards the commands to the respective units of the PPU 300.

[0065] Front-end unit 315 is coupled to scheduler unit 320, which configures various GPCs 350 to process tasks defined by the one or more streams. Scheduler unit 320 is configured to track status information related to the various tasks managed by scheduler unit 320. Status can indicate which GPC 350 a task is assigned to, whether the task is active or inactive, the priority associated with the task, etc. Scheduler unit 320 manages the execution of multiple tasks on the one or more GPCs 350.

[0066] Scheduler unit 320 is coupled to job allocation unit 325, which is configured to assign tasks for execution on GPC 350. Job allocation unit 325 can track a number of scheduled tasks received from scheduler unit 320. In one embodiment, job allocation unit 325 manages a pending task pool and an active task pool for each GPC 350. The pending task pool may include a number of slots (e.g., 32 slots) containing tasks assigned to a particular GPC 350. The active task pool may include a number of slots for tasks actively processed by the GPC 350. When GPC 350 completes the execution of a task, the task is evicted from the active task pool of GPC 350, and one of the other tasks from the pending task pool is selected and scheduled for execution on GPC 350. If an active task on GPC 350 is idle, for example while waiting for data dependencies to be resolved, then the active task can be evicted from GPC 350 and returned to the task pool, while another task in the task pool is selected and scheduled to be executed on GPC 350.

[0067] The work distribution unit 325 communicates with one or more GPCs 350 via an XBar (crossbar switch) 370. The XBar 370 is an interconnect network that couples many units of the PPU 300 to other units of the PPU 300. For example, the XBar 370 can be configured to couple the work distribution unit 325 to a specific GPC 350. Although not explicitly shown, one or more other units of the PPU 300 can also be connected to the XBar 370 via a hub 330.

[0068] Tasks are managed by scheduler unit 320 and dispatched to GPC 350 by work allocation unit 325. GPC 350 is configured to process tasks and generate results. Results may be consumed by other tasks within GPC 350, routed to different GPCs 350 via XBar 370, or stored in memory 304. Results may be written to memory 304 via memory partitioning unit 380, which implements a memory interface for reading data from and writing data to memory 304. Results may be transferred to another PPU 300 or CPU via NVLink 310. In one embodiment, PPU 300 includes U number of memory partitioning units 380, which is equal to the number of independent and distinct memory devices coupled to memory 304 of PPU 300. The following will be combined with... Figure 4B The memory partition unit 380 is described in more detail.

[0069] In one embodiment, the host processor executes a driver kernel that implements an application programming interface (API), enabling the execution of one or more applications on the host processor to schedule operations for execution on the PPU 300. In one embodiment, multiple computing applications are executed concurrently by the PPU 300, and the PPU 300 provides isolation, Quality of Service (QoS), and independent address spaces for the multiple computing applications. Applications can generate instructions (e.g., API calls) that cause the driver kernel to generate one or more tasks for execution by the PPU 300. The driver kernel outputs the tasks to one or more streams being processed by the PPU 300. Each task may include one or more associated thread groups, referred to herein as a warp. In one embodiment, a warp includes 32 associated threads that can execute in parallel. Cooperative threads can refer to multiple threads that include instructions for executing tasks and can exchange data via shared memory. Figure 4C A more detailed description of threads and cooperative threads.

[0070] Figure 4A An embodiment is shown. Figure 3 The PPU 300 and GPC 350. For example... Figure 4A As shown, each GPC 350 includes multiple hardware units for processing tasks. In one embodiment, each GPC 350 includes a pipeline manager 410, a pre-raster operation unit (PROP) 415, a raster engine 425, a work assignment crossbar switch (WDX) 480, a memory management unit (MMU) 490, and one or more data processing clusters (DPCs) 420. It should be understood that... Figure 4A The GPC 350 may include replacements Figure 4A Other hardware units of the unit shown or excluding Figure 4A Other hardware units besides the unit shown.

[0071] In one embodiment, the operation of GPC 350 is controlled by pipeline manager 410. Pipeline manager 410 manages the configuration of one or more DPCs 420 for processing tasks assigned to GPC 350. In one embodiment, pipeline manager 410 may configure at least one of the one or more DPCs 420 to implement at least a portion of the graphics rendering pipeline. For example, DPC 420 may be configured to execute vertex shader procedures on programmable streaming multiprocessor (SM) 440. Pipeline manager 410 may also be configured to route packets received from job allocation unit 325 to appropriate logic units within GPC 350. For example, some packets may be routed to fixed-function hardware units in PROP 415 and / or raster engine 425, while other packets may be routed to DPCs 420 for processing by primitive engine 435 or SM 440. In one embodiment, pipeline manager 410 may configure at least one of the one or more DPCs 420 to implement neural network models and / or computation pipelines.

[0072] PROP unit 415 is configured to route data generated by raster engine 425 and DPC 420 to raster operation (ROP) unit, in conjunction with Figure 4B For a more detailed description, PROP unit 415 can also be configured to perform color blending optimization, organize pixel data, perform address translation, etc.

[0073] Raster engine 425 includes several fixed-function hardware units configured to perform various raster operations. In one embodiment, raster engine 425 includes a setup engine, a coarse raster engine, a culling engine, a clipping engine, a fine raster engine, and a tile aggregation engine. The setup engine receives transformed vertices and generates plane equations associated with the geometric primitives defined by the vertices. The plane equations are sent to the coarse raster engine to generate coverage information for primitives (e.g., x, y coverage masks for tiles). The output of the coarse raster engine is sent to the culling engine, where fragments associated with primitives that fail the z-test are culled, and to the clipping engine, where fragments located outside the view frustum are clipped. Those fragments remaining after clipping and culling can be passed to the fine raster engine to generate properties of pixel fragments based on the plane equations generated by the setup engine. The output of raster engine 425 includes fragments, for example, to be processed by a fragment shader implemented within DPC 420.

[0074] Each DPC 420 included in GPC 350 includes an M-pipeline controller (MPC) 430, a primitive engine 435, and one or more SMs 440. The MPC 430 controls the operation of the DPC 420, routing packets received from the pipeline manager 410 to the appropriate units within the DPC 420. For example, packets associated with vertices can be routed to the primitive engine 435, which is configured to retrieve vertex attributes associated with vertices from memory 304. Conversely, packets associated with shaders can be sent to the SMs 440.

[0075] The SM 440 includes a programmable streaming processor configured to process tasks represented by multiple threads. Each SM440 is multithreaded and configured to execute multiple threads (e.g., 32 threads) from a specific thread group concurrently. In one embodiment, the SM 440 implements a SIMD (Single Instruction, Multiple Data) architecture, where each thread in a thread group (e.g., a warp) is configured to process a different dataset based on the same instruction set. All threads in the thread group execute the same instructions. In another embodiment, the SM 440 implements a SIMT (Single Instruction, Multiple Threads) architecture, where each thread in a thread group is configured to process a different dataset based on the same instruction set, but where individual threads in the thread group are allowed to diverge during execution. In one embodiment, a program counter, call stack, and execution state are maintained for each thread bundle, enabling concurrency between the thread bundle and serial execution within the thread bundle when threads within the thread bundle diverge. In another embodiment, a program counter, call stack, and execution state are maintained for each individual thread, thereby achieving equal concurrency among all threads within and between thread bundles. When maintaining the execution state for each individual thread, threads executing the same instructions can converge and execute in parallel to achieve maximum efficiency. The following section combines... Figure 4C A more detailed description of the SM440.

[0076] MMU 490 provides an interface between GPC 350 and memory partitioning unit 380. MMU 490 can provide virtual address to physical address translation, memory protection, and arbitration of memory requests. In one embodiment, MMU 490 provides one or more translation back buffers (TLBs) for performing translations from virtual addresses to physical addresses in memory 304.

[0077] Figure 4B An embodiment is shown. Figure 3 The PPU 300's memory partition unit 380. For example... Figure 4BAs shown, the memory partition unit 380 includes a raster operation (ROP) unit 450, a secondary (L2) cache 460, and a memory interface 470. The memory interface 470 is coupled to the memory 304. The memory interface 470 can implement 32, 64, 128, or 1024-bit data buses for high-speed data transfer. In one embodiment, the PPU 300 incorporates U memory interfaces 470, one memory interface 470 per pair of memory partition units 380, wherein each pair of memory partition units 380 is connected to a corresponding memory device of the memory 304. For example, the PPU 300 can be connected to up to Y memory devices, such as high-bandwidth memory stacks or synchronous dynamic random access memory of Graphics Dual Data Rate Version 5, or other types of persistent memory.

[0078] In one embodiment, memory interface 470 implements the HBM2 memory interface, and Y is equal to half of U. In one embodiment, the HBM2 memory stack is located on the same physical package as PPU 300, providing significant power savings and area savings compared to conventional GDDR5 SDRAM systems. In one embodiment, each HBM2 stack includes four memory dies and Y is equal to 4, wherein each HBM2 stack includes two 128-bit channels per die, for a total of eight channels and a 1024-bit data bus width.

[0079] In one embodiment, memory 304 supports Single Error Corrected Double Error Detection (SECDED) error correction code (ECC) to protect data. ECC provides enhanced reliability for computational applications sensitive to data corruption. Reliability is particularly critical in large-scale cluster computing environments where the PPU 300 handles very large datasets and / or long-running applications.

[0080] In one embodiment, PPU 300 implements a multi-level memory hierarchy. In one embodiment, memory partitioning unit 380 supports unified memory to provide a single unified virtual address space for the CPU and PPU 300 memory, enabling data sharing between virtual memory systems. In one embodiment, the frequency of PPU 300 accesses to memory located on other processors is tracked to ensure that memory pages are moved to the physical memory of the PPU 300 that accesses the page more frequently. In one embodiment, NVLink 310 supports an address translation service that allows PPU 300 direct access to the CPU's page tables and provides full access to the CPU's memory by the PPU 300.

[0081] In one embodiment, the replication engine transfers data between multiple PPUs 300 or between a PPU 300 and a CPU. The replication engine can generate page faults for addresses not mapped to page tables. The memory partitioning unit 380 can then service the page faults, mapping the addresses to page tables, after which the replication engine can perform the transfer. In conventional systems, multiple replication engines operating on fixed memory (e.g., non-pageable) across multiple processors significantly reduce available memory. Due to hardware page faults, addresses can be passed to the replication engine without concern for whether memory pages reside, and the replication process is transparent.

[0082] Data from memory 304 or other system memory can be retrieved by memory partitioning unit 380 and stored in L2 cache 460, which is located on-chip and shared among the various GPCs 350. As shown, each memory partitioning unit 380 includes a portion of the L2 cache 460 associated with the corresponding memory 304. Lower-level caches can then be implemented in multiple cells within the GPC 350. For example, each SM 440 can implement a Level 1 (L1) cache. The L1 cache is a dedicated memory for a specific SM 440. Data from L2 cache 460 can be fetched and stored in each L1 cache for processing within the functional units of the SM 440. L2 cache 460 is coupled to memory interface 470 and XBar 370.

[0083] ROP unit 450 performs graphic raster operations related to pixel color, such as color compression and pixel blending. ROP unit 450 also performs depth testing in conjunction with raster engine 425, receiving the depth of sample locations associated with pixel fragments from the culling engine of raster engine 425. The depth of the sample location associated with the fragment is tested relative to the corresponding depth in the depth buffer. If the fragment passes the depth test for the sample location, ROP unit 450 updates the depth buffer and sends the result of the depth test to raster engine 425. It will be understood that the number of memory partition units 380 may differ from the number of GPCs 350, and therefore each ROP unit 450 may be coupled to each GPC 350. ROP unit 450 tracks data packets received from different GPCs 350 and determines which GPC 350 the result generated by ROP unit 450 is routed to via Xbar 370. Although in Figure 4B ROP unit 450 is included within memory partition unit 380, but in other embodiments, ROP unit 450 may be located outside memory partition unit 380. For example, ROP unit 450 may reside in GPC 350 or another unit.

[0084] Figure 4C An embodiment is shown. Figure 4A The streaming multiprocessor 440. For example... Figure 4C As shown, the SM 440 includes an instruction cache 405, one or more (K) scheduler units 445, a register file 455, one or more processing cores 442, one or more special function units (SFUs) 452, one or more load / store units (LSUs) 454, an interconnect network 458, and a shared memory / L1 cache 465.

[0085] As described above, the work allocation unit 325 schedules tasks to execute on the GPC 350 of the PPU 300. Tasks are assigned to a specific DPC 420 within the GPC 350, and if the task is associated with a shader program, it can be assigned to an SM 440. The scheduler unit 445 receives tasks from the work allocation unit 325 and manages the instruction scheduling of one or more thread blocks assigned to the SM 440. The scheduler unit 445 schedules the thread blocks to execute as thread bundles of parallel threads, where each thread block is assigned at least one thread bundle. In one embodiment, each thread bundle executes 32 threads. The scheduler unit 445 can manage multiple different thread blocks, assign thread bundles to different thread blocks, and then dispatch instructions from multiple different cooperative groups to various functional units (i.e., core 442, SFU 452, and LSU 454) during each clock cycle.

[0086] Collaboration groups are a programming model for organizing groups of communicating threads. They allow developers to express the granularity at which threads are communicating, enabling richer and more efficient parallel decompositions. The Collaboration Startup API supports synchronization between blocks of threads to execute parallel algorithms. Conventional programming models provide a single, simple structure for synchronizing collaborative threads: a barrier across all threads in a block (e.g., the `syncthreads()` function). However, programmers often want to define thread groups at a granularity smaller than that of thread blocks and synchronize within those groups, enabling higher performance, design flexibility, and software reuse through a collective group-wide function interface.

[0087] Collaboration groups enable programmers to explicitly define thread groups at both the sub-block (e.g., as small as a single thread) and multi-block granularity levels and perform collective operations, such as synchronization on threads within a collaboration group. The programming model supports clean composition across software boundaries, allowing libraries and utility functions to be safely synchronized in their local environments without making assumptions about convergence. Collaboration group primitives enable new modes of cooperative parallelism, including producer-consumer parallelism, opportunistic parallelism, and global synchronization across the entire mesh of thread blocks.

[0088] Dispatch unit 448 is configured to send instructions to one or more functional units. In this embodiment, scheduler unit 445 includes two dispatch units 448, which enables the scheduling of two different instructions from the same thread bundle during each clock cycle. In an alternative embodiment, each scheduler unit 445 may include a single dispatch unit 448 or additional dispatch units 448.

[0089] Each SM 440 includes a register file 455, which provides a set of registers for functional units of the SM 440. In one embodiment, the register file 455 is partitioned between each functional unit such that each functional unit is allocated a dedicated portion of the register file 455. In another embodiment, the register file 455 is partitioned between different thread bundles executed by the SM 440. The register file 455 provides temporary memory for operands in the data paths connected to the functional units.

[0090] Each SM 440 includes L processing cores 442. In one embodiment, the SM 440 includes a large number (e.g., 128) of different processing cores 442. Each core 442 may include fully pipelined, single-precision, double-precision, and / or mixed-precision processing units, including floating-point arithmetic logic units and integer arithmetic logic units. In one embodiment, the floating-point arithmetic logic units implement the IEEE 754-2008 standard for floating-point arithmetic. In one embodiment, core 442 includes 64 single-precision (32-bit) floating-point cores, 64 integer cores, 32 double-precision (64-bit) floating-point cores, and 8 tensor cores.

[0091] Tensor cores are configured to perform matrix operations, and in one embodiment, one or more tensor cores are included in core 442. Specifically, tensor cores are configured to perform deep learning matrix operations, such as convolution operations used for neural network training and inference. In one embodiment, each tensor core operates on a 4×4 matrix and performs matrix multiplication and accumulation operations D = A×B + C, where A, B, C, and D are 4×4 matrices.

[0092] In one embodiment, matrix multiplication inputs A and B are 16-bit floating-point matrices, while accumulation matrices C and D can be either 16-bit or 32-bit floating-point matrices. The Tensor Core performs operations on the 16-bit floating-point input data and the 32-bit floating-point accumulation. The 16-bit floating-point multiplication requires 64 operations to produce a full-precision product, which is then accumulated by adding the 32-bit floating-point products to other intermediate products of the 4×4×4 matrix multiplication. In practice, the Tensor Core is used to perform operations on larger two-dimensional or higher-dimensional matrices built from these smaller elements. APIs (such as the CUDA 9 C++ API) expose specialized matrix loading, matrix multiplication and accumulation, and matrix storage operations to efficiently utilize the Tensor Core from CUDA-C++ programs. At the CUDA level, the thread bundle-level interface assumes that a 16×16-size matrix spans all 32 threads of the thread bundle.

[0093] Each SM 440 also includes M SFUs 452 that perform special functions (e.g., attribute evaluation, inverse square root, etc.). In one embodiment, an SFU 452 may include a tree traversal unit configured to traverse a hierarchical tree data structure. In one embodiment, an SFU 452 may include a texture unit configured to perform texture map filtering operations. In one embodiment, a texture unit is configured to load a texture map (e.g., a 2D array of texture pixels) from memory 304 and sample the texture map to produce sampled texture values ​​for use in a shader program executed by the SM 440. In one embodiment, the texture map is stored in shared memory / L1 cache 465. Texture units implement texture operations, such as filtering operations using mip maps (i.e., texture maps at different levels of detail). In one embodiment, each SM 440 includes two texture units.

[0094] Each SM 440 also includes N LSUs 454, which implement load and store operations between the shared memory / L1 cache 465 and the register file 455. Each SM 440 includes an interconnect network 458 connecting each functional unit to the register file 455 and the shared memory / L1 cache 465. In one embodiment, the interconnect network 458 is a crossbar switch that can be configured to connect any functional unit to any register in the register file 455 and a memory location in the shared memory / L1 cache 465.

[0095] Shared memory / L1 cache 465 is an on-chip memory array that allows data storage and communication between SM 440 and primitive engine 435, as well as between threads within SM 440. In one embodiment, shared memory / L1 cache 465 includes 128KB of storage capacity and is located on the path from SM 440 to memory partition unit 380. Shared memory / L1 cache 465 can be used for cache reads and writes. One or more of shared memory / L1 cache 465, L2 cache 460, and memory 304 are backup storage.

[0096] Combining data caching and shared memory functionality into a single memory block provides optimal overall performance for both types of memory access. This capacity can be used by the program as a cache that does not utilize shared memory. For example, if shared memory is configured to use half its capacity, texture and load / store operations can use the remaining capacity. The integration within the shared memory / L1 cache 465 enables it to function as a high-throughput pipeline for streaming data, while simultaneously providing high-bandwidth and low-latency access to frequently reused data.

[0097] When configured for general-purpose parallel computing, a simpler configuration can be used compared to graphics processing. Specifically, Figure 3 The fixed-function graphics processing unit shown is bypassed, creating a simpler programming model. In the general-purpose parallel computing configuration, the work allocation unit 325 directly assigns and distributes thread blocks to the DPC 420. Threads within a block execute the same program, using a unique thread ID in the computation to ensure each thread produces a unique result, using the SM 440 to execute the program and perform the computation, using the shared memory / L1 cache 465 for communication between threads, and using the LSU 454 to read and write global memory via the shared memory / L1 cache 465 and the memory partitioning unit 380. When configured for general-purpose parallel computing, the SM 440 can also write commands to the scheduler unit 320 that can be used to start new jobs on the DPC 420.

[0098] The PPU 300 can be included in desktop computers, laptop computers, tablet computers, servers, supercomputers, smartphones (e.g., wireless, handheld devices), personal digital assistants (PDAs), digital cameras, vehicles, head-mounted displays, handheld electronic devices, etc. In one embodiment, the PPU 300 is contained on a single semiconductor substrate. In another embodiment, the PPU 300 is included on a system-on-a-chip (SoC) along with one or more other devices, such as an additional PPU 300, memory 304, a reduced instruction set computer (RISC) CPU, a memory management unit (MMU), a digital-to-analog converter (DAC), etc.

[0099] In one embodiment, the PPU 300 may be included on a graphics card, which includes one or more memory devices. The graphics card may be configured to interface with a PCIe slot on a desktop computer's motherboard. In yet another embodiment, the PPU 300 may be an integrated graphics processing unit (iGPU) or a parallel processor included in a chipset of the motherboard.

[0100] Exemplary computing system

[0101] Systems with multiple GPUs and CPUs are being used across various industries as developers expose to and leverage greater parallelism in applications such as artificial intelligence computing. High-performance GPU-accelerated systems with tens to thousands of compute nodes are being deployed in data centers, research institutions, and supercomputers to tackle larger problems. As the number of processing devices within high-performance systems increases, communication and data transmission mechanisms need to be scaled to support this increased bandwidth.

[0102] Figure 5A This is based on the use of one embodiment. Figure 3 A conceptual diagram of a processing system 500 implemented by a PPU 300. The exemplary system 500 can be configured to implement... Figure 1B The computational lithography method 120 and / or shown Figure 1C The parallel MRC 155 shown is illustrated. The processing system 500 includes a CPU 530, a switch 510, multiple PPUs 300, and corresponding memory 304.

[0103] Each PPU 300 may include, and / or be configured to perform the functions of one or more processing cores and / or components thereof, such as a tensor core (TC), tensor processing unit (TPU), pixel vision core (PVC), vision processing unit (VPU), graphics processing cluster (GPC), texture processing cluster (TPC), streaming multiprocessor (SM), tree traversal unit (TTU), artificial intelligence accelerator (AIA), deep learning accelerator (DLA), arithmetic logic unit (ALU), application-specific integrated circuit (ASIC), floating-point unit (FPU), input / output (I / O) element, peripheral component interconnect (PCI) or peripheral component interconnect fast (PCIe) element, etc.

[0104] The NVLink 310 provides a high-speed communication link between each PPU 300. Although Figure 5A A specific number of NVLink 310 and interconnect 302 connections are shown, but the number of connections to each PPU 300 and CPU 530 can vary. Switch 510 interfaces between interconnect 302 and CPU 530. PPU 300, memory 304, and NVLink 310 can reside on a single semiconductor platform to form a parallel processing module 525. In one embodiment, switch 510 supports two or more protocols that interface between various different connections and / or links.

[0105] In another embodiment (not shown), NVLink 310 provides one or more high-speed communication links between each PPU 300 and CPU 530, and switch 510 interfaces between interconnect 302 and each PPU 300. PPU 300, memory 304, and interconnect 302 may reside on a single semiconductor platform to form parallel processing module 525. In yet another embodiment (not shown), interconnect 302 provides one or more communication links between each PPU 300 and CPU 530, and switch 510 uses NVLink 310 to interface between each PPU 300 to provide one or more high-speed communication links between PPUs 300. In another embodiment (not shown), NVLink 310 provides one or more high-speed communication links between PPUs 300 and CPU 530 via switch 510. In yet another embodiment (not shown), interconnect 302 directly provides one or more communication links between each PPU 300. One or more NVLink 310 high-speed communication links can be implemented as physical NVLink interconnects or on-chip or die interconnects using the same protocol as NVLink 310.

[0106] In the context of this specification, a single semiconductor platform can refer to a unique, single semiconductor-based integrated circuit fabricated on a bare die or chip. It should be noted that the term single semiconductor platform can also refer to a multi-chip module with increased connectivity, simulating on-chip operation and substantially improved by utilizing conventional bus implementation methods. Of course, various circuits or devices can also be placed separately or in various combinations of semiconductor platforms, depending on the user's needs. Optionally, the parallel processing module 525 can be implemented as a circuit board substrate, and each of the PPU 300 and / or memory 304 can be a packaged device. In one embodiment, the CPU 530, switch 510, and parallel processing module 525 reside on a single semiconductor platform.

[0107] In one embodiment, the signaling rate of each NVLink 310 is 20 to 25 gigabits per second, and each PPU300 includes six NVLink 310 interfaces (e.g., Figure 5A As shown, each PPU 300 includes five NVLink 310 interfaces. Each NVLink 310 provides a data transfer rate of 25 gigabits per second in each direction, with six links providing 300 gigabits per second. When the CPU 530 also includes one or more NVLink 310 interfaces, the NVLink 310 can be specifically used for applications such as... Figure 5A The example shows PPU-to-PPU communication, or a combination of PPU-to-PPU and PPU-to-CPU communication.

[0108] In one embodiment, the NVLink 310 allows direct load / store / atomic access from the CPU 530 to the memory 304 of each PPU 300. In one embodiment, the NVLink 310 supports coherent operation, allowing data read from memory 304 to be stored in the cache hierarchy of the CPU 530, reducing cache access latency of the CPU 530. In one embodiment, the NVLink 310 includes support for Address Translation Service (ATS), allowing the PPU 300 to directly access page tables within the CPU 530. One or more NVLink 310s can also be configured to operate in a low-power mode.

[0109] Figure 5B An exemplary system 565 is illustrated, in which various architectures and / or functions of various prior embodiments can be implemented. The exemplary system 565 can be configured to implement... Figure 1B The computational lithography method 120 and / or shown Figure 1C The parallel MRC 155 shown.

[0110] As shown in the figure, a system 565 is provided, which includes at least one central processing unit 530 connected to a communication bus 575. The communication bus 575 may directly or indirectly couple one or more of the following devices: main memory 540, network interface 535, CPU 530, display device 545, input device 560, switch 510, and parallel processing system 525. The communication bus 575 may be implemented using any suitable protocol and may represent one or more links or buses, such as address bus, data bus, control bus, or combinations thereof. The communication bus 575 may include one or more bus or link types, such as Industry Standard Architecture (ISA) bus, Extended Industry Standard Architecture (EISA) bus, Video Electronics Standards Association (VESA) bus, Peripheral Component Interconnect (PCI) bus, Peripheral Component Interconnect High Speed ​​(PCIe) bus, HyperTransport, and / or another type of bus or link. In some embodiments, direct connections exist between components. As an example, CPU 530 may be directly connected to main memory 540. Furthermore, CPU 530 may be directly connected to parallel processing system 525. In cases where there is a direct or point-to-point connection between components, the communication bus 575 may include a PCIe link that implements the connection. In these examples, the PCI bus need not be included in the system 565.

[0111] Although using lines Figure 5B The different blocks are shown connected via a communication bus 575, but this is not intended to be limiting and is merely for clarity. For example, in some embodiments, a presentation component such as a display device 545 can be considered an I / O component, such as an input device 560 (e.g., if the display is a touchscreen). As another example, the CPU 530 and / or the parallel processing system 525 may include memory (e.g., main memory 540 may represent storage devices other than the parallel processing system 525, the CPU 530, and / or other components). In other words, Figure 5B The term "computing device" is merely illustrative. No distinction is made between categories such as "workstation," "server," "laptop," "desktop," "tablet," "client device," "mobile device," "handheld device," "game console," "electronic control unit (ECU)," "virtual reality system," and / or other device or system types, as all of these are expected to fall under [the relevant category]. Figure 5B Within the scope of computing devices.

[0112] System 565 also includes main memory 540. Control logic (software) and data are stored in main memory 540, which can take the form of a variety of computer-readable media. Computer-readable media can be any available medium that can be accessed by system 565. Computer-readable media can include volatile and non-volatile media, as well as removable and non-removable media. For example and without limitation, computer-readable media can include computer storage media and communication media.

[0113] Computer storage media may include volatile and non-volatile media and / or removable and non-removable media implemented in any method or technology for storing information such as computer-readable instructions, data structures, program modules, and / or other data types. For example, main memory 540 may store computer-readable instructions such as an operating system (e.g., representing programs and / or program elements). Computer storage media may include, but is not limited to, RAM, ROM, EEPROM, flash memory or other memory technologies, CD-ROM, digital versatile disc (DVD) or other optical disc storage devices, magnetic cartridges, magnetic tape, disk storage devices or other magnetic storage devices, or any other medium that may be used to store desired information and can be accessed by system 565. When used herein, computer storage media does not include the signal itself.

[0114] Computer storage media may contain computer-readable instructions, data structures, program modules, or other data types in modulated data signals such as carrier waves or other transmission mechanisms, and may include any information transport medium. The term "modulated data signal" may refer to a signal whose characteristics are set or varied in such a way that information is encoded into that signal. For example and without limitation, computer storage media may include wired media such as wired networks or direct wired connections, and wireless media such as sound, RF, infrared, and other wireless media. Any combination of the above should also be included within the scope of computer-readable media.

[0115] When executed, the computer program enables system 565 to perform various functions. CPU 530 may be configured to execute at least some of the computer-readable instructions to control one or more components of system 565 to perform one or more of the methods and / or processes described herein. Each of CPUs 530 may include one or more cores (e.g., one, two, four, eight, twenty-eight, seventy-two, etc.) capable of processing numerous software threads simultaneously. Depending on the type of system 565 implemented, CPU 530 may include any type of processor and may include different types of processors (e.g., processors with fewer cores for mobile devices and processors with more cores for servers). For example, depending on the type of system 565, the processor may be an advanced RISC machine (ARM) processor implemented using Reduced Instruction Set Computing (RISC) or an x86 processor implemented using Complex Instruction Set Computing (CISC). In addition to one or more microprocessors or supplementary coprocessors such as math coprocessors, system 565 may include one or more CPUs 530.

[0116] In addition to or alternatively to CPU 530, parallel processing module 525 may be configured to execute at least some of the computer-readable instructions to control one or more components of system 565 to perform one or more of the methods and / or processes described herein. Parallel processing module 525 may be used by system 565 to render graphics (e.g., 3D graphics) or perform general-purpose computing. For example, parallel processing module 525 may be used for general-purpose computing on a GPU (GPGPU). In embodiments, CPU 530 and / or parallel processing module 525 may execute any combination of the methods, processes, and / or portions thereof, discretely or jointly.

[0117] System 565 also includes input device 560, parallel processing system 525, and display device 545. Display device 545 may include a display (e.g., a monitor, touchscreen, television screen, head-up display (HUD), other display types, or combinations thereof), speakers, and / or other presentation components. Display device 545 may receive data from other components (e.g., parallel processing system 525, CPU 530, etc.) and output that data (e.g., images, video, sound, etc.).

[0118] Network interface 535 enables system 565 to be logically coupled to other devices, including input device 560, display device 545, and / or other components, some of which may be embedded (e.g., integrated into) system 565. Illustrative input device 560 includes microphone, mouse, keyboard, joystick, gamepad, game controller, satellite dish, scanner, printer, wireless device, etc. Input device 560 can provide a natural user interface (NUI) that processes user-generated air gestures, voice, or other physiological input. In some instances, input can be transmitted to appropriate network elements for further processing. NUI can implement voice recognition, stylus recognition, facial recognition, biometric recognition, on-screen and adjacent-screen gesture recognition, air gestures, head-eye tracking, and touch recognition associated with the display of system 565 (described in more detail below). System 565 may include depth cameras for gesture detection and recognition, such as stereo camera systems, infrared camera systems, RGB camera systems, touchscreen technology, and combinations thereof. In addition, system 565 may include an accelerometer or gyroscope that allows motion detection (e.g., as part of an inertial measurement unit (IMU)). In some examples, the output of the accelerometer or gyroscope may be used by system 565 to render immersive augmented reality or virtual reality.

[0119] Furthermore, system 565 can be coupled to a network (e.g., a telecommunications network, a local area network (LAN), a wireless network, a wide area network (WAN) such as the Internet, a peer-to-peer network, a cable network, etc.) via network interface 535 for communication purposes. System 565 can be included in a distributed network and / or cloud computing environment.

[0120] Network interface 535 may include one or more receivers, transmitters, and / or transceivers, enabling system 565 to communicate with other computing devices via an electronic communication network, including wired and / or wireless communications. Network interface 535 may be implemented as a network interface controller (NIC) including one or more data processing units (DPUs) to perform operations such as (e.g., but not limited to) packet parsing and accelerating network processing and communication. Network interface 535 may include components and functions that allow communication over any of several different networks, such as wireless networks (e.g., Wi-Fi, Z-Wave, Bluetooth, Bluetooth LE, ZigBee, etc.), wired networks (e.g., communication over Ethernet or InfiniBand), low-power wide area networks (e.g., LoRaWAN, SigFox, etc.), and / or the Internet.

[0121] System 565 may also include an auxiliary storage device (not shown). The auxiliary storage device 610 includes, for example, a hard disk drive and / or a removable storage drive representing a floppy disk drive, magnetic tape drive, compact disc drive, digital multifunction disc (DVD) drive, recording device, Universal Serial Bus (USB) flash memory. The removable storage drive reads from and / or writes to the removable storage unit in a well-known manner. System 565 may also include a hard-wired power supply, a battery power supply, or a combination thereof (not shown). This power supply can supply power to System 565 to enable the components of System 565 to operate.

[0122] Each of the aforementioned modules and / or devices may even reside on a single semiconductor platform to form system 565. Alternatively, various different modules may be placed individually or located in various combinations of semiconductor platforms as desired by the user. Although various different embodiments have been described above, it should be understood that they are given by way of example only and without limitation. Therefore, the breadth and scope of preferred embodiments should not be limited to any of the exemplary embodiments described above, but should be defined only by the following claims and their equivalents.

[0123] Example network environment

[0124] A network environment suitable for implementing embodiments of this disclosure may include one or more client devices, servers, network-attached storage devices (NAS), other back-end devices, and / or other device types. Client devices, servers, and / or other device types (e.g., each device) may be... Figure 5A Processing system 500 and / or Figure 5B Implemented on one or more instances of the exemplary system 565, for example, each device may include similar components, features and / or functions of the processing system 500 and / or the exemplary system 565.

[0125] Components of a network environment can communicate with each other via a network, which can be wired, wireless, or a combination of both. A network can include multiple networks or a network of networks. For example, a network can include one or more wide area networks (WANs), one or more local area networks (LANs), one or more public networks—such as the Internet, and / or the Public Switched Telephone Network (PSTN), and / or one or more private networks. In cases where the network includes a wireless telecommunications network, components such as base stations, communication towers, or even access points (along with other components) can provide wireless connectivity.

[0126] A compatible network environment may include one or more peer-to-peer network environments—in which case the server may not be included in the network environment—and one or more client-server network environments—in which case one or more servers may be included in the network environment. In a peer-to-peer network environment, the functionality described herein regarding the server can be implemented on any number of client devices.

[0127] In at least one embodiment, the network environment may include one or more cloud-based network environments, distributed computing environments, combinations thereof, etc. A cloud-based network environment may include a framework layer, a job scheduler, a resource manager, and a distributed file system implemented on one or more servers, which may include one or more core network servers and / or edge servers. The framework layer may include a framework of one or more applications supporting a software layer and / or an application layer. The software or application may include web-based service software or applications, respectively. In embodiments, one or more client devices may use the web-based service software or application (e.g., by accessing the service software and / or application via one or more application programming interfaces (APIs)). The framework layer may be, but is not limited to, a free and open-source software web application framework type that can be used for large-scale data processing (e.g., "big data").

[0128] A cloud-based network environment can provide cloud computing and / or cloud storage to implement the computing and / or data storage functions (or one or more portions thereof) described herein. Any of these different functions can be distributed across multiple locations from a central or core server (e.g., a central or core server in one or more data centers, which may be distributed across states, regions, countries, globally, etc.). If the connection to a user (e.g., a client device) is relatively close to an edge server, then the core server can assign at least a portion of the functions to the edge server. A cloud-based network environment can be private (e.g., limited to a single organization), public (e.g., available to many organizations), and / or a combination thereof (e.g., a hybrid cloud environment).

[0129] Client devices may include Figure 5A Example processing system 500 and / or Figure 5BAt least some of the components, features, and functions of the exemplary system 565. For example and without limitation, the client device may be implemented as a personal computer (PC), laptop computer, mobile device, smartphone, tablet computer, smartwatch, wearable computer, personal digital assistant (PDA), MP3 player, virtual reality headset, global positioning system (GPS) or device, video player, video camera, surveillance equipment or system, vehicle, ship, spacecraft, virtual machine, drone, robot, handheld communication device, hospital equipment, gaming equipment or system, entertainment system, vehicle computer system, embedded system controller, remote control, appliance, consumer electronics device, workstation, edge device, any combination of these defined devices, or any other suitable device.

[0130] Machine Learning

[0131] Deep neural networks (DNNs) developed on processors such as the PPU 300 have been used in a wide variety of use cases, from self-driving cars to faster drug development, from automatic image captioning in online image databases to intelligent real-time language translation in video chat applications. Deep learning is a technique that models the neural learning process of the human brain, which continuously learns, becomes smarter, and delivers more accurate results faster over time. Just as a child is initially taught by adults to correctly identify and classify various shapes, eventually becoming able to identify shapes without any guidance, a deep learning or neural learning system needs to be trained in object recognition and classification so that it becomes smarter and more efficient at identifying basic objects, occluded objects, and so on, while also attaching context to objects.

[0132] At its simplest level, neurons in the human brain receive various inputs, assigning a level of importance to each of these inputs, and the output is passed to other neurons to make a response. Artificial neurons, or perceptrons, are the most basic model of neural networks. In one example, a perceptron can receive one or more inputs representing various features of objects that the perceptron is being trained to recognize and classify, and each of these features is assigned a weight based on its importance in defining the shape of the object.

[0133] Deep neural network (DNN) models consist of multiple layers of numerous connected nodes (e.g., perceptrons, Boltzmann machines, radial basis functions, convolutional layers, etc.) that can be trained on massive amounts of input data to solve complex problems quickly and with high accuracy. In one example, the first layer of a DNN model breaks down an input image of a car into different segments and searches for basic patterns such as lines and angles. The second layer assembles these lines to find higher-level patterns such as wheels, windshields, and mirrors. The next layer identifies the type of vehicle, and the final few layers generate labels for the input image that identify the model of a specific car brand.

[0134] Once trained, a DNN can be deployed and used to identify and classify objects or patterns in a process called inference. Examples of inference (the process by which a DNN extracts useful information from a given input) include identifying handwritten digits on a check deposited into an ATM, identifying images of friends in a photograph, delivering movie recommendations to over 50 million users, identifying and classifying different types of cars, pedestrians, and road hazards in self-driving cars, or translating human language in real time.

[0135] During training, data flows through the DNN in the forward propagation phase until a prediction indicating a label corresponding to the input is produced. If the neural network does not correctly label the input, the error between the correct label and the predicted label is analyzed, and the weights are adjusted for each feature during the backpropagation phase until the DNN correctly labels the input as well as other inputs in the training dataset. Training complex neural networks requires significant parallel computing power, including floating-point multiplication and addition supported by the PPU300. Inference is less computationally intensive than training and is a latency-sensitive process where the trained neural network is applied to new inputs it has not seen before for tasks such as image classification, sentiment detection, label recommendation, language recognition and translation, and typically infers new information.

[0136] Neural networks rely heavily on matrix mathematical operations, and for both efficiency and speed, complex multi-layered networks require massive floating-point performance and bandwidth. Leveraging thousands of processing cores optimized for matrix mathematical operations and delivering tens to hundreds of TFLOPS of performance, the PPU 300 is a computing platform capable of providing the performance required for deep neural network-based artificial intelligence and machine learning applications.

[0137] Figure 5CComponents of an example system 555, which can be used to train and utilize machine learning according to at least one embodiment, are illustrated. As will be discussed, various components can be provided by a single computing system or various combinations of computing devices and resources, which may be under the control of a single entity or multiple entities. Furthermore, aspects may be triggered, initiated, or requested by different entities. In at least one embodiment, the training of the neural network may be guided by a vendor associated with vendor environment 506, while in at least one embodiment, training may be requested by a customer or other user who can access the vendor environment through client device 502 or other such resources. In at least one embodiment, training data (or data to be analyzed by the trained neural network) may be provided by a vendor, user, or third-party content provider 524. In at least one embodiment, client device 502 may be, for example, a vehicle or object to be navigated on behalf of a user, who can submit requests and / or receive instructions that aid in device navigation.

[0138] In at least one embodiment, a request can be submitted via at least one network 504 for receipt by a vendor environment 506. In at least one embodiment, the client device can be any suitable electronic and / or computing device that enables a user to generate and send such requests, such as, but not limited to, desktop computers, laptop computers, computer servers, smartphones, tablets, game consoles (portable or otherwise), computer processors, computing logic, and set-top boxes. One or more networks 504 can include any suitable network for transmitting requests or other such data, such as the Internet, intranet, Ethernet, cellular network, local area network (LAN), wide area network (WAN), personal area network (PAN), self-organizing network providing direct wireless connectivity between peers, etc.

[0139] In at least one embodiment, a request may be received at interface layer 508, which in this example may forward data to training and inference manager 532. Training and inference manager 532 may be a system or service including hardware and software for managing services and requests corresponding to data or content. In at least one embodiment, training and inference manager 532 may receive a request to train a neural network and may provide data for the request to training module 512. In at least one embodiment, if the request is not specified, training module 512 may select an appropriate model or neural network to use and may train the model using the associated training data. In at least one embodiment, training data may be a batch of data stored in training data repository 514, received from client device 502, or obtained from third-party vendor 524. In at least one embodiment, training module 512 may be responsible for training the data. The neural network may be any suitable network, such as a recurrent neural network (RNN) or convolutional neural network (CNN). Once the neural network is trained and successfully evaluated, the trained neural network may be stored in, for example, model repository 516, which may store different models or networks for users, applications, or services, etc. In at least one embodiment, there may be multiple models for a single application or entity, which can be utilized based on multiple different factors.

[0140] In at least one embodiment, at a subsequent point in time, a request for content (e.g., path determination) or data that is at least partially determined or influenced by a trained neural network can be received from client device 502 (or another such device). This request may include, for example, input data to be processed using the neural network to obtain one or more inference or other output values, classifications, or predictions. Alternatively, in at least one embodiment, the input data may be received by interface layer 508 and directed to inference module 518, although different systems or services may also be used. In at least one embodiment, if not already locally stored in inference module 518, inference module 518 may obtain a suitably trained network, such as a trained deep neural network (DNN) as discussed herein, from model repository 516. Inference module 518 may provide data as input to the trained network, which may then generate one or more inferences as outputs. This may, for example, include the classification of instances of input data. In at least one embodiment, the inference may then be transmitted to client device 502 for display to a user or for other communication with the user. In at least one embodiment, user context data may also be stored in a user context data repository 522, which may include data about the user that can be used as network input to generate inference or determine data returned to the user after obtaining an instance. In at least one embodiment, relevant data, including at least some of the input or inference data, may also be stored in a local database 534 for processing future requests. In at least one embodiment, the user may use account information or other information to access resources or functions of the vendor environment. In at least one embodiment, user data may also be collected and used to further train the model, if permitted and available, to provide more accurate inference for future requests. In at least one embodiment, requests to a machine learning application 526 executed on a client device 502 may be received via a user interface, and the results may be displayed via the same interface. The client device may include resources such as a processor 528 and a memory 562 for generating requests and processing results or responses, and at least one data storage element 552 for storing data for the machine learning application 526.

[0141] In at least one embodiment, processor 528 (or the processor of training module 512 or inference module 518) will be a central processing unit (CPU). However, as mentioned above, resources in such an environment can utilize GPUs to process data for at least some types of requests. GPUs such as the PPU 300 have thousands of cores and are designed to handle large amounts of parallel workloads, thus becoming popular in deep learning for training neural networks and generating predictions. While using GPUs for offline building allows for faster training of larger, more complex models, offline prediction generation means that request-time input features cannot be used, or predictions must be generated for all features and stored in a lookup table for real-time service requests. If the deep learning framework supports CPU mode and the model is small and simple enough that the feedforward can be performed on the CPU with reasonable latency, then a service on a CPU instance can host the model. In this case, training can be done offline on the GPU and inference can be performed in real-time on the CPU. If the CPU approach is not feasible, the service can run on a GPU instance. However, due to the different performance and cost characteristics of GPUs compared to CPUs, running a service that offloads runtime algorithms to the GPU may require it to be designed differently from a CPU-based service.

[0142] In at least one embodiment, video data can be provided from client device 502 for enhancement in vendor environment 506. In at least one embodiment, the video data can be processed for enhancement on client device 502. In at least one embodiment, the video data can be streamed from third-party content provider 524 and enhanced by third-party content provider 524, vendor environment 506, or client device 502. In at least one embodiment, video data can be provided from client device 502 for use as training data in vendor environment 506.

[0143] In at least one embodiment, supervised and / or unsupervised training may be performed by client device 502 and / or vendor environment 506. In at least one embodiment, a set of training data 514 (e.g., classified or labeled data) is provided as input for use as training data. In at least one embodiment, the training data may include instances of at least one type of object for which the neural network is to be trained, and information identifying that object type. In at least one embodiment, the training data may include a set of images, each image including a representation of an object of a type, wherein each image also includes, or is associated with, tags, metadata, classification, or other information identifying or identifying the type of object represented in the corresponding image. Various other types of data may also be used as training data, which may include text data, audio data, video data, and so on. In at least one embodiment, training data 514 is provided as training input to training module 512. In at least one embodiment, training module 512 may be a system or service including hardware and software, such as one or more computing devices executing a training application for training a neural network (or other model or algorithm, etc.). In at least one embodiment, training module 512 receives instructions or requests indicating the type of model to be used for training. In at least one embodiment, the model can be any suitable statistical model, network, or algorithm useful for such a purpose, which may include artificial neural networks, deep learning algorithms, learning classifiers, Bayesian networks, etc. In at least one embodiment, training module 512 may select an initial model or other untrained models from an appropriate repository and train the model using training data 514 to generate a trained model (e.g., a trained deep neural network) that can be used to classify similar types of data or generate other such inference. In at least one embodiment where training data is not used, an initial model can still be selected to train on the input data of each training module 512.

[0144] In at least one embodiment, the model can be trained in several different ways, which may depend in part on the type of model chosen. In at least one embodiment, a training dataset can be provided to a machine learning algorithm, wherein the model is a model artifact created through a training process. In at least one embodiment, each instance of the training data contains the correct answer (e.g., classification) that may be referred to as the target or target attribute. In at least one embodiment, the learning algorithm finds patterns in the training data that map input data attributes to the target—the answer to be predicted—and the machine learning model is the output that captures these patterns. In at least one embodiment, the machine learning model can then be used to obtain predictions for new data without a specified target.

[0145] In at least one embodiment, the training and inference manager 532 may select from a set of machine learning models, including binary classification, multi-class classification, generative, and regression models. In at least one embodiment, the type of model to be used may depend at least in part on the type of target to be predicted.

[0146] Graphics processing pipeline

[0147] In one embodiment, PPU 300 includes a graphics processing unit (GPU). PPU 300 is configured to receive commands specifying a shader program for processing graphics data. Graphics data can be defined as a set of primitives such as points, lines, triangles, quadrilaterals, triangle strips, etc. Typically, a primitive includes data specifying the number of vertices used for that primitive (e.g., in a model-space coordinate system) and attributes associated with each vertex of that primitive. PPU 300 can be configured to process graphics primitives to generate framebuffers (e.g., pixel data for each pixel in a display).

[0148] The application writes model data (such as attributes and vertex sets) for the scene into memory such as system memory or memory 304. The model data defines each of the objects that may be visible on the display. The application then makes API calls to the driver kernel, requesting that the model data be rendered and displayed. The driver kernel reads the model data and writes commands to one or more streams to perform operations that process the model data. These commands may reference different shader programs to be implemented on SMs 440 within the PPU 300, including one or more vertex shaders, shell shaders, domain shaders, geometry shaders, and pixel shaders. For example, one or more of the SMs 440 may be configured to execute a vertex shader program that processes a number of vertices defined by the model data. In one embodiment, these different SMs 440 may be configured to execute different shader programs concurrently. For example, a first subset of the SMs 440 may be configured to execute vertex shader programs, while a second subset of the SMs 440 may be configured to execute pixel shader programs. A first subset of the SM 440 processes vertex data to produce processed vertex data and writes it to L2 cache 360 ​​and / or memory 304. After the processed vertex data is rasterized (e.g., transformed from 3D data to 2D data in screen space) to produce fragment data, a second subset of the SM 440 executes pixel shaders to produce processed fragment data, which is then mixed with other processed fragment data and written to the framebuffer in memory 304. Vertex shader and pixel shader programs can execute concurrently, pipelinedly processing different data from the same scene until all model data for that scene has been rendered to the framebuffer. The contents of the framebuffer are then transferred to the display controller for display on the display device.

[0149] Example Streaming System

[0150] Figure 6 This is a schematic diagram of an example system 605 of a streaming system according to some embodiments of the present disclosure. Figure 6 Includes server 602 (which may include with Figure 5A Example processing system 500 and / or Figure 5B (Similar components, features and / or functions to exemplary system 565), client 604 (which may include similar ... Figure 5A Example processing system 500 and / or Figure 5B The exemplary system 565 has similar components, features, and / or functions to the network 606 (which may be similar to the network described herein). In some embodiments of this disclosure, system 605 may be implemented.

[0151] In one embodiment, streaming system 605 is a game streaming system, and server 604 is a game server. In system 605, for a game session, client device 604 can simply receive input data in response to input from input device 626, send the input data to server 603, receive encoded display data from server 603, and display the display data on display 624. In this way, computationally intensive computation and processing are offloaded to server 603 (e.g., rendering of the game session's graphics output, especially ray or path tracing, is performed by the GPU 615 of server 603). In other words, the game session is streamed from server 603 to client device 604, thereby reducing the demands on client device 604 for graphics processing and rendering.

[0152] For example, regarding the instantiation of a game session, client device 604 can display frames of the game session on display 624 based on display data received from server 603. Client device 604 can receive input from one of input devices 626 and generate input data in response. Client device 604 can send the input data to server 603 via communication interface 621 and over network 606 (e.g., the Internet), and server 603 can receive the input data via communication interface 618. CPU 608 can receive the input data, process the input data, and send the data to GPU 615, which causes GPU 615 to generate a rendering of the game session. For example, the input data can represent the movement of a user character in the game, such as firing a weapon, reloading, passing a ball, turning a vehicle, etc. Rendering component 612 can render the game session (e.g., representing the result of the input data), and rendering capture component 614 can capture the rendering of the game session as display data (e.g., image data as frames of the captured game session rendering). The rendering of a game session may include lighting and / or shadow effects computed using one or more parallel processing units of server 603 (e.g., a GPU, which may further employ one or more dedicated hardware accelerators or processing cores to perform ray or path tracing techniques). Encoder 616 can then encode the display data to generate encoded display data, which can be sent to client device 604 via communication interface 618 through network 606. Client device 604 can receive the encoded display data via communication interface 621, and decoder 622 can decode the encoded display data to generate display data. Client device 604 can then display the display data via display 624.

[0153] It should be noted that the techniques described herein can be embodied in executable instructions stored in a computer-readable medium for use by or in conjunction with a processor-based instruction execution machine, system, apparatus, or device. Those skilled in the art will appreciate that, for some embodiments, various types of computer-readable media may be included for storing data. When used herein, “computer-readable medium” includes one or more of any suitable media for storing executable instructions of a computer program, such that an instruction execution machine, system, apparatus, or device can read (or retrieve) the instructions from the computer-readable medium and execute those instructions to implement the described embodiments. Suitable storage formats include one or more of electronic, magnetic, optical, and electromagnetic formats. A non-exhaustive list of conventional exemplary computer-readable media includes: portable computer disks; random access memory (RAM); read-only memory (ROM); erasable programmable read-only memory (EPROM); flash memory devices; and optical storage devices, including portable compact discs (CDs), portable digital video discs (DVDs), and the like.

[0154] It should be understood that the arrangement of components shown in the accompanying drawings is for illustrative purposes, and other arrangements are possible. For example, one or more of the elements described herein may be implemented wholly or partially as electronic hardware components. Other elements may be implemented in software, hardware, or a combination of software and hardware. Moreover, some or all of these other elements may be combined, some may be omitted entirely, and additional components may be added while still achieving the functionality described herein. Therefore, the subject matter described herein can be implemented in many different variations, and all such variations are contemplated to be within the scope of the claims.

[0155] To facilitate understanding of the topics described herein, many aspects are described in sequence of actions. Those skilled in the art will recognize that various actions can be performed by dedicated circuitry or circuit systems, by program instructions executed by one or more processors, or by a combination of both. The description of any sequence of actions herein is not intended to imply that a particular order in which the actions described for execution must be followed. All methods described herein can be performed in any suitable order unless otherwise indicated herein or otherwise clearly contradicted by the context.

[0156] In the context of describing the subject matter (especially in the context of the claims below), the use of the terms “a,” “an,” “this,” and similar designations should be interpreted to cover both the singular and plural, unless otherwise specified herein or obviously contradicted by the context. The use of the term “at least one” (e.g., at least one of A and B) followed by a list of one or more items should be interpreted to mean one item selected from the listed items (A or B), or any combination of two or more of the listed items (A and B), unless otherwise specified herein or obviously contradicted by the context. Furthermore, the foregoing description is for illustrative purposes only and not for limiting purposes, as the scope of protection sought is defined by the claims set forth thereafter with their equivalents. The use of any and all example or exemplary language provided herein (e.g., “such as”) is intended merely to better illustrate the subject matter and does not constitute a limitation on the scope of the subject matter, unless otherwise stated. The use of “based on,” and other similar phrases indicating conditions leading to the result, in both the claims and the written description, is not intended to exclude any other conditions leading to that result. The language in the description should not be interpreted as indicating that any unclaimed element is essential for the implementation of the claimed invention.

Claims

1. A computer-implemented method, comprising: Receive the set of edges that define the mask shape for the manufacture of integrated circuits; The mask shape of the integrated circuit is divided into multiple parts; For each part containing at least one optical proximity correction OPC error, correct the OPC error caused by optical lithography effects; Identify at least one mask manufacturing rule violation corresponding to the mask shape of one portion of the plurality of parts, wherein the at least one mask manufacturing rule violation is caused by a change in at least one mask shape to compensate for the at least one OPC error; In parallel computation, adjustments are made to the set of said edges to reduce or eliminate the violation of at least one mask manufacturing rule; and At least one edge in the set of edges is adjusted according to the calculated adjustment to produce an adjusted set of edges.

2. The computer-implemented method according to claim 1 further includes: Constructing a search tree containing the set of said edges, wherein identifying the at least one mask manufacturing rule violation includes traversing the search tree to locate the nearest neighbor edge of at least one edge associated with the at least one mask manufacturing rule violation.

3. The computer-implemented method according to claim 2 further includes: Measure the area of ​​the mask shape; as well as The measured area is stored in the search tree.

4. The computer-implemented method of claim 1, wherein the plurality of parts are assigned to a processing core for the computation to be performed in parallel.

5. The computer-implemented method of claim 1, wherein the calculation includes considering state information of each edge in the set of edges, the state information including at least one of a maximum possible adjustment amount or an ideal adjustment amount to reduce or eliminate the at least one mask manufacturing rule violation.

6. The computer-implemented method of claim 5, wherein the state information of at least two edges associated with the at least one mask manufacturing rule violation is shared to calculate the adjustment for the at least two edges.

7. The computer-implemented method of claim 1, wherein the adjustment comprises adjusting a first edge in the set of edges and a second edge in the set of edges to maintain the geometric symmetry of the mask shape defined by the first edge and the second edge and to maintain the measured area of ​​the mask shape.

8. The computer-implemented method of claim 1, wherein each of the plurality of parts is assigned to one of the plurality of processing cores and each edge in the set of edges is assigned a thread for the plurality of processing cores to execute in parallel for the identification, calculation and adjustment.

9. The computer-implemented method according to claim 1, further comprising: The adjusted set of edges is evaluated to identify any violations of mask manufacturing rules; as well as The calculations and adjustments are repeated until no mask manufacturing rules are violated, in order to produce the final mask shape for the integrated circuit.

10. The computer-implemented method according to claim 1, further comprising: The adjusted set of edges is evaluated to identify any violations of mask manufacturing rules; as well as The calculations and adjustments are repeated until multiple mask manufacturing rules are violated by less than a threshold, in order to produce the final mask shape of the integrated circuit; Calculate at least one additional mask shape change to compensate for the optical lithography effect; as well as Before generating the final mask shape of the integrated circuit, the at least one additional mask shape variation is determined to be within tolerance.

11. The computer-implemented method of claim 1, wherein the identification, calculation, and adjustment steps are performed by a graphics processing unit (GPU).

12. The computer-implemented method of claim 1, wherein at least one of the identification, calculation, or adjustment steps is performed on a server or in a data center to define an adjusted mask shape for the manufacture of the integrated circuit.

13. The computer-implemented method of claim 1, wherein at least one of the identification, calculation, or adjustment steps is performed within a cloud computing environment.

14. The computer-implemented method of claim 1, wherein at least one of the identification, calculation, or adjustment steps is performed on a virtual machine comprising a portion of a graphics processing unit.

15. A system comprising: A memory that stores a set of edges of a mask shape used for the manufacture of integrated circuits; as well as A processor connected to the memory, wherein the processor is configured to: The mask shape of the integrated circuit is divided into multiple parts; For each part containing at least one optical proximity correction OPC error, correct the OPC error caused by optical lithography effects; Identify at least one mask manufacturing rule violation corresponding to the mask shape of one portion of the plurality of parts, wherein the at least one mask manufacturing rule violation is caused by a change in at least one mask shape to compensate for the at least one OPC error; In parallel computation, adjustments are made to the set of said edges to reduce or eliminate the violation of at least one mask manufacturing rule; and At least one edge in the set of edges is adjusted according to the calculated adjustment to produce an adjusted set of edges.

16. The system of claim 15, wherein the calculation includes considering state information for each edge in the set of edges, the state information including at least one of a maximum possible adjustment amount or an ideal adjustment amount to reduce or eliminate the at least one mask manufacturing rule violation.

17. The system of claim 16, wherein the state information of at least two edges associated with the at least one mask manufacturing rule violation is shared to calculate one or more of the adjustments.

18. The system according to claim 16, wherein, Each of the plurality of parts is assigned to one of the plurality of processing cores, and each edge in the set of edges is assigned a thread for the plurality of processing cores to execute in parallel.

19. The system according to claim 16, wherein, The adjustment includes adjusting a first edge in the set of edges and a second edge in the set of edges to maintain the geometric symmetry of the mask shape defined by the first edge and the second edge and to maintain the measured area of ​​the mask shape.

20. A non-transitory computer-readable medium storing computer instructions that, when executed by one or more processors, cause the one or more processors to perform the following steps: Receive the set of edges that define the mask shape for the manufacture of integrated circuits; The mask shape of the integrated circuit is divided into multiple parts; For each part containing at least one optical proximity correction OPC error, correct the OPC error caused by optical lithography effects; Identify at least one mask manufacturing rule violation corresponding to the mask shape of one portion of the plurality of parts, wherein the at least one mask manufacturing rule violation is caused by a change in at least one mask shape to compensate for the at least one OPC error; In parallel computation, adjustments are made to the set of said edges to reduce or eliminate the violation of at least one mask manufacturing rule; and At least one edge in the set of edges is adjusted according to the calculated adjustment to produce an adjusted set of edges.

21. The non-transitory computer-readable medium of claim 20, wherein the adjustment comprises adjusting a first edge in the set of edges and a second edge in the set of edges to maintain the geometric symmetry of the mask shape defined by the first edge and the second edge and to maintain the measured area of ​​the mask shape.

Images