1.前言

UVM driver在接口协议的实现中起着非常重要的作用，因为它一端处理基于类的事务级sequence，另一端处理基于时钟的信号/引脚级的总线行为。因此，如何实现 UVM driver及其与sequence的同步对于 DUT 和 UVM 环境之间的交互以及避免 UVM driver和sequence之间的任何死锁情况都是至关重要的。

而UVM reg model则提供了强大的前/后门访问寄存器的方式以便于对寄存器进行高效地配置和读取，主要是通过UVM源码中所提供的uvm_reg_map::do_bus_read、uvm_reg_map::do_bus_write方法实现，该方法的实现依赖于sequencer和adapter这2个组件。

其中adpter完全处理基于类的事务级sequence，它能够将uvm_reg_item类和uvm_sequence_item类做相互转译。通过reg2bus方法将寄存器模型能够读懂的uvm_reg_bus_op翻译为总线bus_item事务级sequence，如源码第2009行，调用adapter.reg2bus（rw_access），这一步相当于adapter充当了sequence产生bus_req transaction。

由于环境中指定了寄存器模型使用的sequencer，因此源码中第2014行将bus_req transaction交给该sequencer，随后调用start_item()，finish_item()，从而完成sequencer对sequence的仲裁及传输，确保driver能够井然有序地拿到这些transaction。

环境中打开了auto_predict功能，因此寄存器模型会根据driver返回的读取值，更新寄存器的期望值和镜像值。因此driver中要完成对读写寄存器的反馈逻辑，这一部分通常都是通过driver中的seq_item_port.item_done(bus_req)来完成的，前提是未使用adapter.provides_responses功能，在低速、简单的寄存器操作接口比如I2C、SPI、APB等，这种方式较为常见，因为对寄存器的操作不会涉及到复杂的总线行为，driver只要按顺序调用seq_item_port.get_next_item（bus_req）从sequencer拿到sequence，再将bus_req按照时序驱动到总线上，随后按顺序调用seq_item_port.item_done(bus_req)即可，这样我们是可以直接把返回信息通过req返回的。

但对于复杂的总线协议，例如AHB、AXI等，driver就必须要用put_response（bus_rsp）来返回信息。比如AHB时序中，因为读数据有可能在多拍之后才能从总线上获取，此时master早已经将发送了下一笔transaction，如果采用bus_req来返回信息，那么driver没办法模拟真实的总线行为，不能完成诸如burst类型的传输，此时必须要开启adapter.provides_responses功能。从源码第2024~2030行可以看出，一旦开启该功能，adapter的bus2reg方法会将bus_rsp而非bus_req转译为uvm_reg_bus_op类型，从而使得寄存器模型能够根据读数据正确地更新镜像值和期望值的同时，driver还能模拟真实的AHB总线行为。

本文就是从UVM的源码do_bus_read/do_bus_write出发，采用adapter.provides_responses（）功能，结合rm.default_map.set_auto_predict(1)方法，通过reg_model->adapter->sequencer->driver这样的通路，实现了通过寄存器模型读写，产生AHB时序的pin级接口时序的寄存器操作接口方法。

本文将分为几个部分，分别阐述reg_model，sequence，adapter，driver的具体实现方式。

具体的环境架构如下：