验证基础之（Stimulator、monitor、checker）
测试平台（testbench）是整个验证系统的总称。它包括验证结构中的各个组件、组件之间的连接关系、测试平台的配置和控制。更系统的来讲，它还包括编译仿真的流程、结果分析报告和覆盖率检查等。从狭义上来讲，我们主要关注验证平台的结构和组件部分，他们可以产生设计所需要的各种输入，也会在此基础上进行设计功能的检查。
对一个测试平台，各个组件之间是相互独立的，验证组件与设计之间需要连接、验证组件之间也需要进行通信、验证环境也需要时钟和复位信号的驱动。下面来讲一讲基础的验证组件Stimulator、monitor、checker。
激励发生器（Stimulator）
Stimulator（激励发生器）是验证的重要部件，在些场合中，它也被称为Driver、BFM(buf function model）、behavior（行为模型）或者generator（发生器）。
Stimulator的主要职责是模拟与DUT相邻设计的接口协议，只需要关注如何模拟接口信号，使其能够以真实的接口协议来发送激励给DUT。Stimulator 不应该违反协议，但不拘束于真实的硬件行为，还可以给出更多丰富的只要协议允许的激励场景。
它具有比真实硬件更丰富的激励，会使得在模块级的验证更加充分，因为它不但验证过了硬件的普通接口协议情景，还模拟出更多复杂的、在更高系统级别无法产生出来的场景。
Stimulator的接口主要与DUT之间连接，此外，也应该有时钟和复位的输入，确保生成的数据同DUT的接口一侧是同步的关系。较精细的Stimulator还可以有其他的配置接口用来控制接口的数据生成。Stimulator也可以有存储接口数据生成历史的功能，方便在结束后查看接口数据。
如果用一个Stimulator去验证一个FIFO，就要考虑FIFO的状态可遍历。例如，典型的FIFO状态可以分为empty、full以及中间状态即有数据存储但未存满。要使得FIFO可以触发这些状态，我们就应该控制Stimulator的传输速率。
在寄存器读写传输上，可以考虑连续的写、读、或者读写交叉的方式测试寄存器模块的读写功能。对于读写寄存器的所有比特位测试都应该覆盖。对于只读状态寄存器需要测试是否为不可写入的设定，你说你是只读的，我就偏要往里写，然后再读出来，看看你是不是真的是只读的。
监测器（Monitor）
Monitor（监测器）的主要功能是用来观察DUT的边界或者内部信号，并且经过打包整理传送给其他验证平台的组件，例如checker（比较器）。
monitor可以观测DUT边界信号。对于系统信号如时钟，可以监测其频率变化；对于总线信号，可以监测总线的传输类型和数据内容，以及检查总线时序是否符合协议。
monitor也可以观察DUT内部信号。从灰盒验证的手段来看，往往需要探视DUT内部信号，用来指导Stimulator的激励发送，或者完成覆盖率收集，又或者完成内部功能的检查。
对于monitor，更倾向于一个Stimulator配一个monitor，即不同的接口信号的采集交给不同的monitor，因为就各个接口的功能而言，它们之间没有联系性，易于切割。
利用分立的monitor还有一个好处，就是相对独立的monitor可以更好地作为验证IP被其他的验证环境复用，也更方便验证后期项目修改的维护工作。
比较器（checker）
checker肩负模拟设计行为和功能检查的任务，所以无论是从实现难度还是维护人力上讲，checker都应当是最需要时间投入的验证组件了。
比较器需要能缓存从各个monitor收集到的数据。将DUT输入接口侧的数据汇集给内置的reference model。通过数据比较的方法，检查实际收集到的DUT输出端口数据是否同reference model产生的期望数据一致。对于设计内部的关键功能模块，也有相对应的线程进行独立的检查。
实现方式：
1.线上比较（online check）：在仿真时收集数据和在线比较，并且实时报告。
2.线下比较（offline check）：将仿真时收集到的数据记录在文件中，在仿真结束后，通过脚本或者其他手段，进行数据比较。
对于复杂的系统验证，我们更倾向于集中管理Stimulator和checker，因为它们两者都需要主动给出激励或者判断结果，也需要较多的协调处理。而monitor则相对更独立，因为它只作为检测方，任务就是把监测到的数据都交给checker就行了。
monitor和Stimulator是一一对应的，所以我们通常将它们进一步封装在agent单元组件中，而checker则最终集群搁置在中心化的位置。
