声明：本内容来自于学习路科验证发布在B站上的免费视频课程后的笔记
一、验证平台testbench
它是整个验证系统的总称，包括：
1、验证结构中的各个组件、组件之间的连接关系、测试平台的配置和控制；
2、编译仿真的流程、结果分析报告和覆盖率检查；
我们主要关注验证平台的结构和组件部分，因为它们会为待测的硬件设计(DUT)提供所需要的各种激励输入，同时也会检查待测硬件设计的功能。
编译compile分为两步：
第一步，编译DUT的RTL文件；
第二步，编译测试平台的TB文件。
总结：
1、测试平台中的各个验证组件之间相互独立，但需要进行通信；
2、所有的验证平台的验证组件与待测设计DUT之间的连接都是通过接口interface连接的；
3、验证平台中的某些验证组件也需要时钟和复位信号的驱动，比如stimulator、Monitor。
模块级module level和子系统级sub-system level主要用SV和UVM，而到了系统级system level则主要用C。
二、验证环境组件
1、激励发生器stimulator：
也被称为驱动器driver，总线功能模型BFM(bus function model)，行为模型behavioral或者发生器generator。
1）它的作用是模拟与待测硬件设计DUT相邻设计的接口协议。
我们关注的是如何模拟接口信号，使之能以真实的接口协议来发送激励给DUT。因此，stimulator不能违反该接口协议，但它也不被限制在真实的硬件所规定的行为里(也就是说，只要不违反接口协议，就可以不按照真实的硬件规定来发送激励信号，比如真实的硬件接收激励信号时需要按照一定的频率，信号不连续等来接收)，这样就能制造出更多的协议所允许的激励场景来验证DUT，也能验证DUT能否支持更多的接口协议。
这种提供比真实的硬件行为更丰富的激励信号，会让模块级module level的验证更充分，因为它不但验证了硬件接口对普通接口协议的适配场景，还模拟出了更复杂、在更高系统级别无法产生出来的一些场景。
2）它的接口主要同DUT连接，因而它也应该具备时钟和复位(clock/reset)的输入，以此来确保它所生成的数据和DUT接口一侧保持同步的关系。
注：它不是向DUT的内部信号发送激励，它不能修改DUT的内部行为，DUT的内部行为由它本身的各种逻辑综合后来决定的。
3）有些精细的stimulator也有其它的配置接口用来控制接口的数据生成，比如数据的内容。
4）它也可以由存储接口数据并生成历史的功能，这样在仿真运行时或者结束后查看接口数据，方便做统计或者调试。
5）我们可以将stimulator进一步分成以下两种：
发起器initiator：主动发起接口数据传输；
响应器responder：对接口数据的发送请求做出响应(反馈)，它本身不会主动发送数据。
2、监测器monitor
它是用来观察DUT的边界或者内部信号，然后将其打包整理后传送给验证平台的其它组件，如比较器checker。
1）观察DUT边界信号：对于系统信号如时钟，可以监测它的频率变化；对于总线信号，可以监测它的传输类型和数据内容，以及检查总线时序是否符合协议（激励发送端的协议有问题，还是DUT本身反馈回的协议有问题）。
2）观察DUT内部信号：从灰盒验证来看，需要探视DUT的内部信号，以此来指导stimulator的激励发送，或者完成覆盖率收集，又或者完成内部功能的检查。
灰盒验证：以黑盒验证的观察边界信号输入输出为主，白盒验证的观察内部关键信号为辅。
验证过程中，应该尽量少地去观察内部信号，而且应该是观察表示状态的信号。观察采集的中间变量信号，它们的时序、逻辑以及留存性（信号保持同一状态？）都不稳定，因而会对验证环境的收敛有害。
可以通过接口信息计算预测出来的，也应尽量少的去监测内部信号，因为这种方式有悖于假定设计有缺陷的验证思想。我们观测到的内部信号在被环境采纳之前也有必要确认它们的逻辑正确性，这一要求可以通过动态检查或者断言触发的方式来实现。
模块的边界信号变化比较少，内部信号则变化很频繁。
Monitor不可以从stimulator直接获取激励数据，而应该从interface获取数据，因为这样监测到的数据会更准确，比如stimulator发送了一个激励信号，但这个信号不满足接口协议，如果monitor直接从stimulator获取激励信号的话，它就不知道这个信号是否满足接口协议。
3、比较器checker
1）它主要负责功能检查和模拟硬件设计行为（参考模型reference model）。
2）会缓存从各个monitor收集到的数据。
3）我们需要checker分析DUT的边界激励，理解数据的输入，并且按照硬件功能来预测输出的数据内容，得到期望数据。这种预测的过程，就发生再reference model中，因此，checker也会被称为predictor。
4）参考模型reference model扮演了模拟硬件功能的角色，它会内置一些缓存，存放monitor从DUT输入端观察到的数据和经过功能转换后的期望数据（checker将DUT输入接口侧的数据汇集到内置的参考模型上，按照它所理解的硬件功能进行一定转换后得到期望数据）。
checker也有缓存来存放从输出端采集到的数据，这样通过数据比较，检查实际从DUT输出端接口收集到的数据是否同RM（reference model）的期望数据一致。
对于DUT内部的关键功能模块，也有相对应的线程进行独立的检查。
在检查过程中，可以将检查成功的信息统一纳入到检查报告中，便于仿真后的追溯；如果检查失败，可以暂停仿真同时报告错误信息，进行在线调试。
线上比较（online check）：在仿真时边收集数据边比较，并产生实时报告。文章来源：https://www.toymoban.com/news/detail-594020.html
线下比较（offline check）：将仿真是收集到的数据记录在文件中，仿真结束后，通过脚本或者其它手段进行数据比较。文章来源地址https://www.toymoban.com/news/detail-594020.html
到了这里，关于SV芯片验证之验证环境的文章就介绍完了。如果您还想了解更多内容，请在右上角搜索TOY模板网以前的文章或继续浏览下面的相关文章，希望大家以后多多支持TOY模板网！
