MCDF顶层验证环境方案一

如果参照SV篇章的MCDF顶层环境集成方式，也可以将上述的各个模块的UVM环境作为子环境集成复用到顶层。那么，顶层验证环境的结构图大致如下：

从这个图可以看到，MCDF的顶层验证环境分别复用了模块验证环境的如下组件：

• reg_master_agent

• chnl_master_agent

• fmt_slave_agent

通过这三个激励组件可以有效生成新的激励序列。在将各个agent中的sequencer句柄合并在一处时，virtual sequencer的作用就体现出来了。可以通过这个中心化的序列分发管道重心，将各个agent的sequence也集中管理。而MCDF的scoreboard提供了一个完成的数据通路覆盖方案，是从各个agent中的monitor数据监测端口将数据收集起来，同时建立MCDF的参考模型，预测输出数据包，最终进行数据比对。

这个顶层环境的集成例码可以参考下面的部分：

MCDF顶层验证环境方案二

上面的方案中最大的额外人力在于需要新建一个scoreboard用来检查MCDF的整体功能。如果顶层的设计不那么复杂，像本文中的MCDF一样，重新实现一个顶层的scoreboard复杂度还是可控的；但是如果将来的顶层环境更加复杂，那么复用底层的scoreboard就变得省时省力了。因此，方案二的根本目的在于复用底层模块环境的scoreboard，减少顶层环境的额外成本。下面是方案二的结构框图：

从这个环境可以看出，不同于方案一的有下列几个地方：

• 集成与顶层环境的组件都是原先各个模块的验证环境。

• 顶层环境在集成子模块验证环境时，需要将各个子模块中的agent配置为不同的模式（active或者passive），来适应顶层的场景。

• 不再需要实现新的scoreboard，而是可以复用原有各个子环境的scoreboard。

方案一与方案二相同的地方在于，顶层都需要新建virtual sequencer和virtual sequence，用来生成顶层的测试序列。而virtual sequence也不是从无创建的，它本身是利用原有子模块环境的序列库，进行有机的组合，最后协调生成了新的测试序列。关于virtual sequence与virtual sequencer，我们将会在后面的《UVM序列篇》中详细讲解。

下面的例码是方案二顶层环境的集成实现：

从方案二可以看出，mcdf_env的子组件不再是uvm_agent，而是各个模块的验证环境uvm_env类型。通过直接继承这些子环境，也间接复用了它们内部的scoreboard。而在connect阶段，需要将各个子环境中不需要再做激励的agent，配置为passive模式，而默认情况下这些agent的均为active模式。也正因为这种复用方式，无需再新建一个MCDF的scoreboard，只需要确保MCDF的各个子模块均有验证组件会检查它们的功能，而且从整体上可以覆盖完整的数据通路。

读者可以从上面的图例和代码中观察到，UVM对于环境复用，相比于之前SV的验证环境做到了下面的几个优势：

• 各个模块的验证环境是独立封装的，对外不需要保留数据端口，因此便于环境的进一步集成复用。

• 由于UVM自身的phase机制，在顶层协调各个子环境时，无需考虑由于子环境之间的例化顺序导致的对象引用时句柄悬空的问题。

• 由于子环境的测试序列也是相对独立的，这使得顶层在复用子环境测试序列而构成virtual sequence时，不需要其它额外的迁移成本。

• UVM提供的config_db配置方式，使得整体环境的结构和运行模式都可以从树状的config对象中获取，这也使得顶层环境可以在不同的uvm_test中进行集中管理配置。

下一节路桑将带领读者，从一个抽象的角度来考虑构建一个验证环境的层次中，有哪些核心要素需要考虑。通过这种化繁为简的方式，希望读者可以参出一些验证平台的内经心

法。

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