【路科V0】验证环境2——验证环境组件

测试平台(testbench)结构图

典型验证结构框图

主要验证环境 组件

• 激励发生器
• 监测器
• 比较器

激励发生器

Stimulator（激励发生器）是验证环境的重要部件。

在一些场合中，它也被称为

• driver (驱动器）
• BFM (bus function model,总线功能模型）,
• behavioral(行为模型）
• generator (发生器）。

Stimulator的主要职责

        模拟与DUT相邻设计的接口协议，只需要关注于如何模拟接口信号，使其能够以真实的接口协议来发送激励给DUT。

        Stimulator不应该违反协议，但不拘束于真实的硬件行为，还可以给出更多丰富的只要协议允许的激励场景。

        比真实硬件行为更丰富的激励，会使得在模块级的验证更加充分，因为它不但可以验证硬件普通的接口时序，还模拟出更多复杂的、在更高系统级别无法产生出来的激励场景。

        Stimulator的接口主要是同DUT连接，此外，也有时钟和复位信号的输入,确保生成的数据同DUT的接口一侧是同步的关系。

        Stimulator还可以有其它的配置接口用来控制接口数据的生成。

        Stimulator也可以有存储接口数据生成历史的功能，这可以用来在仿真运行时或者结束后查看接口数据，方便统计或者调试。

激励组件结构框图

被测设计DUT：MCDT 

在构建验证环境时，会先将stimulator和 添加进来

channel generator负责生成激励数据，送往channel initiator

channel initiator在接收到激励数据以后，会将它们按照协议时序，驱动到接口上面

接口与设计MCDT相连，这时MCDT的端口接收到了激励数据，将其存入到缓存中。

​​​​​​​stimulator分类：

 从stimulator同DUT的连接关系来看，我们可以将其进一步分为两种:

• initiator (发起器）用来对设计主动发送数据请求
• responder(响应器） 作为从端，被动响应

实现initiator的要求

以MCDT ​​​​​​​为例

1、满足时序协议 

        由于channel从端接口协议上有握手信号，我们需要遵照接口时序，确保chx_ready为低时，保证chx_data和chx_valid保持不变。

2、发送的数据之间是否考虑空闲周期，设定整体数据的传输速率

        相邻数据之间没有数据包的限制，所以相邻数据之间的关系较弱，但也应该考虑数据之间是否有空闲周期，以及整体数据的传输速率设定。

3、由于每一个数据从端都有对应的FIFO缓存数据，所以也需要考虑如何使得FIFO的状态可遍历

        例如，典型的FIFO状态可以分为empty、 full以及中间状态即有数据存储但未写满。

        要使得FIFO可以触发这些状态，我们就应该控制channel initiator的传输速率。

监测器

Monitor（监测器）的主要功能

        用来观察DUT的边界或者内部信号，并且经过打包整理传送给其它验证平台的组件，例如 checker(比较器）。

从监测信号的层次来划分monitor的功能：

• 观察DUT边界信号
• 观察DUT内部信号

观察DUT边界信号

•   对于系统信号如时钟，可以监测其频率变化
•   对于总线信号，可以监测总线的传输类型和数据内容，以及检查总线时序是否符合协议。

观察DUT内部信号

        从灰盒验证的手段来看，往往需要探视DUT内部信号，用来指导stimulator的激励发送，或者完成覆盖率收集，又或者完成内部功能的检查。

监测器组件结构框图

        分布式的monitor结构，monitor一般会对应一个stimulator 。

        对于MCDT 验证结构,我们需要3个channel monitor来监测对应的channel接口，以及1个arbiter monitor来监测arbiter接口。

监测器实现建议 

         如果没有特殊的需要，我们应采取灰盒验证的策略（而非白盒）。

        观察的内部信号应当尽量少，且应当是表示状态的信号。（不建议采集中间变量信号的原因在于，这些信号的时序、逻辑甚至留存性都不稳定，这种不稳定对于验证环境的收敛是有害的。）

        可以通过接口信息计算的,就尽量少去监测内部信号（因为这种方式也有悖于假定设计有缺陷的验证思想）

我们观测到的内部信号在被环境采纳之前也有必要确认它们的逻辑正确性，使用方式

• 动态检查
• 断言触发

比较器

         无论是从实现难度,还是从维护人力上来讲，checker （比较器）都应当是最需要时间投入的验证组件了。

         我们将checker添加到验证环境中，需要它分析DUT的边界激励，理解数据的输入，并且按照硬件功能来预测输出的数据内容。

        这种预测(prediction）的过程,发生在reference model中，有时我们也将其称为predictor。

        reference model也会内置一些缓存，存放从DUT输入端观察到的数据，以及经过功能转换的数据，同时checker也有其它缓存来存放从输出端采集到的数据。

checker作用：

• 模拟设计行为和功能检查的任务。
• 缓存从各个monitor收集到的数据。

        checker缓存从各个monitor收集到的数据继而 将DUT输入接口侧的数据汇集给内置的reference model(参考模型）。

Reference model在这里扮演了模拟硬件功能的角色（需要较多精力维护的部分，因为验证者需要在熟悉硬件功能的情况下实现该模型，而又不应参考真实硬件的逻辑。）

         通过数据比较的方法，检查实际收集到的DUT输出端接口数据是否同reference model产生的期望数据一致。

        对于设计内部的关键功能模块，也有相对应的线程进行独立的检查。

        在检查过程中，可以将检查成功的信息统一纳入到检查报告中，便于仿真后的追溯。如果检查失败，也可以采取暂停仿真同时报告错误信息的方式，进行在线调试。

数据比较方式

• 线上比较（online check) 在仿真时收集数据和在线比较，并且实时报告。
• 线下比较（offline check) 将仿真时收集到的数据记录在文件中，在仿真结束后，通过脚本或者其它手段，进行数据比较。

比较器组件结构框图

白色部分：待测设计MCDT

蓝色部分：验证环境部分

        channel generator和channel initiator之间保持通信，monitor和checker之间保持通信。

（线程间的通信）​​​​​​​

比较器实现建议

        对于复杂的系统验证，我们倾向于集中管理stimulator和checker，因为它们两者都需要主动给出激励或者判断结果，也需要较多的协调处理。

        而monitor则相对更独立，因为它只是作为监测方，将其兢兢业业观察到的数据一字不落地交给checker即可，至于checker怎么使用，monitor并不需要关心。

        因此，stimulator和monitor是一一对应，我们通常将它们进一步封装在agent单元组件中，而checker则最终集群搁置在中心化的位置。