BACKGROUND

[0001] Electronic circuits are used in nearly every facet of modern society, from automobiles to microwaves to personal computers. Design of circuits may involve many steps, known as a "design flow." The particular steps of a design flow often are dependent upon the type of circuit being designed, its complexity, the design team, and the circuit fabricator or foundry that will manufacture the circuit. Electronic design automation (EDA) applications support the design and verification of circuits prior to fabrication. EDA applications may include various functions, tools, capabilities, or features to test or verify a circuit design at various stages of the design flow.

BRIEF DESCRIPTION OF THE DRAWINGS

[0002] Certain examples are described in the following detailed description and in reference to the drawings.

[0003] Figure 1 shows an example of a computing device that supports resource allocation of a secondary computing resource for multiple optical proximity correction (OPC) processes of an EDA application.

[0004] Figure 2 shows an example of multi-OPC process resource allocation and access control by a lithography simulation server engine.

[0005] Figure 3 shows an example use of a shared memory by the lithography simulation server engine and OPC processes in support of execution of OPC tasks through secondary computing resources. [0006] Figure 4 shows an example of a communication timeline between an OPC process and the lithography simulation server engine.

[0007] Figure 5 shows an example of logic that a computing device may implement to support resource allocation of a secondary computing resource for multiple OPC processes of an EDA application.

[0008] Figure 6 shows an example of a computing device that supports resource allocation of a secondary computing resource for multiple OPC processes of an EDA application.

DETAILED DESCRIPTION

[0009] The following disclosure relates to EDA applications which may be used to facilitate the design and manufacture of circuits. As technology improves, modern circuit designs may include billions of components, often times more. To support increasing degrees of circuit design complexity, EDA applications may include various features such as high-level synthesis, schematic capture, transistor or logic simulation, field solvers, functional and physical verifications, geometry processing, equivalence checking, design rule checks, OPC or lithography simulations, mask data preparation, and more. [0010] Execution of EDA applications and processes may require significant computational resources, and how particular EDA computing environments are implemented may vary between different entities that use EDA applications for circuit design and verification. Distributed computing environments configured to execute EDA processes across multiple different computing devices may range from 16 central processing unit (CPU) configurations, to 10,000 of CPUs, to more. As circuit designs continue to increase in complexity, computational requirements of EDA applications may continue to increase. As such, improvements in the computational performance and capability of computing systems used to execute EDA applications may provide significant technical benefits.

[0011] OPC flows may be one area of EDA design flows with increasing computational requirements. OPC flows may refer to any OPC execution sequence, OPC application capability, or other OPC-related feature that an EDA application can perform. Aspects of OPC flows can include geometry processing, lithography simulations (also referred to herein as OPC simulations), and more. Execution of modern OPC flows may be incredibly complex and can often involve large-scale parallel processing systems using a distributed network of individual computing devices. In some conventional implementations, a primary OPC process may oversee execution of the OPC flow, which may include initiating multiple OPC worker processes on individual computing devices that form the parallel processing system to perform various OPC tasks that are part of the OPC flow. Each of the OPC worker processes may perform a discrete OPC task for the OPC flow, and communicate primarily (e.g., solely) with the primary OPC process that oversees the OPC flow.

[0012] Such a conventional OPC flow implementation may pose challenges for utilizing secondary computing resources of computing devices to perform OPC tasks. For example, graphical processing units (GPUs) may provide an efficient option to execute OPC simulation tasks, but multi-process access to GPU architectures by conventional OPC implementations can result in resource collisions, memory overruns, and application errors. Since the OPC worker processes do not communicate with one another, GPU resource coordination may not be possible under current OPC flow implementations. On the other hand, limiting GPU access to a single-OPC process per computing device may result in increased execution latencies and reduced application performance that may be impractical or otherwise fail to meet modern EDA application performance requirements.

[0013] The features described herein may support resource allocations of a secondary computing resource for multiple OPC processes of an EDA application. The multi-OPC process resource allocation technology described herein may provide resource allocation and control access to secondary computing resources via a single multi-threaded process, and may do so instead of allowing access to the secondary computing resource by multiple OPC processes. Accordingly, the multi-OPC process resource allocation features provided herein can support parallel processing of OPC tasks via GPUs (and other secondary computing resources) with increased computational efficiency and parallelism as compared to conventional OPC flow implementations. In doing so, the multi-OPC process resource allocation technology according to the present disclosure may act as a single interface to GPU hardware, thereby supporting resource allocations between different OPC tasks performed through a GPU with increased effectiveness and efficiency. [0014] These and other technical benefits of the multi-OPC process resource allocation features according to the present disclosure are described herein. [0015] Figure 1 shows an example of a computing device 100 that supports resource allocation of a secondary computing resource for multiple OPC processes of an EDA application. The computing device 100 may be single computing entity, and may be one element of a distributed processing system that hosts, executes, or implements an EDA application or any underlying EDA capability. As such, the computing device 100 may be an individual workstation, compute node, remote worker, application server, data server, desktop or laptop computer, smart phone or other mobile device, tablet device, embedded controller, and the like. In some implementations, the computing device 100 may be a computing system (e.g., comprising multiple workstations or compute nodes) that may be viewed as a single logical computing entity of a distributed or parallel EDA processing system.

[0016] The computing device 100 shown in Figure 1 includes a CPU 106 and secondary computing resource 108. The CPU 106 may be any single or multi processor computing resource capable of executing instructions. The CPU 106 may include multiple CPU cores, memory, peripheral interfaces, and other circuitry or logic to support instruction execution. The secondary computing resource 108 may be any other computing hardware that is independent from, different, distinct, or otherwise separate from the CPU 106. Secondary computing resources 108 may operate independently from the CPU 106, and may take the form of specialized computing resources designed to support specific types of execution flows with increased efficiency. Example secondary computing resources of a computing device may include GPUs (sometimes also referred to as visual processing units (VPUs)), field programmable gate arrays (FPGAs), quantum computing hardware, etc. The CPU 106 and secondary computing resource 108 may be independent computing resources of the computing device 100, but may share access to different computing resources (e.g., shared memories). In some instances, the CPU 106 and the secondary computing resource 108 may be implemented on the same physical die.

[0017] The computing device 100 shown in Figure 1 also includes a lithography simulation server engine 110. The computing device 100 may implement the lithography simulation server engine 110 (and components thereof) in various ways, for example as hardware and programming. The programming for the lithography simulation server engine 110 may take the form of processor-executable instructions stored on a non-transitory machine- readable storage medium and the hardware for the lithography simulation server engine 110 may include a processor to execute those instructions. A processor may take the form of single processor or multi-processor systems, and in some examples, the computing device 100 implements multiple engine components or device elements using the same computing system features or hardware components (e.g., a common processor or common storage medium for the lithography simulation server engine 110 and other elements, logic, or capabilities of the computing device).

[0018] In operation, the lithography simulation server engine 110 may identify a first OPC process of an EDA application to perform a first OPC simulation task through the computing device 100 as well as identify a second OPC process of the EDA application to perform a second OPC simulation task through the computing device 100. In operation, the lithography simulation server engine 110 may also control access to the secondary computing resource 108 for performing the first OPC simulation task and the second OPC simulation task via a single multi-threaded process, instead of allowing access to the secondary computing resource 108 by multiple OPC processes that include the first OPC process and the second OPC process. The lithography simulation server engine 110 may do so by allocating use of the secondary computing resource 108 for performing the first OPC simulation task and the second OPC simulation task.

[0019] These and other multi-OPC process resource allocation features are described in greater detail next.

[0020] Figure 2 shows an example of multi-OPC process resource allocation and access control by the lithography simulation server engine 110. In the example of Figure 2, the lithography simulation server engine 110 allocates resources of a GPU 210 for use in executing OPC tasks of multiple OPC processes that are part of an OPC flow and assigned to a computing device that implements the lithography simulation server engine 110. The GPU 210 may be a secondary computing resource of such a computing device in a parallel processing system, and the lithography simulation server engine 110 may support multi-OPC process access and resource control for the GPU 210.

[0021] The lithography simulation server engine 110 may identify multiple OPC processes initiated for execution by a computing device. Each of the multiple OPC processes may be executing on the computing device and may be distinct, each process representing a different “program” in execution (though these OPC processes may be part of the same OPC flow). In that regard, the multiple OPC processes executing on a computing device may be independent or isolated from one another, such that different OPC processes do not share memory resource allocations, OPC data, or execution contexts with one another. Different OPC processes executing on a computing device may be distinct or independent in that they may not otherwise communicate execution or memory states with one another as well.

[0022] As also noted herein, different OPC processes executing on a computing device may perform different OPC tasks in an OPC flow, and the different OPC tasks may be discrete from one another such that execution of the OPC tasks can be performed independently via the different OPC processes. The OPC tasks may perform specific OPC processing on different portions of a circuit design, for example, whether that include geometry processing, edge processing, lithography or other OPC simulations, and more. In the example shown in Figure 2, the lithography simulation server engine 110 identifies the OPC process 221 and OPC process 222 executing (or scheduled to execute) on a computing device.

[0023] The OPC processes 221 and 222 may each be part of an OPC flow for analyzing, designing, or processing a circuit design. The OPC processes 221 and 222 may be OPC worker processes, in that a primary OPC process overseeing execution of the OPC flow may assign independent OPC tasks for execution by a computing device, respectively performed through the OPC process 221, the OPC process 222, and any other discrete OPC process the computing device may initiate to execute a distinct OPC task. As an illustrative example, the OPC process 221 may be configured, initialized, or executed to perform a first OPC task (e.g., a lithography simulation for a specific circuit segment or hierarchical database element) and the OPC process 222 may be configured, initialized, or executed to perform a second OPC task that is different, distinct, or independent from the first OPC simulation task.

[0024] Some OPC tasks of an OPC flow may be more efficiently performed through the GPU 210 than a CPU of a computing device. GPUs may include highly-parallel computing structures which can be particularly effective in manipulating computer graphics, image processing, or other types of processing. In particular, the high degree of parallelism in GPU architectures may be useful for performing specific types of OPC tasks, including lithography or OPC simulations since such OPC simulation tasks may be amenable to large degrees of parallel processing. As such, some OPC tasks may be more efficiently executed on GPUs than on CPUs, including OPC and lithography simulation tasks of an OPC flow.

[0025] Modern GPUs, however, may be incapable or inefficient in supporting multi-process access to a single GPU. As such, GPU resource requests, execution context, and memory allocations handled directly by multiple OPC processes may cause execution issues, memory overruns, and application failures. For instance, some GPU application program interfaces (APIs) are designed to be initiated on a per-process basis. The Compute Unified Device Architecture (CUDA) API model, as one example, is one example of a resource interface by which resources of modern GPUs can be accessed (processing time, GPU memory allocation, etc.). The CUDA platform may be designed such that an instance of a CUDA runtime interface is initiated for each process that accesses a GPU. Such a design of modern GPU API models may be incompatible with execution of OPC flows which can execute multiple OPC processes per computing device, each of process OPC data separately and independently. When multiple OPC processes access a GPU, each OPC process may initiate a separate instance of API model elements, such as multiple CUDA runtime instances. The multiple OPC processes may execute independently from one another, and each separate instance of CUDA runtime interfaces (separately initiated by the multiple OPC processes) may be unaware that other instances of CUDA runtime are also accessing and using GPU resources. Resource contentions, multiple OPC processes allocating and using overlapping portions of GPU memory, and other unintended or error-causing consequences can thus result. Explained another way, GPU memory overruns, execution errors, and application failure can result when multiple distinct processes attempt to access the same GPU resource of a computing device. [0026] The lithography simulation server engine 110 may address such short comings of modern GPU architectures and multi-process OPC flow executions. In particular, the lithography simulation server engine 110 may act as an interface between the multiple OPC processes executing on a given computing device and the GPU of the given computing device (or any other secondary computing resource of the given computing device). For instance, the lithography simulation server engine 110 may allocate resources and control access to the GPU 210 for execution of the OPC tasks of the OPC processes 221 and 222.

[0027] In some implementations, the lithography simulation server engine 110 may execute a lithography simulation server process to oversee execution of multiple, discrete OPC tasks assigned for execution by the given computing device. The lithography simulation server process executed or otherwise implemented by the lithography simulation server engine 110 may be a single, multi-threaded process that interfaces with the GPU 210 to perform the OPC tasks of multiple OPC processes, including the OPC process 221 and the OPC process 222. In some implementations, the lithography simulation server engine 110 itself may be implemented, in part, as a single, multi-threaded process that controls access to the GPU 210 of a computing device for execution of OPC tasks. By executing a single, multi-threaded process for performing OPC tasks of multiple different OPC processes, the lithography simulation server engine 110 may address single-process access requirements applicable to modern GPU architectures while also leveraging GPU capabilities to process different OPC simulation tasks in parallel.

[0028] The lithography simulation server engine 110 may initiate a separate execution thread for each identified OPC process assigned or initiated by a given computing device. As such, the lithography simulation server engine 110 may perform thread-level control, scheduling, and processing of OPC tasks through the GPU 210. In some cases, the lithography simulation server engine 110 may initiate execution threads to perform OPC simulation tasks of identified OPC processes on a one-to-one basis. Explained another way, the lithography simulation server engine 110 may initiate an execution thread for each identified OPC process that requests execution of an OPC task through the GPU 210. Execution threads initiated by the lithography simulation server engine 110 may directly correlate, correspond to, or perform the OPC tasks of OPC processes assigned to a particular computing device (e.g., by a primary OPC process). For example, execution of OPC simulation tasks assigned for a particular computing device may be performed via the execution threads initiated by the lithography simulation server engine 110, instead of the OPC processes initiated on the particular computing device (as would be the case under execution of conventional OPC flow implementations).

[0029] In the example shown in Figure 2, the lithography simulation server engine 110 initiates an execution thread 231 to perform a first OPC simulation task of the OPC process 221 and a second execution thread 232 to perform a second OPC simulation task of the OPC process 222. By maintaining a 1:1 OPC process-to-thread correspondence, the lithography simulation server engine 110 may preserve performance stability and avoid unintended performance consequences or irregularities that may arise if a given OPC process was allocated multiple execution threads in the lithography simulation server process. In other implementations, the lithography simulation server engine 110 may initiate a different number of execution threads for different OPC processes, and in doing so may support weighted parallelism or prioritized processing and resource allocation.

[0030] By executing as a single, multi-threaded process, the lithography simulation server engine 110 may provide a single interface to the GPU 210 in performing multiple, independent OPC simulation tasks. In doing so, the lithography simulation server engine 110 may initiate a single instance of a resource interface 240 to interface with GPU resources of the GPU 210, doing so instead of allowing the multiple OPC processes, including the first OPC process 221 and the second OPC process 222, to initiate multiple instances of the resource interface 240. The resource interface 240 may be any API or interface logic that can support access or use of a secondary computing resource, such as CUDA runtime instances.

[0031] For the CUDA platform and similar GPU API models, the lithography simulation server engine 110 may initiate a single CUDA runtime instance that can track, assign, and control resource allocations of the GPU 210. Since the lithography simulation server engine 110 may implement the sole process that interfaces with the GPU 210, no other CUDA runtime instances are or need to be initiated, thus avoiding memory overrun and execution errors that can occur from multi-process access to the GPU 210 of conventional OPC executions. Access control, thread scheduling, and resource allocations may be performed by the lithography simulation server engine 110 using any type of scheduling or access control schemes, and instantiated resource interfaces (such as a CUDA runtime instance) may provide resource allocations and control features in support of the lithography simulation server engine 110.

[0032] In some examples, the lithography simulation server engine 110 may leverage shared resources of a computing device in order to increase the efficiency by which OPC tasks are performed through a secondary computing resource of a computing device. For example, the lithography simulation server engine 110 may leverage a shared memory of a computing device to access OPC simulation data and write simulation results. Example features of leveraging of a shared memory for OPC task executions are described next with reference to Figure 3.

[0033] Figure 3 shows an example use of a shared memory by the lithography simulation server engine 110 and OPC processes in support of execution of OPC tasks through secondary computing resources. As used herein, a shared memory may refer to any memory of a computing device that is configured, allocated, accessible, or shared between different processes executing on the computing device. As such, multiple different processes executing on the computing device may have read and write access to the shared memory. A shared memory 310 is shown in the example of Figure 3, and the shared memory 301 may take the form of any non-transitory machine-readable medium on which data can be stored, retrieved, or otherwise accessed.

[0034] The shared memory 310 may be part of a particular computing device, and multiple processes executing on the particular computing device may be capable of accessing data stored on the shared memory 310. In Figure 3, both the OPC process 221 and the lithography simulation server engine 110 have access to the shared memory 310. The single, multi-threaded process executed by the lithography simulation server engine 110 to control access to the GPU (or any other secondary computing resource) of the particular computing device may likewise access data stored in the shared memory 310. Through the shared memory 310, the lithography simulation server engine 110 may increase the efficiency of OPC task executions by the GPU or other secondary computing resources, doing so by reducing the latency, use of, or need for inter-process data transfers.

[0035] For instance, the lithography simulation server engine 110 may access OPC data for performing OPC tasks directly from the shared memory 310 instead of through inter-process communications from OPC processes executing on a particular computing device. By doing so, the OPC processes executing on the particular computing device may request access to the GPU for execution of OPC tasks without having to perform an inter-process data transfer of the OPC data needed to perform the OPC tasks. In some implementations, the OPC process 221 may request use of the GPU 210 for performing a first OPC simulation task by sending a request memory handle 320 to the lithography simulation server engine 110.

[0036] The request memory handle 320 may indicate a portion in a shared memory 310 at which OPC data for the first OPC simulation task is stored. As such, the request memory handle 320 may take the form of a memory address or address range at which the OPC process 221 has stored the OPC data for performing an OPC simulation task, and the OPC process 221 need not additionally transfer the OPC data to the lithography simulation server engine 110 (or a lithography simulation server process executed by the lithography simulation server engine 110). By leveraging shared memory locations, OPC processes and the lithography simulation server engine 110 may reduce data transfer latencies and internal communication bandwidth for performing OPC tasks through secondary computing resources.

[0037] The lithography simulation server engine 110 may control execution of the OPC simulation task for the OPC process 221 by accessing the OPC data stored in the shared memory 310. Through an initiated execution thread and aa resource interface 420 to a GPU 210, the lithography simulation server engine 110 may use the GPU 210 to perform the OPC simulation task of the OPC process 221 (e.g., in any of the ways described herein). Upon completion of performing the OPC simulation task of the OPC process 221, the lithography simulation server engine 110 need not perform an inter-process data transfer to provide the simulation results of the OPC simulation task back to the OPC process 221. Such an inter-process communication of simulation results may consume internal communication bandwidth of a computing device.

[0038] Instead, the lithography simulation server engine 110 may leverage the shared memory 310. While performing the OPC simulation task of the OPC process 221, the lithography simulation server engine 110 may write simulation results to allocated portions of the shared memory 310. Instead of retrieving and sending the simulation results (already stored on the shared memory 310) to the OPC process 221, the lithography simulation server engine 110 may provide a response 330 to the OPC process 221 that execution of the OPC simulation task via the GPU 210 has completed. The response 330 may include a response memory handle that indicates the portion (e.g., address range) in the shared memory 310 at which simulation results for the OPC simulation task have been stored by the lithography simulation server engine 110. Such leveraging of shared memories may reduce inter-process data transfers and reduce execution latencies for OPC tasks performed through the lithography simulation server engine 110.

[0039] Figure 4 shows an example of a communication timeline 400 between an OPC process and the lithography simulation server engine 110. The communication timeline 400 shown in Figure 4 is between the OPC process 221 and the lithography simulation server engine 110, and the OPC process 221 may be initiated by a computing device to perform an OPC simulation task in any of the various ways described herein.

[0040] The OPC process 221 may start an OPC simulation task. To perform an OPC simulation task, a computing device may receive an assignment from a primary OPC process overseeing an OPC flow to perform the OPC simulation task. In response, the computing device may initiate execution of the OPC process 221 to perform the OPC simulation task. In some implementations, the computing device may verify, prior to initiating the OPC process 221 for execution, that the GPU 210 of the computing device is available to perform the OPC simulation task. If not, the computing device may respond to the primary OPC process that the GPU 210 is unavailable, and the primary OPC process may assign the OPC simulation task to a different computing device in a distributed EDA processing system. Responsive to a verification that the GPU 210 of the computing device is available to perform the OPC simulation task, the computing device may initiate execution of the OPC process 221. In other implementations, verification of GPU availability can be performed as part of initiating a distributed EDA computing system or as part of an initialization sequence for an OPC flow (e.g., GPU availability verifications performed by a primary OPC process for computing devices in a distributed EDA computing system).

[0041] The OPC process 221 itself may be assigned to perform the OPC simulation task, and may have access to the OPC data for which to perform the OPC simulation task on (e.g., as communicated from the primary OPC process). In support of performing the OPC simulation task, the OPC process 221 may allocate a portion of a shared memory 310 and write the OPC data for the OPC simulation task to the allocated portion. Then, the OPC process 221 may request performance of the OPC simulation task through a GPU 210 of the computing device (or another secondary computing resource).

[0042] As described herein, the OPC process 221 may request access to the GPU 210 for performing the OPC simulation task by sending a request memory handle 320 to the lithography simulation server engine 110. The lithography simulation server engine 110 may execute a single, multi-threaded process that controls access to the GPU 210 for performance of OPC tasks. In response to receiving the request from the OPC process 221, the lithography simulation server engine 110 may initiate an execution thread to support, control, or perform the OPC simulation task of the OPC process 221. Any aspect of performing the OPC simulation task by the lithography simulation server engine 110 described in the communication timeline 400 of Figure 4 or presented herein may be performed or otherwise supported by an execution thread executed by the lithography simulation server engine 110. [0043] The lithography simulation server engine 110 may receive the request memory handle 320 from the OPC process 221 , and then access the OPC data stored in the shared memory 310 as indicated by the request memory handle 320. In some implementations, he lithography simulation server engine 110 may allocate a portion of the shared memory 310 to write simulation results to, and this allocated portion may be different, the same, or overlap in part with the portion of the shared memory 310 at which the OPC data is stored by the OPC process 221 for the OPC simulation task.

[0044] The lithography simulation server engine 110 may perform the OPC simulation task via the GPU 210 using the OPC data retrieved from the shared memory 310. During execution of the OPC simulation task, the lithography simulation server engine 110 may write the simulation results to the shared memory 310 (e.g., an allocated portion thereof). Upon completion of the OPC simulation task, the lithography simulation server engine 110 may detach its access to the shared memory 310 and send a response 330 to the OPC process 221. The response 330 may indicate the portion of the shared memory 310 at which the lithography simulation server engine 110 stored the simulation results of the OPC simulation task executed via the GPU 210. Upon receiving the response 330 from the lithography simulation server engine 110, the OPC process 221 may access the simulation results from the shared memory 310 and may also detach itself from the shared memory 310.

[0045] In any of the ways described herein, OPC processes and the lithography simulation server engine 110 may leverage shared memories to improve the efficiency and reduce (or eliminate) inter-process communication latencies for GPU executions of OPC simulation tasks.

[0046] While many of the features described herein are provided using a GPU as an example secondary computing resource, the disclosure is not so limited. The multi-OPC process resource allocation features described herein may be consistently applied for any secondary computing resource, including FPGAs, quantum processors, and the like. Likewise, OPC processes are described herein as but one example type of process for which any of the described multi- process resource allocation features can be applied to, but the present disclosure is not limited to OPC processes only. The multi-OPC process resource allocation features described herein may be consistently applied to any multi-process capability of an EDA design flow and computing devices that form a distributed computing system to execute EDA flows or perform EDA capabilities through parallel processing and distributed computing devices. [0047] Figure 5 shows an example of logic 500 that a computing device may implement to support resource allocation of a secondary computing resource for multiple OPC processes of an EDA application. In some examples, the computing device 100 may implement the logic 500 as hardware, executable instructions stored on a machine-readable medium, or as a combination of both. The computing device 100 may implement the logic 500 via the lithography simulation server engine 110, for example, through which the computing device 100 may perform or execute the logic 500 as a method to support resource allocation of a secondary computing resource for multiple OPC processes of an EDA application. The following description of the logic 500 is provided using the lithography simulation server engine 110 as an implementation example. However, various other implementation options by a system are possible.

[0048] In implementing the logic 500, the lithography simulation server engine 110 may identify a first OPC process of an EDA application to perform a first OPC simulation task (502) and identify a second OPC process of the EDA application to perform a second OPC simulation task (504). The first and second OPC processes may be assigned, initiated, or configured to be performed through a computing device that implements the lithography simulation server engine 110 (e.g., assigned to the computing device 100). The lithography simulation server engine 110 may control access to the GPU for performing the first OPC simulation task and the second OPC simulation task via a single multi-threaded process instead of allowing access to the GPU by multiple OPC processes that include the first OPC process and the second OPC process (506). For example, the lithography simulation server engine 110 may execute a lithography simulation server process as a multi-threaded process to allocate use of the GPU for performing the first OPC simulation task and the second OPC simulation task by the GPU.

[0049] While example multi-OPC process resource allocation features are shown and described through Figure 5, the logic 500 may include any number of additional or alternative steps as well. The logic 500 may additionally or alternatively implement any other multi-OPC process resource allocation features described herein, for example any with respect to the lithography simulation server engine 110.

[0050] Figure 6 shows an example of a computing device 600 that supports resource allocation of a secondary computing resource for multiple OPC processes of an EDA application. The computing device 600 may include a processor 610, which may take the form of a single or multiple processors. The processor(s) 610 may be a CPU of the computing device 600 and may include processing hardware, microprocessor, or any hardware device suitable for executing instructions stored on a machine-readable medium. The computing device 600 may include a secondary computing resource 612, which may be in the of any computing hardware different, distinct, or otherwise separate from the processor 610. For example, the secondary computing resource 612 may be a GPU, an FPGA, a quantum computing resource (e.g., a quantum processor), or any other hardware.

[0051] The computing device 600 may include a machine-readable medium 620. The machine-readable medium 620 may take the form of any non- transitory electronic, magnetic, optical, or other physical storage device that stores executable instructions, such as the lithography simulation server instructions 622 shown in Figure 6. As such, the machine-readable medium 620 may be, for example, random access memory (RAM) such as a dynamic RAM (DRAM), flash memory, spin-transfer torque memory, an electrically- erasable programmable read-only memory (EEPROM), a storage drive, an optical disk, and the like.

[0052] The computing device 600 may execute instructions stored on the machine-readable medium 620 through the processor 610. Executing the instructions may cause the computing device 600 to perform any of the multi- OPC process resource allocation features described herein, including according to any of the features of the lithography simulation server engine 110. For example, execution of the lithography simulation server instructions 622 by the processor 610 may cause the computing device 600 to identify a first OPC process of an EDA application to perform a first OPC simulation task through the computing device 600 as well as identify a second OPC process of the EDA application to perform a second OPC simulation task through the computing device 600. Execution of the lithography simulation server instructions 622 by the processor 610 may also cause the computing system 600 to control access to the secondary computing resource 612 for performing the first OPC simulation task and the second OPC simulation task via a single multi-threaded process, instead of allowing access to the secondary computing resource 612 by multiple OPC processes that include the first OPC process and the second OPC process, which may be include allocating use of the secondary computing resource 612 for performing the first OPC simulation task and the second OPC simulation task.

[0053] While some example features are described in Figure 6, the lithography simulation server instructions 622 may implement any combination of the features described herein.

[0054] The systems, methods, devices, and logic described above, including the computing device 100, OPC processes, and lithography simulation server engine 110, may be implemented in many different ways in many different combinations of hardware, logic, circuitry, and executable instructions stored on a machine-readable medium. For example, the lithography simulation server engine 110, computing device 100, CPU 106, secondary computing resource 108, or any combination thereof, may include circuitry in a controller, a microprocessor, or an application specific integrated circuit (ASIC), or may be implemented with discrete logic or components, or a combination of other types of analog or digital circuitry, combined on a single integrated circuit or distributed among multiple integrated circuits. A product, such as a computer program product, may include a storage medium and machine readable instructions stored on the medium, which when executed in an endpoint, computer system, or other device, cause the device to perform operations according to any of the description above, including according to any features of the lithography simulation server engine 110.

[0055] The processing capability of the systems, devices, and engines described herein, including the lithography simulation server engine 110, may be distributed among multiple system components, such as among multiple processors and memories, optionally including multiple distributed processing systems or cloud/network elements. Parameters, databases, and other data structures may be separately stored and managed, may be incorporated into a single memory or database, may be logically and physically organized in many different ways, and may be implemented in many ways, including data structures such as linked lists, hash tables, or implicit storage mechanisms. Programs may be parts (e.g., subroutines) of a single program, separate programs, distributed across several memories and processors, or implemented in many different ways, such as in a library (e.g., a shared library).

[0056] While various examples have been described above, many more implementations are possible.