路科验证的个人空间 https://blog.eetop.cn/1561828 [收藏] [复制] [分享] [RSS]

空间首页 动态 记录 日志 相册 主题 分享 留言板 个人资料

日志

验证的结构篇之四:监测器

已有 1633 次阅读| 2016-11-27 23:02 |个人分类:验证系统思想|系统分类:芯片设计

Monitor(监测器)的主要功能是用来观察DUT的边界或者内部信号,并且经过打包整理传送给其它验证平台的组件,例如checker(比较器)。从更多的功能来划分monitor的功能,它们包括有:
  • 观察DUT边界信号。对于系统信号如时钟,可以监测其频率变化;对于总线信号,可以监测输入总线的传输类型,以及检查输出总线是否符合协议。
  • 观察DUT内部信号。从灰盒验证的方法来看,往往需要探视DUT内部信号,用来指导stimulator的激励发送,或者完成覆盖率收集,又或者完成内部功能的检查。

结合上一节stimulator的验证结构图布置,我们有如下的两种monitor结构框图:
从上图可以看出,我们需要在验证平台中置入一个monitor,该组件的功能需要监视整个环境中的信号,这包括了:
  • 寄存器配置接口。
  • 3个通道从端数据接口。
  • formatter输出接口。
  • MCDF内部信号,包括register、arbiter以及formatter的关键信号。

同时,我们再转入到下面这张图来看monitor是如何配置的。从图中可以发现,每一个monitor都对应一个stimulator,所以,我们需要如下的monitor:
  • 3个channel monitor用来分别检测对应的channel initiator。
  • Register monitor监测寄存器配置接口。
  • Formatter monitor监测formatter输出接口。
  • MCDF monitor监测register、arbiter和formatter的内部信号。
从功能的角度来看,无论是前者的集为一体的monitor,还是后者的使之分离各司其职的monitor群,都可以完成监测全局的任务,那么,两者之间应该采用哪种方式为好呢?我们试着就如下几个方面进行对比:
  • 独立性:我们倾向于后者,即将不同接口信号的采集交给相应的monitor。因为就各个接口的功能而言,它们之间没有联系性,易于切割。
  • 复用性:仍然是后者,可以考虑如果MCDF的接口也可能会运用到别的验证环境中,那么相对独立的monitor功能可以更好地作为验证IP被其它验证环境所采用。基于这个考虑,我们也将通道从端数据接口的采集分别对应到了3个channel monitor,而每一个monitor只需要负责监视一组总线。
  • 可维护性:后者也优于前者,可以想象MCDF外部接口必定先于内部信号趋于稳定,那么平行的monitor组更有利于验证者定向维护MCDF monitor,而不需要考虑其它的monitor种类。同样地,到了后期项目,或者设计遇到修改时,更可能修改的是内部逻辑,而非接口信号,这种情况下也只需要更新MCDF monitor,而不必要更新其余的接口类型monitor。
  • 封装性:后者的优势在于可以与各个stimulator一一对应,形成验证环境的小单位,这些小单位之间的通信可以按照统一的方式交流,但又需要保持各自的独立性。这样的话,各个小单位即一个stimulator对应一个monitor,就可以将其封装为独立的组件,使其提供激励和监测的功能。

从上面的分析可以得出,无论是monitor还是stimulator,我们都倾向于将验证环境中的组件尽量做到功能单一,而非采取大而全的方式,这种方式带来的好处,可以在日后我们实际代码的验证环境集成和垂直复用中得到印证。

对于monitor的监测功能实现,我们也应该遵循同stimulator一致的要求,即验证者应该深度理解协议的细节,这样无论是按照协议采集数据,还是检查DUT的输出接口是否按照协议实施,都是必须的。对于需要监测MCDF内部信号的要求,我们也应该尽量遵循如下的建议:
  • 如果没有特殊的需要,我们应采取灰盒验证的策略(而非白盒)。
  • 观察的内部信号应当尽量少,且同时属于表示状态的信号。不建议采集中间变量信号的原因在于这些信号的时序、逻辑甚至留存性都不稳定,这种不稳定对于验证环境的稳定收敛是有害的。
  • 可以通过接口信息计算的,就尽量少去监测内部信号,因为这种方式也有悖于假定设计有缺陷的验证思想。我们观测到的内部信号在被环境采纳之前也有必要确认它们的逻辑正确性,这种检查方式可以使用动态检查或者断言触发的方式来实现。

最后,在数据监测收集、覆盖率收集、协议检查之外,在高级的验证环境中, monitor也可以通过收集的覆盖率加以分析,来反馈指导stimulator的激励数据生成,这种方式我们称之为功能覆盖率驱动验证(function coverage driven verification),我们也将在下一篇SystemVerilog的实践部分给出代码实例以供参考。

下一节我们将介绍验证组件的最后一个成员,checker(检查器),来看一看checker的功能和需要注意的地方有哪些。

谢谢你对路科验证的关注,也欢迎你分享和转发真正的技术价值,你的支持是我们保持前行的动力。


点赞

评论 (0 个评论)

facelist

您需要登录后才可以评论 登录 | 注册

  • 关注TA
  • 加好友
  • 联系TA
  • 0

    周排名
  • 0

    月排名
  • 0

    总排名
  • 0

    关注
  • 253

    粉丝
  • 25

    好友
  • 33

    获赞
  • 45

    评论
  • 访问数
关闭

站长推荐 上一条 /1 下一条

小黑屋| 关于我们| 联系我们| 在线咨询| 隐私声明| EETOP 创芯网
( 京ICP备:10050787号 京公网安备:11010502037710 )

GMT+8, 2024-4-26 17:07 , Processed in 0.016864 second(s), 12 queries , Gzip On, Redis On.

eetop公众号 创芯大讲堂 创芯人才网
返回顶部