[UVM源代码研究] sequencer与driver之间如何实现通信

[UVM源代码研究] sequencer与driver之间如何实现通信

首先我们看下在uvm_sequencer里是如何实现get_next_item这样一个通信方法的

这里需要注意的是get_next_item_called（sequence_item_requested同理）这样一个变量，也就是说调用get_next_item的时候get_next_item_called一定为0，调用完get_next_item取出数据后get_next_item_called赋值为1。那么什么时候赋值为0的呢？

由此我们知道get_next_item()一定要对应一个item_done()，否则就会报错。有种情况可以在get_next_item()后没有item_done()，那就是主动调用stop_sequences()函数（会清空sequencer上所有的待发送内容以及相关标志位，类似于一个对sequencer的reset操作）

这里对sequence的关闭再做个引申：同一个sequence可能会执行多次的send_request操作，因而m_req_fifo是可能存多个transaction，执行sequencer.stop_sequences()会将当前获得sequencer权限的sequence所有发出的包清空，同时释放sequencer的权限，所以stop_sequences()仅仅针对的是当前正在执行的sequence，类似的方法还可以执行sequence.kill()。

下面再看下get_next_item里的m_select_sequence都做了什么

这实际上就是在做一个sequence的仲裁，等到有sequence被发起，否则阻塞。

然后从m_req_fifo中将REQ取出，get_next_item执行结束。

再来看看这个m_req_fifo里的数据又是从哪来的。

m_req_fifo本质上是一个uvm_tlm_fifo类型，而往该fifo里put数据是在下面的function里进行的。

那这个send_request又是什么时候被调用的呢？看看函数的描述：

所以盲猜是在sequence里通过p_sequencer调用的，类似于在`uvm_send宏里实现，那我们再找找该函数何时被调用

可以看到该函数是在finish_item()中被调用的，也就是sequence把包发给sequencer是在finish_item中完成的，发完之后再阻塞等待item_done，那么start_item里又都干了啥呢？

总结一下，start_item里完成的主要工作就是获取sequencer -> wait_for_grant。

通过以上的源代码分析我们就知道，同一时刻某个sequencer只会被一个sequence所占用，并且发送的包在send_request到item_done之间会暂存在在一个uvm_tlm_fifo中，数据在get_next_item的时候并不会从fifo中pop出来，而是用的peek函数，只有等到item_done的时候才用try_get将fifo对应的数据清除掉了，如下图所示：

同时我们注意到在try_get的时候还做了检查，如果此时数据丢失了则报错，正确的话就会包该数据的id记录下来如果item_done有参数的话还会执行put_response的操作，最后再去做sequencer的解锁操作，允许其他sequence获得grant。

这里还顺遍补充两个知识点：

一、tlm里的知识，就是driver里的seq_item_port和sequencer里的seq_item_export究竟是什么类型的。

正好印证了我们之前在tlm那篇里提到的port/imp一一对应的关系。

二、item_done里调用put_response用的seq_item_export.put_response(item)，这又是怎么传递给对应的sequence的？首先得看下uvm_seq_item_pull_imp这个类的定义

再找到相应的宏定义

最终调用的是this_type里定义的put_response()

即我们的uvm_sequencer里的put_response

我们在基类中找到了put_response的定义

在这里将response跟对应的sequence通过id关联上并将item发给了sequence

通过如上分析，我们便知道sequence -> sequencer -> driver之间的通信时如何进行的。