system verilog 硬件验证语言（Hardware Verification Language，HVL)
- 受约束的随机激励生成
- 功能覆盖率
- 更高层次的结构（面向对象）
- 多线程及线程间的通信
- 支持HDL数据类型，例如verilog的四状态数值
- 集成事件仿真器
（硬件设计的目的在于创建一个基于设计规范并能完成特定任务的设备）
（1）受约束的随机激励
（2）功能覆盖率
（3）使用事务处理器的分层测试平台
（4）对所有测试通用的测试平台
（5）独立于测试平台之外的个性化测试代码
定向测试：（找出设计中预期的漏洞）->在时间轴上往前推进，覆盖率可能维持不变
随机测试：（能够找出预料不到的漏洞）->需要用功能覆盖率来评估验证的进展情况
随着漏洞出现率的下降，创建新的随机约束去探索新的区域，最后的几个漏洞可能通过定向测试来发现，但是绝大部分的漏洞都应该会在随机测试中出现。
受约束的随机激励：希望仿真器能产生随机激励，但同时又不希望这些激励数值完全随机；一个随机测试的覆盖范围往往比一个定向测试大，多出来的覆盖部分可能会与其他测试发生交叠，或者探测到事先没有预料到的新区域。如果这些对新区域的测试不合法，需要编写更多的约束去阻止随机测试产生非法的功能；最后，对于那些受约束的随机测试覆盖不到的地方，还需要编写定向测试。
随机化对象是什么？
需要广泛地考虑所有的设计输入：
（1）设备配置和环境配置
（没有尝试足够的不同配置->察觉不到漏洞最常见的原因）
（2）输入数据
（3）协议异常、错误和违例
（尽量尝试去仿真在实际的硬件中可能出现的错误，而且针对所有可能出现的错误，只要确保能够使代码在出错的地方停止仿真，很容易应对测试中的错误）
（4）时延和同步
使用受约束的随机时延有助于捕获协议的漏洞
（5）并行的随机测试
随机测试则包含了测试平台代码和随机种子。使用多个种子运行同一个测试可以加大覆盖率，同时减小工作量，需要为每次仿真选定一个独特的种子（如果自然时间作为种子，多项任务可能会于同一时间在不同的计算机上启动，还是会得到相同的随机种子并运行相同激励）
功能覆盖率：在测试平台中加入代码，用于监控进入设备中的激励，以及设备对激励的反应，并据此确定哪些功能已经被验证过。运行几次仿真，使用不同的种子，接下来，把这些仿真的结果合并到一个报告中，最后决定如何采用新的激励来达到那些尚未被测试到的条件和逻辑。
从功能覆盖率到激励的反馈：随着功能覆盖率逐渐接近极限，需要改变测试，找出新的方法来达到那些尚未被覆盖的区域。
测试平台的构建：在仿真时，测试平台会把整个待测设计包围起来
如果实际应用中设备被连接到AMBA、USB、PCI和SPI总线，必须在测试平台中建立能够产生激励并校验响应的等效构件。（如果把设计原型在FPGA上实现或者进行硬件仿真，这些BFM(总线功能模型）需要可综合
分层的测试平台
1、不分层的测试平台
（以上是重复的写入激励来判断）
2、使用把一些通用的操作放入一个子程序中，可以提高工作效率并减小出错
（信号和命令层的建立只是通往分层测试平台的第一步）
- 信号层：包含有待测设计和把待测设计连接到测试平台的信号
- 命令层：
1、执行总线读或写命令的驱动器驱动待测设计的输入
2、监视器负责检测信号的变化，并把这些变化按照命令分组
3、断言负责监视独立的信号以寻找穿越整个命令的信号变化 - 功能层：
1、代理（事务处理器）接受到来自上层的事务，例如DMA 读写，把它们分解成独立的命令
2、这些命令送往预测事务结果的计分板
3、检验器负责比较来自监视器和计分板的命令 - 场景层：待测设备能够完成预期的任务
测试的层次和功能覆盖率：
建立一个分层的测试平台
1、创建一个简单的驱动器
驱动器接受来自代理的命令，驱动器可能会注入错误或者增加时延，然后把命令分解成一些信号的变化，例如总线请求或握手。（核心部分是一个循环）
仿真环境的阶段：
建立（build）：
（1）生成配置，把待测设计的配置和周围的环境随机化
（2）建立环境，基于配置来分配和连接测试平台构件
（3）对待测设计进行复位
（4）配置待测设计：基于第一步生成的配置，载入待测设计的命令寄存器
运行（run）：
（1）启动环境，运行测试平台构件
（2）运行测试，启动测试然后等待测试完成
收尾（wrap-up）：
（1）清空：在最下层完成之后，需要等待待测设计清空最后的事务
（2）报告：一旦待测设计空闲，可以清空遗留在测试平台的数据
最大限度的代码重用
