日志

验证的结构篇之五：比较器

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

无论是从实现难度，还是从维护人力上来讲，checker（比较器）都应当是最需要时间投入的验证组件了。之所以这样评估，是因为checker肩负了几乎所有模拟设计行为和功能检查的任务。更细致来看，一个checker的功能包括：

缓存从各个monitor收集到的数据
将DUT输入接口侧的数据汇集给内置的reference model（参考模型）。Reference model在这里扮演了模拟硬件功能的角色，也是需要较多精力维护的部分，因为验证者需要在熟读硬件功能描述的情况下实现模型，而不应该参考真实硬件。
通过数据比较的方法，检查实际收集到的DUT输出端接口数据是否同reference model产生的期望数据一致。
对于设计内部的关键功能模块，也有相对应的checker进行独立的功能检查。
在检查过程中，可以将检查成功的信息统一纳入到检查报告文件当中便于仿真后的追溯。如果检查失败，也可以采取暂停仿真以及报告错误信息的方式便于验证者调试。

从checker这些细分的功能来看，我们需要记住几个关键词：数据缓存、参考模型和检查报告。而我们在后期的代码实例中也会围绕着这几个部分进行梳理。

在实际项目中，各种checker的实现方式迥异，大致分为两类：

线上比较（online check）：在仿真时收集到的数据，可以在仿真时检查并且实时报告。
线下比较（offline check）：通过仿真收集到的数据，在仿真结束以后，经过脚本或者其它方式处理，进行数据比较。

在硬件设计发展初期，由于DUT的功能较为简单，所以才去直接测试（directed test）和线下比较的方式就不足为奇了，甚至验证者没有数据处理脚本或者参考模型，只是通过自己对功能的理解进行眼睛比较也是存在的。而伴随着设计的功能愈加复杂，靠验证者自己每次进行繁琐检查的方式也缺少了验证的可靠性。于是我们将checker添加到验证环境中，需要它做的是可以分析DUT的边界激励，理解数据的输入，并且按照硬件的功能来预测输出的数据内容。这种预测（prediction）的过程，即发生在reference model中，有时我们也将其称之为predictor。

从MCDF的checker来看，对于数据的整形（formatter）部分，控制寄存器可以控制生成数据包的长度，那么reference model也需要register monitor的观察数值来做数据包内容的预测。一般而言，reference model也会内置一些缓存，用来存储从DUT输入端观察到的数据，以及经过功能转换的数据存放到独立缓存中。同时，checker内也应该有其它独立的缓存来存储从输出端采集到的数据，即下图中由forammter monitor存放到MCDF checker的formatter FIFO。

由于MCDF是有着数据通路的功能，所以我们认为reference model存储的数据内容顺序和formatter FIFO中数据的顺序是一致的。这种顺序一致性也有利于我们做前后的数据比较，即data checker一旦发现两者的FIFO都有数据时，即可以从中读出等量数据来做比较。如果数据比较成功，可以将数据信息和比较信息打印到仿真窗口，以及仿真文件当中；如果数据比较失败，则可以暂停仿真，将比较失败的数据信息提供给验证者。

除过上面介绍的reference model、formatter FIFO（output data buffer）和data checker之外，我们也可以考虑引入更多细致的检查功能，这些检查功能实际和各个模块相对应，它们分别是：
channel checker
arbiter checker
register checker
formatter checker

我们再回顾上一节谈到的关于monitor的分布，不难发现checker、monitor和stimulator与MCDF内部的各个模块都有着一一对应的关系。我们之前也建议将monitor和stimulator各自对应组成一个个的小单元，那么checker是否也合适与其对应呢？又应该怎么放置呢？在回答这个问题之前，我们不妨考虑一下进行分散搁置与集群搁置的特点是什么。

分散搁置
各自检查对应模块的功能
checker之间通信需要特殊连接
报告信息较难统一
对于各个checker的使能控制因其分散变得复杂

集群搁置
各自检查对应模块的功能
checker各自相邻，可以共享monitor的输入，减少复杂的连接关系
可以按照统一的报告形式，写入到统一的文件当中
集中式管理各个checker，例如在前期使能各个模块的checker，在后期可以将其作为黑盒验证，只使能data checker。

对于更加复杂的系统验证方式，我们也倾向于集中管理stimulator和checker，因为它们两者都需要主动给出激励或者判断结果，所以需要较多的协调处理。而monitor则相对好处理，因为它只是作为监测方，将其兢兢业业观察到的数据一字不落地交给checker即可，至于checker怎么使用monitor并不需要关心。

那么既然checker需要集群式管理，为什么stimulator可以跟monitor作为独立的单元，不需要集群式搁置呢？这一点疑问我们会在SV和UVM的章节中为读者提供可以分别实现集中管理的方式，读者也可以通过对比来评价两种方式的优劣。

我们下一节也将同大家再次分析DUT MCDF的结构，以及考虑作为一个项目，如何高效地完成实际的验证工作，其中也涉及到验证者之间协作、验证同设计的进度安排关系，读者可以更开阔地考虑如果你负责这个设计时准备如何展开验证工作？

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