作为QuestaSim10.6（2016年发布）的新特性，UVM Framework受到了不少的关注，这与它旨在于将M家（MentorGraphics）验证套件（QuestaSim、Questa VIP、inFact）做资源整合，发挥testbench建立效率最大化有关，以此来完成资源的深度应用。毫无疑问，如果路粉们所在的公司就在使用M家系列的验证套件，并且事深度绑定用户的话，那就继续深入下去使用这些更高层次的插件，以此能够快速应用VIP、并且可以将激励实现较方便的复用（inFact提供的特性）。

然而，三大厂商的客户都挺广泛，而且经常有验证工具套件几家厂商混用的情况，例如用C家（Cadence）的USB VIP，同时使用S家（Synopsys）家的PCIe VIP和M家的DDR VIP。遇到这种情况，那么上一节介绍的Questa VIP configurator则无法发挥理想的作用，于此同时，UVM Framework也无法快速地集成，同时也不能依赖于inFact实现跨平台、跨层次的复用。除此以外，作为开源或者说一个尽量贴合各位路粉的自动化工具，首先要考虑到不同公司的verifier们面临的情形：

• 使用的VIP可能是商业的，而且来自于不同的公司。

• 使用的VIP也可能是自研发的，不同的VIP来自于不同的团队和开发者，有不同的接口标准。

• 寄存器模型的生成和集成流程也往往不同，这是由于寄存器描述文件的不同标准（可能是自定义的word、excel、xml或者别的格式）还有不同的寄存器访问总线接口（AHB、APB等）

• 在于DUT在顶层testbench连线时，需要考虑自动化（或者半自动）的连线方式，减少人为错误，也提供连线效率。

• 公司们基于历史原因，可能无法直接使用基于可移植激励的新型验证方式（例如inFact），但是verifier们仍然有激励复用的需求，即从模块级到子系统级、再到系统级，以及跨平台的需求。

• 当然，对于TB自动化工具的基本要求，也少不了能够快速实现平台结构搭建、生成基本测试用例、减低调试成本的需要。

如果结合M家的UVM Framework，我们可以说，这个工具的特性，非常适合于M家的纯粹用户，而对于非M家用户、或者在环境中兼容别家VIP或者自研发VIP的情形时，就能力有限了。所以，一句老话运用到自定制的TB自动化工具上面来说，颇有几分契合——金窝银窝不如自己的狗窝。虽然，路桑的Pangu团队都是兼职，都是运用了8小时以外的时间来完成这个工具，但值得高兴的是，我们获得的一线verifier的反馈是没有经过过滤的，而且我们最为自研发团队，可以就公司的实际情况对工具的特性做出添加和调整，这一点很关键，也正是这一点使得这一款TB自动化工具无法被EDA厂商自己的自动化工具所替代。

接下来，我们首先就Pangu可以解决的问题给出一个特性列表：

• 可以兼容任何公司的VIP和自研发的VIP

• 可以将自己公司的寄存器模型创建集成到环境中去

• 可以实现testbench顶层连线自动化

• 可以实现激励从模块级到系统级的复用

从这些特性来看，Pangu是更广义层次上的TB自动化工具，它的兼容性更强，而且也能够集成公司自身的寄存器创建流程。它解决的问题，同UVM Framework有重合的地方，比如生成一致的验证环境结构、避免结构层面上出现不同的UVM使用习惯、快速集成不同的VIP同时也能够生成对应的文件和makefile，同时它更友好的地方还在于，无论哪家的VIP，在经历一点小的“整容”之后就可以很快地融入到这个结构中来，它还可以集成公司已有的寄存器模型创建的流程（如果没有，也可以在这个框架中实现），更快第完成testbench连线，此外还有一个重要特性，就是在它的机构之上，给出可行的激励跨层次复用（垂直复用）方案。当然，这个工具还有一些要改进的地方，不过这仍然取决于客户实际的使用需求，还是那句话，只要有idea和customer，就没有实现不了的方案。

在接下来的部分，我们就下面几个部分来介绍Pangu的特性：

• 验证环境的自动化创建

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

• 中心化的功能覆盖率管理

验证环境的自动化创建

在进入Pangu创建的框架之前，我们需要来了解下面这些关键词，这对于稍后了解更多关于Pangu这款自动化工具有帮助：

• Pangu：测试平台自动化工具

• uTB（unified testbench）：这是由Pangu自动化生成的测试平台。

• uIF（unified interface）：这是一个协议跨接桥，用来将从uNet网络接收到的一致化命令转化为对应的VIP所识别的sequence/item。

• uTB command：这是一种一致化的命令集，用来创建测试用例，提高可读性和维护性。

• uNet：这是一个AHB的物理传输网络，负责从uTB的master端将uTB command以AHB协议穿过其网络，最终送达uIF接口的输入端。

假设如果要验证一个新的模块，在使用Pangu来自动化创建一个uTB之前，需要从DUT收集这些信息：

• 标准总线的类型、数目、地址范围、位宽等。

• 时钟和复位的数目、频率、同步关系等。

• 非标准总线（自定义总线）的信息。

• 其它零散接口信息。

• 寄存器描述文件、基地址等。

在收集到这些信息之后，将这些信息作为Pangu的uTB结构数据输入，继而自动化生成uTB。下面给出的便是一个生成了uTB框架：

结合之前的uTB中的关键词汇，下面的再给出一些组成uTB框架的核心组件：

• uTB master：用来充当发送uTB command的角色，由它们来扮演控制各个VIP的角色，如果有两个以上的master则可以实现并行控制VIP的要求。

• RGM（register model）：这是由之前给入的寄存器信息生成的寄存器模型。

• uNet（AHB network）：uNet是一个AHB多点传输的物理网络，支持多个master到多个slave的AHB数据传输。在这里，我们复用了Synopsys AMBA验证套件提供的AHB系统总线网络。

• uTB slave：这些个uTB slave扮演了协议转换桥接的角色，一方面它们从uNet接收一致化数据包排列的uTB command，另外一方面它们也需要解析这些包，继而将获取的数据转化为不同VIP所识别的sequence/item。

• VIP：这些VIP可以是任意公司的VIP和自家开发的VIP，它们与其对应的uTB slave相连接。

在完成了验证结构从上到下的数据传输连接之后，就到了各个VIP的interface一级和DUT的连接，这一部分也可以由Pangu在自动化时生成对应的testbench文件和信号连接。对于这样的一个uTB结构，它最重要的部分是uTB master可以集中化地发送uTB command来控制任意一个VIP master agent，另外一部分这离不开协议的转换，即uTB command在uTB master侧发出，继而转化为标准的AHB网络数据抵达uNet slave端，稍后uNet slave端收到AHB数据包之后传递给uTB slave，经过uTB slave的转换变为各个VIP识别的sequence/item，最后从VIP的sequencer到driver，继而在interface一侧驱动到DUT。

要理解uTB结构的重要性，就需要首先理解数据传输中的协议转化。为了总结不同层次的协议转换，我们将其分为四个层面的转化：

• Layer1：从TLM2 socket数据包转为AHB pin。这里的TLM2 socket只是数据包的打包方式，而内在的内容则是uTB command的数据。这种数据必须按照严格的数据格式安排，有它内在的协议要求，通常uTB command需要包含目标uTB slave对应的地址、命令类型、发送数据和其它参数。在uTB master一侧需要将uTB command按照TLM2 socket包格式发送到uNet AHB master一侧，该AHB master接受这种数据格式，并且将其转化为AHB system network上的pin level信号。

• Layer2：AHB pin level信号再次转换为uTB command TLM2 socket数据包，这恰好是Layer1转化的反方向形式。具体是发生在有uNet AHB master发起pin level信号驱动，继而数据按照时序关系依次穿过uNet AHB network之后，抵达目标uNet slave端。抵达之后的数据会被AHB收集整合为TLM2 socket形式。

• Layer3：TLM2 socket uTB command数据格式转化为VIP可识别的sequence/item。这一层转化是重点转化部分，因为用户需要自己去实现从同一格式的uTB command数据内容提取对应的命令符、传输数据和其它参数，继而创建和发送对应的VIP sequence/item，传递到VIP的sequencer和driver端。

• Layer4：VIP sequencer/driver接收到的sequence/item转化为pin level的信号激励。这一层则是由VIP本身实现的。

上面的四层协议转化中，Layer1和Layer2转化完成了uTB command数据从无时序信息的软件对象到AHB pin level的时序转化，或者反向的转化，对于这两层的转化是由中心化维护（Pangu开发者）的，使用者无需关心它们背后的细节。Layer3则是重点，因为它不但提取了uTB command软件对象中的有用信息，而且将其转化为VIP识别的sequence/item。这一层用户可能需要维护，例如一个新的VIP需要加入时，这种转化关系需要提前创建。而对于Layer4则无需关系，它本身在VIP sequencer/driver的实现范围之内。

从上面给出的uTB框架的例子，可以看到它完成了跟testench自动化相关的几个方面：

• 验证框架的自动化生成

• 寄存器模型的创建和集成

• 所需VIP的快速集成

为了使用户能够同上一节UVM Framework给出的示例有一个比较，我们仍然假定有同一款设计：

在给入了一些Pangu所需要的设计信息之后，我们可以将其生成的uTB框架绘制如下：

从图上可以看到，Pangu也可以快速集成各个VIP master或者slave，同时生成空模板的user defined VIP（cpb_in、cpb_out、mem_out）。相比于UVM Framework在结构自动化生成上的优势则是它可以兼容不同源、不同接口标准的VIP，而非M一家的VIP，同时它还可以实现寄存器模型的一体化集成。而在激励复用层面的对比，我们会在后面部分介绍。因此，Pangu在验证结构上的优势即是更开发包容的接口快速搭建和寄存器模型的一体化。针对block_c，Pangu生成的uTB结构可以划分为：

• utb_master。这个结构中有两个master端，用来支持并行发送指令，进而要求两个VIP的master可以并行发送数据。

• uNet。这个网络的AHB master数量和AHB slave数量由utb_master和utb_slave的数量决定，同时verifier需要给出各个utb_slave对应的地址段。

• utb_slave。各个utb_slave需要独立开发，对于标准VIP，Pangu在前期开发中已经实现它们的utb_slave，而对于customized UVC，例如pkt-out agent,则需要用户在后期实现对应的utb_slave，进而将utb command转化为pkt-out agent的sequence/item。

• VIP。无论是商业VIP、自研发VIP还是个别新定义的VIP，都需要将这些VIP的agent集成到uTB中。上面图中既包括master agent，用来接收utb_slave的转化指令，进而在interface对DUT做驱动，也包括slave agent，该组件则用来嵌入到uTB环境中，用来模拟对应的总线从端，一般作为外接的memory使用。

• 顶层的testbench。该模块即是将各个VIP interface同block_c的接口信号进行连接。