V0 第11节验证环境组件

本文主要是介绍V0 第11节验证环境组件，希望对大家解决编程问题提供一定的参考价值，需要的开发者们随着小编来一起学习吧！

1. 激励发生器

Simulator (激励发生器)是验证环境的重要部件，在一些场合中，它被称为driver(驱动器)、BFM（bus function model,总线功能模型），behavioral(行为模型) 或者 generator(发生器)
Simulator的主要职责是模拟与DUT相邻设计的接口协议，只需要关注如何模拟接口信号，使其能够以真实的接口协议来发送激励给DUT
Simulator 不应该违反协议，但不拘束于真实的硬件行为，还可以给出丰富的只要协议允许的激励场景
比真实硬件行为更丰富的激励，会使得在模块级的验证更加充分，因为它不但可以验证硬件普通的接口时序，还模拟出更多复杂的、在更高系统级别无法产生出来的激励场景
Simulator的接口主要是同DUT连接，此外，也有时钟和复位信号的输入，确保生成的数据同DUT的接口一侧是同步的关系
Simulator还可以有其它的配置接口用来控制接口数据的生成
Simulator也可以有存储接口数据生成历史功能，这可以用来在仿真运行时或者结束后查看接口数据，方便统计或者调试

在这里插入图片描述

从simulator同DUT的连接关系来看，我们可以将其进一步分为两种：initiator(发起器)和responder(响应器)
由于channel 从端接口协议上有握手信号，我们需要遵照接口时序，确保chx_ready为低时，保证chx_data和chx_valid保持不变
相邻数据之间没有数据包的限制，所以相邻数据之间的关系较弱，但也应该考虑数据之间是否有空闲周期，以及整体数据的传输速率设定
由于每一个数据从端都有对应的FIFO缓存数据，所以也需要考虑如何使得FIFO的状态可遍历，例如，典型的FIFO状态可以分为empty,full以及中间状态即有数据存储但未写满，要使得FIFO可以触发这些状态，我们就应该控制channel initiator的传输速率

在这里插入图片描述

无论是从实现难度，还是从维护人力上来讲，checker(比较器)都应当是最需要时间投入的验证组件
checker肩负了模拟设计行为和功能检查的任务
缓存从各个monitor收集到的数据
将DUT输入接口侧的数据汇集给内置的reference model(参考模型)reference model 在这里扮演了模拟硬件功能的角色，也是需要较多精力维护的部分，因为验证者需要在熟悉硬件功能的情况下实现该模型，而又不应参考真实硬件的逻辑
通过数据比较的方法，检查实际收集到的DUT输出端接口数据是否同reference model产生的期望数据一致
对于设计内部的关键功能模块，也有相对应的线程进行独立的检查
在检查过程中，可以将检查成功的信息统一纳入到检查报告中，便于仿真后的查询，如果检查失败，也可以采取暂停仿真同时报告错误信息的方式，进行在线调试
线上比较 online check:在仿真时收集数据和在线比较，并且实时报告
线下比较 offline check: 将仿真时收集到的数据记录在文件中，在仿真结束后，通过脚本进行数据比较