第一章：验证导论（续）

本想第一章就将导论一起写完，但是总觉得对一些重要的概念还是想以小篇幅的形式突出重点写出来，所以接下来的这篇文章就是对上篇文章的延续。

1.6 随机化对象

以一个初入验证领域的人来讲，所谓的随机化就是数据字段，这种激励最容易创建---只需要调用$random()函数即可。但是这种随机数据在找漏洞方面的回报是很小的。使用这种随机数据找到的漏洞一般都是在数据路径上，很可能还都是比特级的错误。其实我们更加需要找到一些控制逻辑上的漏洞。比如下面几种类型：

• 设备和环境配置
  很多测试只使用了仅仅经过复位的设计或者施加固定的初始向量集把设计引向一个已知的状态。在一个实际的应用环境中，随着待测设计使用时间的增加，其配置会变得越来越随机。你应该对整个环境的配置进行随机化，包括仿真的时长、设备的数量，以及它们的配置方式。
• 输入数据
  当看到看到随机激励时，可能会想到选取一个总线写入的事务或ATM信元，然后把随机数值填充到其中的数据字段里。
• 协议异常、错误和违例
  设备死机的最有可能的原因就是产品内部的一部分逻辑一旦遇到错误以后无法恢复过来，因此设备不能正常工作。我们就想尽量去尝试仿真在实际的硬件中可能出现的错误，要对这些情况一一尝试，然后确保设备还能继续正常运作。
  尝试使用不当的命令去激励硬件的同时注意捕捉出现的问题。
• 时延和同步
  一个代码块对于来自同一接口的所有可能激励也许都能正常工作，但同时面对多个输入，隐蔽的漏洞可能就会出现。
• 并行的随机测试
  随机测试包含了测试平台代码和随机种子。如果你想对同一个测试运行50次，每次都采用不同的种子，那么你将会得到50个不同的激励集合。使用多个种子运行同一个测试可以加大覆盖率，同时也能减少你的工作量。

1.7 功能覆盖率

前面我们讲述了如何创建激励并使用这些激励遍历整个可能的输入空间。使用这种方法，你的测试平台会频繁访问部分区域，但是需要花费很长时间来达到所有可能的状态。即使对仿真时间不加限制，无法达到的状态还是永远也不会被访问到。这个时候我们就需要知道哪些部分已经被验证过，这样才能对验证计划中的项目进行核对。
对功能覆盖率的测量和使用包括下面几个步骤：
（1）在测试平台中加入代码，用于监控进入设备中的激励，以及设备对激励的反应，并据此确定哪些功能已经被验证过。
（2）运行几次仿真，每次使用不同的种子。
（3）把这些仿真的结果合并到一个报告中。
（4）对结果进行分析，最后决定如何采用新的激励来达到那些尚未被测试到的条件和逻辑。

1.7.1 从功能覆盖率到激励的反馈

使用随机总线事务和终止判断。

• 运行的时间越长，则覆盖率就会越高。
• 创建激励时灵活性很高，足以应对设计有改变的情况。
  这种方法的原理就是在测试代码中加入一个反馈循环，用于监测已生成的激励，并根据情况调整约束的权重。这种方法能大大缩短达到完全覆盖的时间，而且只需要很少的人工干预。

1.8 测试平台的构件

在这里我给出一个框图，希望能够在本专题更新完以后，能够对这个框图有深入的认识。

分层的完整测试平台.png

我们以一个基本的事务处理器为例，映射到SystemVerilog相应的代码如下：

task run();
        done=0;
        while(!done)
           begin
                 //获取下一事务；
                 //进行变换；
                 //发送事务；
             end
  endtask

小结：第一章就从一个大概的轮廓介绍了利用SystemVerilog搭建测试平台的框架。要想对其有深刻的了解还是需要进一步的深入学习。