日志

欺骗你的覆盖率（上）

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

摘要

功能覆盖率是保证验证过程整体完整性的关键指标，然而有很多证据表明覆盖率模型往往不准确，不完整和具有误导性。作者这种覆盖缺陷是非常常见的，并且覆盖分析往往集中于没有覆盖到的点而不是已经覆盖到的点的准确性，因此验证过程的整体质量存在着重大的风险。在对问题进行一般性介绍后，本文讨论了实际案例，并提出了实用的解决方案，以提高验证质量和最小化风险。最后，我们演示了USCIS API的一个应用程序来相互参照功能覆盖率各个方面的数据，以确保验证模型在各种情况下的正确性。

一、介绍

目前看来，许多团队在使用功能覆盖率时，没有严格分析他在验证模型中的准确性。作者的调查包含了多个公司、多个项目、多种语言。本文不提供解决所有这些问题的有效方法，而是通过全面讨论和实践示例提高认识，提供实用的方法指南，并讨论未来可能的工具和方改进方法。所有这些都为了提高验证质量和展现更真实的功能覆盖。本文所提出的概念是与语言无关的，但是所使用的任何术语都来自SystemVerilog和通用验证方法（UVM），以便理解。

二、覆盖率

功能覆盖对于约束随机验证（确定实际产生和检查什么激励）以及对于定向测试（验证测试是否实现其预期目标）是有益的。功能覆盖率来自多次运行、使用不同种子的多个测试用例，它被整理到单个数据库中来给出验证状态的总体测量值。虽然测试平台的激励的范围和质量是一个关键的指标，但是更要注意的是，功能行为的所有方面也需要检查，仅仅覆盖到是完全不够的。

代码覆盖率仅识别被测设备（DUT）中的那些代码被验证环境激活，但不识别这些代码是否正确的或在适当的时间被执行。代码覆盖具有可以自动测量（尽管通常被手动过滤）的好处。

本文的重点是确定功能覆盖实现的准确性以及其他方面。

三、真理是这样的

功能覆盖率的目标是针对在验证环境中已经被激活（和检查）的功能进行准确、完整和简明的测量。

A、一连串的谎言

基于对大量不同客户、项目、应用和语言的覆盖分析，功能覆盖的功能正确性和完整性通常是不正确的和误导性的。甚至可以说，整体覆盖模式和实施的具体细节其实展现了一连串的谎言。

这是一个非常大胆的声明，但通过进一步的观察证明覆盖结果似乎总是以面值的方式进行，并且唯一能引起工程师兴趣的似乎只是那些没有覆盖到的点。换句话说，如果覆盖结果被表示为事实，那么这个结果中任何不合理的行为都可以解释为谎言。

功能覆盖模型中发生的谎言的类型可以如下分类：

欺骗
缺省
制造

欺骗类型的谎言一般是覆盖组中直接的错误，它的结果不会告诉你什么有用的真相。例如，覆盖点的范围可能没有被正确的指定，是的我们从不从激励中观察本应施加给设计的最大值或者最小值。这类缺陷通常会在审查代码时被发现和纠正。

缺省类型的谎言指那些遗漏的覆盖点，此时的覆盖率结果不能告诉我们应该考虑的全部真相。例如，如果设计具有任何内部存储器（流水线，缓冲器，FIFO等），则基于纯事务的覆盖率是不够的，还应考虑这些事件之间附加的时间关系。这种缺陷难以检测，需要很好的了解项目以及实际的验证要求。

制造类型的谎言指那些从事件、条件或数据中测量的结果，但是这些结果在现实中并没有发生，这意味着更有趣的情景被触发而不是真是发生的。例如，覆盖值是写入寄存器的内容而不是寄存器被设计使用时的内容。这种缺陷可能是最难发现的，并且对覆盖率的质量构成了破坏性的威胁。审核人员真正需要了解验证环境的详细操作和应用程序需求，以得出正确的结论。

B、非恶意行为

我们需要清楚的是谎言一般来说并不是恶意行为的结果，它们并不是被故意引入的。

考虑这一点：在项目开发的任何后期阶段，合格的验证工程师都可以操作代码库，以便覆盖范围奇迹般地达到100％ ，这是恶意行为，但是技术上是可以直接实现的。我们可以移除难以到达的覆盖点，引入额外的抽样事件，操纵范围以吸收边角情况等。接下来，我们的调查表明，由于前文所述的这些谎言导致某些仓被忽略、覆盖范围不正确、在错误的时间或者不正确的条件下记录了覆盖率。这意味着即使没有进行恶意操作，你仍然有可能得到一个相同的结果，一个假的（同样奇迹般的）100%覆盖率，使大家都很开心。

四、实例

本节提供一些现实例子来说明问题的范围，并提高读者对于寻找什么样的谎言的意识。 这些示例取自不同类型的验证环境，并且与语言无关。一个特定的缺陷可能被归类为一个小谎言或者一个大问题，这取决于应用程序。这个列表并不全面，但所示的示例都是相当常见的缺陷。

A、事务覆盖率

事务和其它类的内容构成了验证环境的功能覆盖率模型的主要部分。这是最简单的覆盖率，但仍然有可能有不准确和缺陷，从而导致错误的报告来误导用户。

1.字段范围
正确的指定事件中覆盖点的范围是对不良激励的最后一道防线。如果定义某些关键值（例如最大值和最小值）的仓没有和它所在的范围分离开来，那么我们可以得到很好的覆盖率报告但是忽略了关键值出现的情况。这很可能是一个致命的问题。例如，图形应用程序未能强调长度或半径参数为零的圆弧绘制算法，但是覆盖率报告却没有反应出这种情况未被跑到，因此导致几个关键错误被暴露在DUT中。
2.字段条件
事务覆盖率中另一个常见的错误是在同样的采样事件中未加任何过滤覆盖该事件的所有字段。许多应用程序具有仅在特定事务类型（例如扩展字段或消息参数）中才有效的条件字段，这些字段应该使用覆盖语句中的条件构造来限定（例如，只有在一些附加条件有效的情况下才对该值进行计数） ，不然这些仓即使被命中也是没有意义的。
3.配置对象
由于在配置或更改配置对象时，配置内容可能被使用也可能不被使用，因此配置内容此时是具有误导性的。所以，这些字段值应该仅在DUT中发生依赖操作（例如，在接口上发生事务或执行变换算法）时被覆盖。 这可能需要将配置对象字段分解成多于一个覆盖组以允许独立的采样事件（例如，单独的发送和接收事件）。
4.事务关系
对于许多应用程序，仅仅是基于事务的覆盖率是不够的，我们还要考虑底层接口级别和高层系统级别的情形下事务之间的关系。例如，我们需要覆盖PCIe网络中的合法数据包重排序，DigRF流中的嵌套帧或复位或其他重要事件后的事务顺序。这些覆盖点对于应用程序成功至关重要，但通常很难实现或直接把它们从覆盖模型中省略。 这种类型的覆盖通常在环境的记分板中实现，但通常很难定义，甚至更难以检查准确性和完整性。
5.错误注入
在覆盖模率型结果中通常难以表示与误差注入相关的功能覆盖率（即故意添加违背协议的激励，例如CRC错误）。其原因在于，当错误注入被激活时，注入监视器这样的模块不能有效区分事务的具体内容（例如，编码错误可能被误认为内容错误）。这是少数我们建议对覆盖率模型进行补充的情况之一，如果需要的话可以添加来自于驱动器的激励覆盖率来根据sequence中的错误注入标志对其进行统计。
6.不相关数据
在任何特定的DUT（例如模块，子系统或者整个芯片）中捕获的覆盖率数据中有很多事不相关的，这些数据很有误导性，因为它看起来好像很多有趣的事情正在发生，但实际可能并不是这样。这些数据与实际的工作可能并不相关，因此会给出错误的激励结果，并掩盖真正缺失的覆盖点，夸张的说，这也是一种谎言。例如，在片上网络应用中，可以通过总线结构传输非常多类型的包，然而如果目标是验证路由器子系统的全部功能，则仅应该覆盖与该路由器相关的分组信息（比如用于路由决策的一些包头字段，数据流信息，总的包的长度等等），路由器不关心分组内容（例如有效负载）及包的其它一些内容，不关心的内容应该从覆盖率模型中除去。
我们不建议将覆盖范围内的所有内容进行采样，然后再根据验证计划挑选几个方面进行数据追踪，因为这样会使得原始覆盖数据变得非常庞大。更好的方法是保证原始覆盖数据的精简和相关性，然后根据验证计划对适当的方面进行向前或向后的数据追踪。
B、时间覆盖
在这种情景下，时间覆盖率与事件在功能覆盖率不同方面的时序有关，而不仅仅是单个协议接口中相关联的特定事务的数据的累计。
1.时钟关系
大多数现代设计具有多个时钟域，需要特殊技术来验证时钟域交叉（CDC）信号是否正确同步。 即使在存在完全有效的CDC或派生同步时钟的情况下，也需要在所有相关时钟条件下验证DUT的操作。但由于某种原因，此覆盖范围通常从覆盖模型中省略。
对于基于事件的仿真，绝对时钟值不重要（尽管它们可能用于模拟块的嵌入式模型），但时钟关系很重要。例如，我们要测量源的时钟域和目标的时钟域是否具有相同的由快到慢或者由慢到快的时钟关系。这可以根据速率的差异程度进行进一步的分解，例如异步时钟之间可能更关心小于、等于后大于2倍的差异（由于它们需要同步）。或者两个异步时钟和它们驱动的时钟域更关心等于和大于Nx的差异，N是RTL设计的顺序深度（例如，流水线深度，路由延迟，处理时间等）。时钟关系本质上是对时钟进行配置，因此仅当实际的时钟被使用时（例如，当在时钟域之间发送或接受事务时）才对其进行采样，而不是在当DUT中什么都没有发生的时候进行采样。
2.复位条件
通常，当DUT处于不同状态（例如，处理事务，空闲，唤醒，进入睡眠等）时，我们希望覆盖复位激励。非常常见的是，将初始复位事件与非零复位事件放到同一个覆盖组中，这是很具有误导性的，因为初始复位时DUT不处于任何状态。最好从此覆盖范围中排除初始复位事件，并确保仅使用了后续非零复位事件。
3.时间关系
在具有多于一个接口或者多于一个内部存储阶段（例如，管线，缓冲期，FIFO，同步器等）的任何设计中，覆盖到针对这样的DUT的所有验证问题是很难做到的。我们需要覆盖到重要的时间关系（例如，单独接口上的相关事务时序，与掉电相关的事务时序，与处理状态相关的刷新请求的产生等等）。这种覆盖常需要在环境级别进行专门的跨接口监视以跟踪各种接口的相对状态和事件时序，它也很难实现和审查，但是极其有价值。
4.覆盖率检查
覆盖率检查需要覆盖到系统中所有运行的检查。为了准确地覆盖，我们还需要知道在什么条件下检查是成功的，并且这通常需要记录额外的信息以知道我们已经覆盖了所有情况（例如，声明“A必须导致B或C”是有效的检查， 但需要定义两个覆盖点以知道“A造成B”和“A造成C”）。
监视器中事务内容的检查和记分板中事务关系的检查也是需要明确地指定覆盖。例如，如果环境能够丢弃具有错误类的包，则记分板模型必须知道这一点以防止不匹配，但是我们还需要在功能上覆盖所有这样的有效过滤条件的发生。由于某些原因，这些条件通常从覆盖模型中省略，即使它们是我们知道的需要进行激励和检查的关键行为。这个概念并不复杂，只需要问问你自己：“你能不能说出，在覆盖率结果中，是否每一个被认为需要的检查都发生了，多久发生一次，在什么情况下发生？”
5.子事务事件
许多协议需要增加一些中间事件的覆盖，当接口尝试进行解码时。有时，这些重要事件甚至不会导致监视器产生事务（例如，如果在仲裁期间两个竞争的主控器退避），因此需要一些其它方式记录它们。例如，在I2C协议中，我们需要提供这样的覆盖，它标志了在仲裁竞争的不同阶段期间（外部主设备赢得仲裁时）的DUT退避情况，并且我们还需要识别外部主设备在那个时候是否正在对DUT进行寻址。
C、寄存器覆盖
寄存器模型的覆盖率错误信息通常与DUT的状态和操作相关。此外，一些与寄存器细节相关的数据在没有正确封装的情况下可能掩盖覆盖率的其它方面。
这里有一些在定义寄存器相关覆盖率目标时需要注意的事情：
我们是否在控制和配置中使用了所有相关的值和范围？
我们是否从DUT读取了所有适当状态的响应？
我们是否验证了寄存器中所有的复位值？
我们是否访问了所有寄存器的地址？
我们是否尝试了每个寄存器的所有方位类型？
我们是否对寄存器的域进行了所有适当的访问？
1.写寄存器
当对寄存器进行写操作时，控制和配置寄存的值对覆盖率是很具有误导性的。这可能导致很高的覆盖率，即使在只有很少或者根本没有额外功能的DUT的功能测试中（例如，我们可以向寄存中写入十个不同的值，但是只用到了其中的一个）。相反，我们应该在这些值被DUT实际使用（例如发送事务或执行算法）时，在进行覆盖率统计。这种情况下，覆盖率的实现可以由寄存器模型提供，但它是在环境中有适当的事件发生时被动的由监视器触发的。
2.读寄存器
寄存器的读操作对覆盖率也是有误导性的，因为这其中一些结果可能是由复位导致的，而不是DUT的操作。仅当数值从复位值更改或者从先前读取的值更改时，才更适合统计读取寄存器数值的覆盖率。元数据可用于跟踪字段值之前的状态。
3.复位值
为了验证DUT中寄存器的复位值与模型中寄存器的复位值匹配，在复位后没有对寄存器进行其他操作时，我们需要覆盖对寄存器的读访问。但实际中可能很难实现，特别是对于异变字段（被RTL更新的字段），这种覆盖率通常在模型中省略。如果我们将一些元数据添加到寄存器字段以跟踪来自总线操作或RTL的更新（通过扩展主动监视功能），我们可以更精确地覆盖到复位状态寄存器的读取（并单独检查值）。
4.地址映射
为了验证RTL层次中地址解码和分区的实现，我们需要覆盖对设计中所有寄存器地址的访问。 寄存器内容（字段值）应该单独覆盖，后门访问应该从这个覆盖集合中排除（因为我们需要知道我们是否真的可以访问DUT中的寄存器）。理想情况是，仅当观察到效果时（即写入的值对DUT的影响被观察到时检查读取值）才会覆盖寄存器访问，但是通常如果字段内容被单独覆盖，则不需要。
5.访问权限
特定地址映射中的寄存器的访问权限可以对该寄存器允许的操作类型（和它们产生的附加字段）施加附加的限制。对于地址映射范围中的每个寄存器，必须覆盖到合法和非法访问类型（例如，我们需要覆盖对只读寄存器的尝试写入）。这种覆盖经常被忽略，并因此使得访问权限没有被验到。
6.访问策略
不管地址映射中的总体访问权限如何，每个寄存器字段是否具有应用的特定访问策略（例如，只写，只读，读到清除，写入到清除等）。 我们都需要确保在这些字段上尝试了所有可能的访问，有必要的话还要考虑访问数据值。例如，对于只读寄存器字段，我们需要覆盖对字段的读取和写入尝试，并且写入必须具有与字段内容不匹配的值。 同样，对于写一清除字段，我们需要覆盖尝试写入一和零。
如果访问策略是动态的（例如，为了实现硬件防火墙），则可能需要额外的交叉覆盖。 在这种情况下，我们需要在每种可用模式中涵盖合法和非法尝试，并在适当时使用相应的数据。