原创 [转]利用SystemVerilog实现有效的SoC设计验证

随着SoC设计中采用的技术愈加复杂，验证工程师的规划过程也需不断改进。基于测试的归划正在被更复杂的跟踪覆盖和断言的验证规划所替代。引起这种变化的原因之一是支持功能覆盖点、断言和测试平台约束规范的SystemVerilog在业界的普及，而另一个重要的原因则是越来越多的约束随机测试平台代替手工编写测试。

传统的验证过程需要识别设计中的所有重要特性，定义一整套验证这些特性的直接测试，以及手工编写测试，并在仿真环境中运行和调试这些测试。这种方法适合小型设计，但SoC器件需要上千个手工编写的直接测试才能完成所有特性的验证。租用限制、上市压力和编写测试的繁复单调都迫切需要一种更好的方法。约束随机测试平台要求验证小组规定出用于定义设计输入规则的约束条件。

一旦这些设置工作完成后，测试平台自动化工具或仿真器就能产生输入激励来验证设计。通过改变约束条件、选择不同随机种子或偏置输入产生的值，都可能引起所生成的测试发生变化。SystemVerilog可提供定义约束、种子和偏置所必需的结构。

从直接测试发展到约束随机测试要求验证规划过程也有相应的变化。传统测试规划包括设计的特性列表、验证每个特性的测试和测试状态。随着测试的编写、运行和调试，它们的状态将在验证规划中不断更新。这些规划可以用文档或电子表格的形式进行手工维护，也可以作为验证过程自动化(VPA)流程的一部分实现自动更新。

直接测试主要用于验证设计的特殊部分，而约束随机测试可以同时验证设计的许多部分。这就形成了很大的挑战，因为在特性和测试之间不再有明显的分界线。

对验证小组来说匹配自动测试与相应设计特性的最佳方法是通过功能覆盖指标规定。设计师和验证工程师能规定代表重要设计行为的功能覆盖点。这些点中有一些代表了正常操作，而其它点反映了无法覆盖的功能点条件，此处最可能潜伏缺陷。随着重点从跟踪测试向跟踪功能覆盖转移，传统测试规划必须加以改进。

在现代验证规划中，特性被更精确地定义，以便在每个特性和功能覆盖点之间呈现一一对应关系。随着验证的不断进展，规划可以作为VPA流程的一部分而获得自动更新。

SystemVerilog提供了两种定义功能覆盖的基本机制。第一种是源自硬件验证语言的覆盖组(cover group)。覆盖组可包含多个单独的覆盖点，允许“储藏”多个值，支持交叉覆盖以便跟踪组合值。由于一些RTL工具不支持覆盖组，因此覆盖组经常在测试平台中被定义。

另外一种机制是可以在设计或测试平台中规定的覆盖属性(cover properties)。覆盖属性结构是SystemVerilog Assertions(SVA)子集的一部分，与断言规范共享临时序列和其它构造模块。覆盖组和覆盖属性指标可以在仿真器中进行收集和报告。一些允许 SVA断言的形式工具也支持覆盖属性。现代验证规划也可以用来跟踪设计和测试平台中规定的SystemVerilog断言。

在项目早期，特性是在验证规划中确定的。增加了针对覆盖点和断言的文本描述。随着覆盖点和断言被加进设计和测试平台，链接将被增加进规划。最后根据规划报告覆盖结果(覆盖或未覆盖)和断言结果(通过或失败)。