CN114296935A - 用于光学邻近校正的方法、电子设备和存储介质 - Google Patents

Abstract

公开了用于光学邻近校正的方法、电子设备和存储介质。该方法包括响应于接收针对版图的多个任务的信息，确定多个任务的优先级。将多个任务中的每个任务划分为多个子任务，多个子任务中的各个子任务分别一一对应于版图上的物理位置范围。确定在后优先级的任务中的在后子任务与在前优先级的任务中的在前子任务的依赖关系，获得确定结果。依赖关系表示在后子任务的执行依赖于对应版图上相同物理范围的在前子任务的执行状态。基于确定结果，调度在后子任务的执行。本公开实施例能够提高用户操作的易用性及任务执行效率。

Description

用于光学邻近校正的方法、电子设备和存储介质

技术领域

本公开的实施例主要涉及半导体制造技术领域，并且更具体地，涉及用于光学邻近校正的方法、电子设备和计算机可读存储介质。

背景技术

随着晶圆制程的不断演进，掩模的密度和复杂度也在不断提升。一般来说，光学邻近校正(Optical Proximity Correction，OPC)的计算引擎会通过分布式处理，将任务分解为一组子任务来执行，最后将子任务融合成为一个最终的执行结果。例如，一个典型的OPC校正任务，会被划分成数十万个子任务，运行在数千颗CPU上，总的运行时长可能长达数十个小时。

OPC计算引擎一般会根据用户的不同配置，来执行不同类型的任务。如果执行的一组任务存在输入输出的依赖关系，就需要保证严格的逻辑串行时序。这导致用户需要额外关注前后任务之间的输入输出。此外，由于任务之间需要保持严格的逻辑串行时序，所以会导致整个任务的运行时间过长。

发明内容

根据本公开的示例实施例，提供了一种改进的用于光学邻近校正的方案。

在本公开的第一方面，提供一种用于光学邻近校正的方法。该方法包括：响应于接收针对版图的多个任务的信息，确定多个任务的优先级；将多个任务中的每个任务划分为多个子任务，多个子任务中的各个子任务分别一一对应于所述版图上的物理位置范围；确定在后优先级的任务中的在后子任务与在前优先级的任务中的在前子任务的依赖关系，获得确定结果，依赖关系表示在后子任务的执行依赖于对应版图上相同物理范围的在前子任务的执行状态；以及基于确定结果，调度在后子任务的执行。

在本公开的第二方面中，提供了一种电子设备。该电子设备包括处理器以及与处理器耦合的存储器，存储器具有存储于其中的指令，指令在被处理器执行时使设备执行动作。该动作包括：响应于接收针对版图的多个任务的信息，确定多个任务的优先级；将多个任务中的每个任务划分为多个子任务，多个子任务中的各个子任务分别一一对应于版图上的物理位置范围；确定在后优先级的任务中的在后子任务与在前优先级的任务中的在前子任务的依赖关系，获得确定结果，依赖关系表示在后子任务的执行依赖于对应版图上相同物理范围的在前子任务的执行状态；以及基于确定结果，调度在后子任务的执行。

在一些实施例中，该动作还包括：确定所述多个任务的业务逻辑配置；以及将多个任务的业务逻辑配置读入内存空间中，使得多个任务的业务逻辑配置在多个任务的执行期间处于同一进程中。

在一些实施例中，其中确定多个任务的优先级包括：基于多个任务中各个任务对应的工艺顺序而确定多个任务的优先级。

在一些实施例中，将多个任务中的每个任务划分为多个子任务包括：将版图划分为单元格矩阵；以及使多个任务中的每个任务的各个子任务所处理的区域分别一一对应于单元格矩阵中的一个单元格的物理位置范围区域。

在一些实施例中，确定在后优先级的任务中的在后子任务与在前优先级的任务中的在前子任务的依赖关系包括：确定与在后子任务的执行是否依赖于与在后子任务对应于版图上相同物理范围的在前子任务是否执行完毕；在所述在前子任务未执行完毕的情况下，确定在后子任务与在前子任务存在依赖关系。

在一些实施例中，该方法还包括：在每个在前子任务执行完毕后，更新在前子任务的状态。

在一些实施例中，基于确定结果调度在后子任务的执行包括：如果确定结果表明在后子任务不依赖于在前子任务，则指示开始执行在后子任务；以及如果确定结果表明在后子任务依赖于在前子任务，则指示在后子任务等待在前子任务的完成。

在一些实施例中，动作还包括：将在前子任务的执行结果存储到磁盘空间中；以及在在后子任务依赖于在前子任务的情况下，基于存储到磁盘空间中的执行结果来执行在后子任务。

在本公开的第三方面中，提供了一种计算机可读存储介质，其上存储有计算机程序，该程序被处理器执行时实现根据本公开的第一方面的方法。

应当理解，发明内容部分中所描述的内容并非旨在限定本公开的实施例的关键或重要特征，亦非用于限制本公开的范围。本公开的其它特征将通过以下的描述变得容易理解。

附图说明

结合附图并参考以下详细说明，本公开各实施例的上述和其他特征、优点及方面将变得更加明显。在附图中，相同或相似的附图标注表示相同或相似的元素，其中：

图1示出了一种典型的OPC多级应用实例流程图；

图2示出了本公开的实施例能够在其中实现的示例环境的示意图；

图3示出了根据本公开的一些实施例的用于光学邻近校正的方法的流程图；

图4示出了根据本公开的一些实施例的精细依赖管理器的架构示意图；

图5示出了根据本公开的一些实施例的OPC计算引擎的架构示意图；以及

图6示出了能够实施本公开的多个实施例的计算设备的框图。

具体实施方式

下面将参照附图更详细地描述本公开的实施例。虽然附图中显示了本公开的某些实施例，然而应当理解的是，本公开可以通过各种形式来实现，而且不应该被解释为限于这里阐述的实施例，相反提供这些实施例是为了更加透彻和完整地理解本公开。应当理解的是，本公开的附图及实施例仅用于示例性作用，并非用于限制本公开的保护范围。

在本公开的实施例的描述中，术语“包括”及其类似用语应当理解为开放性包含，即“包括但不限于”。术语“基于”应当理解为“至少部分地基于”。术语“一个实施例”或“该实施例”应当理解为“至少一个实施例”。术语“第一”、“第二”等等可以指代不同的或相同的对象。下文还可能包括其他明确的和隐含的定义。

OPC工艺流程包括多个步骤。可简要分为：OPC前处理阶段，比如定义理想晶圆光刻成像目标，来满足蚀刻的工艺需求。OPC阶段，该阶段通过建模仿真调整掩模，使光刻***的成像效果不断逼近理想晶圆光刻成像目标。OPC后处理，该阶段一般是从其他的角度来对OPC的结果进行交叉验证。

典型的OPC计算引擎设计通常是针对在运行时只处理一种作业，不同的作业任务通过脚本或者手工方式串联起来。如上文所简要提及的，由于任务之间需要保持严格的逻辑串行时序，所以会导致整个任务的运行时间过长。

图1示出了一种典型的OPC多级应用实例流程图100。如图1所示，其包含JOB0’、JOB1’和JOB2’三个作业，也可称为三个任务，分别用J0’、J1’和J2’表示。对于每一个作业，用户通过业务逻辑(Recipe)来启动一个对应的OPC引擎(OPC引擎0’、OPC引擎1’和OPC引擎2’之一)来执行用户定义的业务逻辑。业务逻辑可以理解为不同或者相同的多种处理规则。在实际的业务逻辑中，后一级的任务需要使用前一(多)级任务的输出作为输入或者参考。也就是说，后一级的任务需要在前一级或多级任务执行完毕后方可执行。因此，执行这三个任务的总时长就等于三个任务的各自时长之和。

此外，从整体来看，JOB0’、JOB1’和JOB2’需要保证严格的串行，同时用户需要前后级的输入输出关联。为此，不同的作业任务需要用户通过脚本或者手工方式串联起来。例如，通过手动点击任务或者额外的程序执行参数来指定各个任务的优先级或者说执行顺序。例如，指定JOB0’最先执行，其次JOB1’执行，最后JOB2’执行。

上述方式主要存在以下弊端：OPC任务通常需要分布式处理，所以算力分布在不同的电脑上，因此数据关联只能通过磁盘文件来交互，运行速度会受到文件***性能(磁盘I/O,网络硬盘速度)的影响。此外，前后任务之间的通信通过硬盘的交互，需要用户去额外关注任务之间的输入输出，因此易用性差。再者，子任务具有局部性特征，有的子任务运行快，有的子任务运行慢，有可能整个任务的运行时间被局部一些子任务延迟很长时间。

为此，需要一种改进的方法，以提高用户的易用性，并且期望降低任务的处理时间。

根据本公开的实施例，提出了一种用于光学邻近校正的方案。该方案中，响应于接收针对版图的多个任务的信息，确定多个任务的优先级。将多个任务中的每个任务划分为多个子任务，多个子任务中的每个子任务对应于版图上相应的部分。确定在后优先级的任务中的在后子任务与在前优先级的任务中的在前子任务的依赖关系，获得确定结果，依赖关系表示在后子任务的执行依赖于对应版图上相同物理范围的在前子任务的执行状态。基于确定结果，调度在后子任务的执行。

该方案中，通过将任务划分为多个子任务，并且基于子任务的执行状态以及在前子任务与在后子任务之间的依赖关系，能够对在后子任务的执行时间进行调度优化，从而能够将串联执行的任务转化为至少部分并行执行。因此，能够显著提高任务的执行效率。此外，使用者无需关注各个任务之间的切换，因此能够显著提高用户操作的易用性。

以下将参照附图来具体描述本公开的实施例。参考图2，其示出了本公开的多个实施例能够在其中实现的示例环境200的示意图。如图2所示，示例环境200中包含计算装置210、客户端220。

在一些实施例中，计算装置210可以与客户端220进行交互。例如，计算装置210可以接收来自客户端220的输入消息，并向客户端220输出反馈消息。在一些实施例中，来自客户端220的输入消息可以指定待处理的任务。计算装置210可以针对输入消息中指定的任务，进行处理。在一些实施例中，计算装置210可以向客户端220发送控制消息，以控制客户端220执行任务。例如，计算装置210可以将待处理的任务分配给客户端220来执行。并且接收来自客户端220反馈的执行结果。

在一些实施例中，计算装置210可以包括但不限于个人计算机、服务器计算机、手持或膝上型设备、移动设备(诸如移动电话、个人数字助理PDA、媒体播放器等)、消费电子产品、小型计算机、大型计算机、云计算资源等。在一些实施例中，客户端220也可以包括但不限于个人计算机、服务器计算机、手持或膝上型设备、移动设备(诸如移动电话、个人数字助理PDA、媒体播放器等)、消费电子产品、小型计算机、大型计算机、云计算资源等。

应当理解，仅出于示例性的目的描述示例环境200的结构和功能并不旨在限制本文所描述主题的范围。本文所描述主题可以在不同的结构和/或功能中实施。

上文描述的技术方案仅用于示例，而非限制本发明。应理解，示例环境200还可以具有其他多种实施方式。为了更清楚地解释本公开方案的原理，下文将参考图3来更详细描述。

图3示出了根据本公开的一些实施例的用于光学邻近校正的方法的流程图。例如，方法300可以由如图2所示的计算装置210来实施。以下结合图4和图5来描述方法300。图4示出了根据本公开的一些实施例的精细依赖管理器的架构示意图。图5示出了根据本公开的一些实施例的OPC计算引擎的架构示意图。应当理解，方法300还可以包括未示出的附加框和/或可以省略所示出的某些框。本公开的范围在此方面不受限制。

在框302处，响应于接收针对版图的多个任务的信息，确定多个任务的优先级。在一些实施例中，可接收来自外部的输入信息，输入信息中指定要执行的任务。例如，对版图进行处理的任务。输入信息可以通过各种方式输入。例如，可以通过接收消息的方式，或者可以通过接收文件的方式，等等。本公开的实施例并不以此为限。每个作业或者说任务具有对应的业务逻辑。业务逻辑中可指定对该任务执行何种处理、如何进行处理等等。例如，业务逻辑中可以指定将版图旋转90度，并将其切割成尺寸为10nm乘10nm的单元格。又例如，业务逻辑可以指定将正方形拉长，左右两边各拉长5nm，然后旋转90度，然后计算其面积。此处的“将正方形拉长”、“左右两边各拉长5nm”即为业务逻辑，也可称为业务规则。其中5你们和90度可称为业务逻辑配置。即，用户希望做的一组操作的配置。按照上述规则执行相应的动作可称为作业或者任务，例如执行上述拉长的动作可称为作业或任务JOB0。旋转90度这个动作可称为JOB1。计算该长方形的面积，这个动作可称为作业或者任务JOB2。在一些实施例中，任务可以由OPC引擎来执行。引擎通常位于多台计算机上。如前面所提到的，一个典型的OPC修正任务，会被划分成数十万个子任务，运行在数千颗CPU上。

在一些实施例中，用户接收输入的文件，例如关于要执行的任务的信息。用户可指定一些规则，即指定业务逻辑。引擎则可执行相应的动作来执行任务。本公开的一些实施例中，每道工序(作业)或者说任务对应的业务逻辑对其他工序的调度器可见。例如，在一些实施例中，调度器可以是软件实现的应用程序。所有作业的业务逻辑对每一级调度器都是可见的。因此，在每一级调度器中能够知晓其他作业的业务逻辑，从而能够对子任务的执行进行合理调度。

在一些实施例中，用户可以根据需要指定多个任务的处理顺序，或者说优先级。在一些实施例中，优先级也可以由管理器来指定。

在一些实施例中，可以从输入的信息中确定所述多个任务的业务逻辑配置。此外，可将多个任务的业务逻辑配置读入内存空间中，使得多个任务的业务逻辑配置在多个任务的执行期间处于同一进程中。各个子任务的执行状态存储在内存中。例如，一个业务逻辑配置存储在地址1到10000，另一个存储在20000至3000，另一个存储在4000到50000。当然，这仅是示例性的，本公开的方案并不限于此。

在典型的OPC流程中，各个任务之间的业务逻辑是透明的，即不可知的。在后的任务并不知晓、也不关心在前任务的具体业务逻辑。因此各个任务的执行位于不同的进程中。此外，如前面所提到的，不同任务之间的数据通常位于不同的节点(例如，电脑、手持设备等等)上，因此数据关联只能通过磁盘文件来交互，运行速度会收到磁盘I/O性能的影响。此外，前后任务之间的通信通过硬盘的交互，需要用户去额外关注任务之间的输入输出。即用户需要处理依赖关系，因此易用性差。此外，数据交互的时间较长。而在本公开的一些实施例中，通过将多个任务的业务逻辑配置均读入内存空间中，使得多个任务的业务逻辑配置在多个任务的执行期间处于同一进程中，从而使得用户无需关注各个任务之间的切换。此外，内存上读取信息的速度相比通过磁盘文件交互信息要快得多。以此方式，在后任务执行过程中，可以获知在前任务的执行状况，并且确定相互之间是否有依赖关系。基于此，可以合理调度不同任务的执行。也就是说，在后任务的执行并不限制在在前任务执行完毕之后。由此可以显著提高多个任务的执行效率，大大节省执行时间。

在一些实施例中，基于多个任务中各个任务对应的工艺顺序而确定多个任务的优先级。在一些实施例中，用户可以根据实际需要指定其他的优先级或者说执行顺序。

在框304处，将多个任务中的每个任务划分为多个子任务。多个子任务中的每个子任务可对应于版图上相应的部分。例如，参见图4，图4示出了根据本公开的一些实施例的精细依赖管理器的架构400的示意图。402为任务JOB0的视图，其总体对应于版图。该图中示出了四个子任务t00-t03，其分别对应于该任务视图中的一个方格(单元格)。在一些实施例中，将多个任务中的每个任务划分为多个子任务后，可以通过确定在后优先级的任务中的在后子任务与在前优先级的任务中的在前子任务的依赖关系，来确定在后子任务的执行时间，以此方式可以优化任务的执行。

在一些实施例中，将多个任务中的每个任务划分为多个子任务包括使所述多个任务中的每个任务的各个子任务所处理的区域分别一一对应于所述单元格矩阵中的一个单元格区域的物理位置范围。

下面结合图4对此进一步描述。如图4所示，如前面所提到的，402为任务JOB0的视图，其总体对应于版图。其中示出了四个子任务t00-t03，其分别对应于该任务视图中的一个方格。此外，404为任务JOB1的视图，其总体对应于版图。例如，JOB1的一个子任务t1-0对应于该任务视图中的一个方格，即一个单元格区域的物理位置范围。JOB1的一个子任务t1-0所对应的方格与JOB0的视图中的四个子任务t00-t03对应的方格在物理上为同一范围。换言之，子任务t1-0所处理的版图上的区域与四个子任务t00-t03所处理的版图上的区域是相同区域。如图所示的实施例中，JOB0的视图402所划分的单元格的尺寸与JOB1的视图404所划分的单元格的尺寸虽然不同，但是对于每个任务来说，其各个子任务分别一一对应于版图上的物理位置范围，即其中的某个单元格。

再次参见图4，其中404为任务JOB1的视图，其总体对应于版图。例如，JOB1的一个子任务t1-0对应于该任务视图中的一个方格。408表示版图的视图，JOB0的视图402以及JOB1的视图404均对应于版图的视图408。换句话说，表示版图的视图对于所有的任务都是可见的，各个子任务分别对应于版图上的预定物理范围。例如，如前面所提到的，JOB1的一个子任务t1-0对应于该任务视图中的一个方格。JOB0的视图中的四个子任务t00-t03对应于该任务视图中的四个方格(单元格)组成的子矩阵。上述两个子任务对应于版图上的同一物理范围。

以此方式，通过使在后的子任务与在前的子任务中的一个或者多个对应于相同的物理范围，具体地，将版图划分为单元格的矩阵，并且使多个任务中的每个任务的各个子任务所处理的区域分别一一对应于单元格的矩阵中的一个单元格区域的物理位置范围，能够在在后子任务的执行前，查询对应于相同物理范围的在前子任务的执行状况，从而可以确定何时可以开始在后子任务的执行。由此能够将各个任务之间整体的串行执行变换为局部子任务的串行执行以及整体上各个任务并行执行。

在框306处，确定在后优先级的任务中的在后子任务与在前优先级的任务中的在前子任务的依赖关系，由此获得确定结果。依赖关系表示在后子任务的执行依赖于对应版图上相同物理范围的在前子任务的执行状态。在典型的OPC流程中，各个任务的执行仅是简单的串联执行，并不考虑对任务进行细分，以及细分后的子任务之间有何依赖关系。在本公开的一些实施例中，通过将任务细分为子任务，并且确定在后优先级的任务中的在后子任务与在前优先级的任务中的在前子任务的依赖关系，能够优化任务的执行顺序，提高执行效率。

在一些实施例中，确定在后优先级的任务中的在后子任务与在前优先级的任务中的在前子任务的依赖关系包括确定与在后子任务对应于版图上相同物理范围的在前子任务是否执行完毕，在所述在前子任务未执行完毕的情况下，确定所述在后子任务与所述在前子任务存在依赖关系。在一些实施例中，可以向精细依赖管理器406查询在前子任务的状态，其中在每个在前子任务执行完毕后，调度器可向精细依赖管理器406更新子任务的状态。在一些实施例中，在每个在前子任务执行完毕后，调度器还向精细依赖管理器406通知执行结果存储到何处。

以下参照图5进一步描述调度器以及精细依赖管理器的运行。图5示出了根据本公开的一些实施例的OPC计算引擎的架构500的示意图。如图5所示，其中示出了用户502，OPC引擎504。OPC引擎504可包括精细依赖管理器406以及调度器0、调度器1和调度器2。图中还示出三个任务，即JOB0、JOB1和JOB2。每个任务有一个对应的调度器，分别为调度器0、调度器1和调度器2。

任务JOB0由于优先级最高，所以不需要依赖于任何其他任务，所以可以直接执行。每做完一个子任务就报告给精细依赖管理器406。精细依赖管理器406可以更新该子任务的状态。在一些实施例中，每个任务中的各个子任务的状态可以以矩阵的形式存储在内存中。随着子任务的执行，不断更新(如箭头S0所示)矩阵中各个子任务的状态。例如，执行完毕状态更新为1，未执行状态保持为0。此处子任务的存储方式仅仅是示例性的，本公开的方式并不限于此，而是可以有多种变化方式。对于JOB1来说，由于其优先级低于JOB0，所以有可能其中的子任务依赖于JOB0中子任务，因此在执行前需要调度器1先去查询是否依赖于JOB0中对应位置的子任务的执行，具体地，可查询该在前子任务是否执行完毕。例如，如图5所示，JOB1在调度子任务t1-0执行以前，会去查询子任务t1-0所对应的在前子任务，即JOB0上对应的t0-0到t0-3，是否有依赖，即查询其执行情况。如果有依赖的话(即未执行完)，则调度器0就可通知(如箭头S1所示)在后子任务暂缓执行，等待在前的子任务t0-0到t0-3执行完毕。如果这几个依赖的子任务已经执行完毕，那么JOB1的调度器1就能够确认可以执行t1-0。此外，在前的子任务t0-0到t0-3执行完毕后，调度器1就可通知(如箭头S1所示)在后子任务现在可以执行。JOB1的在后子任务执行完毕后，也向精细依赖管理器406更新该子任务的执行状态。由图4中可以看出，S1为双向箭头，表示调度器1与精细依赖管理器406之间的交互是双向的，既可以查询状态并通知该子任务的执行，又可以更新执行状态。

对于任务JOB2，与JOB1类似，在其执行前需要调度器2先去查询是否依赖于JOB0以及JOB1中对应位置的子任务，即查询该在前子任务的执行状态。如果有依赖的话，调度器2就可通知(如箭头S2所述)在后子任务暂缓执行，等待在前的子任务例如JOB0和/或JOB1执行完毕。在前的子任务执行完毕后，调度器2就可通知(如箭头S2所述)在后子任务现在可以执行。JOB2由于是优先级最低的任务，所以其子任务执行完毕后，无需向精细依赖管理器406更新该子任务的执行状态。以此方式，用户可仅定义执行顺序，不需要关心依赖关系，由此提高易用性。此外，依赖关系可由调度器来确定，并且通过调度器与精细依赖管理器406协同工作，能够优化子任务的执行顺序，提高执行效率。

在框308处，基于确定结果，调度在后子任务的执行。在一些实施例中，基于确定结果调度在后子任务的执行包括：如果确定结果表明在后子任务不依赖于在前子任务，则指示开始执行在后子任务。如果确定结果表明在后子任务依赖于在前子任务，则可指示在后子任务等待在前子任务执行完毕。在各个任务中的子任务执行完毕后，可以将子任务结合到一起形成完整的任务输出。

如前面结合图4和图所描述的，基于确定结果，调度器可以指示在后子任务暂缓执行，或者在后子任务可以执行。也就是说，调度器可以实现查询状态、分发任务、统筹安排子任务的执行时间等功能。在一些实施例中，对应于每个任务的调度器可以调度相应的引擎来执行各个任务。相应的引擎可以位于同一台计算设备(例如计算机)上，也可以位于不同的计算设备上。

在一些实施例中，该方法还包括将在前子任务的执行结果存储到文件中(例如磁盘或者网络硬盘)或者说磁盘空间中。并且在在后子任务依赖于在前子任务的情况下，基于执行结果来执行在后子任务。

在一些实施例中，例如前面提到的，业务逻辑中可以指定将版图旋转90度，并将其切割成尺寸为10nm乘10nm的单元格。OPC引擎可按照程序设定的方式进行旋转和切割，形成一个个JOB的子任务。当完成子任务后对应的处理结果存放在一区域，例如磁盘空间中，由其他JOB通过精细依赖管理器406进行获取以用于其他具有依赖关系的子任务。

上述实施例仅为示意性的，本公开的实施例并不限于上述实施例，而是可以有多种变型方式。

本公开的一些实施例中，通过引入精细依赖管理器以及调度器，能够实现并行处理，来管理不同工序(任务)之间的子任务依赖关系。精细依赖管理器可主要基于以下三点任务执行特点来设计。1.不同工序看到的OPC版图的全局视图一致。2.根据预设的物理尺寸(例如，可以由用户设定，也可能基于其他考虑由OPC设定)，将作业分割为一组子任务。3.不同工序的子任务的依赖限定在相同的物理范围内。基于以上三点，可以实现一种新的OPC引擎架构：调度器将执行完成的子任务状态更新到精细依赖管理器。调度器查询将要执行的子任务所依赖的前级对应子任务是否完成。基于此，能够优化任务的执行，提高执行效率。

本公开的一些实施例中，通过精细依赖管理器，将作业之间的整体依赖，细分到子任务级别的局部依赖。同时配置多道作业，并将作业间的优先级顺序按照分布式任务的特点，提高用户易用性，并且提高效率。精细依赖管理器将依赖关系精细化到子任务的级别，从而获得运行期作业级别的并行性。此外，引擎可以同时获取不同作业的配置，不需要用户显示的关注任务切换的细节，从而提升易用性。

本公开的一些实施例中，基于流水线的OPC分布式计算引擎设计，将多个作业组合成为一个流水线，每一个作业作为流水线上的一道工序，用户可只将不同工序的业务逻辑配置好，OPC引擎对每一道工序创建一个独立的子任务调度器。每道工序对应的业务逻辑配置对其他工序的调度器可见，所以用户不再需要关心工序与工序之间的切换逻辑。因为多组逻辑对不同工序调度器可见，工序与工序之间的数据交互可以通过内存交互完成。所以从整体上看，工序之间不再存在明显的先后关系，每道工序的子任务执行期依赖可由精细依赖管理器的检查结果来独立分发，所以实际的运行期效果是并行的流水线。

本公开的实施例，子任务之间的依赖关系对用户保持透明，即各个业务逻辑之间知道其相互依赖关系，从而能够将串行变为并行。同时让用户的配置更加简单，提升了用户易用性。

本申请还可以为其他特性提供统一的实现框架，同时兼容作业与作业之间有全局的串行依赖的情形。只要将某一个任务抽象为一个工序，放入流水线中合适的位置，就可以由引擎按照依赖规则自动触发运行。

本公开的实施例中，以三个JOB为例进行了说明书，本公开的实施例并不限于此，而是可以为任意其他数量的JOB，例如数十万个JOB。

图6示出了可以用来实施本公开的实施例的示例设备600的示意性框图。例如，本公开的电子设备可以由设备600来实施。如图所示，设备600包括中央处理单元(CPU)601，其可以根据存储在只读存储器(ROM)602中的计算机程序指令或者从存储单元608加载到随机访问存储器(RAM)603中的计算机程序指令，来执行各种适当的动作和处理。在RAM 603中，还可存储设备600操作所需的各种程序和数据。CPU 601、ROM 602以及RAM 603通过总线604彼此相连。输入/输出(I/O)接口605也连接至总线604。

设备600中的多个部件连接至I/O接口605，包括：输入单元606，例如键盘、鼠标等；输出单元607，例如各种类型的显示器、扬声器等；存储单元608，例如磁盘、光盘等；以及通信单元609，例如网卡、调制解调器、无线通信收发机等。通信单元609允许设备600通过诸如因特网的计算机网络和/或各种电信网络与其他设备交换信息/数据。

处理单元601执行上文所描述的各个方法和处理，例如方法300。例如，在一些实施例中，方法300可被实现为计算机软件程序，其被有形地包含于机器可读介质，例如存储单元608。在一些实施例中，计算机程序的部分或者全部可以经由ROM 602和/或通信单元609而被载入和/或安装到设备600上。当计算机程序加载到RAM 603并由CPU 601执行时，可以执行上文描述的方法300中的一个或多个步骤。备选地，在其他实施例中，CPU 601可以通过其他任何适当的方式(例如，借助于固件)而被配置为执行方法300。

本文中以上描述的功能可以至少部分地由一个或多个硬件逻辑部件来执行。例如，非限制性地，可以使用的示范类型的硬件逻辑部件包括：场可编程门阵列(FPGA)、专用集成电路(ASIC)、专用标准产品(ASSP)、芯片上***的***(SOC)、负载可编程逻辑设备(CPLD)等等。

用于实施本公开的方法的程序代码可以采用一个或多个编程语言的任何组合来编写。这些程序代码可以提供给通用计算机、专用计算机或其他可编程数据处理装置的处理器或控制器，使得程序代码当由处理器或控制器执行时使流程图和/或框图中所规定的功能/操作被实施。程序代码可以完全在机器上执行、部分地在机器上执行，作为独立软件包部分地在机器上执行且部分地在远程机器上执行或完全在远程机器或服务器上执行。

在本公开的上下文中，机器可读介质可以是有形的介质，其可以包含或存储以供指令执行***、装置或设备使用或与指令执行***、装置或设备结合地使用的程序。机器可读介质可以是机器可读信号介质或机器可读储存介质。机器可读介质可以包括但不限于电子的、磁性的、光学的、电磁的、红外的、或半导体***、装置或设备，或者上述内容的任何合适组合。机器可读存储介质的更具体示例会包括基于一个或多个线的电气连接、便携式计算机盘、硬盘、随机存取存储器(RAM)、只读存储器(ROM)、可擦除可编程只读存储器(EPROM或快闪存储器)、光纤、便捷式紧凑盘只读存储器(CD-ROM)、光学储存设备、磁储存设备、或上述内容的任何合适组合。

此外，虽然采用特定次序描绘了各操作，但是这应当理解为要求这样操作以所示出的特定次序或以顺序次序执行，或者要求所有图示的操作应被执行以取得期望的结果。在一定环境下，多任务和并行处理可能是有利的。同样地，虽然在上面论述中包含了若干具体实现细节，但是这些不应当被解释为对本公开的范围的限制。在单独的实施例的上下文中描述的某些特征还可以组合地实现在单个实现中。相反地，在单个实现的上下文中描述的各种特征也可以单独地或以任何合适的子组合的方式实现在多个实现中。

尽管已经采用特定于结构特征和/或方法逻辑动作的语言描述了本主题，但是应当理解所附权利要求书中所限定的主题未必局限于上面描述的特定特征或动作。相反，上面所描述的特定特征和动作仅仅是实现权利要求书的示例形式。

Claims (10)

1.一种用于光学邻近校正的方法，包括：

响应于接收针对版图的多个任务的信息，确定所述多个任务的优先级；

将所述多个任务中的每个任务划分为多个子任务，所述多个子任务中的各个子任务分别一一对应于所述版图上的物理位置范围；

确定在后优先级的任务中的在后子任务与在前优先级的任务中的在前子任务的依赖关系，获得确定结果，所述依赖关系表示所述在后子任务的执行依赖于对应所述版图上相同物理范围的在前子任务的执行状态；以及

基于所述确定结果，调度所述在后子任务的执行。

2.根据权利要求1所述的方法，还包括：

确定所述多个任务的业务逻辑配置；以及

将所述多个任务的业务逻辑配置读入内存空间中，使得所述多个任务的业务逻辑配置在所述多个任务的执行期间处于同一进程中。

3.根据权利要求1所述的方法，其中确定所述多个任务的优先级包括：

基于所述多个任务中各个任务对应的工艺顺序而确定所述多个任务的优先级。

4.根据权利要求1所述的方法，其中将所述多个任务中的每个任务划分为多个子任务包括：

将所述版图划分为单元格矩阵；以及

使所述多个任务中的每个任务的各个子任务所处理的区域分别一一对应于所述单元格矩阵中的一个单元格区域的物理位置范围。

5.根据权利要求1所述的方法，其中确定在后优先级的任务中的在后子任务与在前优先级的任务中的在前子任务的依赖关系包括：

确定与所述在后子任务对应于版图上相同物理范围的在前子任务是否执行完毕；以及

在所述在前子任务未执行完毕的情况下，确定所述在后子任务与所述在前子任务存在依赖关系。

6.根据权利要求1所述的方法，其中还包括：

在每个所述在前子任务被执行完毕后，更新所述在前子任务的状态。

7.根据权利要求1所述的方法，其中基于所述确定结果，调度所述在后子任务的执行包括：

如果所述确定结果表明所述在后子任务不依赖于所述在前子任务，则指示开始执行所述在后子任务；或者

如果所述确定结果表明所述在后子任务依赖于所述在前子任务，则指示所述在后子任务等待所述在前子任务执行完毕。

8.根据权利要求1所述的方法，其中还包括：

将所述在前子任务的执行结果存储到磁盘空间中；以及

在所述在后子任务依赖于所述在前子任务的情况下，基于存储到所述磁盘空间中的所述执行结果来执行所述在后子任务。

9.一种电子设备，包括：

处理器；以及

与所述处理器耦合的存储器，所述存储器具有存储于其中的指令，所述指令在被处理器执行时使所述设备执行动作，所述动作包括：

响应于接收针对版图的多个任务的信息，确定所述多个任务的优先级；

将所述多个任务中的每个任务划分为多个子任务，所述多个子任务中的各个子任务分别一一对应于所述版图上的物理位置范围；

确定在后优先级的任务中的在后子任务与在前优先级的任务中的在前子任务的依赖关系，获得确定结果，所述依赖关系表示所述在后子任务的执行依赖于对应所述版图上相同物理范围的在前子任务的执行状态；以及

基于所述确定结果，调度所述在后子任务的执行。

10.一种计算机可读存储介质，其上存储有计算机程序，所述程序被处理器执行时实现如权利要求1-8中任一项所述的用于光学邻近校正的方法。

Images