0 引言

　　在传统的验证流程中，通常会先编写好验证计划（verification plan，vplan），然后再编写验证用例（testcase）。但是由于项目需求、规格变更，验证计划和testcase会有着比较大差异的情况，testcase不能真实地反映验证计划，而验证计划就失去了其指导testcase编写的本意。要避免这种情况发生，就需要工程师手动对验证需求、覆盖目标、覆盖结果进行管理和跟踪，使得验证迭代过程变得繁琐，耗时，降低验证效率。

　　借助于vManager，通过完整的标准度量驱动验证（Metric Driven Verification，MDV）流程参见图1，可以很好地解决上面存在的问题。MDV验证方法使用功能覆盖率，仿真正确性检查和断言作为验证需求通过准则(Metrics)，并使验证计划成为验证过程本身的一个可执行的(executable)部分，即使用验证过程自动化工具制定（或读取）验证计划，并收集覆盖数据，产生基于验证计划的状态报告。使得验证计划在整个项目周期内充当验证过程检验标准的角色。

图1  完整的MDV流程

1 建立executable验证计划

　　验证计划的编写是整个MDV流程的开始，在MDV流程中通过vplanner进行编写验证计划，如图2所示，在vplanner中添加了两个用例[1]。在这里一开始并没有编写完全部的验证计划，主要是基于以下两个原因：(1)验证计划是一个逐次迭代的过程，随着验证工作的展开，以及对DUT(Design Under Test)理解的加深，验证计划会修改多次，所以一开始，先编写两个简单用例，跑通数据流，为后续工作的开展，奠定坚实的基础；(2)以这两个testcase为例，重点介绍如何将所编的vplan和testcase建立一种关联，而这种关联的建立，是MDV流程的基础，同时它能够使得验证计划和testcase的更新相互促进。

图2  vplanner编写testcase

　　1.1 vsif和仿真脚本

　　vsif(Verification Session Input Format)文件是整个MDV流程的重要组成部分，该文件中描述了vManager在启动仿真时，需要执行的用例、仿真时需要执行的脚本、每个用例最长的仿真时间等内容[2]，根据文献[2]的方式，编写的debug_tb.vsif文件的部分内容如图3所示。

图3  vsif文件部分内容

　　在这个group geInternal_intfFormat里面，设定了这个group中用例需要执行的次数、所使用的种子、用例的名称、以及这个用例所执行的模式，同时也可以根据自己的需要设定其他的一些信息。

　　1.2 vplan和验证平台testcase/覆盖率模型(ucm)建立关联

　　在vManager中launch一个vsif（Verification Session Input Format）文件，待仿真结束后，在vplanner中load某个 session，然后进行验证平台中的testcase和vplan中的testcase建立关联的操作，如图4所示。

图4  选中对应的session

　　接下来，点击Metrics标签，然后窗口左右两边选中对应的testcase，点击map建立关联， Map之后，需要对vplan进行保存。

　　通过前文的介绍，已经建立了vplan与testcase的关联，通过这种关联，在vmanager中可以实时地查看vplan中相关feature的覆盖情况（不仅仅局限于Testcase，同时也可以包括assertion、function coverage等，图5中仅以testcase为例，关于assertion也将在下文介绍），通过这种图形化的显示，可以让验证人员更加直观地了解到vplan中哪些feature尚未被覆盖，可以及时调整工作方向和工作重点。

图5  vplan中的覆盖情况

2 多维度度量分析

　　当仿真进行到一定阶段之后，需要进行testcase、assertion、coverage三个方面的分析，表现在vplan中的testcase被执行了多少，还剩余哪些；assertion 是否被触发；coverage达到了多少，哪些testcase对coverage的贡献最新，所有的这些分析在Analysis Center中完成。

　　2.1 testcase和assertion分析

　　首先，按照上一个小节介绍的方法，增加相关用例，然后在vManager中launch相关vsif文件，仿真结束后在vplan中load相关session，那么接着就可以在vManager中进行分析，图6中展示了部分testcase的覆盖情况：

图6  vplan分析

　　从图6中可以看到在vplan中关于1.1.1的gmii的testcase这一Metric已经被覆盖了，单从testcase上说，暂时可以告一段落了，后续如果再需要添加相应用例的话，也可以按照上面的前文所述之方法进行相对应的分析。

　　正如前文所言，验证工程师需要从多个维度展开验证工作，testcase的编写只是一方面，断言assertion也是非常有用的手段，添加assertion之后，这些assertion是否被触发，是否成功都需要关注。在MDV中，assertion也可以反映在vplan中，而且可以与testcase类似进行相对应的map，在vplan中添加的断言如图7所展示。

图7  vplan中添加assertion

　　在仿真结束之后，load相应的session，在vplan中可以进行如图8的map。

图8  对assertion进行map

　　完成map之后，可以对assertion进行分析，如图9所示。

图9  assertion覆盖情况

　　通过上面的操作，可以将所编写的assertion清晰地展现出来，其优点体现在以下几个方面：

　　(1)整个验证计划中有哪些assertion，可以清晰地展现。

　　(2)assertion是否被覆盖可以在vplan分析中容易被发现。

　　不会在regression中遗漏assertion。这是因为assertion对仿真速度有着很大的影响，可能在某次仿真中，验证工程师“关闭”了assertion，但是在后期的regression中又忘记“打开”，而使用vplan进行map以及在vmanager中对vplan进行分析，就可以很好地避免这种情况的出现。

　　2.2 Coverage分析

　　验证过程中需要在适当的里程碑节点关注DUT的coverage情况，以便及时地添加用例，同时在regression时，确定哪些用例对覆盖率贡献比较高，那么在regression的时候，就可以优先回归；而对覆盖率贡献比较低的testcase，可以分析其原因加以改进。另外在覆盖率分析的时候，可能某些特定的模块和开发沟通之后知道它是冗余的或者不需要覆盖，而这些不需要覆盖的模块可以通过在coverage分析的时候将其“剔除”，最终使coverage达到可解释的100%如图10所示。

图10  coverage分析

　　我们可以通过图10对coverage的情况有直观的了解，同时也可以在instance名字，比如GE4_MAC_TX上右击，然后进行更加细致地分析比如Block Analysis、Expression Analysis、FSM Analysis等，关于这些细节这里不再进行详细地探讨，留给读者自行尝试。这里介绍如何确定testcase对coverage贡献的情况，那么在后续regression时，可以优先执行对coverage贡献大的用例。

　　在Analysis Center中，执行Rank Runs操作，其方法在图11给出了描述。

图11  Rank Runs

　　在Rank Runs的结果中，需要重点关注两列。testRankRuns(Rank)，这一列显示出用例对覆盖率整体的贡献大小；另外一列是delta_testRankRuns(Rank)，它显示了在所有罗列的仿真中，本次仿真用例相对于其他用例，对coverage贡献的大小。例如第一行的geInternal_intfFormat/RVC_pcs2mac_metric，在仿真中相对其他testcase而言，对coverage的贡献是67.74%；而那些delta_tessRankRuns(Rank)为0的行，表示，在这次仿真中，相对其他的几次的仿真，对coverage没有任何额外的贡献。值得注意的是RVC_pcs2mac_metric在第一行中delta_tessRankRuns(Rank)为67.74%；而在最后一行中delta_tessRankRuns(Rank)为0%，这是因为在仿真中用例可能被执行多次，而且每次的seed都有可能是随机的，那么就会出现同一个testcase对coverage贡献不同的情况。

3 项目级别状态进展汇报

　　3.1 项目进度状态跟踪

　　验证工程师不仅要完成日常工作，还有需要将工作之进展向验证经理进行汇报，在vManager中提供了非常方便的Report功能，生成Report的格式也可以是多样的；另一方面，作为验证经理也需要关注每个验证工程师testcase执行的情况，如testcase总数、pass多少、失败多少；或者是在某个时间段内，验证工作的进展。vManager的Tracking Center提供了非常便捷的方式，以多样化的图表展示出验证工作的进展。

　　首先，需要Taking snapshot，选中所要分析的sessions，然后执行如图12中所示的操作。

图12  take snapshot

　　在Tracking Center中，可以看到生成的表格颜色，其中bar的颜色是可以自己设置的，从图13中可以看到这个session中，用例总共是6个，pass和fail都是3个。

图13  用例执行情况（toatal、Pass、Fail）

　　按照上面的方法，可以再增加一些session，其结果如图14所示。

图14  增加多个session

　　通过图14，比较直观地了解到这几个工作日用例执行的情况；在tracking center中，也可以tracking coverage的情况，通过tracking coverage，验证工程师能够更好地调整用例的执行，否则即使用例pass再多，coverage一直很低，或者一直维持在一个恒定的水平，那么说明testcase设计的不够合理，或者是没有使用随机化种子。

　　基于这样的考虑，我们进行在tracking center中查看coverage的情况，其主要步骤如图15所示。最终的结果如图16所示。

图15  tracking metric

图16  coverage图表

　　验证工程师，生成了所需要的数据，可以将结果反馈给验证经理，数据结果的生成也是比较简单的，点击Create Report，然后选择相应的路径即可，如图17所示。查看生成的最终结果如图18所展示。

图17  生成Report

图18  最终的html格式图表（部分内容）

　　通过上面的操作，将所感兴趣的内容最终以html格式的文件向验证经理进行汇报，通过图表，更加直观地展示了工作的进展，coverage的趋势，有助于降低项目的风险，节省项目管理所需要的时间。

　　3.2 基于server的项目管理

　　在上一个小节中，提及了验证工程师如何向验证经理汇报工作进展，作为验证经理，从项目管理的角度，需要知晓团队中所有的验证工程师的工作进展，而传统的EDA工具无法让验证经理实时知晓每个人的进展，用例执行情况，用例耗时等信息，这些信息需要在周末或者月末汇总之后才可以得知。

　　vManager是基于server进行管理的，server的地址以及端口号，需要设置在环境变量中，设置完成之后，验证工程师在自己的服务器上启动vManager，launch vsif文件启动仿真时，这些信息会传递到server上，验证经理可以在自己的服务器上启动vManager，在regression Center中查看每个人的情况，如图19所示。

图19  查看项目中所有的seesion

　　当然验证经理也可以在tracking Center中查看到所有session状态，如pass, fail, session duration time等等，如图20所示。

图20  查看团队中所有用例执行情况

4 小结

　　Cadence vManager作为MDV验证方法的实现工具，将项目验证过程变得自动化和可管理化。本文由vplan和session如何建立关联开始，详细地介绍了建立关联的意义以及流程。接着向读者展示如何借助于vManager进行testcase分析，assertion分析，重点介绍了如何在Coverage分析时，如何借助于Rank Runs查找对覆盖率贡献最大的testcase。最后介绍了验证工程师如何利用tracking Center生成相关报告，以便更加直观地反馈自己的进展以及所负责模块的覆盖率趋势；验证经理如何利用regression Center查看团队session执行的情况，以及在Tracking Center中以图表的形式查看整个团队session执行的情况。

　　验证质量的提升与MDV验证方法的实施紧密相连。工具本身并不能保证验证的完备性，但其具备的制定可执行验证计划，自动回归验证管理及仿真数据管理，覆盖率分析，以及验证进度可视化等功能为MDV验证方法的实施提供了强有力的支撑，为验证过程中大量耗时管理工作节约了时间，使验证工程师能够有更多时间专注于设计本身，对设计中功能点进行详细分析和验证，以提升验证完备性。

　　当验证计划发生变化时，所有改动都能够被工具记录，跟踪并保证最终能得以验证，因而可执行的验证计划在整个验证过程中都是有意义的一部分，而非如传统验证计划，在项目初期完成后就很少被使用。同时，可执行的验证计划使验证进度变得透明，帮助验证团队提高验证可预见性，以及更好的利用资源。

　　参考文献

　　[1] Cadence.2_mdv_foundations_planning workshop.pdf.

　　[2] Cadence.3_mdv_foundations_infrastructure_workshop.pdf.