2.1.2 -1【验证环境的结构和组件】

1. 测试平台

1.1 概述

测试平台 (testbench) 是整个验证系统的总称

它包括验证结构中的各个组件、组件之间的连接关系、测试平台的配置和控制。

从更系统的意义来讲，它还包括编译仿真的流程、结果分析报告和覆盖率检查等

从狭义上讲，我们主要关注验证平台的结构和组件部分，他们可以产生设计所需要的各种输入，也会在此基础上进行设计功能的检查。

测试平台结构图

2. 硬件设计描述

寄存器：所有的硬件跟外部交互的接口，无论是跟处理器，还是硬件与硬件之间的交互都要通过寄存器 一方面对功能做配置，另一方面可以获取硬件本身的一个状态，一个成熟的硬件需要自己的寄存器读写模块

读懂接口，各个信号之间代表什么含义

系统信号接口

• CLK(0)：时钟信号。 0代表1位

整形器接口

下行数据输出的时候很多接口，

控制寄存器接口

要对整个硬件功能模块做配置，要对寄存器里面写数值。 控制模块里面有多少个寄存器？

整形器接口时序

req送到下行的时候，下行拿到了，但是要消化这一拍，要花一个clk的时间。到下一个clk的时候，如果下行数据本身内部有足够的缓存话，grant可以立马拉起来，如果下行数据缓存不够，不到4个world余量的时候,grant也不会拉高。所以reg和grant之间至少保持一个周期的延迟。因为grant表示能接受4位的数据包

MCDF寄存器描述

读写寄存器：即可以写，也可以读

3. 激励发生器

要符合时序协议，在时序协议基础上，考虑怎样通过丰富的时序组合 最终满足设计的不同状态

4. 检测器

要符合时序协议，在时序协议基础上，考虑怎样通过丰富的时序组合 最终满足设计的不同状态，离不开检测器。检测器要捕捉接口时序、内部状态、内部时序。激励发生器一般关注接口上的，监测器关注端口 内部都可以

内部信号监测建议

•  如果没有特殊的需要，我们应采取灰盒验证的策略 (而非白盒)
•  观察的内部信号应当尽量少，且应当是表示状态的信号。不建议采集中间变量信号的原因在于，这些信号的时序、逻辑甚至留存性都不稳定，这种不稳定对于验证环境的收敛是有害的。 跑门极仿真的时候，会把内部网表信号打散，内部信号经过优化都不见了
•  可以通过接口信息计算的，就尽量少去监测内部信号，因为这种方式也有悖于假定设计有缺陷的验证思想。我们观测到的内部信号在被环境采纳之前也有必要确认它们的逻辑正确性，这一要求可以通过动态检查或者断言触发的方式来实现。

5. 比较器

概述
无论是从实现难度，还是从维护人力上来讲，checker (比较器都应当是最需要时间投入的验证组件了. checker不单要把monitor监测到的数据要利用好，怎么利用？
checker肩负了模拟设计行为和功能检查的任务

功能
缓存从各个monitor收集到的数据
将DUT输入接口侧的数据汇集给内置的reference mode(参考模型)。 Reference model在这里扮演了模拟硬件功能的角色，（不可综合的behaiver model，功能和mcdf一样，从monitor拿到的数据交给自己，相当于reference mode从各个channel拿到的数据，然后按照自己打包的理解，将数据打包出来。 reference mode 还要模拟寄存器，寄存器不同的配置都会影响reference mode：把每一个chanel打开关掉、不同的优先级、包的长度 ）也是需要较多精力维护的部分，因为验证者需要在熟悉硬件功能的情况下实现该模型，而又不应参考真实硬件的逻辑。
通过数据比较的方法，检查实际收集到的DUT输出端接口数据是否同reference model产生的期望数据一致。
对于设计内部的关键功能模块，也有相对应的线程进行独立的检查
在检查过程中，可以将检查成功的信息统一纳入到检查报告中便于仿真后的追溯。如果检查失败，也可以采取暂停仿真同时报告错误信息的方式，进行在线调试

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

比较器组件结构 (续
除过上面个绍的reference model、 formatter FIFO (outputdata buffer) 和data checker之外，我们也可以考虑引入更多细致的检查功能，这些功能和各个模块相对应，它们分别是
channel checker
arbiter checker
register checker
formatter checker

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

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

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

比较器结构实现建议
对于复杂的系统验证，我们倾向于集中管理stimulator和checker，因为它们两者都需要主动给出激励或者判断结果，也需要较多的协调处理
而monitor则相对更独立，因为它只是作为监测方，将其兢兢业业观察到的数据一字不落地交给checker即可，至于checker怎么使用，monitor并不需要关心。
因此，monitor和stimulator是一一对应，我们通常将它们进一步封装在agent单元组件中，而checker则最终集群搁置在中心化的位置。

6. 验证结构

如果把mcdf当做一个子系统，子系统里面个个模块一开始有对应的人去验证

情景模拟
我们将模拟实际工作，来抛出一系列的问题，希望同学加以思考课程给出的建议不是最好的，至少按照工程项目观点来看，它是合理的。

项目背景
需要考虑分配设计人员和验证人员你将是这个设计模块的负责人，而老师作为验证的老司机，对于下面这些模块的实现难度做出了评修

• channel slave (slave interface + FIFO)需要7个工作日
• arbiter 需要10个工作日
• formatter 需要5个工作日
• registers 需要4个工作日
• MCDF integration (模块集成)需要2个工作日）

目前一共有3位designer: 肖、吕、高，你需要在最短的时间安排他们完成设计工作。你考虑的人力安排是怎么样的呢? 由于MCDF模块之间有着独立性，我们可以同时安排3名设计者展开工作，那么一种较为合理的建议是
肖: channel slave 7天 + MCDF integration 2天 = 9天

吕：arbiter 10天 = 10天

高: formatter 5天 + registers 4天 = 9天
从设计完成的周期来看，一共需要10天(取最长的设计者所用时间）那么针对这份设计的进度安排，你又该怎么安排排验证工作呢?

当肖做到第7天的时候，arbiter和formatter的端口都稳定了， 就可以做基于端口的集成了
 

验证进度安排
在开展验证之前，首先恭喜你，运气还不错，你被分配了4位verifier:梅、尤、娄、董，比designer还要多呢。如果按照简单的人力比例，即验证人力: 设计人力大致为 1.5:1的话，那么上述各个模块的验证人力大致需要
channel slave 11个工作日
arbiter 15个工作日
formatter 8个工作日
registers 6个工作日
MCDF integration的验证人力还有待商榷，因为它不单单需要2x1.5个工作日，而是在MCDF集成以后，各个模块在子系统完成集成验证，我们暂时按照30个工作日计算。

 项目计划表

只要设计有初步的版本，设计边界稳定，有基本的功能，就可以写验证了。

董：先做验证的集成环境（mcdf的集成环境：channel 、 arbiter 、formatter）

设计子系统（mcdf）集成完成，要做顶层验证

从设计人力利用上来看，尽力做到了设计从各个模块设计开始到交付用了最短的时间。
从验证一侧看，verifier梅、尤、娄的验证开展时间要略晚于设计部分。这是因为只有在设计的边界和功能有初步版本时，验证才可以开始进入

在verifier梅、尤、娄开始搭建验证环境的过程中，verifier董看似没有事情可以安排，因为designer高的另外一个设计registers还没有开始准备，那么verifier需要等待吗? 实际上verifier董可以在其余三位verifier搭建模块验证环境一段时间以后着手准备顶层验证环境

待完成初步验证环境集成以后verifier董也可以在适当时间开始验证模块registers。在完成模块验证以后，verifier董可以进行最后阶段的（子系统）验证环境持续集成
verifier梅、尤、娄在verfier董进行验证环境的持续集成前后可以在完成模块验证之后，进入顶层验证，检查各自的模块是否工作，而所用到的checker均来自于他们的模块验证环境。同verifier董也应该进行最后的顶层验证检查模块registers的功能
MCDF作为一个整体子系统，我们不能忽视各个模块的协调使用这项工作我们交给了verifier娄，因为他还有一定的时间来完成这项任务。完成MCDF整体验证的任务包括，协调stimulator和checker来创建激励场景和检查数据。数据检查用到的reference model、formatter FIFO和data checker需要由verifier娄来实现。

对于顶层验证的内容，你认为它包括什么?尝试列举对于channel slave、arbiter、register和formatter在顶层验证时的各一个功能验证点。
例如:registers需要在]页层验证它对各个slave的开关功能是否可以通过寄存器配置生效，以此来检查registers模块和各个channel slave模块的集成是否正确

对于模块来讲，关注的是给它们实现一些丰富的激励，越往上走关注的是模块与模块之间的互动