验证通识2 比较器

功能

模拟硬件设计行为 检查功能（数据缓存 参考模型 检查报告），详细来讲：

• 缓存从各个monitor收集到的数据（如formatter FIFO存放formatter monitor发送来的数据）
• 将DUT输入接口侧的数据汇集给内置的reference model，reference model 模拟硬件行为，模拟出的数据和DUT输出端接口数据的做数据比较（r m分析DUT的边界激励，理解数据的输入，并按硬件功能来预测输出的内容）
• DUT内部的关键功能模块（register arbiter formatter），checker也有相应的线程进行独立检查
• 模拟寄存器：因为寄存器不同的配置会影响reference model的模拟行为(比如channel的开关、数据的不同优先级、包的长度等）
• 主线是做数据端完备性检查，对一些关键信息如时序，也会做一些task或断言做检查）

checker怎么来的？----来自模块验证环境

检查结果的处理

检查成功：
检查成功的信息统一纳入到检查报告中，便于仿真后的追溯

检查失败：
立即暂停仿真，找到案发现场，报告错误信息，进行在线调试

reference model（不可综合）

对于一些复杂的reference model，不建议验证师自写自验，写出来的r m几乎和硬件一模一样，只是可综合不可综合的区别，验证师需要在熟悉硬件功能的情况下实现该模型，不应参考真实硬件的逻辑

数据比较

线上比较：
仿真过程中收集数据，在线比较，并实时报告

线下比较：
仿真结束后将收集到的数据通过脚本或其他工具进行数据比较

建议checker集群搁置

集群搁置的特点（优势）：

• 各自检查对应模块的功能
• checker们共享monitor的输入，减少复杂连接
• 对各个checker的使能控制变得容易（集中管理checker的好处）（例如在前期检查各个模块，就使能各个模块的checker，后期不需要模块checker的时候将其关掉，此时mcdf checker相当于黑盒验证，只使能data checker（数据完备性checker)）

stimulator monitor checker分布特点

建议集中管理stimulator和checker，因为stimulator需要主动给出激励，checker需要判断结果，都需要协调处理：
例如，协调各个stimulator顺序or并行发送激励？；使能单一checker或是所有checker？

建议分布式monitor：
monitor相较于stimulator和checker更独立，只是监测方，只需把自己检测到的数据发送给checker即可

列举顶层验channel slave register arbiter formatter时的一些功能点

• 时序问题：对于formatter模块级验证来讲，formatter只能在固定的阶段接收来自某一固定channel的数据（formatter不能同时接受来自channel1和channel2的数据），比如出现arbiter在第一拍发送channel1的数据，第二拍发送channel2的数据，**这种时序问题在单独验模块的时候是验不出来的（**单独验formatter的时候相当于假设arbiter不应该出现这种情况），只能在MCDF子系统级别的验证时才能检查得到
• register需要在顶层验证它对各个slave的开关功能是否可以通过寄存器配置生效，以此来检查register模块和各个channel slave模块的集成是否正确
• 某一个channel打开的时候，channel的输入数据和formatter的输出数据是否一样（channel打开的时候数据是不是真正通过channel并从formatter输出）
• 打开或关闭某些channel对其他channel有没有影响

题目

1.ABCD

2.ABC