日志

欺骗你的覆盖率（下）

已有 1428 次阅读| 2017-7-30 13:43 |个人分类:验证前沿资讯|系统分类:硬件设计

五、测谎器

不幸的是，在不同的验证抽象级别的环境中，没有用于验证功能覆盖模型的正确性和完整性的银弹，考虑到覆盖结果在验证流程中的重要性，这代表了重要的风险。本节为改进方法提供了一些务实的指导，包括覆盖模型构造的建议以及分析运行过代码的覆盖率的准确性。此外，我们还尝试了自动化的一些方面，随着工具开发人员对这个重要问题的重视，它很可能在未来进行扩展。

A、复审

1.覆盖结构和计划的复审

验证结构开发期间，在执行覆盖代码之前，有必要对每一个细节进行分析，以减少不准确性和遗漏。关于对功能覆盖规划的过程和要求的讨论不在本文的范围内。

对于验证环境的每个组件，我们应该创建一个详细的覆盖信息表：

涵盖了什么内容（项目和范围）
在什么时间采样事件发生（事件时间）
在什么条件下允许采样（逻辑条件）

应该考虑覆盖的所有方面，包括事务字段，配置设置，控制，状态，时间关系，检查等。这里的目标是简洁和完整。在实现之前，就应对覆盖计划进行审查，以便检测缺失、不相关和不正确内容。这种对条件和时序方面的分析非常重要，这些通常被缺乏经验的团队忽略，导致验证计划过度重视事务内容，并且验证的不充分。不推荐将条件和时序方面的细节放到实现阶段实现，因为这样它们更难以复审且更容易出错。

2.覆盖执行复审

一旦验证环境处于成熟的开发阶段，就有必要对功能覆盖代码进行复审。特别是根据计划的覆盖范围复审覆盖执行情况，寻找不准确和缺失的项目以及由不良采样、分组或触发导致的覆盖率。尤其是：

是否所有的计划项目都被实际的代码执行到了？
是否在代码库中清楚的记录了未执行的项目？
用于覆盖点的正确范围是否被键值正确的隔离？
覆盖点是否仅在正确的逻辑条件下被记录？
覆盖组的采样时间是不是相关内容被DUT使用到的时间？
交叉覆盖率的范围、相关性是否正确，是否可实现？
在复用来自其它VIP的覆盖率时，是否针对当前的应用进行了正确的调整？
是否所有检查都有对应的覆盖项目来确定项目通过的条件？

覆盖执行复审的其它方面包括编码风格、风格和控制。重要的是，覆盖被正确地封装在允许被重载的类中，以使得用户在需要时能轻易地替换。同样，要确保没有用到覆盖是从模型中真正的移除而不仅仅是阻止覆盖组的采样。

此覆盖复审需要在执行代码是进行，而不是在项目结束时进行。因为我们的目标是对缺陷进行识别和修复，而不仅仅是提供覆盖复审的报告。

B、覆盖分析

通常，覆盖分析比较重视相关覆盖率数据库工具给出的漏洞以及没有覆盖到的点。而本文重点是分析覆盖率报告的准确性，以确定模型的正确性。

仅仅独立于环境实际的行为来分析覆盖率的执行和结果是远远不够的。在项目开发的各个阶段，应该根据对不同的测试场景的观测来分析覆盖范围。复审员可以选择几个特定的测试（除了最简单的测试外，还要包括适当的扩展功能的测试）进行验证：

告中的覆盖是否真正的在测试中发生
对于没有发生的时间没有多余的覆盖被写到报告中
所有有必要的激励情况都被可观察到的覆盖记录
所有相关的检查都有对应的覆盖，并且没有多余或缺失的检查被报告

换句话说，分析实在报告的结果中针对实际测试情况寻找欺骗、省略和制造的谎言。这需要对应用和测试平台的环境有深入的了解。

作为示例，考虑图4所示的数据包交换情况。对于特定的测试场景种子，我们向DUT发送了10个不同的数据包，其中一个被注入CRC错误以使它无效。

在分析细节行为时多方面参考验证环境的各个方面是非常重要的。这不仅仅是我们在这个分析中关注的特定覆盖点的成功命中，而是每个bin的绝对得分 - 包括类型和基于实例的覆盖结果的分布。 对于当前示例，我们覆盖率多方面的参考如下：
日志文件告诉我们在每个接口上观察到了什么事务：
是否所有的事物字段在覆盖率中被正确的报告？
诸如包长度这样的元数据和延时这样的元数据的情况如何？
是否记录了过多的非相关字段的数据（像数据包的实际内容）？
错误是否在事务覆盖率中被正确的报告？
波形说明了各个事务的相对时序：
接口上事务的关系是否被覆盖率正确的记录（例如overlaps）？
是否有重要的事务排列事件需要报告（例如overtaking）？
延时是否被正确的测量和报告？
覆盖率能否反应有多少数据包正在DUT中使用？
覆盖率能否反应在一个特定的时间点有多少进程正在进行？
观察到的时钟关系能否由覆盖率正确地报告？
检查由断言（协议），监视器（内容）和记分板（关系）展现：
执行了哪些检查，它们是否被反应到了覆盖率中？
观察到的断言和记分板以及事务覆盖率匹配吗？
覆盖率是否反映记分板模型也过滤了数据包？
寄存器或者协议信号中的错误检测产生的影响是否被覆盖到了？
这种对于覆盖率细节的整体分析与所观察到的情况进行对比能够快速找到覆盖模型中的一些主要缺陷和遗漏。通常我们可以确定激励和检查时有效的，但不能保证具体的情况被良好地反映到了覆盖率中。该分析过程的正确结果还提高了对于整个验证环境和覆盖率准确性的信心。
C、自动化
就目前的技术而言，实现自动确定什么类型的功能覆盖率适应于大多数高层协议的适用场景是比较困难的。当然，一旦确定，就可以自动生成覆盖模型并将它与DUT参数想适应，但这并不是本文的重点。
一个更值得注意的是“我们能够自动的验证给定覆盖模型的功能覆盖率的准确性和完整性吗？”。在一定程度上这是可能的，因为我们需要的是一个基于一定规则的应用程序，正如前文所述的手动分析的那样。作者不知道是否有这样的工具，为了展示这一概念，我们尝试着使用统一覆盖互用性标准（UCIS）和（PyUCIS）来验证覆盖率。UCIS是一个开放的行业标准，提供了一个应用程序编程接口（API），可以使来自不同供应商的多种工具（例如模拟器，加速器，正式工具，定制工具）实现覆盖率数据互通。PyUCIS是一个SWIG / Python包装器，能够提供比原始C代码实现更简单的用户体验。UCIS的其他应用包括动态激励适应，测试分级和同化来自多个来源的覆盖报告。
使用UCIS交叉参考检查和覆盖率
基本原理是来自于接口的SystemVerilog 断言（SVA）的覆盖率和来自不同的基于类的功能覆盖组都在覆盖率数据库（UCISDB）中，因此至少在交叉覆盖检查的一些方面可以使用UCIS，如图5所示：
为了尝试这种新颖的方法，我们选择了一个OCP验证环境，具有探知配置的断言（启用或不启用基于配置文件的配置）和基于类的事务覆盖。 使用UCIS，我们可以访问和比较：
断言和基于类的覆盖率的得分
接口中不同断言的得分
基于类的覆盖率的不同方面
理论上，断言结果与所观察的事务的功能覆盖之间存在牢固的关系，例如，如果我们得到N个有效的协议断言通过，则对于事务覆盖的任何方面，我们不应该具有大于N的分数。同样地，可以比较不同的断言分数，例如，对于协议的不同阶段的请求（请求，数据握手，响应）应当具有基于事务类型的适当的覆盖得分。还可以在环境中的组件和层之间比较基于事务的覆盖，例如，可以将事务覆盖中报告的协议错误数量与来自记分板的检查器覆盖进行比较。
UCISDB用于存储分层信息（scope）和覆盖计数（coveritem）。 为了访问所需的仓的计数信息，我们需要打开UCISDB，并迭代地搜索scopes，直到我们匹配所需的coveritem名称，然后我们可以提取覆盖计数。 请注意以下代码段：
我们通过python助手来从指定的路径中查找UCIS范围，返回字符串或者正则表达式（pyucis_find_scope），并从UCISDB中提取相应的coveritem（pyucis_get_count，pyucis_get_cov_count）的覆盖率，代码如下所示。这些辅助方法也可以通过PyUCIS获得。
在我们的环境中我们执行了一个Python脚本作为单次仿真和回归完成的后续处理步骤。为了访问所需的bin的命中信息，我们需要打开UCISDB，例如：
特定的应用程序规则对应的覆盖点被硬编程到用户脚本中。例如，在OCP中，我们可以检查命令覆盖率是否能与命令相关断言通过的数量相匹配（MCcd在请求阶段的时间内必须保持稳定）：
对于OCP，由于配置文件的配置以及一些断言在每个阶段多次触发，许多覆盖检查更加复杂。例如，burstlength配置字段标识是否存在MBurstLength。如果是，在请求阶段的每个时钟用断言检查它的值。如果burstlength被配置过有效（cp_burstlength bin “1”被命中），我们只需检查该覆盖点的覆盖率从未获得比总共的断言得分更高的分数。
在这个概念验证阶段，我们确定了大约40个规则（并非所有这些规则都已实施），包括60个断言和包含30个覆盖点的5个覆盖组。在对这些联系不同覆盖组的规则进行编码和验证的过程中，和使用不同配置文件进行配置的回归运行中，我们能够检测到：
不正确的断言编码导致的高于预期的分数
对于事务内容的一些方面的误导性的功能覆盖率
需要注意的是，这个级别的交叉检查仅仅是实际执行过的项目的覆盖验证的一个方面。实际上，实际上，使用UCIS验证覆盖范围仅仅为我们提供了可用覆盖范围的健全性检查。这个技术也可以进行扩展，为可复用验证组件的覆盖率和断言方面提供一些单元测试。此外，该技术还展示了它在未来的环境中实现覆盖验证自动化的潜力。