用于合并覆盖数据的EDA覆盖日志的方法和装置.pdf

本申请涉及用于合并覆盖数据的EDA覆盖日志的方法和装置。公开了一种合并覆盖日志的电子设计自动化技术。通过验证硬件描述语言电路设计来生成覆盖日志。在生成覆盖日志时合并覆盖日志而不等待所有未决覆盖日志。还公开了合并覆盖日志的另一电子设计自动化技术。合并的覆盖日志包括硬件描述语言电路设计的第一仿真的第一覆盖日志和硬件描述语言电路设计的第二仿真的第二覆盖日志。第一仿真基于硬件描述语言电路设计的第一硬件验证语言覆盖模型。第二仿真基于硬件描述语言电路设计的第二硬件验证语言覆盖模型。第二硬件验证语言覆盖

1.  一种电子设计自动化方法，包括：
在硬件描述语言电路设计的验证所生成的覆盖日志生成时，合并所述覆盖日志，而不等待未决验证的所有覆盖日志。

2.  根据权利要求1所述的电子设计自动化方法，其中所述覆盖日志的至少一个覆盖日志由所述硬件描述语言电路设计的仿真生成。

3.  根据权利要求1所述的电子设计自动化方法，还包括：响应于所述合并，变更所述硬件描述语言电路设计的未决仿真的条件。

4.  根据权利要求1所述的电子设计自动化方法，还包括：
响应于所述合并，变更所述硬件描述语言电路设计的未决仿真的输入参数。

5.  根据权利要求1所述的电子设计自动化方法，还包括：
响应于所述合并，释放至少部分大容量存储。

6.  根据权利要求1所述的电子设计自动化方法，还包括：
响应于所述合并以及响应于满足预定条件，生成覆盖报告。

7.  根据权利要求1所述的电子设计自动化方法，还包括：
响应于所述合并，确定预期完成未决验证不足以改进所述硬件描述语言电路设计的验证覆盖。

8.  根据权利要求1所述的电子设计自动化方法，还包括：
响应于所述合并，通过确定将由未决仿真进行仿真的所述硬件描述语言电路设计的属性已经进行过仿真，从而确定预期完成所述未决验证不足以改进所述硬件描述语言电路设计的验证覆盖。

9.  根据权利要求1所述的电子设计自动化方法，还包括：
响应于所述合并，确定预期完成所述未决验证不足以改进所述硬件描述语言电路设计的验证覆盖，并且使所述未决验证停止。

10.  根据权利要求1所述的电子设计自动化方法，其中所述合并得到包括形式验证覆盖数据的已合并覆盖日志。

11.  根据权利要求1所述的电子设计自动化方法，还包括：
响应于执行所述合并的就绪状态，请求在执行所述合并的所述就绪状态之前生成的覆盖日志数据。

12.  根据权利要求1所述的电子设计自动化方法，还包括：
响应于所述合并，执行：
更新所述硬件描述语言电路设计的验证覆盖的覆盖度量，所述覆盖度量包括来自所述合并的覆盖数据。

13.  根据权利要求1所述的电子设计自动化方法，还包括：
创建多个运行实例，所述多个运行实例执行所述硬件描述语言电路设计的仿真的覆盖日志的合并。

14.  一种具有用于电路设计的计算机可读指令的计算机可读介质，包括：
在硬件描述语言电路设计的验证所生成的覆盖日志生成时合并所述覆盖日志而不等待未决验证的所有覆盖日志的计算机指令。

15.  根据权利要求14所述的计算机可读介质，还包括：
响应于所述合并而变更所述硬件描述语言电路设计的未决仿真的条件的计算机指令。

16.  根据权利要求14所述的计算机可读介质，还包括：
响应于所述合并而释放至少部分大容量存储的计算机指令。

17.  根据权利要求14所述的计算机可读介质，还包括：
响应于所述合并以及响应于满足预定条件而生成覆盖报告的计算机指令。

18.  一种装置，包括：
具有存储的计算机，所述存储器存储在硬件描述语言电路设计的验证所生成的覆盖日志生成时合并所述覆盖日志而不等待未决验证的所有覆盖日志的计算机指令。

19.  根据权利要求18所述的装置，其中所述存储器还存储：
响应于所述合并而变更所述硬件描述语言电路设计的未决仿真的条件的计算机指令。

20.  根据权利要求18所述的装置，其中所述存储器还存储：
响应于所述合并而释放至少部分大容量存储的计算机指令。

21.  根据权利要求18所述的装置，其中所述存储器还存储：
响应于所述合并以及响应于满足预定条件而生成覆盖报告的计算机指令。

用于合并覆盖数据的EDA覆盖日志的方法和装置
技术领域
本申请总体上涉及电子设计自动化，并且更具体地，涉及用于合并覆盖数据的EDA覆盖日志的方法和装置。
背景技术
电子设计自动化EDA在半导体产业中应用于实际上所有器件设计项目。在进行了产品构思之后，EDA工具用来定义具体实现。在称为“流片”的过程中，使用EDA工具定义的实现用来创建掩模数据，该掩模数据用于产生掩模以便在生产成品芯片时进行光刻。继而创建掩模，并且将这些掩模与制造设备一起用来制造集成电路晶片。对晶片进行分割、封装和组装，从而提供集成电路芯片以便分发。
使用EDA工具的示例设计程序开始于使用架构定义工具的总体系统设计，这些工具描述将使用集成电路实现的产品的功能。接下来，应用逻辑设计工具，以便基于描述语言如Verilog或者VHDL等来创建高级描述；并且在迭代过程中应用功能验证工具，以保证该高级描述实现设计目标。接下来，使用合成和测试设计工具将高级描述转移成网表，针对目标技术优化网表，以及设计和实现允许按照网表来检查成品芯片的测试。
典型设计流程可能接下来包括设计规划阶段，在该阶段中，构造和分析芯片的总体平面图，以保证可以在高层级实现网表的时序参数。接下来，可以严格地检查网表是否遵循时序约束以及使用VHDL或者Verilog在高层级定义的功能描述。在确定网表并且将网表映射到用于最终设计的单元库的迭代过程之后，使用物理实现工具进行布置和布线。执行布置的工具将电路元件定位于布局上，而进行布线的工具定义电路元件的互连。
在布置和布线之后，继而通常使用抽象工具在晶体管层级分析所定义的部件并且验证这些部件，以保证实现电路功能并且满足时序约束。可以用迭代方式按照需要重新访问布置和布线过程。接下来，对设计进行物理验证过程，诸如设计规则检查DRC、布局规则检查LRC和布局比对示意LVS检查，这些物理验证过程分析可制造性、电子性能、光刻参数以及电路正确性。
在通过设计和验证过程(例如上文描述的过程)的迭代达成可接受的设计之后，可以对得到的设计进行解析度增强技术，其提供对布局的几何操控以提高可制造性。最后，准备掩模数据并对其流片，以用于生产最终产品。
发明内容
本发明的一个方面是一种合并覆盖日志的电子设计自动化方法。通过验证硬件描述语言电路设计，来生成覆盖日志。在生成覆盖日志时合并覆盖日志，而不等待未决验证(pending verification)的所有覆盖日志。未决验证的示例是未决动态仿真(例如，纯随机仿真、定向随机仿真和纯定向仿真)和未决形式验证。
在一些实施方式中，通过仿真硬件描述语言电路设计来生成至少一个覆盖日志。在一些实施方式中，合并覆盖日志得到包括形式验证覆盖数据的合并覆盖日志。
各种实施方式具有响应于合并覆盖日志的结果。一个这样的结果是更改硬件描述语言电路设计的未决仿真的条件。改变条件的示例包括更改输入参数，例如更改输入条件(例如：改变输入配置文件和/或参数以在不同模式/配置中仿真芯片；改变测试平台的控制参数，这继而将添加更多约束和/或放宽现有约束，由此导致生成不同的输入激励)或者改变随机种子条件。
另一这样的结果是释放至少部分大容量储存。
另一这样的结果是，不仅响应于合并覆盖日志，而且还响应于满足预定条件，而生成覆盖报告。
另一这样的结果是确定：预期完成未决验证将不足以改进硬件描述语言电路设计的验证覆盖。一种用以确定未决验证不足以改进验证覆盖的方式是：确定将要通过该未决仿真来仿真的硬件描述语言电路设计的属性已经进行了仿真。在一个实施方式中，当确定未决验证不足以改进验证覆盖时，则停止未决验证。
另一这样的结果是较新的硬件描述语言电路设计的验证覆盖的覆盖度量。覆盖度量包括来自合并覆盖日志的覆盖数据。示例覆盖度量考虑断言覆盖、功能覆盖和代码覆盖(例如线覆盖、条件覆盖、分支覆盖、路径覆盖、触发覆盖、指派触发覆盖)。
在一些实施方式中，本发明从未就绪状态变为合并覆盖日志的就绪状态。响应于这一状态改变，请求在状态改变之前生成的覆盖日志数据。
一些实施方式创建多个运行实例。这些多个运行实例执行对硬件描述语言电路设计的仿真的覆盖日志的合并，或者一般地称为验证。
本发明的另一方面是一种合并覆盖日志的电子设计自动化方法。合并的覆盖日志包括硬件描述语言电路设计的第一仿真的第一覆盖日志和硬件描述语言电路设计的第二仿真的第二覆盖日志。第一仿真基于硬件描述语言电路设计的第一硬件验证语言覆盖模型。第二仿真基于硬件描述语言电路设计的第二硬件验证语言覆盖模型。第二硬件验证语言覆盖模型比第一硬件验证语言覆盖模型更新，并且与第一硬件验证语言覆盖模型不同。
硬件描述语言电路设计的硬件描述语言包括Verilog、SystemVerilog和VHDL中的任何硬件描述语言。
第一和第二硬件验证语言模型的硬件验证语言包括SystemVerilog、Native Testbench、E和Vera中的任何硬件验证语言。
各种实施方式具有响应于合并覆盖日志来控制是否删除和/或保持覆盖数据的各种条件。
一种这样的条件包括：响应于第一覆盖日志和第二覆盖日志包括不同最大数目的自动创建的面元(bin)，保持第二覆盖日志的覆盖点的覆盖数据并且从第一覆盖日志删除覆盖点的覆盖数据。
另一这样的条件包括：响应于第一覆盖日志包括面元名称未存在于第二覆盖日志中的面元，在所述合并之后删除该面元的覆盖数据。
另一这样的条件包括：响应于所述第一覆盖日志包括面元名称存在于第二覆盖日志中的面元，在所述合并之后保持该面元的覆盖数据。
另一这样的条件包括：响应于第一覆盖日志具有第一表达式宽度的覆盖点而第二覆盖日志具有与第一表达式宽度不同的第二表达式宽度的覆盖点，保持第二表达式宽度的覆盖点的覆盖数据，并且删除第一表达式宽度的覆盖点的覆盖数据。
另一这样的条件包括：响应于第一覆盖日志具有按照第一面元定义的面元而第二覆盖日志具有按照与第一面元定义不同的第二面元定义的面元，然后在所述合并之后保持按照第二面元定义的面元的覆盖数据，并且删除第一面元定义的覆盖数据。
另一这样的条件包括：响应于第一覆盖日志包括命名至少两个覆盖点标识符的、交叉覆盖点的交叉覆盖点名称，而第二覆盖日志包括命名所述至少两个覆盖点标识符的、交叉覆盖点的交叉覆盖点名称，则响应于从第一覆盖日志删除至少一个已标识覆盖点的覆盖数据，来删除第一覆盖日志的交叉覆盖点的覆盖数据。
另一这样的条件包括：响应于第一覆盖日志包括第一交叉覆盖点的、用户定义的第一交叉面元，而第二覆盖日志包括第二交叉覆盖点的、用户定义的第二交叉面元，第一交叉覆盖点和第二交叉覆盖点具有相同名称，则尽管用户定义的第一交叉面元和用户定义的第二交叉面元具有不同定义，仍然保持用户定义的第一交叉面元的覆盖数据和用户定义的第二交叉面元的覆盖数据。
另一这样的条件包括：响应于第一覆盖日志包括第一交叉覆盖点的第一自动交叉面元，而第二覆盖日志包括含有第一交叉覆盖点的自动交叉面元的、用户定义的第二交叉面元，在第二覆盖日志的用户定义的第二交叉面元中保持第一自动交叉面元的覆盖数据。
另一这样的条件包括：响应于第一覆盖日志包括第一交叉覆盖点而第二覆盖日志包括第二交叉覆盖点，则尽管第一交叉覆盖点和第二交叉覆盖点具有不同的自动交叉覆盖空间，仍然保持i)第二交叉覆盖点的自动交叉覆盖空间所包含的第一交叉覆盖点的自动交叉覆盖数据和ii)第二交叉覆盖点的覆盖数据。
另一这样的条件包括：响应于第二覆盖日志包括未存在于第一覆盖日志中的交叉覆盖点，保持该交叉覆盖点。
另一这样的条件包括：响应于第一覆盖日志包括未存在于第二覆盖日志中的交叉覆盖点，删除该交叉覆盖点。
另一这样的条件包括：响应于第一覆盖日志包括未存在于第二覆盖日志中的属性覆盖，保持该属性覆盖。
另一这样的条件包括：响应于第二覆盖日志包括未存在于第一覆盖日志中的属性覆盖，保持该属性覆盖。
本发明的其它方面涉及一种具有用于电路设计的计算机可读指令的计算机可读介质，这些计算机可读指令包括实现这里所述技术的计算机指令。本技术的其它方面涉及一种具有存储器的计算机，该计算机存储实现这里所述技术的计算机指令。
附图说明
图1是从构思阶段经过电子设计自动化(EDA)阶段并且结束于集成电路的制造集成电路的简化过程流程。
图2是进行硬件验证语言电路设计仿真的系统的简化框图。
图3是示出了图2的仿真系统的操作的简化状态图。
图4是图2和图3的仿真系统的简化目录结构。
图5A和5B是对比通过合并而不是丢弃在先覆盖日志的改进仿真流程的简化流程图。
图6是各种实施方式的计算机系统的简化框图。
具体实施方式
图1是从构思阶段经过电子设计自动化(EDA)阶段并且结束于集成电路的制造集成电路的简化工艺流程。
图1示出了示例数字集成电路设计和测试流程的简化表示。与这里所有流程图一样，将理解可以组合、并行进行或者在不同序列中进行图1中的许多步骤而不影响实现的功能。在一些情况下，仅当还进行了某些其它改变时，对步骤的重新安排将实现相同的结果，而在其它情况下，如果满足某些条件，则对步骤的重新安排将实现相同结果。读者将清楚这样的重新安排可能性。
图1的过程在高级别从产品构思(步骤100)开始并且用EDA(电子设计自动化)软件设计过程(步骤110)来实现。当设计完成时，进行制造过程(步骤150)以及封装和组装过程(步骤160)，从而最终获得成品集成电路芯片(结果170)。在步骤180中使用预先定义的测试矢量和预期响应在测试器机器中测试一些或者所有成品芯片。
EDA软件设计过程(步骤110)实际上包括多个步骤112-130，为了简化起见将这些步骤以线性方式示出。在实际的集成电路设计过程中，在步骤中可能需要返回特定的设计，直到通过了某些测试。类似地，在任何实际的设计过程中，这些步骤可以按照不同的顺序以及结合进行。以此，该描述是以上下文以及一般性说明的方式给出的，而不是作为针对具体集成电路的特定或是推荐设计流程。
现在将提供对EDA软件设计过程(步骤110)的组成步骤的简要描述。
系统设计(步骤112)：设计者描述其想要实现的功能，其可以执行假设(what-if)规划来细化功能、检查成本等。硬件-软件架构可以在此阶段进行。在此步骤，可以使用来自Synopsys公司的示例EDA软件产品，包括Model Architect，Saber，System Studio以及Design产品。
逻辑设计和功能性验证(步骤114)：在此阶段，编写用于系统中模块的VHDL或者Verilog代码，并且检查设计的功能性精度。更具体地，对设计进行检查，以确认响应于特定的输入激励将产生正确的输出。在此步骤，可以使用来自Synopsys公司的示例EDA软件产品，包括VCS，VERA，DesignMagellan，Formality，ESP以及LEDA产品。尽管某些设计可能在这一阶段已经包括某些测试设计特征，例如扫描链和关联扫描压缩或者解压电路，但是当这里使用术语“逻辑设计”和“电路设计”时在这些术语中并不包括这些特征
用于测试的综合和设计(步骤116)：这里，将VHDL/Verilog转换为网表。网表可以针对目标技术而优化。此外，进行测试的设计和实现，以允许检查完成的芯片。在此步骤，可以使用来自Synopsys公司的示例EDA软件产品，包括DesignPhysicalCompiler，Test Compiler，Power Compiler，FPGA Compiler，TetraMAX以及Design产品。一种用于实现测试架构的当前产品是DFTMAX，其具有如上所述的几个用户指定的配置设置。DFT MAX在Synopsys的DFT MAX AdaptiVe Scan Compression Synthesis，Datasheet(2007)中进行了描述，在此通过引用将其并入。
网表验证(步骤118)：在此步骤，检查网表与定时约束的兼容性以及与VHDL/Verilog源代码的对应性。在此步骤，可以使用来自Synopsys公司的示例EDA软件产品，包括Formality，PrimeTime以及VCS产品。
设计规划(步骤120)：这里，构建和分析芯片的总体平面图，以用于定时和顶层通路选择。在此步骤，可以使用来自Synopsys公司的示例EDA软件产品，包括Astro和IC Compiler产品。
物理实现(步骤122)：在此步骤进行放置(电路元件的定位)和通路选择(电路元件的连接)。在此步骤，可以使用来自Synopsys公司的示例EDA软件产品，包括Astro和IC Compiler产品。
分析和抽象(步骤124)：在此步骤，在晶体管级别验证电路功能，这继而允许假设细化。在此步骤，可以使用来自Synopsys公司的示例EDA软件产品，包括AstroRail，PrimeRail，Primetime以及Star RC/XT产品。
物理验证(步骤126)：在此步骤，执行各种检查功能，以确认制造、电子问题、光刻问题和电路的正确性。在此步骤，可以使用来自Synopsys公司的示例EDA软件产品，包括Hercules产品。
流片(步骤127)：此步骤提供用于掩模生产的“流片”数据以供光刻使用，以产生最终的芯片。在此步骤，可以使用来自Synopsys公司的示例EDA软件产品，包括CATS(R)系列产品。
解析度增强(步骤128)：此步骤涉及布局的几何操控，以改进设计的可制造性。在此步骤，可以使用来自Synopsys公司的示例EDA软件产品，包括Proteus/ProGen，ProteusAF以及PSMGen产品。
掩模预备(步骤130)：此步骤包括掩模数据预备以及掩模本身的书写二者。在此步骤，可以使用来自Synopsys公司的示例EDA软件产品，CATS(R)系列产品。
本发明的方面特别涉及上述“逻辑设计和功能验证”。
设计和功能验证是证明硬件描述语言电路设计满足电路设计规范的过程。虽然静态和动态验证方法均可用，但是由于静态方法要执行对硬件描述语言电路设计的形式化证明，因此其往往限于相对较小的电路块。动态方法依赖于对硬件描述语言电路设计的仿真，并且无法实现完整验证。为了对具有现代复杂度的数以百万计的门的硬件描述语言电路设计进行合理的彻底验证，仿真站运行具有不同条件(例如不同输入条件或者不同随机种子)的大量仿真。这样的仿真持续进行，直至一个或者多个合计覆盖度量令人满意。
鉴于计算资源增加而成本减少这一趋势，每当调节仿真模型时，本领域普通技术人员往往重新运行仿真以达到令人满意的一个或者多个覆盖度量的结果。
来自对硬件描述语言电路设计的已完成仿真的结果覆盖数据作为覆盖日志而存储在大容量储存中。各种电子设计自动化销售商一般具有其自己的专有覆盖日志，这些日志仅存储电子设计自动化覆盖数据，而不像Oracle、IBM、MySQL等的数据库那样存储通用数据。覆盖数据是有望在仿真期间发生的、令人感兴趣的条件或者属性集合。
在一些实施方式中，将合并覆盖日志。覆盖模型是想要在仿真期间观察的令人感兴趣的条件集合。每个仿真创建覆盖日志，该覆盖日志表示该仿真涵盖了覆盖模型的哪个部分。合并操作聚集覆盖日志，以计算覆盖模型的哪些部分总体上由所有仿真涵盖。
仿真按照包括功能覆盖和断言覆盖的硬件验证语言覆盖模型来执行。其它实施方式包括功能覆盖、断言覆盖和代码覆盖中的一个或者多个覆盖的各种组合。
覆盖数据在IEEE标准1800“IEEE Standard for SystemVerilog-Unified Hardware Design，Specification，and VerificationLanguage”中讨论，在此通过将其并入。对覆盖数据的以下讨论主要摘自这一IEEE标准。
覆盖组可以包含一个或者多个覆盖点。覆盖点可以是积分变量或者积分表达式。每个覆盖点包括与其采样值或者其值跃迁相关联的面元集合。面元可以由用户明确定义或者由硬件验证语言环境自动创建。覆盖点的面元可以由硬件验证语言环境自动建立或者被明确定义。
覆盖点面元或者面元将名称和计数与一组值或者值跃迁的序列相关联。如果面元指定了一组值，则每当覆盖点与该组中的一个值匹配时，计数递增。如果面元指定了值跃迁的序列，则每当覆盖点与整个值跃迁序列匹配时，计数递增。
因此，面元是标识进行仿真的硬件描述语言电路的属性的单位，从而使得在仿真之后，模型的覆盖度量是基于面元来计算的。覆盖度量是对验证硬件描述语言电路设计的进程的评估。覆盖模型是包括所有面元的合集，其包括面元的交叉点和面元的覆盖点。在一些实施方式中，将相同模型用于所有仿真，并且合并得到的覆盖数据。在其它实施方式中，至少针对某些仿真使用不同模型，并且有选择地合并得到的覆盖数据。
覆盖组可以指定两个或者更多覆盖点或者变量之间的交叉覆盖。将N个覆盖点的集合的交叉覆盖定义为：与这N个覆盖点相关联的所有面元的所有组合的覆盖，也就是N组覆盖点面元的笛卡尔积。自动交叉覆盖是自动生成的、覆盖点与另一覆盖点的交叉覆盖。
可以根据覆盖点的面元是由用户显式定义还是由工具自动创建，来有区别地计算覆盖点项目的覆盖。
对于用户定义的面元，将覆盖点的覆盖计算为以下i)和ii)之比：i)所覆盖的面元的基数(cardinality)，即覆盖的所有(已定义)面元的子集以及ii)所定义的面元集合的基数。
对于自动生成的面元，将覆盖点的覆盖计算为以下i)和ii)之比：i)所覆盖的面元的基数，即覆盖的所有(自动定义的)面元的子集以及ii)a)表示覆盖点所需的最少位数和b)auto_bin_max中较小的一个。
累计覆盖考虑所有有效面元的并集；因此，它包括所有实例的所有面元(包括重叠面元)的贡献。
为了确定覆盖组的特定面元是否被覆盖，累计覆盖计算考虑所积累的所有实例的at_least选项的值。因而，只有面元的命中计数等于或者超过所有实例的所有at_least值中的最大值，才认为该面元被覆盖。最大值的使用表示较为保守的选择。
图2-4给出了EDA验证(具体地，由覆盖驱动的验证)的一个实施方式。
所讨论的这一实施方式并不要求在可以合并所有覆盖日志之前创建这些覆盖日志。这一方式特别适合随机回归测试环境，其中，具有大量输入条件或者随机种子的随机测试每周7日、每日24小时的运行。由于覆盖日志是在创建最后覆盖日志之前进行合并的，所以在这一方式中所需的盘空间数量不再与测试次数直接成比例。类似地，无需等待最后的仿真完成运行便可以对合并的覆盖日志进行采样。维持未处理(未合并)的覆盖日志的流水线。对覆盖日志的早先聚集还允许在所有测试已经完成运行之前辅助对覆盖孔的标识和分析。“不良”激励被较早而不是较晚地揭示出来激励。
图2-4讨论如下。
图2是进行硬件验证语言电路设计仿真的系统的简化框图。该系统包括个体仿真客户端210、用以存储覆盖日志的文件系统220、位置储存库服务器230以及合并守护器(daemon)240。仿真客户端充当多个生产者，而“urg”合并守护器充当多个消费者，并且提供同步原语以维持队列的一致性。
个体仿真客户端210是个体随机仿真，其生成功能覆盖日志。每个测试客户端输出如下覆盖日志，该覆盖日志表示该客户端的目标覆盖模型的部分。每个客户端保证以下各项：
1)其不会超出不同仿真客户端的数据库目录的限制。
2)其将日志保持于可从如下机器访问的文件系统上，“Urg合并守护器”在该机器针对统一报告生成器而运行。
3)这些客户端使用接口(例如按照Perl)来与位置储存库服务器交互。
客户端向位置储存库服务器230通知覆盖日志在文件系统220上所在的目录。一种示例实现是利用以下示例性方法的面向对象的perl接口(例如VtgSimClientIntf)：
1)new：用以创建对象的构造器。取得两个必需变元和一个可选变元。
i)server：位置储存库服务器运行所在机器的名称
ii)port：位置储存库服务器运行所在端口号
iii)newmodel：这一变元可选。默认值是0。在设置成1时，其切换用于合并服务器处灵活合并的主模型。
2)dispatchLocation：用以向位置储存库服务器通知覆盖日志位置的方法。在成功时返回小xml串而在失败时返回undef。
例1：
use VtgSimClientIntf；
my $simcli＝VtgSimClientIntf->new(server＝>′vgamd84′，port＝>7070)；
      my   $retVal＝$simcli->dispatchDbLocation(“/u/foo/bar.vdb”)；
If successful the value of$retVal would be：
<dbsummary currdb＝″/u/foo/bar.vdb″/>
例2：
     use VtgSimClientIntf；
     my $simcli＝VtgSimClientIntf->new(server＝>′vgamd84′，port＝>7070，
newmodel＝>1)；
     my    $retVal＝$simcli->dispatchDbLocation(“/u/foo/bar.vdb”)；
此例将mergeserver(合并服务器)所使用的主覆盖模型切换为存储在/u/foo/bar.vdb下的覆盖模型。如果成功，则$retVal的值将是：
<dbsummary currdb＝″/u/foo/bar.vdb″/>
由于需要存储来自大量个体仿真客户端210的覆盖日志，因此用来保存覆盖日志的文件系统220总体上表示数量庞大的大容量储存。
位置储存库服务器230是轻量级服务器，其跟踪个体仿真所生成的各个覆盖日志目录的位置。它跟踪顶层目录位置。一些实施方式没有进行数据移动。
合并守护器240是计算密集过程，其查询位置储存库服务器230以取读覆盖日志列表进行处理。继而才能干文件系统220访问实际覆盖日志并对其进行处理。诸如urg(统一报告生成器)的聚集工具合并由个体仿真所生成的覆盖日志，以计算覆盖模型的哪些部分由验证组中的所有测试共同覆盖。合并守护器提供钩子(hook)，以便在完成所有覆盖日志之前对聚集的覆盖日志进行采样。
图3是图2的仿真系统的操作的简化状态图。
早先状态是启动合并服务器310。合并服务器启动并且能够接收覆盖日志，继而然后激活“serv_post_start_call_back”。这一回调用于提交在合并服务器脱机之时已经生成的任何覆盖数据。如果多个合并服务器运行于相同机器上，则选项“daemon_port_start”指定端口，合并守护器通过该端口运行。
中间状态是活跃状态310。随着仿真运行，当特定仿真作业完成时，它使用仿真客户端接口将覆盖日志位置提交到合并服务器。在这一状态，进行检查点回调。在合并预定数目的覆盖日志之后(在配置文件中可由checkpoint_granularity配置)或者按照定期间隔(可由time_granularity配置)，其激活用于每个合并守护器的‘检查点回调’。这一回调删除如下覆盖日志，这些覆盖日志没有添加任何值或是跟踪覆盖度量是如何改变的。
后续状态是停止合并服务器330。此时，其激活用于合并守护器的daemon_post_call_back。这进行清除活动、发送电子邮件等。
关于合并服务器钩子/回调的细节从A)-E)列举如下：
A)覆盖日志提交钩子：这一钩子允许覆盖日志提交到合并服务器以进行聚集。
B)位置服务器启动后回调：(图中的“serv_post_start_call_back”)这一回调在合并服务器启动之后便被激活，并且能够接收覆盖日志。这一回调应当用于提交在合并服务器脱机之时已经生成的任何覆盖日志(使用覆盖日志提交钩子)。
C)检查点回调：(图中的checkpoint_callback)按照经由以下参数配置的定期间隔来激活这一回调：
1)time_granularity：用户可以将这一参数设置成某个值(以秒为单位)，用以指示何时应当激活这一回调。例如，如果该值是1800秒，这将在每1800秒之后激活该回调。
2)checkpoint_granularity：用户可以设置这一参数，以指示应当多频繁地激活这一回调。例如，如果将该值设置成900，则将在合并每900个覆盖日志之后激活这一回调。
除了上述预定条件之外，激活这一回调并且生成覆盖报告的其它预定条件是已合并覆盖日志所达到的覆盖比例或者其它覆盖度量数量。
如果设置这两个参数，则无论哪个事件先发生都将激活回调。checkpoint_callback具有以下信息：
1)上次回调中每个度量的基本分数
2)对于合并的每个覆盖日志，检查点回调具有以下信息：2a)覆盖日志的名称；2b)每个度量的聚集覆盖分数
这一回调可以用来实现定制动作。下面是某些定制动作：
1)增量分级：如果用于覆盖日志的增量覆盖分数是零，则可以删除它。将测试所添加的增量覆盖构建到合并服务器所暴露的钩子中。因而，如果覆盖日志没有添加任何值，则可以立即删除它，由此，将所需大容量存储的数量大约界定为作为目标的可覆盖对象的总数。
2)监视覆盖分数如何随时间而改变：这一回调可以用来描绘覆盖分数如何随时间而改变。如果覆盖分数没有改变或者改变很少，则客户端可以尝试改变激励或者向真实个人(经由电子邮件/页面)指示需要采取的动作。
3)良好测试的备份：客户端可以确定特定的覆盖日志是否指示了覆盖分数的改变，或者覆盖了难以命中/覆盖的可覆盖对象，并且备份该测试。
一般而言，检查点回调命令能够与合并守护器异步运行。合并守护器不会等待脚本完成。检查点回调接口是能够处理xml文件的命令。如果该命令是‘cpcb’，则将在合并守护器创建检查点之后从合并守护器将该命令作为‘cpcb path-to-a-valid-xml-file’来调用。
检查点回调接口文件的示例方案如下：
<！ELEMENT checkpointed_databases   (basescore)(dir*)>
<！ELEMENT basescore(score*)>
<！ATTLIST  basescore  EMPTY>
<！ELEMENT dir(test*) >
    <！ATTLIST      dir path    CDATA#REQUIRED>
    <！ATTLIST dir error    (yes|no)#REQUIRED>
    <！ATTLIST dir newmodel      (yes|no)#OPTIONAL>
    <！ELEMENT test(score*)>
    <！ATTLIST test name CDATA #REQUIRED>
    <！ELEMENT score>
    <！ATTLIST score metric (assert|testbench|line|cond|fsm|branch) #
REQUIRED>
    <！ATTLIST score numerator    CDATA#REQUIRED>
    <！ATTLIST score denominator   CDATA#REQUIRED>
“basescore”元素包含用于测试的覆盖数据分数，所有覆盖日志目录都增量式地合并到其上。
“dir”元素表示已处理的顶级覆盖日志目录。属性“path”表明目录的位置。属性“error”表明在处理该目录之时是否出现错误。将错误细节重定向到文件“err.log”。
“分数”表示在逐个度量的基础上用于每个测试的覆盖分数。
示例检查点回调文件如下：
        <checkpointed_databases>
            <basescore>
              <score metric＝″assert″numerator＝″0″denominator＝″0″/>
              <score metric＝″testbench″numerator＝″0″denominator＝″0″/>
            </basescore>
            <dir   path＝″/remote/Vtghome6/manojb/demo/pr/junk/db_0″，
error＝″no″>
            <test
name＝″/remote/vtghome6/manojb/demo/pr/junk/db_0/results″>
            <score metric＝″assert″numerator＝″1″denominator＝″1″/>
            <score metric＝″testbench″numerator＝″0″denominator＝″0″/>
        </test>
         <test name＝″/remote/Vtghome6/manojb/demo/pr/junk/db_0/t3″>
             <score metric＝″assert″numerator＝″1″denominator＝″1″/>
             <score metric＝″testbench″numerator＝″0″denominator＝″0″/>
         </test>
         <test name＝″/remote/vtghome6/manojb/demo/pr/junk/db_0/test″>
             <score metric＝″assert″numerator＝″1″denominator＝″1″/>
            <score metric＝″testbench″numerator＝″47″denominator＝″50997″
/>
          </test>
         </dir>
         <dir    path＝″/remote/vtghome6/manojb/demo/pr/junk/db_1″，
error＝″no″newmodel＝″yes″>
         <test name＝″/remote/vtghome6/manojb/demo/pr/junk/db_1/results″
>
           <score metric＝″assert″numerator＝″1″denominator＝″1″/>
           <score             metric＝″testbench″          numerator＝″47″
denominator＝″50997″/>
        </test>
        <test name＝″/remote/vtghome6/manojb/demo/pr/junk/db_1/t3″>
          <score metric＝″assert″numerator＝″1″denominator＝″1″/>
          <score             metric＝″testbench″         numerator＝″47″
denominator＝″50997″/>
          </test>
          <test name＝″/remote/vtghome6/manojb/demo/pr/junk/db_1/test″>
             <score metric＝″assert″numerator＝″1″denominator＝″1″/>
             <score             metric＝″testbench″        numerator＝″47″
denominator＝″50997″/>
         </test>
      </dir>
</checkpointed_databases>
D)守护器启动前回调：(图中的daemon_pre_call_back)在合并守护器开始处理覆盖日志之前，激活这一回调一次。这一回调可以用来收集针对每个合并守护器的统计。
E)守护器启动后回调：(图中的daemon_post_call_back)当停止合并服务器时激活这一回调。针对每个合并守护器，激活一个这样的回调。这可以用来采取如以下动作这样的动作：
1.生成客户报告
2.发送电子邮件等。
图4是图2和图3的仿真系统的简化目录结构。
默认地，每个合并守护器在directory_prefix指定的目录内创建子目录。例如，对于由“./aggregated_data”指定的默认配置文件，创建图4的目录结构。“UrgDaemon_1/UserDir/MergeDb”是第一合并守护器创建的聚集覆盖日志。“UrgDaemon_1/UserDir/err.log”是由第一守护器完成的覆盖日志聚集的错误日志文件。将错误(损坏的覆盖日志、工具中的故障/崩溃)重定向到这一文件。
以下是在位置储存库服务器230上起动合并服务器的示例语法。
mergeserv[--config＝<config_file>]**start|--stop
config_file是合并服务器读取的[可选]配置文件。这一配置文件的示例格式提供如下。
--start：启动合并服务器。如果合并服务器已经运行，则这一选项无动作。
--stop：停止合并服务器。这发起停止序列。当已经合并所有提交的数据库之后，合并服务器退出。
xml格式的示例合并服务器配置文件如下。
<mserv_config>
 <location_serv port＝″7070″datadir＝”/u/regress_usr/locationdb”/>
 <serv_post_start_call_back command＝”submit_again”/>
         <merge_daemon num＝″2″directory_prefix＝”./aggregated_data”>
           <daemon_pre_call_back command＝”pre.pl”/>
           <merge_daemon_options        checkpoint_granularity＝”300”
time_granularity＝″900”/>
           <check_point_call_back command＝”foo.pl”/>
           <daemon_post_call_back command＝”post.pl”/>
         </merge_daemon>
       </mserv_config>
在这一示例默认配置中：
1)位置储存库服务器在端口7070上运行。
2)合并守护器的单个实例被激活。
3)所有合并守护器客户端在目录“aggregated_data”下创建聚集的数据。
4)合并服务器在属性datadir指定的目录之下存储的日志中维护未处理的覆盖日志的列表。在多个实施方式中，只有运行合并服务器的用户才具有对该目录的写权限。datadir的默认值是“.”。
运行合并守护器的多个实例是一种用来处理覆盖日志快速生成情况的性能优化。为了在相同机器上运行多个合并服务器，用于激活个体合并服务器的配置文件不应当相互冲突。具体而言，配置文件中的以下条目不应当冲突。
i)location_serv port
ii)datadir
iii)directory_prefix
iV)daemon_port_start
与合并服务器一起使用的任何回调脚本也不应当修改相同系统资源。例如，如果检查点回调在某一文件/目录中保存有用测试信息，则个体回调脚本所用文件/目录应当针对各合并服务器而不同。
这里是用于在相同机器上运行两个合并服务器的样本配置文件示例。
        <mserv_config>
          <location_serv port＝″7070″datadir＝”/u/regress_usr/locationdb”/>
          <serv_post_start_call_back command＝”submit_again”/>
          <merge_daemon num＝″2″directory_prefix＝”./aggregated_data”>
             <daemon_pre_call_back command＝”pre.pl”/>
             <merge_daemon_options    checkpoint_granularity＝”300”
time_granularity＝″900”/>
             <check_point_call_back command＝”foo.pl”/>
             <daemon_post_call_back command＝”post.pl”/>
           </merge_daemon>
         </mserv_config>
           <mserv_config>
           <location_serv port＝″7071″
    datadir＝”/u/regress_usr/locationdb.second”/>
           <serv_post_start_call_back command＝”submit_again”/>
           <merge_daemon num＝″2″
    directory_prefix＝”./aggregated_data.second”>
               <daemon_pre_call_back command＝”pre.pl”/>
               <merge_daemon_options    checkpoint_granularity＝”300”
time_granularity＝″900”daemon_port_start＝”14449”/>
               <check_point_call_back command＝”foo.pl”/>
               <daemon_post_call_back command＝”post.pl”/>
           </merge_daemon>
        </mserv_config>
前文主要涉及合并覆盖日志，而下文主要地涉及合并特定覆盖日志的技术。
图5A和5B是对比通过合并而不是丢弃在先覆盖日志的改进仿真流程的简化流程图。鉴于计算资源增加而成本减少这一趋势，每当调节仿真模型时，本领域技术人员往往如图5A中所示重新运行仿真，以达到令人满意的一个或者多个覆盖度量的结果，而不是保留来自旧仿真模型的覆盖日志中的任何覆盖数据。
图5A的过程流程如下。在501中创建功能覆盖模型。在503中从某输入条件或者某第一随机种子开始运行随机仿真。在505中合并仿真所生成的覆盖日志。在507中分析合并的覆盖日志。在509中细化(refine)功能覆盖模型。当在511中删除先前覆盖日志之后，该过程流重复。
图5B的过程流程修改图5A的过程流程。在504中，利用新的输入条件或者新的随机种子运行随机仿真，而不是从503中的某输入条件或者某第一随机种子开始随机仿真。在512中，导入先前覆盖日志而不是如511中一样删除覆盖日志。
当覆盖日志在完成所有仿真时进行合并或者如上文结合图2-4讨论的那样在完成最后仿真之前进行合并时，都可以应用图5B的技术。
下文的示例使用System Verilog样式语法来表示覆盖日志，但是同样适用于具有相当语法的任何硬件验证语言。日志T1代表较旧的覆盖日志。日志T1代表较新的覆盖日志。合并的日志代表合并相应覆盖日志的结果。每个示例之后伴有说明。
例1：