本文主要是介绍V0 第11节 验证环境组件，希望对大家解决编程问题提供一定的参考价值，需要的开发者们随着小编来一起学习吧！
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则最终集群搁置在中收化的位置
这篇关于V0 第11节 验证环境组件的文章就介绍到这儿，希望我们推荐的文章对编程师们有所帮助！
