在reg_mod发起操作,便会产生uvm_reg_bus_op变量,同时调用reg2bus,在adapter中完成映射,将uvm_reg_bus_op映射为bus_transaction,而bus_transaction会经由bus_sqr+bus_drv发送至dut_reg(注意:这里的transaction是后台发生的,不需要自己调用),实现对dut_reg的配置.

3.无论是读还是写都需要发起bus2reg么?

是的

读的时候自然需要,一旦adapter从bus_sqr获得bus_transaction便会调用bus2reg完成转换,得到uvm_reg_bus_op返回reg_mod

写的时候,也需要完成事务之后的反馈

3.adapter的集成

1.关于reg_mod的例化位置

正常情况下,会将reg_mod/adapter/env/v_sqr一同例化在base_test中,并且将reg_mod在v_sqr中声明,env调用reg_mod时便通过句柄调用(记得在base_test中,给句柄赋值).

2.adapter的集成发生在哪里

而reg_mod/adapter/bus_sqr的连接也就是adapter的集成也在base_test中发生(bus_agent例化在env中),核心就是找到三者,可以通过层层路径,eg:rm.default_map.set_sequencer(env.bus_agt.sqr, reg_sqr_adapter),下图帮助理解set_sequencer这个函数

通过reg_mod的map调用,在创建reg_mod的时候回用map.add_reg将reg_mod加入map中,reg_mod的绝对地址可以通过map获得,因此adapter通过map可以连接到reg_mod,同时在这个函数中也就连接了adapter和bus_sequencer.

3.reg_mod.map.set_auto_predict()是什么意思?

这里会引入预测这个概念,要从本质上理解reg_mod的作用,reg_mod会随时和保持一致dut_reg保持一致,尤其是对dut_reg配置之后(drv通过总线发到dut,mon就会捕捉到),以便ref_mod依据reg_mod的信息进行更新,然后对ref_mod和dut的输出进行对比比较,而从总线上读回配置信息更新reg_mod,这便是预测.

这个过程起重要作用的是predictor,没有predictor时就会使用set_auto_predict()实现自动更新reg_mod,但是这个过程对用户是个黑盒子,不知道是否更新了reg_mod,后续引入predictor,使预测这个过程更加完善.

4.访问方式

1.前门访问和后门访问

区别:

1.是否通过总线,是否消耗时间

2.怎么做预测?

3.读写对象是谁?

4.是否可以验证总线?

2.前门访问

1.两种方式

uvm_reg::read()/write和uvm_reg_sequence::read_reg()/write()

3.后门访问

1.在reg_mod创建时,要完成路径映射

2.在访问方式上除了前门访问也有的uvm_reg::read()/write和uvm_reg_sequence::read_reg()/write()(注意使用使表明是UVM_BACKDOOR),增加了uvm_reg::peek()/poke()(只有后门访问才有)

4.前门后门混合应用

1.先通过前门对reg_dut进行配置,然后通过后门对reg_dut进行访问,两者进行对比,验证地址是否匹配

2.前门后门都存在时间延迟,无法实时反映dut_reg的情况

原文链接：https://blog.csdn.net/weixin_41212895/article/details/120854856