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则最终集群搁置在中收化的位置