（11）UVM 寄存器模型概览

概述

寄存器是模块之间互相交谈的窗口，一方面可以通过读出寄存器的状态，获取硬件当前的状况，另外一方面也可以通过配置寄存器，使得寄存器工作在一定的模式下。

在验证的过程中，寄存器的验证排在了验证清单的前列，只有首先保证寄存器的功能正确，才会使得硬件与硬件之间的交谈是“语义一致”的。

如果寄存器配置结果与寄存器配置内容不同，那么硬件无法工作在想要的模式下，同时寄存器也可能无法正确反映硬件的状态。

关于UVM寄存器模型的介绍中，会将MCDF寄存器模块简化，通过硬件的寄存器模型和总线UVC建立一个小的验证环境：

• 寄存器有关的设计流程。
• 寄存器模型的相关类。
• 如何将寄存器模型集成到现有环境，与总线UVC桥接，与DUT模型绑定。
• 寄存器模型的常用方法和预定义的sequence。
• 寄存器测试和功能覆盖率的实际用例。

UVM寄存器

硬件中的各个功能模块可以由处理器来配置功能以及访问状态，而与处理器的对话即是通过寄存器的读写来实现的。寄存器的硬件实现是通过触发器，而每一个比特位的触发器都对应着寄存器的功能描述（function specification）。

一个寄存器一般由32个比特位构成，将单个寄存器拆分之后，又可以分为多个域（field），不同的域往往代表着某一项独立的功能。单个的域可能由多个比特位构成，也可能由单一比特位构成，这取决于该域的功能模式可配置的数量。
而不同的域，对于外部的读写而言，又大致可以分为WO（write-only，只写），RO（read-only，只读）和RW（read and write，读写），除过这些常见的操作属性以外，还有一些特殊行为（quirky）的寄存器，例如读后擦除模式（clean-on-read，RC），只写一次模式（write-one-to-set，W1S）。

MCDF的寄存器模块描述，将0×00功能寄存器和0×10状态寄存器位用图来表示。
通常来讲，一个寄存器有32位宽，寄存器按照地址索引的关系是按字对齐的（word-align），上图中的寄存器有多个域，每个域的属性也可以不相同，reserved域表示的是该域所包含的比特位暂时保留以作日后功能的扩展使用，而对保留域的读写不起任何作用，即无法写入而且读出值也是它的复位值。

寄存器块（register block）:将寄存器按照地址排列，即可构成寄存器列表。寄存器块除了包含寄存器，也可以包含存储器，因为它们的属性都近乎于读写功能，以及表示为同外界通信的接口。

寄存器块

右边是真实硬件实现，左边是软件模型
硬件里面所有的寄存器都要从软件里面构建起来；所有硬件信息都在map里面要构建起来；
利用软件的寄存器模型，可以做驱动

1、一个寄存器以由多个域构成，而单个域可以包含多个比特位；一个功能模中的多个寄存器可以组团构成一个寄存器模型（register model）。示图中除子包含DUT的寄存器模块（由硬件实现），还有属于验证环境的寄存器模型。
2、这两个模块包含的寄存器信息是高度一致的，属于验证环境的寄存器模型也可以抽象出一个层次化的寄存器列表，该列表所包含的地址、域、属性等信息都与硬件一侧的寄存器内容一致。
3、对于功能验证而言，可以将总线访问寄存器的方式抽象为寄存器模型访问的方式，这种方式使得寄存器后期的地址修改（例如基地址更改）或者域的添加都不会对已有的激励构成影响，从而提高已有测试序列的复用性。

中心化管理方式

1、一份中心化管理的寄存器描述文件用来保证通过软件建立寄存器模型的方法与硬件寄存器的内容属性保持一致。
2、通过将寄存器描述中心化管理呢，使采用单一源的管理方式可以尽量降低出现分歧和错误的可能。
3、寄存器描述文档使用了结构化的文档描述方式。

推荐使用寄存器自动生成器的原因：
1、因为手动转换会有潜在的错误，而且寄存器越多出现错误的可能性越大，这样会使得后期调试的难度更大。
2、一个广义的寄存器生成器（register generator），应该依据统一格式的寄存器描述文件，来生成UVM寄存器模型（为验证），或者硬件寄存器模块（被集成到设计中）。
3、一个稳定的寄存器不但可以保证从文本信息到寄存器模型的无错误转换，还可以在转换过程中通过语义检查发现寄存器描述文件违规的情况帮助修正寄存器描述文件内容。
4、如果寄存器描述文件内容有更新，寄存器生成器可以再次生成需要的相关文件格式，这对于流程化作业非常方便。
5、对于验证所需的寄存器模型而言，一个更有效的做法是可以通过封装已有的寄存器生成器，使得可以通过指定多个寄存器模块和其对应基地址，继而生成一个层次化的寄存器模型，从而将系统级的寄存器模型归纳在一起，便于操作管理。

UVM_reg相关概念

在构建UVM寄存器模型的过程中，需要了解与模型构建相关的类和它们的功能：

class ctrl_reg extends uvm_reg; 
	`uvm_object_utils(ctrl_reg)
	uvm_reg_field reserved; 
	rand uvm_reg_field pkt_len; 
	rand uvm_reg_field prio_level; 
	rand uvm_reg_field chnl_en; 
	function new(string name="ctrl_reg"); 
		super.new(name,32, UVM_NO_COVERAGE); 
	endfunction 
	virtual function build(); 
		reserved=uvm_reg_field::type_id::create("reserved"); 
		pkt_len=uvm_reg_field::type_id::create("pkt_len"); 
		prio_level=uvm_reg_field::type_id::create("prio_level"); 
		chnl_en=uvm_reg_field::type_id::create("chnl_en"); 
		reserved.configure(this,26,6,"RO",0,26'h0,1,0,0); 
		pkt_len.configure(this,3,3,"RW",0,3'h0,1,1,0); 
		prio_level.configure(this,2,1,"RW",0,2'h3,1,1,0); 
		chnl_en.configure(this,1,0,"RW",0,1'h0,1,1,0); 
	endfunction 
endclass
class stat_reg extends uvm_reg; 
	`uvm_object_utils(stat_reg)
	uvm_reg_field reserved; 
	rand uvm_reg_field fifo_avail; 
	function new(string name="stat_reg"); 
		super.new(name,32, UVM_NO_COVERAGE); 
	endfunction 
	virtual function build(); 
		reserved=uvm_reg_field::type_id::create("reserved"); 
		fifo_avail=uvm_reg_field::type_id::create("fifo avail"); 
		reserved.configure(this,24,8,"RO",0,24'h0,1,0,0); 
		fifo_avail.configure(this,8,0,"RO",0,8'h0,1,1,0); 
	endfunction 
endclass
class mcdf_rgm extends uvm_reg_block; 
	`uvm_object_utils(mcdf_rgm)
	rand ctrl_reg chnl0_ctrl_reg; 
	rand ctrl_reg chnl1_ctrl_reg;
	rand ctrl_reg chnl2_ctrl_reg; 
	rand stat_reg chnl0_stat_reg; 
	rand stat_reg chnl1_stat_reg; 
	rand stat_reg chnl2_stat_reg; 
	uvm_reg_map map; 
	function new(string name="mcdf_rgm"); 
		super.new(name, UVM_NO_COVERAGE); 
	endfunction
	virtual function build(); 
		chnl0_ctrl_reg=ctrl_reg::type_id::create("chnl0_ctrl_reg"); 
		chnl0_ctrl_reg.configure(this); 
		chnl0_ctrl_reg.build(); 
		chnl1_ctrl_reg=ctrl_reg::type_id::create("chnl1_ctrl_reg"); 
		chnl1_ctrl_reg.configure(this); 
		chnl1_ctrl_reg.build(); 
		chnl2_ctrl_reg=ctrl_reg::type_id::create("chnl2_ctrl_reg"); 
		chnl2_ctrl_reg.configure(this); 
		chnl2_ctrl_reg.build(); 
		chnl0_stat_reg=stat_reg::type_id::create("chnl0_stat_reg"); 
		chnl0_stat_reg.configure(this); 
		chnl0_stat_reg.build(); 
		chnl1_stat_reg=stat_reg::type_id::create("chnl1_stat_reg"); 
		chnl1_stat_reg.configure(this); 
		chnl1_stat_reg.build(); 
		chnl2_stat_reg=stat_reg::type_id::create("chnl2_stat_reg"); 
		chnl2_stat_reg._configure(this); 
		chnl2_stat_reg.build();
		//map name, offset, number of bytes, endianess 
		map=create_map("map",'h0,4, UVM_LITTLE_ENDIAN); 
		map.add_reg(chnl0_ctrl_reg,32'h00000000,"RW"); 
		map.add_reg(chnl1_ctrl_reg,32'h00000004,"RW"); 
		map.add_reg(chnl2_ctrl_reg,32'h00000008,"RW"); 
		map.add_reg(chnl0_stat_reg,32'h00000010,"RO"); 
		map.add_reg(chnl1_stat_reg,32'h00000014,"RO"); 
		map.add_reg(chnl2_stat_reg,32'h00000018,"RO"); 
		lock_model(); 
	endfunction 
endclass: mcdf_rgm

整理出关于寄存器建模的基本要点和顺序如下：

• 在定义单个寄存器时，需要将寄存器的各个域整理出来，在创建之后还应当通过uvm_reg_field::configure（）函数来进一步配置各自属性。
• 在定义uvm_reg_block时，需要注意reg_block与uvm_mem、uvm_reg以及uvm_reg_map的包含关系。首先uvm_reg和uvm_mem分别对应着硬件中独立的寄存器或者存储，而一个uvm_reg_block可以用来模拟一个功能模块的寄存器模型，其中可以容纳多个uvm_reg和uvm_mem实例；其次map的用来表示寄存器和存储对应的偏移地址，同时由于一个reg_block可以包含多个map，各个map可以分别对应不同总线或者不同地址段。在reg_block中创建了各个uvm_reg之后，需要调用uvm_reg::configure（）去配置各个uvm_reg实例的属性。
  ·考虑到uvm_reg_map也会在uvm_reg_block中例化，在例化之后需要通过uvm_reg_map::add_reg（）函数来添加各个uvm_reg对应的偏移地址和访问属性等。只有规定了这些属性，才可以在稍后的前门访问（frontdoor）中给出正确的地址。
  ·uvm_reg_block可以对更大的系统做寄存器建模，这意味着uvm_reg_block之间也可以存在层次关系，上层uvm_reg_block的uvm_reg_map可以添加子一级uvm_reg_block的uvm_reg_map，用来构建更全局的“版图”，继而通过uvm_reg_block与uvm_reg_map之间的层次关系来构建更系统的寄存器模型。

UVM_reg使用流程

寄存器模型从一开始的寄存器描述文档到最后的功能检查，都需要贯穿寄存器模型的生命周期。

对于验证过程中的不同角色，他们会参与上述的部分流程：

• 系统工程师需要提供寄存器描述文件。
• 模块验证人员需要生成寄存器模型。
• VIP开发人员需要提供总线适配器。
• TB构建人员（与模块验证人员有时候不是同一个人）需要集成寄存器模型。
• 模块验证人员还需要完成后续的寄存器模型检查和功能覆盖率收集。

这篇笔记参考《UVM实战》、《芯片验证漫游指南》和某验证视频整理而成，仅作学习心得交流，如果涉及侵权烦请请告知，我将第一时间处理。