1. 激励发生器

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

1.1 激励器组件结构框图

1.2 Channel Initiator 组件

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

2.监测器

• Monitor (监测器)的主要功能是用来观察DUT的边界或者内部信号，并且级过打包整理传送给其它验证平台的组件例如checker 比较器
• 从监测信号的层次来划分monitor的功能，它们可以分为观察DUT边界信号和观察DUT内部信号

2.1 监测器组件结构框图

• 如果没有特殊的需要，我们应采取灰盒验证的策略（非白盒）
• 观察的内部信号应当尽量少，且应当是表示状态的信号，不建议采集中间变量信号的原因在于，这些信号的时序，逻辑甚留存性都不稳定， 这种不稳定对于验证环境的收敛是有害的

3. 比较器

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

3.1 比较器组件结构框图

3.2 比较器实现建议

• 对于复杂的系统验证，我们倾向于集中管理simulator和checker,因为它们两都都需要主动给出激励或者判断结果，也需要较多的协调处理
• simulator和monitor是一一对应的，我们通常将它们进一步封装在agent单元组件中，而checker则最终集群搁置在中收化的位置

标签：11,验证,数据,接口,V0,信号,组件,DUT
来源： https://blog.csdn.net/shui1025701856/article/details/120539602