作为一名验证工程师，你应该尽可能细致深入地去检验设计，并提取出所有可能的漏洞。在流片之前每发现一个漏洞就意味着最终到顾客手里就会少一个漏洞。接下来我将更新一个系列的文章来讲述SystemVerilog这门验证语言，希望能够学有所长。本章内容就做一个大体的介绍，有很多东西也许解析不到位，希望以后能修改补充。
在熟悉Verilog语言的基础上，我希望能够学习System Verilog硬件验证语言（Hardware Verification Language，HVL）。相比于硬件描述语言（HDL），HVL具有以下典型的性质：
- 受约束的随机激励生成。
- 功能覆盖率。
- 更高层次的结构，尤其是面向对象的编程。
- 多线程及线程之间的通信。
- 支持HDL数据类型。
- 集成了事件仿真器，便于对设计施加控制。
除此之外，还有很多特性，这些特质保证了我们能够运用HVL来创建高度抽象的测试平台。
1.1 验证流程
什么是验证呢？作为一名验证工程师，你的目的就是确保该设备能够成功地完成预定的任务，换句话说，该设计是对规范的一种准确表达。
验证的流程并行于设计流程。一名验证工程师，你必须阅读硬件规范并拟定验证计划，创建测试来检查RTL代码是否准确地实现了所有的特性。
1.1.1 不同层次上的测试
设计上的漏洞会在不同层次上产生漏洞，下面从底层开始对设计中的漏洞进行下面几种分类。
- 代码块层次，在module创建的代码块。
- 代码块的边界，不同的设计者会对同一个规范有不同的理解，这样会造成硬件逻辑上的争议。
- 为了仿真一个代码块，你需要创建测试集来模拟周围代码块产生激励，这样低层次的仿真运行起来会很快，但是产生激励的方式会很繁琐。将多个代码块集成到一起，在待测设计的最高层次上，整个系统都会被测试，代码块之间相互激励，运行起来速度会更慢一些，但是仿真过程就会简单很多。你的测试应该尽可能让所有的代码块并发活动。所有的输入输出端口都被激活，处理器正在处理数据，而高速缓存也在载入数据。这样的话，数据分配和时序上的漏洞肯定会出现。
- 错误注入和处理，一旦验证了待测设计能够执行所有预期的功能以后，你还需要看一下当出现错误时，待测设计会怎样操作。
我们永远也无法证明没有任何漏洞留下，所以需要不停地尝试新的验证策略。
1.1.2 验证计划
验证计划主要包括以下几种方法：定向测试、随机测试、断言、软硬件协同验证、硬件仿真、形式验证，以及对验证IP的使用等等。
1.2 基本测试平台的功能
测试平台的用途在于确定待测设计的正确性。包含下列步骤：
(1) 产生激励。
(2) 把激励施加到DUT上。
(3) 捕捉响应。
(4) 检验正确性。
(5) 对照整个验证目标测算进展情况。
1.3 定向测试
所谓定向测试就是针对待测设计制订具体的激励向量，然后使用这些向量对待测设计进行仿真。仿真结束后，手工查看一下结果文件和波形确保设计的行为和预期一致。如果测试结果正确，你就可以继续下一个测试。如果给予你足够的时间和人力，定向测试可以完成验证计划百分之百覆盖率所需要的全部测试。
1.4 方法学基础
方法学的原则如下：
(1)受约束的随机激励。
定向测试可以找出设计中预期的漏洞，随机激励能够找出预料不到的漏洞。在复杂的设计中，随机激励十分关键。
(2)功能覆盖率。
当使用随机激励时，需要用功能覆盖率来评估验证的进展情况。使用自动生成的激励，就需要一种能够自动预测结果的方式---通常是记分板或参考模型。建立包括自预测在内的测试平台基础设施是一件工作量很大的事情。
(3)使用事务处理器的分层测试平台。
分层的测试平台能够把问题分解为容易处理的小块，这样有助于控制复杂度。
(4)对所有测试通用的测试平台。
建立一个测试平台所需要的基础设施，它们能在所有测试中通用并且不需要经常性修改。你只需要在某些地方放置“钩子”，以便测试能够在这些地方执行调整激励或注入错误这样特定的操作。
(5)独立于测试平台之外的个性化测试代码。
针对单一测试的个性化代码必须与测试平台分开，这样可以避免增加基础设施的复杂度。
总之，建立这种风格的测试平台所需的时间要比传统的定向测试平台多得多---尤其是自检部分。结果是可能需要很长的准备时间才能进行第一次可运行的测试。每个随机测试都可以公用测试平台。受约束的随机测试平台找起来漏洞会比很多定向测试快很多。
随着漏洞出现率的下降，你应该创建新的随机约束去探索新的区域。最后的几个漏洞可能只能通过定向测试来发现，但是绝大部分的漏洞都应该会在随机测试中出现。
1.5 受约束的随机激励
我们希望仿真器能够产生随机激励，但同时又不希望激励时完全随机的。SystemVerilog语言可以描述激励的格式，然后让仿真器产生满足约束的数值。这些数值会被发送到设计中去，同时也会被发送到一个负责预测仿真结果的高层模块中去。设计的实际输出最终需要和预测输出做对比。下图为达到完全覆盖的技术路线。
其中，最少的代码修改一般包括：使用新的约束和把错误或延时加入到待测设计中。