Method, electronic device and storage medium for optical proximity correction

Abstract

A method, an electronic device and a storage medium for optical proximity correction are disclosed. The method comprises determining priorities of a plurality of tasks for a layout in response to receiving information of the plurality of tasks. Each of the plurality of tasks is divided into a plurality of subtasks, each of the plurality of subtasks respectively corresponding to a physical location range on the layout. A dependency relationship between a subsequent subtask in a subsequent priority task and an anterior subtask in an anterior priority task is determined, and a determination result is obtained. The dependency relationship indicates that the execution of the subsequent subtask depends on the execution state of the anterior subtask corresponding to the same physical range on the layout. Based on the determination result, the execution of the subsequent subtask is scheduled. The embodiments of the present disclosure can improve the ease of use of user operation and the efficiency of task execution.

Description

Technical Field

[0001] The embodiments of this disclosure are primarily related to the field of semiconductor manufacturing technology, and more specifically, to methods, electronic devices, and computer-readable storage media for optical proximity correction. Background Technology

[0002] As wafer fabrication processes continue to evolve, the density and complexity of masks are also constantly increasing. Generally, the computational engine for Optical Proximity Correction (OPC) uses distributed processing to decompose the task into a set of subtasks for execution, and finally merges the subtasks into a final execution result. For example, a typical OPC correction task might be divided into hundreds of thousands of subtasks, running on thousands of CPUs, with a total runtime potentially reaching tens of hours.

[0003] OPC computing engines typically execute different types of tasks based on the user's configuration. If a set of tasks has input-output dependencies, a strict logical sequential timing must be maintained. This requires the user to pay extra attention to the input-output relationships between successive tasks. Furthermore, because tasks must maintain a strict logical sequential timing, the overall task execution time can become excessively long. Summary of the Invention

[0004] According to an example embodiment of this disclosure, an improved scheme for optical proximity correction is provided.

[0005] In a first aspect of this disclosure, a method for optical proximity correction is provided. The method includes: in response to receiving information about multiple tasks for a layout, determining the priorities of the multiple tasks; dividing each of the multiple tasks into multiple subtasks, each subtask corresponding to a physical location range on the layout; determining a dependency relationship between a later subtask in a later-priority task and a earlier subtask in a earlier-priority task, obtaining a determination result, the dependency relationship indicating that the execution of a later subtask depends on the execution state of an earlier subtask within the same physical range on the corresponding layout; and scheduling the execution of the later subtask based on the determination result.

[0006] In a second aspect of this disclosure, an electronic device is provided. The electronic device includes a processor and a memory coupled to the processor, the memory having instructions stored therein, the instructions causing the device to perform actions when executed by the processor. The actions include: in response to receiving information about a plurality of tasks for a layout, determining the priorities of the plurality of tasks; dividing each of the plurality of tasks into a plurality of subtasks, each subtask corresponding to a physical location range on the layout; determining the dependencies between a later subtask in a later-priority task and a earlier subtask in a earlier-priority task, obtaining a determination result, the dependency indicating that the execution of a later subtask depends on the execution state of an earlier subtask within the same physical range on the corresponding layout; and scheduling the execution of the later subtask based on the determination result.

[0007] In some embodiments, the action further includes: determining the business logic configuration of the plurality of tasks; and reading the business logic configuration of the plurality of tasks into memory space, such that the business logic configuration of the plurality of tasks is in the same process during the execution of the plurality of tasks.

[0008] In some embodiments, determining the priority of multiple tasks includes determining the priority of multiple tasks based on the process sequence corresponding to each task among the multiple tasks.

[0009] In some embodiments, dividing each of the multiple tasks into multiple subtasks includes: dividing the layout into a cell matrix; and making the area processed by each subtask of each of the multiple tasks correspond one-to-one with the physical location range of a cell in the cell matrix.

[0010] In some embodiments, determining the dependency between a subsequent subtask in a later-priority task and a preceding subtask in a earlier-priority task includes: determining whether the execution of the subsequent subtask depends on whether a preceding subtask corresponding to the same physical extent on the layout has been completed; and if the preceding subtask has not been completed, determining that there is a dependency between the subsequent subtask and the preceding subtask.

[0011] In some embodiments, the method further includes updating the state of the preceding subtask after each preceding subtask has been completed.

[0012] In some embodiments, scheduling the execution of a subsequent subtask based on a determination result includes: if the determination result indicates that the subsequent subtask does not depend on the preceding subtask, instructing the execution of the subsequent subtask to begin; and if the determination result indicates that the subsequent subtask depends on the preceding subtask, instructing the subsequent subtask to wait for the completion of the preceding subtask.

[0013] In some embodiments, the action further includes: storing the execution result of the preceding subtask into disk space; and, if the subsequent subtask depends on the preceding subtask, executing the subsequent subtask based on the execution result stored in disk space.

[0014] In a third aspect of this disclosure, a computer-readable storage medium is provided having a computer program stored thereon that, when executed by a processor, implements the method according to a first aspect of this disclosure.

[0015] It should be understood that the description in the Summary of the Invention is not intended to limit the key or essential features of the embodiments of this disclosure, nor is it intended to restrict the scope of this disclosure. Other features of this disclosure will become readily apparent from the following description. Attached Figure Description

[0016] The above and other features, advantages, and aspects of the embodiments of this disclosure will become more apparent from the accompanying drawings and the following detailed description. In the drawings, the same or similar reference numerals denote the same or similar elements, wherein:

[0017] Figure 1 A flowchart of a typical OPC multi-level application example is shown;

[0018] Figure 2 A schematic diagram of an example environment in which embodiments of the present disclosure can be implemented is shown;

[0019] Figure 3 A flowchart of a method for optical proximity correction according to some embodiments of the present disclosure is shown;

[0020] Figure 4 A schematic diagram of the architecture of a fine-grained dependency manager according to some embodiments of the present disclosure is shown;

[0021] Figure 5 A schematic diagram of the architecture of an OPC computing engine according to some embodiments of the present disclosure is shown; and

[0022] Figure 6 A block diagram of a computing device capable of implementing several embodiments of the present disclosure is shown. Detailed Implementation

[0023] Embodiments of this disclosure will now be described in more detail with reference to the accompanying drawings. While some embodiments of this disclosure are shown in the drawings, it should be understood that this disclosure can be implemented in various forms and should not be construed as limited to the embodiments set forth herein. Rather, these embodiments are provided to provide a more thorough and complete understanding of this disclosure. It should be understood that the accompanying drawings and embodiments of this disclosure are for illustrative purposes only and are not intended to limit the scope of protection of this disclosure.

[0024] In the description of embodiments of this disclosure, the term "comprising" and similar terms should be understood as open-ended inclusion, i.e., "including but not limited to". The term "based on" should be understood as "at least partially based on". The term "one embodiment" or "the embodiment" should be understood as "at least one embodiment". The terms "first", "second", etc., may refer to different or the same objects. Other explicit and implicit definitions may also be included below.

[0025] The OPC process flow includes multiple steps. It can be broadly divided into: the OPC preprocessing stage, such as defining an ideal wafer lithography imaging target to meet etching process requirements; the OPC stage, where mask adjustments are made through modeling and simulation to continuously approximate the imaging effect of the lithography system towards the ideal wafer lithography imaging target; and the OPC post-processing stage, which typically involves cross-validating the OPC results from other perspectives.

[0026] A typical OPC computing engine design is usually intended to handle only one type of job at runtime, with different job tasks chained together via scripts or manual methods. As briefly mentioned above, because tasks need to maintain a strict logical sequential order, the overall task execution time can be excessively long.

[0027] Figure 1 A flowchart 100 illustrates a typical OPC multi-level application example. (For example...) Figure 1 As shown, it contains three jobs, JOB0', JOB1', and JOB2', which can also be called three tasks, denoted by J0', J1', and J2' respectively. For each job, the user starts a corresponding OPC engine (one of OPC engine 0', OPC engine 1', and OPC engine 2') through the business logic (Recipe) to execute the user-defined business logic. The business logic can be understood as multiple processing rules, some different and some the same. In the actual business logic, the later-level task needs to use the output of the previous (or more)-level task as input or reference. That is, the later-level task can only be executed after the previous (or more)-level tasks have been completed. Therefore, the total execution time of these three tasks is equal to the sum of the individual times of the three tasks.

[0028] Furthermore, from an overall perspective, JOB0', JOB1', and JOB2' need to maintain strict sequential execution, and users need to ensure the input and output relationships between preceding and subsequent tasks. Therefore, different job tasks need to be chained together by the user through scripts or manual methods. For example, the priority or execution order of each task can be specified by manually clicking on the task or by using additional program execution parameters. For instance, specifying that JOB0' executes first, followed by JOB1', and finally JOB2'.

[0029] The above approach has the following drawbacks: OPC tasks typically require distributed processing, so computing power is distributed across different computers. Therefore, data interaction can only occur through disk files, and the running speed is affected by file system performance (disk I / O, network drive speed). Furthermore, communication between tasks relies on disk interaction, requiring users to pay extra attention to input and output, thus reducing usability. Moreover, subtasks exhibit locality of reference; some subtasks run quickly, while others run slowly, potentially causing significant delays in the overall task's execution time due to the actions of a few subtasks.

[0030] Therefore, an improved approach is needed to enhance user-friendliness and reduce task processing time.

[0031] According to embodiments of this disclosure, a scheme for optical proximity correction is proposed. In this scheme, in response to receiving information about multiple tasks for a layout, the priorities of the multiple tasks are determined. Each of the multiple tasks is divided into multiple subtasks, each subtask corresponding to a corresponding portion of the layout. The dependencies between subsequent subtasks in a later-priority task and preceding subtasks in a earlier-priority task are determined, obtaining a determination result, whereby the execution of a later subtask depends on the execution state of a preceding subtask within the same physical extent on the corresponding layout. Based on the determination result, the execution of the later subtask is scheduled.

[0032] This solution divides tasks into multiple subtasks and optimizes the execution time of subsequent subtasks based on their execution status and dependencies. This transforms sequentially executed tasks into at least partially parallel ones, significantly improving task execution efficiency. Furthermore, users do not need to worry about switching between tasks, greatly enhancing ease of use.

[0033] The embodiments of this disclosure will now be described in detail with reference to the accompanying drawings. (See attached figures) Figure 2 This illustrates a schematic diagram of an example environment 200 in which various embodiments of the present disclosure can be implemented. For example... Figure 2 As shown, example environment 200 includes computing device 210 and client 220.

[0034] In some embodiments, the computing device 210 can interact with the client 220. For example, the computing device 210 can receive input messages from the client 220 and output feedback messages to the client 220. In some embodiments, the input messages from the client 220 can specify tasks to be processed. The computing device 210 can process the tasks specified in the input messages. In some embodiments, the computing device 210 can send control messages to the client 220 to control the client 220 to execute tasks. For example, the computing device 210 can assign tasks to be processed to the client 220 for execution and receive execution results from the client 220.

[0035] In some embodiments, computing device 210 may include, but is not limited to, personal computers, server computers, handheld or laptop devices, mobile devices (such as mobile phones, personal digital assistants (PDAs), media players, etc.), consumer electronics, minicomputers, mainframe computers, cloud computing resources, etc. In some embodiments, client 220 may also include, but is not limited to, personal computers, server computers, handheld or laptop devices, mobile devices (such as mobile phones, personal digital assistants (PDAs), media players, etc.), consumer electronics, minicomputers, mainframe computers, cloud computing resources, etc.

[0036] It should be understood that the description of the structure and functionality of example environment 200 for illustrative purposes only is not intended to limit the scope of the topics described herein. The topics described herein may be implemented in different structures and / or functionalities.

[0037] The technical solutions described above are for illustrative purposes only and are not intended to limit the invention. It should be understood that the example environment 200 can also have many other implementations. To more clearly explain the principles of this disclosure, reference will be made below. Figure 3 Let me describe it in more detail.

[0038] Figure 3 A flowchart of a method for optical proximity correction according to some embodiments of the present disclosure is shown. For example, method 300 may be performed by, for example... Figure 2 The computing device 210 shown is used for implementation. The following is in conjunction with... Figure 4 and Figure 5 Let's describe method 300. Figure 4 A schematic diagram of the architecture of a fine-grained dependency manager according to some embodiments of the present disclosure is shown. Figure 5 A schematic diagram of the architecture of an OPC computing engine according to some embodiments of the present disclosure is shown. It should be understood that method 300 may also include additional boxes not shown and / or certain boxes shown may be omitted. The scope of the present disclosure is not limited in this respect.

[0039] At box 302, in response to receiving information about multiple tasks for the layout, the priority of the multiple tasks is determined. In some embodiments, input information from an external source may be received, specifying the task to be performed. For example, a task to process the layout. The input information can be entered in various ways. For example, it can be entered by receiving a message, or by receiving a file, etc. The embodiments of this disclosure are not limited thereto. Each job or task has corresponding business logic. The business logic can specify what kind of processing to perform on the task, how to perform the processing, etc. For example, the business logic can specify to rotate the layout by 90 degrees and cut it into cells with a size of 10nm by 10nm. As another example, the business logic can specify to stretch a square by 5nm on each side, then rotate it by 90 degrees, and then calculate its area. Here, "stretching the square" and "stretching the left and right sides by 5nm" are the business logic, which can also be called business rules. The 5nm and 90nm can be called the business logic configuration. That is, the configuration of a set of operations that the user wants to perform. Performing the corresponding actions according to the above rules can be called a job or task. For example, performing the stretching action described above can be called job or task JOB0. Rotating by 90 degrees can be called JOB1. Calculating the area of ​​the rectangle can be called job or task JOB2. In some embodiments, tasks can be executed by an OPC engine. The engine typically resides on multiple computers. As mentioned earlier, a typical OPC correction task is divided into hundreds of thousands of subtasks, running on thousands of CPUs.

[0040] In some embodiments, the user receives an input file, such as information about a task to be performed. The user can specify rules, i.e., specify business logic. The engine can then execute corresponding actions to perform the task. In some embodiments of this disclosure, the business logic corresponding to each process (job) or task is visible to the schedulers of other processes. For example, in some embodiments, the scheduler can be a software-implemented application. The business logic of all jobs is visible to each level of scheduler. Therefore, each level of scheduler can know the business logic of other jobs, thereby enabling reasonable scheduling of the execution of subtasks.

[0041] In some embodiments, users can specify the processing order, or priority, of multiple tasks as needed. In some embodiments, the priority can also be specified by the manager.

[0042] In some embodiments, the business logic configurations of the plurality of tasks can be determined from the input information. Furthermore, the business logic configurations of the plurality of tasks can be read into memory, such that the business logic configurations of the plurality of tasks reside in the same process during the execution of the plurality of tasks. The execution state of each subtask is stored in memory. For example, one business logic configuration is stored at addresses 1 to 10000, another at addresses 20000 to 3000, and yet another at addresses 4000 to 50000. Of course, this is merely exemplary, and the solutions disclosed herein are not limited thereto.

[0043] In a typical OPC process, the business logic between tasks is transparent, i.e., agnostic. Subsequent tasks are unaware of and unconcerned about the specific business logic of preceding tasks. Therefore, the execution of each task resides in a different process. Furthermore, as mentioned earlier, data between different tasks typically resides on different nodes (e.g., computers, handheld devices, etc.), so data association can only be achieved through disk files, impacting execution speed due to disk I / O performance. Moreover, communication between tasks via hard drive interaction requires the user to pay extra attention to task input / output. This means the user needs to manage dependencies, resulting in poor usability. Additionally, data interaction takes a considerable amount of time. However, in some embodiments of this disclosure, by reading the business logic configurations of multiple tasks into memory, the business logic configurations of multiple tasks reside in the same process during the execution of multiple tasks, eliminating the need for the user to monitor task switching. Furthermore, reading information from memory is much faster than interacting with information via disk files. In this way, during the execution of a subsequent task, the execution status of the preceding task can be ascertained, and any dependencies between them can be determined. Based on this, the execution of different tasks can be rationally scheduled. In other words, the execution of a later task is not limited to after the completion of a previous task. This can significantly improve the execution efficiency of multiple tasks and greatly save execution time.

[0044] In some embodiments, the priority of multiple tasks is determined based on the process sequence corresponding to each task within the multiple tasks. In some embodiments, the user can specify other priorities or execution orders according to actual needs.

[0045] At box 304, each of the multiple tasks is divided into multiple subtasks. Each subtask corresponds to a specific portion of the layout. For example, see... Figure 4 , Figure 4A schematic diagram of the architecture 400 of a fine-grained dependency manager according to some embodiments of the present disclosure is shown. 402 is a view of task JOB0, which generally corresponds to a layout. The diagram shows four subtasks t00-t03, each corresponding to a square (cell) in the task view. In some embodiments, after dividing each of multiple tasks into multiple subtasks, the execution time of subsequent subtasks can be determined by identifying the dependencies between subsequent subtasks in a later-priority task and preceding subtasks in a earlier-priority task, thereby optimizing task execution.

[0046] In some embodiments, dividing each of the multiple tasks into multiple subtasks includes making the regions processed by each subtask of each of the multiple tasks correspond one-to-one with the physical location range of a cell region in the cell matrix.

[0047] The following is combined with Figure 4 This can be described further. For example... Figure 4 As shown, as mentioned earlier, 402 is the view of task JOB0, which generally corresponds to the layout. It shows four subtasks t00-t03, each corresponding to a cell in this task view. Similarly, 404 is the view of task JOB1, which also generally corresponds to the layout. For example, a subtask t1-0 of JOB1 corresponds to a cell in this task view, representing the physical location of a single cell area. The cell corresponding to subtask t1-0 of JOB1 is physically within the same area as the cells corresponding to the four subtasks t00-t03 in the view of JOB0. In other words, the area on the layout processed by subtask t1-0 is the same area on the layout processed by the four subtasks t00-t03. In the embodiment shown, although the cell sizes of view 402 of JOB0 and view 404 of JOB1 are different, for each task, each subtask corresponds one-to-one to a physical location range on the layout, i.e., a specific cell within it.

[0048] See you again Figure 4Here, 404 represents the view of task JOB1, which corresponds to the overall layout. For example, a subtask t1-0 of JOB1 corresponds to a cell in this task view. 408 represents the layout view; views 402 of JOB0 and 404 of JOB1 both correspond to layout view 408. In other words, the layout view is visible to all tasks, and each subtask corresponds to a predetermined physical area on the layout. For example, as mentioned earlier, a subtask t1-0 of JOB1 corresponds to a cell in this task view. The four subtasks t00-t03 in the view of JOB0 correspond to a submatrix composed of four cells in this task view. The two subtasks mentioned above correspond to the same physical area on the layout.

[0049] In this way, by making one or more of the subsequent subtasks correspond to the same physical area as one or more of the preceding subtasks—specifically, dividing the layout into a matrix of cells, and ensuring that the area processed by each subtask of each task corresponds one-to-one with the physical location range of a cell region in the matrix—the execution status of the preceding subtasks corresponding to the same physical area can be queried before the execution of the subsequent subtask, thereby determining when the execution of the subsequent subtask can begin. This transforms the overall sequential execution of tasks into the sequential execution of local subtasks and the parallel execution of all tasks as a whole.

[0050] At box 306, the dependencies between subsequent subtasks in a later-priority task and preceding subtasks in a earlier-priority task are determined, thereby obtaining the determination result. The dependency indicates that the execution of a later subtask depends on the execution state of an preceding subtask within the same physical scope on the corresponding layout. In a typical OPC flow, the execution of each task is simply a sequential execution, without considering task subdivision or the dependencies between the subdivided subtasks. In some embodiments of this disclosure, by subdividing tasks into subtasks and determining the dependencies between subsequent subtasks in a later-priority task and preceding subtasks in an earlier-priority task, the execution order of tasks can be optimized, and execution efficiency improved.

[0051] In some embodiments, determining the dependency between a subsequent subtask in a later-priority task and a preceding subtask in a earlier-priority task includes determining whether a preceding subtask corresponding to the same physical extent on the layout as the subsequent subtask has been completed. If the preceding subtask has not been completed, it is determined that the subsequent subtask and the preceding subtask have a dependency. In some embodiments, the status of preceding subtasks can be queried from the fine-grained dependency manager 406, wherein the scheduler can update the status of the subtasks to the fine-grained dependency manager 406 after each preceding subtask has been completed. In some embodiments, after each preceding subtask has been completed, the scheduler also notifies the fine-grained dependency manager 406 where the execution results are stored.

[0052] The following is for reference Figure 5 The operation of the scheduler and fine-grained dependency manager is described in further detail. Figure 5 A schematic diagram of the architecture 500 of an OPC computing engine according to some embodiments of the present disclosure is shown. Figure 5 As shown, user 502 and OPC engine 504 are illustrated. OPC engine 504 may include a fine-grained dependency manager 406 and schedulers 0, 1, and 2. Three tasks are also shown in the diagram: JOB0, JOB1, and JOB2. Each task has a corresponding scheduler, namely scheduler 0, scheduler 1, and scheduler 2.

[0053] Task JOB0, having the highest priority, does not depend on any other tasks and can be executed directly. Each completed subtask is reported to the fine-grained dependency manager 406. The fine-grained dependency manager 406 can update the status of that subtask. In some embodiments, the status of each subtask within each task can be stored in memory as a matrix. As subtasks execute, the status of each subtask in the matrix is ​​continuously updated (as shown by arrow S0). For example, the completed status is updated to 1, and the incomplete status remains 0. The storage method for subtasks here is merely exemplary, and the method disclosed herein is not limited to this; various variations are possible. For JOB1, since its priority is lower than JOB0, some of its subtasks may depend on subtasks in JOB0. Therefore, before execution, scheduler 1 needs to query whether it depends on the execution of a corresponding subtask in JOB0; specifically, it can query whether the preceding subtask has been completed. For example, as... Figure 5As shown, before scheduling subtask t1-0 to execute, JOB1 checks if the preceding subtasks corresponding to t1-0 (i.e., t0-0 to t0-3 on JOB0) have dependencies, i.e., it checks their execution status. If there are dependencies (i.e., they haven't finished executing), scheduler 0 can notify (as shown by arrow S1) that the subsequent subtask should be postponed until the preceding subtasks t0-0 to t0-3 have finished executing. If these dependent subtasks have already finished executing, then scheduler 1 of JOB1 can confirm that t1-0 can be executed. Furthermore, after the preceding subtasks t0-0 to t0-3 have finished executing, scheduler 1 can notify (as shown by arrow S1) that the subsequent subtask can now be executed. After the subsequent subtask of JOB1 has finished executing, it also updates the execution status of that subtask to the fine-grained dependency manager 406. Figure 4 As can be seen, S1 is a bidirectional arrow, indicating that the interaction between scheduler 1 and fine-grained dependency manager 406 is bidirectional. It can both query the status and notify the execution of the subtask, and update the execution status.

[0054] Similar to JOB1, before JOB2 is executed, scheduler 2 needs to check whether it depends on subtasks in JOB0 and JOB1 at corresponding positions, i.e., check the execution status of the preceding subtask. If there is a dependency, scheduler 2 can notify (as shown by arrow S2) that the subsequent subtask is temporarily suspended, waiting for the preceding subtask, such as JOB0 and / or JOB1, to complete. After the preceding subtask has completed, scheduler 2 can notify (as shown by arrow S2) that the subsequent subtask can now be executed. Since JOB2 is the lowest priority task, there is no need to update the execution status of its subtasks to the fine-grained dependency manager 406 after their subtasks have completed. In this way, users can define only the execution order without worrying about dependencies, thereby improving usability. Furthermore, dependencies can be determined by the scheduler, and by working together with the fine-grained dependency manager 406, the execution order of subtasks can be optimized, improving execution efficiency.

[0055] At box 308, the execution of subsequent subtasks is scheduled based on the determination result. In some embodiments, scheduling the execution of subsequent subtasks based on the determination result includes: if the determination result indicates that the subsequent subtask does not depend on the preceding subtask, then instructing the execution of the subsequent subtask to begin. If the determination result indicates that the subsequent subtask depends on the preceding subtask, then the subsequent subtask may be instructed to wait for the preceding subtask to complete. After the subtasks in each task have completed execution, the subtasks can be combined to form a complete task output.

[0056] As mentioned above Figure 4As illustrated in the diagram, based on a determined outcome, the scheduler can instruct subsequent subtasks to be postponed or can be executed. In other words, the scheduler can perform functions such as querying status, distributing tasks, and coordinating the execution time of subtasks. In some embodiments, the scheduler corresponding to each task can schedule a corresponding engine to execute each task. The corresponding engines can reside on the same computing device (e.g., a computer) or on different computing devices.

[0057] In some embodiments, the method further includes storing the execution result of the preceding subtask to a file (e.g., a disk or network drive) or disk space. Furthermore, if a subsequent subtask depends on the preceding subtask, the subsequent subtask is executed based on the execution result.

[0058] In some embodiments, such as those mentioned earlier, the business logic may specify rotating the layout by 90 degrees and cutting it into cells with a size of 10nm by 10nm. The OPC engine can perform rotation and cutting according to the program settings, forming subtasks of individual JOBs. After a subtask is completed, the corresponding processing result is stored in an area, such as disk space, and is retrieved by other JOBs through the fine-grained dependency manager 406 for use in other dependent subtasks.

[0059] The above embodiments are merely illustrative, and the embodiments disclosed herein are not limited to the above embodiments, but can have various variations.

[0060] In some embodiments of this disclosure, by introducing a fine-grained dependency manager and a scheduler, parallel processing can be achieved to manage the subtask dependencies between different processes (tasks). The fine-grained dependency manager can be designed primarily based on the following three task execution characteristics: 1. The global view of the OPC landscape seen by different processes. Figure 1 1. The job is divided into a set of subtasks based on preset physical dimensions (e.g., user-defined or OPC-defined for other reasons). 2. The dependencies between subtasks in different processes are limited to the same physical scope. Based on these three points, a new OPC engine architecture can be implemented: the scheduler updates the status of completed subtasks to the fine-grained dependency manager. The scheduler queries whether the preceding subtasks that the subtask to be executed depends on have been completed. Based on this, task execution can be optimized and execution efficiency improved.

[0061] In some embodiments of this disclosure, a fine-grained dependency manager is used to break down the overall dependencies between jobs into local dependencies at the subtask level. Multiple jobs are configured simultaneously, and their priority order is determined according to the characteristics of distributed tasks, improving user-friendliness and efficiency. The fine-grained dependency manager refines dependencies to the subtask level, thereby achieving runtime job-level parallelism. Furthermore, the engine can simultaneously obtain configurations for different jobs without requiring users to explicitly focus on the details of task switching, further enhancing usability.

[0062] In some embodiments of this disclosure, the pipelined OPC distributed computing engine design combines multiple jobs into a pipeline, with each job serving as a step in the pipeline. Users only need to configure the business logic for different steps, and the OPC engine creates an independent subtask scheduler for each step. The business logic configuration corresponding to each step is visible to the schedulers of other steps, so users no longer need to worry about the switching logic between steps. Because multiple sets of logic are visible to different step schedulers, data interaction between steps can be completed through memory interaction. Therefore, from an overall perspective, there is no longer a clear sequential relationship between steps, and the execution dependencies of subtasks in each step can be independently distributed based on the inspection results of the fine-grained dependency manager. Thus, the actual runtime effect is a parallel pipeline.

[0063] In embodiments of this disclosure, the dependencies between subtasks remain transparent to the user; that is, each business logic is aware of its interdependencies, thereby enabling serial processing to be converted into parallel processing. This also simplifies user configuration and improves usability.

[0064] This application can also provide a unified implementation framework for other features, while being compatible with situations where there are global serial dependencies between jobs. As long as a task is abstracted into a process and placed in an appropriate position in the pipeline, the engine can automatically trigger its execution according to dependency rules.

[0065] The embodiments of this disclosure are described using three JOBs as an example. However, the embodiments of this disclosure are not limited to this, but can be any other number of JOBs, such as hundreds of thousands of JOBs.

[0066] Figure 6A schematic block diagram of an example device 600 that can be used to implement embodiments of the present disclosure is shown. For example, the electronic device of the present disclosure can be implemented by device 600. As shown, device 600 includes a central processing unit (CPU) 601, which can perform various appropriate actions and processes according to computer program instructions stored in read-only memory (ROM) 602 or loaded from storage unit 608 into random access memory (RAM) 603. Various programs and data required for the operation of device 600 may also be stored in RAM 603. CPU 601, ROM 602, and RAM 603 are interconnected via bus 604. Input / output (I / O) interface 605 is also connected to bus 604.

[0067] Multiple components in device 600 are connected to I / O interface 605, including: input unit 606, such as keyboard, mouse, etc.; output unit 607, such as various types of monitors, speakers, etc.; storage unit 608, such as disk, optical disk, etc.; and communication unit 609, such as network card, modem, wireless transceiver, etc. Communication unit 609 allows device 600 to exchange information / data with other devices through computer networks such as the Internet and / or various telecommunications networks.

[0068] Processing unit 601 performs the various methods and processes described above, such as method 300. For example, in some embodiments, method 300 may be implemented as a computer software program tangibly contained in a machine-readable medium, such as storage unit 608. In some embodiments, part or all of the computer program may be loaded and / or installed on device 600 via ROM 602 and / or communication unit 609. When the computer program is loaded into RAM 603 and executed by CPU 601, one or more steps of method 300 described above may be performed. Alternatively, in other embodiments, CPU 601 may be configured to execute method 300 by any other suitable means (e.g., by means of firmware).

[0069] The functions described above in this document can be performed at least in part by one or more hardware logic components. For example, exemplary types of hardware logic components that can be used, without limitation, include: field programmable gate arrays (FPGAs), application-specific integrated circuits (ASICs), application-specific standard products (ASSPs), systems-on-a-chip (SoCs), payload programmable logic devices (CPLDs), and so on.

[0070] The program code used to implement the methods of this disclosure may be written in any combination of one or more programming languages. This program code may be provided to a processor or controller of a general-purpose computer, special-purpose computer, or other programmable data processing apparatus, such that when executed by the processor or controller, the program code causes the functions / operations specified in the flowcharts and / or block diagrams to be implemented. The program code may be executed entirely on a machine, partially on a machine, as a standalone software package partially on a machine and partially on a remote machine, or entirely on a remote machine or server.

[0071] In the context of this disclosure, a machine-readable medium can be a tangible medium that may contain or store a program for use by or in conjunction with an instruction execution system, apparatus, or device. A machine-readable medium can be a machine-readable signal medium or a machine-readable storage medium. A machine-readable medium can be, but is not limited to, electronic, magnetic, optical, electromagnetic, infrared, or semiconductor systems, apparatus, or devices, or any suitable combination of the foregoing. More specific examples of machine-readable storage media include electrical connections based on one or more wires, portable computer disks, hard disks, random access memory (RAM), read-only memory (ROM), erasable programmable read-only memory (EPROM or flash memory), optical fiber, portable compact disk read-only memory (CD-ROM), optical storage devices, magnetic storage devices, or any suitable combination of the foregoing.

[0072] Furthermore, although the operations are described in a specific order, this should be understood as requiring that such operations be performed in the specific order shown or in sequential order, or requiring that all illustrated operations be performed to achieve the desired result. In certain environments, multitasking and parallel processing may be advantageous. Similarly, although several specific implementation details are included in the above discussion, these should not be construed as limiting the scope of this disclosure. Certain features described in the context of individual embodiments may also be implemented in combination in a single implementation. Conversely, various features described in the context of a single implementation may also be implemented individually or in any suitable sub-combination in multiple implementations.

[0073] Although the subject matter has been described using language specific to structural features and / or methodological logic, it should be understood that the subject matter defined in the appended claims is not necessarily limited to the specific features or actions described above. Rather, the specific features and actions described above are merely illustrative examples of implementing the claims.

Claims

1. A method for optical proximity correction, comprising: In response to receiving information about multiple tasks related to the layout, the priority of the multiple tasks is determined; Each of the multiple tasks is divided into multiple sub-tasks, and each of the multiple sub-tasks corresponds to a physical location range on the map. Determine the dependency relationship between a subsequent subtask in a later priority task and a preceding subtask in a earlier priority task, and obtain a determination result. The dependency relationship indicates that the execution of the subsequent subtask depends on the execution status of the preceding subtask in the same physical range on the corresponding layout. as well as Based on the determination result, scheduling the execution of the subsequent subtask specifically includes: if the determination result indicates that the subsequent subtask does not depend on the preceding subtask, then instructing the execution of the subsequent subtask to begin; Specifically, before the execution of the subsequent subtask, the execution status of the preceding subtask corresponding to the same physical range is queried to determine when the execution of the subsequent subtask can begin.

2. The method according to claim 1, further comprising: Determine the business logic configuration for the multiple tasks; as well as The business logic configurations of the multiple tasks are read into the memory space, so that the business logic configurations of the multiple tasks are in the same process during the execution of the multiple tasks.

3. The method of claim 1, wherein determining the priority of the plurality of tasks comprises: The priority of the multiple tasks is determined based on the process sequence corresponding to each task.

4. The method of claim 1, wherein dividing each of the plurality of tasks into a plurality of subtasks comprises: The map is divided into a cell matrix; as well as The regions processed by each subtask of each of the multiple tasks are respectively mapped one-to-one to the physical location range of a cell region in the cell matrix.

5. The method of claim 1, wherein determining the dependency relationship between a later subtask in a later priority task and a earlier subtask in a earlier priority task comprises: Determine whether the preceding subtask, which corresponds to the same physical extent on the layout as the subsequent subtask, has been completed. as well as If the preceding subtask has not been completed, it is determined that the subsequent subtask has a dependency relationship with the preceding subtask.

6. The method of claim 1, further comprising: After each preceding subtask is completed, the status of the preceding subtask is updated.

7. The method according to claim 1, wherein scheduling the execution of the subsequent subtask based on the determination result further comprises: If the determination result indicates that the subsequent subtask depends on the preceding subtask, then the subsequent subtask is instructed to wait for the preceding subtask to complete.

8. The method of claim 1, further comprising: Store the execution results of the preceding subtasks into disk space; as well as In cases where the subsequent subtask depends on the preceding subtask, the subsequent subtask is executed based on the execution result stored in the disk space.

9. An electronic device, comprising: processor; as well as A memory coupled to the processor, the memory having instructions stored therein, the instructions causing the device to perform actions when executed by the processor, the actions including: In response to receiving information about multiple tasks related to the layout, the priority of the multiple tasks is determined; Each of the multiple tasks is divided into multiple sub-tasks, and each of the multiple sub-tasks corresponds to a physical location range on the map. Determine the dependencies between subsequent subtasks in a lower-priority task and preceding subtasks in a higher-priority task, obtaining a determination result. The dependency relationship indicates that the execution of the subsequent subtask depends on the execution state of the preceding subtask within the same physical region of the corresponding task on the layout. Based on the determination result, scheduling the execution of the subsequent subtask specifically includes: if the determination result indicates that the subsequent subtask does not depend on the preceding subtask, then instructing the execution of the subsequent subtask to begin; Specifically, before the execution of the subsequent subtask, the execution status of the preceding subtask corresponding to the same physical range is queried to determine when the execution of the subsequent subtask can begin.

10. The electronic device of claim 9, wherein the action further comprises: Determine the business logic configuration for the multiple tasks; as well as The business logic configurations of the multiple tasks are read into the memory space, so that the business logic configurations of the multiple tasks are in the same process during the execution of the multiple tasks.

11. The electronic device of claim 9, wherein determining the priority of the plurality of tasks comprises: The priority of the multiple tasks is determined based on the process sequence corresponding to each task.

12. The electronic device of claim 9, wherein dividing each of the plurality of tasks into a plurality of subtasks comprises: The map is divided into a cell matrix; as well as The regions processed by each subtask of each of the multiple tasks are respectively mapped one-to-one to the physical location range of a cell region in the cell matrix.

13. The electronic device of claim 9, wherein determining the dependency relationship between a subsequent subtask in a later-priority task and a preceding subtask in a earlier-priority task comprises: Determine whether the preceding subtask, which corresponds to the same physical extent on the layout as the subsequent subtask, has been completed. as well as If the preceding subtask has not been completed, it is determined that the subsequent subtask has a dependency relationship with the preceding subtask.

14. The electronic device of claim 9, wherein the action further comprises: After each preceding subtask is completed, the status of the preceding subtask is updated.

15. The electronic device of claim 9, wherein scheduling the execution of the subsequent subtask based on the determination result further comprises: If the determination result indicates that the subsequent subtask depends on the preceding subtask, then the subsequent subtask is instructed to wait for the preceding subtask to complete.

16. The electronic device of claim 9, wherein the action further comprises: Store the execution results of the preceding subtasks into disk space; as well as In cases where the subsequent subtask depends on the preceding subtask, the subsequent subtask is executed based on the execution result stored in the disk space.

17. A computer-readable storage medium having a computer program stored thereon, which, when executed by a processor, implements the method for optical proximity correction as claimed in any one of claims 1-8.

Images