本文主要是介绍UVM寄存器模型——手写Ralf问题debug，希望对大家解决编程问题提供一定的参考价值，需要的开发者们随着小编来一起学习吧！
寄存器模型是UVM中至关重要的一部分，如果没有寄存器模型，那么验证平台对于DUT内寄存器的访问方式将十分有限，对DUT运行状态的把控也会变得更为复杂。
在验证过程中，scoreboard或者其他验证组件经常需要了解当前时间某个寄存器的值，以此来调控激励的输入或者进行数据的比对。如果不使用寄存器模型，那只能够通过启动sequence的方式，给DUT的交互端口特定的地址和操作信号，获取寄存器的值。这种方法不仅十分繁琐，而且在某些情况下会提高测试用例的编写难度。
寄存器模型其实就是DUT内各个寄存器的“拷贝文件”，而且它还能够根据DUT的变化，及时更新内部属性值，达到和DUT内部寄存器同步的目的。这就要求寄存器模型有和真实寄存器类似的结构、相同的属性以及一定的访问方法，这样才方便理解和使用。UVM中的寄存器模型分为了三个级别：uvm_reg_field、uvm_reg以及uvm_reg_block，如下图所示。
uvm_reg_field 是寄存器模型中最基本的单位，对应着真实寄存器中的域。
uvm_reg_field 可以拥有不同的比特长度，定义不同的名称和属性；uvm_reg 与 DUT中的寄存器相对应，每个 uvm_reg 至少包含一个 uvm_reg_field；uvm_reg_block 则 属于比较大的单位，其中可以包含多个 uvm_reg，也可以包含多个 uvm_reg_block，block一般可以涵盖模块级 DUT 中的全部寄存器。
每个寄存器模型除了拥有用来表征寄存器的三级结构外，还需要uvm_reg_map
来实现地址上的映射。DUT 中的每个寄存器都会有对应的地址，用来给外部访问 提供依据。同样，在寄存器模型中，验证人员要在 uvm_reg_map 里添加各个 uvm_reg的访问地址，为寄存器模型前门访问提供相关的信息。
为了方便管理，UVM 在寄存器模型中规定了四种属性来描述寄存器信息。也 就是说，对于 DUT 中的每个寄存器，寄存器模型都会使用四个变量从不同的角度 对寄存器的值进行记录。这四种属性分别为 m_reset、m_mirrored、value 以及m_desired。
其中m_reset用来储存寄存器的复位值，m_mirrored用来存储寄存器的镜像值，m_desired 用来存储期望值，这三个变量都属于本地变量，不能够直接从外部进行 访问，需要使用寄存器模型提供的方法，常用的访问方法如下表所示。而 value属性属于 public 类型，可以从外部直接访问，主要用于功能覆盖率或者域的随机 等方面。寄存器属性常用方法如下：
最后，由于寄存器模型中存储数据的格式和在验证平台中使用的格式不一致，所以需要一个adapter模块负责格式转换，使寄存器模型能够和 sequencer 实现数据交互。寄存器模型在验证环境中的应用结构如下图所示。
景芯SoC全流程训练营验证的VIP学员问：自己写的Ralf文件编译OK，为啥仿真有错？
uvm-1.1/reg/uvm_reg.svh(1296) @ 0: reporter [RegModel]
Field DLAB overlaps field RESERVED_8 in register "UART_LCR"
答：景芯训练营要求大家一切从底层撸，搞清楚设计、验证、DFT、后端的底层逻辑，所以Ralf文件我也要求学员自己写。回到VIP学员问题本身，很明显ralf文件写错了，具体错在哪里，欢迎知识星球查看答案！
如下，field DLAB 7是1bit 学员定义为2bit了，导致fIeld RESERVED_8变成了@9，而不是@8。
修改ralf，然后重新生成reg_model，大家参考训练营文档执行即可。
这篇关于UVM寄存器模型——手写Ralf问题debug的文章就介绍到这儿，希望我们推荐的文章对编程师们有所帮助！
