IP的UVM验证环境：agent

从本文开始，我们进入到搭建UVM验证环境的阶段。首先，我们先来看一下要验证的DUT的时序图：

这个DUT的数据流时序图其实很简单，可以概括为以下三点：
1. 本DUT采用的是上升沿采样；
2. 当输入in_en为1时，输入in1、in2；
3. 输出out_en为1时，输出的out有效。
那么根据上述分析，我们可以规划出我们的两个agent（input_agent、output_agent），接下来我们先看一下agent的结构。

这里需要强调的一点，我们在搭建UVM验证环境的时候同功能组件最好只出现一次，这样才能让环境的复用性更好，且更易于操作。如上图所示，agent当中的driver和monitor都需要用到同样的virtual interface，因此我们就可以在agent_config中统一管理，这样只需要将agent_config中的vif以指针的形式配置到driver和monitor当中即可。

下面我们看一下input_agent和output_agent各自的特性：

input_agent作为我们DUT的输入接口，我们需要主动地创建激励发送到DUT的端口上，因此需要有agent里的driver参与；

而output_agent作为DUT的输出接口，它的时序由DUT产生，不需要driver参与，因此agent只需要monitor将DUT的输出按照时序采样下来即可。

在开始编写agent之前我们需要考虑三件事：
1. 有哪些接口
2. 哪些接口需要从transaction发送或采样到transaction中
3. 根据时序图，编写driver和monitor
以input_agent为例：
先从第一点开始分析，首先作为时序逻辑电路结合时序图，时钟和复位是我们agent必不可少的两个端口（clk/rst_n）。其次，输入还有in_en和in1、in2三个信号。因此，我们可以确定下来interface上的端口有clk、rst_n、in_en、in1、in2五个端口。

其中data1/data2/data_en即in1/in2/in_en（接口名可以不相同，最后我们会在顶层将它们连到一起）。
接下来，我们可以根据驱动还是采样做各自的clocking块（不是必须的）。

再看第二点（哪些接口需要从transaction发送或采样到transaction中）
对于这一点，初学者很多会认为in_en/in1/in2都是我们需要采样到transaction中在环境中传递的内容，其实并不然；实际上环境当中传递的是数据和配置，而in_en是告诉DUT什么时候in1/in2是有效的，in_en本身在环境中传递其实是没有意义的。

总的来说，我们的transaction不关心什么时候是写，什么时候是读，什么时候有效，操作有没有出错（这些是driver和monitor处理的），transaction只关心这些操作最后得到的数据有哪些。因此，对当前DUT的输入而言，transaction只关心in1/in2的数据是什么。

再接下来第三点（根据时序图，编写driver和monitor）：
因为这个DUT的数据流的时序非常简单，这里就不展开说了，放个图大家看一下：


这里需要注意的是，我们发送和采样数据接口都需要在复位完成以后。

下面是output_agent的部分关键代码：

以上就是agent相关的全部内容（如何配置virtual interface以及DUT的连接放到介绍TB顶层的时候再做介绍）。

后续内容大家也可以关注我的公众号继续阅读