UVM结构篇之二：把DUT装进TB分几步？（上）

在SV篇章中，四位verifier们需要给MCDF（Multiple Channel Data Formmater）设计搭建验证环境，进而利用这些模块的验证组件在顶层可以完成集成复用。伴随着他们对UVM机制和组件家族的掌握，他们也开始将原有SV验证组件移植到UVM组件中。

如果回顾之前对于MCDF的功能介绍，就可以知道MCDF的主要功能便是将输入端的三个通道的数据，通过数据整形和过滤，最终输出。而再看MCDF的设计结构，可以将它分为四个模块：

梅、尤、娄、董分别运用UVM组件来搭建模块环境，我们分别看一看这些模块验证环境的构成。

寄存器模块的UVM验证环境结构如下：

对于寄存器模块的验证环境reg_env，它的组织包括：

reg_master_agent，提供寄存器接口驱动信号。
reg_slave_agent，提供寄存器接口反馈信号。
scoreboard，分别从reg_master_agent内的monitor和reg_slave_agent内的monitor获取监测数据，并且进行数据比对。

上行数据的通道从端的UVM验证环境结构如下：

对于上行数据的通道从端的验证环境chnl_env，它的组织包括：

chnl_master_agent，提供上行的激励数据。
chnl_slave_agent，提供用来模拟arbiter仲裁信号，并且接收流出数据。
reg_cfg_agent，提供用来模拟寄存器的配置信号，并且接受内置FIFO的余量信号。
scoreboard，分别从chnl_master_agent、chnl_slave_agent和reg_cfg_agent的monitor接受监测数据，并且对channel的流入流出数据进行数据比对。

仲裁器的UVM验证环境结构如下：

对于仲裁器的验证环境arb_env，它的组织包括：

将用来模拟channel输出接口的arbiter_master_agent例化三次，用来对arbiter提供并行的数据输入，同时对arbiter反馈的仲裁信号做出响应。
arbiter_slave_agent，用来接收arbiter的输出数据，模拟formatter的行为，对arbiter的输出信号做出响应。
reg_cfg_agent，提供用来模拟寄存器的配置信号，对三个channel数据源分别做出不同的优先级配置。
scoreboard，从三个arbiter_master_agent、arbiter_slave_agent和reg_cfg_agent中的monitor获取监测数据，对arbiter的仲裁机制做出预测，并且将输入输出数据按照预测的优先级做出比对。

整形器的UVM验证环境结构如下：

对于整形器的验证环境fmt_env，它的组织包括：

fmt_master_agent，用来模拟arbiter的输出数据。
fmt_slave_agent，用来模拟MCDF的下行数据接收端。
reg_cfg_agent，用来模拟寄存器的配置信号，用来指定输出数据包的长度。
scoreboard，从fmt_master_agent、fmt_slave_agent和reg_cfg_agent的monitor获取数据监测数据，通过数据包长度来预测输出的数据包，与formatter输出进行数据比对。