日志

生成唯一覆盖类，以启用有意义的覆盖组

已有 1475 次阅读| 2017-7-23 14:45 |个人分类:验证前沿资讯|系统分类:硬件设计

定义一个sv的覆盖组，可以通过在一个组件里包含它或者将它导入到组件里的不同方式。第一种情况下，覆盖组将在仿真器结构层次中具有和其在验证组件中相同的类型路径，这个类型路径将因tb的不同而不一样，因此通用性会差一些。

如果覆盖组在验证组件之外通过覆盖类定义，然后导入到组件里，又会出现另一个问题：覆盖组类型变成了静态的，从而不能提供特性来满足特定的验证需求。

解决覆盖组问题需要组合跨验证环境上的覆盖组实例来创建一个有意义的合并结果。一种可能的方案是执行手动模式来匹配仿真器之外的覆盖组和覆盖驱动的测试计划中的代码库，以满足验证需求。但这种方法不是最佳的，因为这易于出错并且面对设计变化很脆弱。验证环境应该产生这些关联的覆盖组类型。

源码资源：

本文中提出的想法通过使用示例验证环境来演示，示例源代码见下面链接：

https://github.com/tenthousandfailures/uniquecoverage 

DUT及验证需求:

为了解释方法和结果，简单描述下实例环境还是很有必要的。tb采集DUT(里面包了一个FIFO)命令并将它们转发给另一个相同的DUT,TB范围随着FIFO链的变化而变化，但都只包含相同的组件和连接，整个DUT如图1所示：

此示例用于模拟在验证环境中发生的真实情况。 小测试平台封装了DUT的一部分，然后包括更多和更大的DUT组件集合需要逐步被集成在更高阶的测试平台上。

SV解决方案：
图12展示了sv代码模板，包含唯一的嵌入式覆盖组。这个模板定义了new函数（实际调用super.new函数），并实例化覆盖组dut_if_cg. 对父类采样很重要，因为子类可以在其所有父类中触发采样。 这提供了与嵌入式覆盖组行为的兼容性，并允许聚合父类覆盖组类型。
抽样。
图14显示了参数化的SystemVerilog接口dut_if。 为了简化本示例，类型传入的是T; 然而，在实际中，可以使用更具描述性的名称。 这个
参数化是嵌入式覆盖组和所提出的唯一嵌入式覆盖组之间的重要区别。
图15显示了测试平台TB0的实现，sv接口dut_if连接dut和tb。这个tb的显著特点是接口被参数化，比如接口被实例化为dut_if_b_c时，传递了一个唯一的嵌入式覆盖组uniq::b_c。
UVM解决方案：
之前的sv解决方案在interface里使用了唯一的嵌入式覆盖组，属于用sv搭建的验证平台。然而如今很多验证环境都是用的UVM框架，UVM解决方案使用唯一的嵌入式覆盖组如图16所示：
UVM验证环境的框图显示了UVM代理如何传递其唯一的嵌入式covergroup参数化到其子组件。 因为代理实例化它的子组件，包括cov类，有必要参数化UVM代理，以便它可以通过在build time时正确的参数化。在哪实例化覆盖对象因验证需求而不同，在这里，目标是能够收集DUT组件之间的接口覆盖数据，因此，使覆盖类实例化在代理中，给上下文和UVM层次结构提供覆盖的接口。

程序包TB0_pkg中显示在图17中，定义typedefs使得将来更新参数化agent变得更加容易，_t后缀被添加以表示类型。不像在sv方案中使用唯一的嵌入式覆盖组参数化interface,而是参数化UVM agent.
在env中将agent的句柄给DUT，并在build phase时实例化agent,如图18所示：
总结：
使用覆盖组实例还是覆盖组类型引用需要权衡，任何一种情况只能合并特定的覆盖组，这取决于覆盖组类型路径。本文提出了一种方法来改进嵌入式覆盖组，是通过克服覆盖组实例和覆盖类型引用的限制实现的。

UML类图显示了如何将覆盖组按类结构分层，嵌入覆盖组的行为保留在基类中，这些基类的子类在实例化时复制包含的这些覆盖组定义。本文介绍如何在SystemVerilog和UVM中实现该提议，并提供了示例的完整源代码。

使用覆盖组的每种方法都会扩展其父类的功能，从简单的covergroups到嵌入式覆盖组，以及到独特的嵌入式覆盖组。增强版的嵌入式覆盖组不仅允许前面提到的所有标准行为，而且增加了跨tb合并覆盖组的功能。

唯一的嵌入式覆盖组增加的功能是一个引人注目的改进：覆盖驱动的测试计划渴望类型覆盖，因为它们不必处理设计层次，独立提供；而独特的嵌入式覆盖组可以在设计周期的早期就提供有用的和特定的覆盖类型引用，使得在每个验证环境都能追踪覆盖度量。