测试平台(Testbench)是整个验证系统的总称。它包含了验证系统的各个组件、组件之间的互联关系,测试平台的配置与控制等, 从更系统的意义来讲,它还包括编译仿真的流程、结果分析报告和覆盖率检查等。 从狭义上讲,我们主要关注验证平台的结构和组件部分,他们可以产生设计所需要的各种输入,也会在此基础上进行设计功能的检查。
我们在刚开始介绍SV的时候就介绍了完整的验证平台结构应该包含哪些部分:
这里我们先从一个最简单的测试平台开始,先把平台搭建起来,再根据需求进行逐步完善。在这里我们暂时只考虑驱动器(也叫激励器Stimulator),监测器(Monitor),比较器(Checker)。
Stimulator(激励发生器)是验证环境的重要部件,在一些场合中,它也被称为driver(驱动器)、BFM(bus function model,总线功能模型),behavioral(行为模型)或者 generator(发生器)。
Stimulator的主要职责是模拟与DUT相邻设计的接口协议,只需要关注于如何模拟接口信号,使其能够以真实的接口协议来发送激励给DUT。
从stimulator同DUT的连接关系来看,我们可以将其进一步分为两种:initiator( 发起器)和responder(响应器)。
对于 initiator,它的功能是主动发起接口数据传输;对于 responder,它的职责是对接口的数据发送请求做出响应,而它自身并不会主动发送数据。
Monitor(监测器)的主要功能是用来观察DUT的边界或者内部信号,并且经过打包整理传送给其它验证平台的组件,例如 checker(比较器)。
从监测信号的层次来划分monitor的功能,它们可以分为观察 DUT 边界信号和观察 DUT 内部信号。
- 观察DUT边界信号。对于系统信号如时钟,可以监测其频率变化;对于总线信号,可以监测总线的传输类型和数据内容,以及检查总线时序是否符合协议。
- 观察DUT内部信号。从灰盒验证的手段来看,往往需要探视 DUT内部信号,用来指导stimulator的激励发送,或者完成覆盖率收集,又或者完成内部功能的检查。
无论是从实现难度,还是从维护人力上来讲,checker(比较器) 都是最需要时间投入的验证组件了。
checker肩负了模拟设计行为和功能检查的任务。 缓存从各个monitor收集到的数据。 将DUT输入接口侧的数据汇集给内置的reference model (参考模型)。Reference model在这里扮演了模拟硬件功能的角色,也是需要较多精力维护的部分,因为验证者需要在熟悉硬件功能的情况下实现该模型,而又不应参考真实硬件的逻辑。 通过数据比较的方法,检查实际收集到的DUT输出端接口数据是否同reference model产生的期望数据一致。
在仿真的时候收集数据和在线比较,并且实时报告。
在仿真时,收集数据记录到文件中,在仿真结束后,通过脚本或者其它手段,进行数据比较。
在硬件设计发展初期,由于DUT的功能较为简单,采取定向测试(directed test)和线下比较的方式就不足为奇了,甚至验证者没有数据处理脚本或者参考模型,进行人为比较(manual check)的古老方式也是存在的。而伴随着设计的功能愈加复杂,靠验证者每次进行繁琐检查的方式也缺少了可靠性。于是我们将checker添加到验证环境中,需要它分析DUT的边界激励,理解数据的输入,并且按照硬件功能来预测输出的数据内容。
对于复杂的系统验证,我们倾向于集中管理stimulator和checker,因为它们两者都需要主动给出激励或者判断结果,也需要较多的协调处理。而monitor则相对更独立,因为它只是作为监测方,将其兢兢业业观察到的数据一字不落地交给checker即可,至于checker怎么使用,monitor并不需要关心。因此,stimulator和monitor是一一对应,我们通常将它们进一 步封装在agent单元组件中,而checker则最终集群搁置在中心化的位置。