MDV流程在geMac验证中的应用

张海波

(深圳市中兴微电子技术有限公司，广东 深圳 518055)

MDV流程在geMac验证中的应用

张海波

(深圳市中兴微电子技术有限公司，广东 深圳 518055)

在验证工作中，验证工程师通常先编写验证计划(verification plan，vplan)，然后根据它来编写验证用例(testcase)。在项目进展的过程中，设计方案会不断的修改更新，那么一段时间后，就会出现设计方案、验证计划和验证用例不匹配的情况，验证计划本身容易流于形式；另外验证工程师也需要定位问题、回归用例、向验证经理汇报工作，工作内容繁多。文章通过 geMac验证实例，介绍了如何借助 Cadence公司 vManager验证工具的 regression center、Metric Center、Tracking Center，更加高效科学地开展验证工作。

testcase；vplan；geMac；vManager

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.1vsif和仿真脚本

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

图3　vsif文件部分内容

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

1.2vplan和验证平台 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.1testcase和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.2Coverage分析

验证过程中需要在适当的里程碑节点关注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_intf-Format/RVC_pcs2mac_metric，在仿真中相对其他 testcase而言，对 coverage的贡献是 67.74%；而那些 delta_tess-RankRuns(Rank)为 0的行，表示，在这次仿真中，相对其他的几次的仿真，对coverage没有任何额外的贡献。值得注意的是 RVC_pcs2mac_metric在第一行中 delta_tess-RankRuns(Rank)为 67.74%；而在最后一行中 delta_tess-RankRuns(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，比较直观地了解到这几个工作日用例执行的情况；在 tracking center中，也可以 tracking coverage的情况，通过 tracking coverage，验证工程师能够更好地调整用例的执行，否则即使用例 pass再多，coverage一直很低，或者一直维持在一个恒定的水平，那么说明 testcase设计的不够合理，或者是没有使用随机化种子。

图14　增加多个session

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

图15　tracking metric

图16　coverage图表

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

图17　生成Report

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

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

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.

Practical application of MDV in geMac verificaton

Zhang Haibo
(Shenzhen Zhong Xing Microelectronics Co.，Ltd，Shenzhen 518055，China)

Verification engineer usually write verification plan(vplan)at first,and then write testcase according to the vplan.However,after a period of time，the testcases do not match the verification plan,and in this case the verification plan is a mere formality.Moreover,verification engineer the verification engineer needs to debug problems,regress,and report to verification manager about the process of jobs.Various things need to be done.This paper whick takes geMac Verfication as an example，and with the help of Cadence’s vManager,using vManager’s regression center,Metric Center and Tracking Center demonstrates how carry out verification job more efficiently and scientificly.

testcase；vplan；geMac；vManager

TN402

A

10.16157/j.issn.0258-7998.2016.08.010

2016-06-16)

张海波(1985-)，男，主要研究方向：芯片设计验证。

中文引用格式：张海波.MDV流程在geMac验证中的应用[J].电子技术应用，2016，42(8)：48-52.

英文引用格式：Zhang Haibo.Practical application of MDV in geMac verificaton[J].Application of Electronic Technique，2016，42 (8)：48-52.