测试框架和测试用例的垂直复用

uTB的优点不但在于它可以自动化生成，而它的另外一大优点还在于构建在这一结构之上的测试标准化。同我们上面介绍的uTB依赖的资源中，统一的测试指令集和通信网络使得各个VIP都可以从uTB master一侧接收到命令，而这些统一的指令（TLM2 socket数据包格式）在穿过了uNet抵达uTB slave之后，就会被解析为对应的VIP sequence/item。

下面这个表中给出了三种统一化的指令子集：

• 数据访问指令

• 寄存器访问指令

• 其它指令

利用这些uTB command，uTB master可以指挥任何一个uTB slave VIP发送出数据、寄存器访问操作或者其它的激励。而这种统一化的指令集形式，使得uTB测试用例更加容易创建、维护和阅读。同时，这一些数量不多的指令也非常方便于UVM新手来使用，它们所构成的测试用例非常像C的测试代码。而考虑到从模块级到系统级的复用，这一套子集也与C测试用例兼容，即同样的一份测试代码，即可以用UVM语句来实现，也可以用C语句来实现。正因为这一套指令集的确定性定义，使得它从UVM层转化为C层非常容易，而用户用C语言写的寄存器配置序列，又可以在更高层的测试中为处理器所复用。

例如下面这段例码，测试的指令时从env.utb_master1发出的，而在调用这些指令时需要按照要求传入相应的参数。

• 在使用command_put时，传入指令、uTB slave地址和参数（个数可变）后，前两条指令操作分别要求对应的CR（Clock & Reset） VIP master agent设置时钟频率以及复位。

• 在接下来的两个操作命令时，通过write_reg_by_name和read_reg指令，对目标寄存器进行了写操作和读操作。而verifier在这里，只需要关系寄存器的名字，至于寄存器的地址（包含在寄存器模型中）和寄存器的访问总线类型（由寄存器地址匹配到对应的uTB slave VIP），verifier并不需要关系。这背后实际上是对访问地址和数据的依赖性，这也是一种标准化的需求，而并不需要考虑映射到的VIP是什么，这种映射关系和协议转换关系，已经由uNet网络和uTB slave所解决。

• 后续的四个操作指令，是对目标地址做了读写操作。这里verifier仍然只需要考虑，往哪个地址段（即对应哪一个接口）上发送数据，因此'h2000_F000和'h4000_F000对应的接口分别是AHB和AXI。

• 最后的两条命令，是对另外一个IOC VIP的操作，该VIP可以用来设置和检查I/O信号。

上面给出的是利用uTB command的UVM测试用例，我们也说过uTB支持C的指令集。那么从模块级到系统级，哪些测试例码部分会被复用呢？寄存器访问一定会被复用，因此如果将寄存器的操作部分一开始就由C来实现，而其余部分用UVM来实现，通过C和UVM的混合模式，在模块一级可以使用，而C的寄存器操作部分代码，由可以无缝衔接到系统级测试。下面我们就给出一段例码：

可以从这段例码中看到，将之前的寄存器访问UVM代码转化为C测试代码utb_c_thread0。通过定义相应的C-DPI接口，使得C测试代码间接对环境中的utb_master发出指令操作。这一段C代码在UVM测试用例lpddr4_command_c_combo_test中将原有的UVM寄存器操作指令替换，而UVM则调用了C的代码。因此，在稍后更高层的测试用例中，寄存器的操作部分即可以复用utb_c_thread0中的C代码。

中心化的功能覆盖率管理

之前的UVM Framework和QVIP configurator相结合，使得在集成了标准VIP和customized VIP到环境中后，还可以实现将各个VIP的monitor的TLM analysis port接入到相应的preidictor和scoreboard中。而在uTB中，这一功能也依然保留了下来。而如果我们再回过头来想一想，为什么要开发一个TB自动化工具时，希望有一致化结构的TB和验证流程标准，是一个重要的考量。那么，除了可以将测试用例标准化之外，还有什么可以标准化呢？在实际的模块级验证过程中，除了验证结构被设定得五花八门以外，对于验证完备性的考量也是因人而异，因此验证经理也很难做到体察入微，去检视每一个verifier的验证量化工作。

那么，如果可以在uTB这样一个中心化平台上面，也将验证量化的部分考虑进去，从平台层面引入验证量化机制，会对整个验证流程的标准化提供又一个衡量标准。从下面这张图可以看到，在仿真过程中可以通过中心化的top coverage manager来收集下面几种类型的覆盖率：

• 寄存器覆盖率

• 总线协议覆盖率

• 其它I/O跳转覆盖率

• 设计内部的覆盖率

由于top coverage manager可以动态地收集覆盖率，进一步将这覆盖率可以分为累积覆盖率和增量覆盖率。累积覆盖率用来指示整体验证的进度，而增量覆盖率用来关联增加的覆盖率和选择的激励序列之间。这两种覆盖率以及背后记录的相关数据可以用来进一步产生动态的随机限定，用来引导产生更有效的随机激励，继而避免越到后期越是盲目无效的随机激励。因此，这种中心化的覆盖率显示和管理机制，不但可以对验证流程给出标准化要求，同时也可以通过其内部的算法用来产生更“智能”的随机激励。在这里，“智能”激励即覆盖率驱动方法，在最近的几年一直是一个热门的验证热门话题，我们也会在后面的《覆盖率驱动验证篇》中进一步介绍。

贯穿到本章中的TB自动化的核心出发点在于，不但需要帮助verifier节省搭建和调试TB的时间、还在于根据公司和项目的实际情况，考虑如何实现跨平台、跨层次复用的问题。MentorGraphics提供的UVM Frameworks提供的是双TB的结构，该出发点是为了后期可以跨平台在emulator上面运行，同时依靠inFact可以实现图形化的激励描述以及在更高一级的激励描述上实现跨层次的激励复用；路桑在本节中介绍的自研发的Pangu，支持的C接口，也是为了模块级到系统级的复用，然而受制于项目的实际情况，uTB的结构并没有为跨平台做出更多的考量，例如如何兼容emulator和FPGA的运行等。虽然说这对于Pangu和uTB看起来是一个“遗憾”，但还是那句话，鞋合不合脚只有自己知道。自研发的工具优点就在于可以解决当下自己所处项目的问题，同时也考虑将现有的流程进一步规范起来。希望路粉们在阅读完这一章之后，有自己的想法，可以实现最贴合公司和项目实际的TB自动化工具。

我们下一章将进一步介绍，如何考虑跨平台的激励描述和复用问题。这个热点话题会时接下来五年验证领域的重点方向，至于路桑为什么会给出这样一个判断，我们在下一章中会详细分析。

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