(11)UVM 寄存器模型的常规方法
mirror、desired和actual value
在应用寄存器模型的时候,除了利用它的寄存器信息,也会利用它来跟踪寄存器的值。寄存器模型中的每一个寄存器,都应该有两个值,一个是镜像值(mirrored value),一个是期望值(desired value)。
期望值是先利用寄存器模型修改软件对象值,而后利用该值更新硬件值;镜像值是表示当前硬件的已知状态值。
镜像值往往由模型预测给出,即在前门访问时通过观察总线或者在后门访问时通过自动预测等方式来给出镜像值。镜像值有可能与硬件实际值(actual value)不一致。例如状态寄存器的镜像值就无法与硬件实际值保持同步更新,另外如果其他访问寄存器的通路修改了寄存器,那么可能由于那一路总线没有被监测,因此寄存器的镜像值也无法得到及时更新。
寄存器模型的预测方式,与上面的三种值相关,这是因为预测行为会直接影响到如何更新镜像值和期望值。
mirrored value与desired value是寄存器模型的属性,而actual value对应着硬件的真实数值。
镜像值有可能与硬件实际值(actual value)不一致。例如状态寄存器的镜像值就无法与硬件实际值保持同步更新,另外如果其他访问寄在器的通路修改了寄存器,那么可能由于那一路总线没有被监测,因此寄存器的镜像值也无法得到及时更新。
预测方式
接下来要理解寄存器模型的预测方式。与上面的三种值相关,这是因为预测行为会直接影响到如何更新镜像值和期望值。需要区别的是,mirrored value与desired value是寄存器模型的属性,而actual value对应着硬件的真实数值。
UVM提供了两种用来跟踪寄存器值的方式,我们将其分为自动预测(auto prediction)
和显式预测(explicit prediction)
。
如果想使用自动预测的方式,还需要调用函数uvm_reg_map::set_auto_predict()。
两种预测方式的显著差别在于,显式预测对寄存器数值预测更为准确,我们可以通过下面对两种模式的分析得出具体原因。
自动预测(auto prediction)
如果没有在环境中集成独立的predictor,而是利用寄存器的操作来自动记录每一次寄存器的读写数值,并在后台自动调用predict()方法的话,这种方式被称之自动预测。
这种方式简单有效,然而需要注意,如果出现了其它一些sequence直接在总线层面上对寄存器进行操作(跳过寄存器级别的write()/read()操作,或者通过其它总线来访问寄存器等这些额外的情况,都无法自动得到寄存器的镜像值和预期值。
显式预测(explicit prediction)
更为可靠的一种方式是在物理总线上通过监视器来捕捉总线事务,并将捕捉到的事务传递给外部例化的predictor,该predictor由UVM参数化类uvm_reg_predictor例化并集成在顶层环境中。
在集成的过程中需要将adapter与map的句柄也一并传递给predictor,同时将monitor采集的事务通过analysis port接入到predictor一侧。
这种集成关系可以使得,monitor一旦捕捉到有效事务,会发送给predictor,再由其利用adapter的桥接方法,实现事务信息转换,并将转化后的寄存器模型有关信息更新到map中
。
默认情况下,系统将采用显式预测的方式,这就要求集成到环境中的总线UVC monitor需要具备捕捉事务的功能和对应的analysis port,以便于同predictor连接。
class mcdf_bus_env extends uvm_env;
mcdf_bus_agent agent;
mcdf_rgm rgm;
reg2mcdf_adapter reg2mcdf;
uvm_reg_predictor#(mcdf_bus_trans)mcdf2reg_predictor;
`uvm_component_utils(mcdf_bus_env)
...
function void build_phase(uvm_phase phase);
agent=mcdf_bus_agent::type_id::create("agent", this);
if(!uvm_config_db#(mcdf_rgm)::get(this,"","rgm", rgm)) begin
`uvm_info("GETRGM","no top-down RGM handle is assigned", UVM_LOW)
rgm=mcdf_rgm::type_id::create("rgm", this);
`uvm_info("NEWRGM","created rgm instance locally", UVM_LOW)
end
rgm.build();
reg2mcdf=reg2mcdf_adapter::type_id::create("reg2mcdf");
mcdf2reg_predictor=uvm_reg_predictor#(mcdf_bus_trans)::type_id::create("mcdf2reg_predcitor", this);
mcdf2reg_predictor.map=rgm.map;
mcdf2reg_predictor.adapter=reg2mcdf;
endfunction
function void connect_phase(uvm_phase phase);
rgm.map.set_sequencer(agent.sequencer,reg2mcdf);
agent.monitor.ap.connect(mcdf2reg_predictor.bus_in);
endfunction
endclass
predictor是一个component,在创建的时候需要指明父类
流向predictor的类型是mcdf_bus_trans,和monitor上analysis port一致
UVM_reg的访问方法
更全面了解uvm_reg_block、uvm_reg、uvm_reg_field三个类提供的用于访问寄存器的方法:
randomize是随机desired value
desired value先更新软件这边的值,之后根据软件这边的值更新硬件的值actual value,随后根据硬件的值来反过来更新软件这边的mirror value
前门没有办法对于field做访问,因为前门都是一个byte在操作
将uvm_reg_sequence提供的方法(均是针对寄存器对象的,而不是寄存器块或者寄存器域)整理如下:
结合着mirrored value、desired value和actual value,理解这四种方法在调用时,三种数值的变化时序关系:
- 对于前门访问的read()和write(),在总线事务完成时,镜像值和期望值才会更新为与总线上相同的值,这种预测方式是显式预测。
- 对于peek()和poke(),以及后门访问模式下的read()和write(),由于不通过总线,默认采取自动预测的方式,因此在零时刻方法调用返回后,镜像值和期望值也相应修改。
reset()和get_reset()
关于reset()和get_reset()的用法,例如硬件在复位触发时,会将内部寄存器值复位,而寄存器模型在捕捉到复位事件时,为了保同硬件行为一致,也应当对其复位。这里注意的是,复位的对象是寄存器模型,而不是硬件。
@(negedge p_sequencer.vif.rstn);
rgm.reset();//register block reset for mirrored value and desired value
rgm.chnl0_ctrl_reg.reset();//register level reset
rgm.chnl0_ctrl_reg.pkt_len.reset();//register field reset
在复位之后,用户也可以通过读取寄存器模型的复位值(与寄存器描述文件一致),与前门访问获取的寄存器复位值进行比较,以此来判断硬件各个寄存器的复位值是否按照寄存器描述去实现。这里的get_reset()方法指的也是寄存器模型的复位值,而不是硬件。
//register model reset value get and check
rstval=rgm.chnl0_ctrl_reg.get_reset();
rgm.chnl0_ctrl_reg.read (status, data, UVM_BACKDOOR, .parent(this));
if(rstval !=data)
`uvm_error("RSTERR","reset value read is not the desired reset value")
set()和update()
下面的方法是运用set()和update()对寄存器做批量修改。
首先set()方法的对象是寄存器模型自身,通过set()可以修改期望值,而在寄存器配置时不妨先对模型随机化,再配置个别寄存器或者域。当寄存器的期望与镜像值不相同时,可以通过update()方法来将不相同的寄存器通过前门访问或者后门访问的方式做全部修改。
这种set()和update()的方式较write()和poke()的写寄存器方式更为灵活的是,它可以实现随机化寄存器配置值(先随机化寄存器模型,后将随机值结合某些域的指定值写入到寄存器),继而模拟更多不可预知的寄存器应用场景,另外update()强大的批量操作寄存器功能使得修改寄存器更为便捷。
//randomize register model, set register/field value and update to hardware actual value
void'(rgm.chnl0_ctrl_reg.randomize());
rgm.chnl0_ctrl_reg.pkt_len.set('h3);
rgm.chnl0_ctrl_reg.update(status, UVM_FRONTDOOR, .parent(this));
void'(rgm.chnl1_ctrl_reg.randomize());
rgm.chnl0_ctrl_reg.set('h22);
rgm.update(status, UVM_FRONTDOOR,. parent(this));
mem与reg的联系和差别
UVM寄存器模型也可以用来对存储建模。uvm_mem类可以用来模拟RW(读写)、RO(只读)和WO(只写)类型的存储,并且可以配置存储模型的数据宽度和地址范围。
uvm_mem不同于uvm_reg的地方在于,考虑到物理存储一旦映射到uvm_mem会带来更大的资源消耗,因此uvm_mem并不支持预测和影子存储(shadow storage)功能,即没有镜像值和期望值。
uvm_mem可以提供的功能就是利用自带的方法去访问硬件存储,相比于直接利用硬件总线UVC进行访问,这么做的好处在于:
- 类似于寄存器模型访问寄存器,利用存储模型访问硬件存储便于维护和复用。
- 在访问过程中,可以利用模型的地址范围来测试硬件的地址范围是否全部覆盖。
- 由于uvm_mem也同时提供前门访问和后门访问,这使得存储测试可以考虑先通过后门访问预先加载存储内容,而后通过前门访问读取存储内容,继而做数据比对,这样做不但节省时间,同时也在测试方式上保持了前后一致性。同时这种方式相比于传统测试方式(利用系统函数或者仿真器实现存储加载),要在UVM框架中更为统一。
与uvm_reg相比,uvm_mem不但有常规的访问方法read()、write()、peek()和poke(),也提供了 burst_read()和burst_write()。之所以额外提供这两种方法,不但是为了可以更高速通过总线BURST方式连续存储,也是为了贴合实际访问存储中的场景。
要实现BURST访问形式,需要考虑下面这些因素:
- 目前挂载的总线UVC是否支持BURST形式访问,例如APB不能支持BURST访问模式。
- 与read()、write()方法相比,burst_read()和burst_write()的参数列表中的一项uvm_reg_data_t value[]采用的是数组形式,不再是单一变量,即表示用户可以传递多个数据。而在后台,这些数据首先需要装载到uvm_reg_item对象中,装载时value数组可以直接写入,另外两个成员需要分别指定为element_kind=UVM_MEM,kind=UVM_BURST_READ。
- 在adapter实规中,也需要考虑到存储模型BURST访问的情形,实现四种访问类型的转换,即UVM_READ、UVM WRITE、UVM_BURST_READ和UVM_BURST_WRITE。
- 对于UVM_READ和UVM_WRITE的桥接,已经在寄在器模型访问中实现,而UVM_BURST_READ和UVM_BURST_WRITE的转换,往往需要考虑写入的数据长度,例如长度是否是4、8、16或者其它。
- 此外还需要考虑不同总线的其它控制参数,例如AHB支持WRAP模式,AXI支持out-of-order模式等,如果想要将更多的总线控制封装在adapter的桥接功能里,需要将更多的配置作为扩展配置,在调用访问方法时作为扩展信息类,传入到形式参数uvm_object extension。
- 对于更为复杂的BURST形式,如果需要实现更多的协议配置要求,那么推荐直接在总线UVC层面去驱动。这样做的灵活性更大,且更能充分全面的测试存储接口的协议层完备性。
内建(built-in)sequences
有一些寄存器即便可以测试,也建议将其作为例外而过滤出去,例如一些重要的系统控制信号(时钟、复位、电源),当写入某些值以后,会使得系统全部或者局部复位、时钟也可能被关闭,这就可能阻碍寄存器的下一步检查。
所以UVM提供了一些特殊域,用来禁止sequence检查这些寄存器或者存储。
寄存器模型内建序列
寄存器健康检查
class mcdf_example_seq extends uvm_reg_sequence;
mcdf_rgm rgm;
`uvm_object_utils(mcdf_example_seq)
`uvm_declare_p_sequencer(mcdf_bus_sequencer)
...
task body();
uvm_status_e status;
uvm_reg_data_t data;
uvm_reg_hw_reset_seq reg_rst_seq=new();
uvm_reg_bit_bash_seq reg_bit_bash_seq=new();
uvm_reg_access_seq reg_acc_seq=new();
if(!uvm_config_db#(mcdf_rgm)::get(null, get_full_name(),"rgm", rgm)) begin
`uvm_error("GETRGM","no top-down RGM handle is assigned")
end
//wait reset asserted and release
@(negedge p_sequencer.vif.rstn);
@(posedge p_sequencer.vif.rstn);
`uvm_info("BLTINSEQ","register reset sequence started", UVM_LON)
reg_rst_seq.model=rgm;
reg_rst_seq.start(m_secquencer);
`uvm_info("BLTINsEQ","register reset secquence finished", UVM_LOW)
`uvm_info("BLTINSEQ","register bit bash sequence started", UVM_LOW)
//reset hardware register and register model
reg_bit_bash_seq.model=rgm;
reg_bit_bash_seq.start(m_secquencer);
`uvm_info("BLTINSEQ","register bit bash secquence finished", UVM_LOW)
`uvm_info("BITINSEQ","register access secquence started", UVM_LOW)
//reset hardware register and register model
reg_acc_seq.model=rgm;
reg_acc_seq.start(m sequencer);
`uvm_info("BLTINSEQ","register access secuence finished", UVM_LOW)
endtask
endclass
rgm从顶层传递下来,然后给每一个模型例化
对于一些寄存器,如果想将其排除在某些内建序列测试范围之外,用户可以额外添加上面列表中提到的“禁止域名”。由于uvm_reg_block和uvm_reg均是uvm_object类而不是uvm_component类,所以可以使用uvm_resource_db来配置“禁止域名”。
下面的代码摘自mcdf_rgm::build()方法,这相当于寄存器模型在自己的建立阶段设定了一些属性。当然,uvm_resource_db的配置也可以在更高层指定,只不过考虑到uvm_resource_db不具备层次化的覆盖属性,我们建议只在一个地方进行“禁止域名”的配置。
class mcdf_rgm extends uvm_reg_block;
...
virtual function build();
...
//disable built-in seq attributes
`uvm_resource_db#(bit)::set({"REG::", this. chnl0_stat_reg. get_full_name()},"NO REG ACCESS TEST",1)
`uvm_resource_db#(bit)::set({"REG::", this. chnl1_stat_reg. get_full_name()},"NO REG ACCESS TEST",1);
`uvm_resource_db#(bit)::set({"REG::", this. chn12_stat_reg. get_full_name()},"NO REG ACCESS TEST",1);
endfunction
endclass
这篇笔记参考《UVM实战》、《芯片验证漫游指南》和某验证视频整理而成,仅作学习心得交流,如果涉及侵权烦请请告知,我将第一时间处理。