作者：JK ZHAN，本文首发于微信公众号“芯片学堂”（ID：HelloICTalking），芯片技术文章分享平台。

寄存器（register）是数字系统中非常重要的部件，它常被用于数字系统的功能控制（control）和状态（status）显示。

RAL（Register Abstract Layer，寄存器抽象层），通常也叫寄存器模型，顾名思义就是对寄存器这个部件的建模。本文要介绍的内容，包括对UVM寄存器模型的概述，如何构建寄存器模型，以及如何将寄存器模型集成到验证环境中。篇幅原因，将在下一篇文章再给出寄存器模型的操作图鉴(前后门访问API)，以及寄存器覆盖率的收集。

01 寄存器模型概述

为什么要对寄存器建模，可能是初学者问得较多的问题。简单地说，寄存器建模要做的事情，就是在软件的世界里面，复刻RTL中的寄存器。既然是面向软件世界做的事情，自然就是为软件所用，要么方便软件观测，要么方便软件使用。

这里的软件，指的是整个验证环境所构造出来的面向对象的世界。有了寄存器模型，软件世界中的参考模型（reference model）可以很方便的获取到当前RTL的功能配置和状态，我们也可以很方便的收集到对寄存器各个域段甚至位的测试覆盖情况等等。

要达成这一目标，就需要考虑两个基本的问题：如何对寄存器进行建模，以及建立怎样的机制才可以让寄存器模型是“实时”复刻RTL寄存器的（上图中的虚线箭头）。这也是本文后面两个小节要介绍的内容。

02 构造寄存器模型

寄存器模型的框架实际上跟RTL中的寄存器组没有什么两样。寄存器组中有的，寄存器模型也应该要有，顶多是多了一些抽象。基于这个想法，构造寄存器模型的工作，便可以从硬件寄存器组的设计，一一映射为对应的数据结构。

寄存器最小的功能单元是域段（field）。一个寄存器要切分成多少个域段、每个域段的位宽、默认值、读写属性以及分别用于什么功能的控制或状态的指示，是根据功能规范来定义的。对域段的建模，UVM类库提供的类型叫uvm_reg_field。

寄存器是可作为单个实体被访问的多个域段的集合，它可以被映射到一个或者多个地址上（memory-mapped）被访问。对寄存器的建模，UVM提供的类型叫uvm_reg。为了提供后门访问（backdoor access），uvm_reg还增加了成员来表示其对应的硬件寄存器在RTL中的层次路径。

寄存器访问译码表，或者叫memory map，是寄存器接口从访问地址到使能对应寄存器所需要的查找表。这张表中指定了每个寄存器的偏移地址（offset）、访问属性、大小端、对应的总线等配置。对memory map的建模，UVM提供的类型叫uvm_reg_map。

多个寄存器及其访问译码表最终构成寄存器组。在同个数字系统的不同总线视角下，寄存器组可以映射到不同的基地址（base）。因此，一个寄存器组除了可以包含多个寄存器，还可以有多个译码表。UVM针对寄存器组的建模提供的类型叫uvm_reg_block。为了便于集中管理，uvm_reg_block还可以包含其他子uvm_reg_block。

在同一类族中，UVM还提供了uvm_mem类，用于对连续地址存储空间的建模。uvm_mem对象也可以被集成到uvm_reg_block中，并通过uvm_reg_map做地址映射，

此外，UVM还提供了uvm_reg_file类。这个类更像是一个对象容器，可以用来装载多个寄存器（uvm_reg）和其他uvm_reg_file，以便对相同规格的寄存器进行多次例化。

03 集成到验证环境

如果只是简单把寄存器模型集成到验证环境，那么只要例化寄存器模型就可以了。现在主要的问题是，建立怎样的机制才可以让寄存器模型“实时”复刻RTL寄存器的值。为了解决这个问题，UVM引入Prediction机制，用到了两个新的组件：Adapter和Predictor。

Adapter，可以翻译为适配器，它的作用是寄存器访问事务和总线事务的相互转换。寄存器访问事务对数据的封装格式相对固定，一般包含读写类型、地址、数据和字节掩码。而总线事务则根据不同的总线协议会有所不同。因此，Adapter扮演了中间做事务转换的角色，其主要实现的函数为reg2bus和bus2reg。

Predictor，是保持寄存器模型“实时”复刻RTL寄存器值的关键组件。Predictor翻译过来叫预测器，可能反而不是很好理解，对其功能比较好的描述我觉得应该是“monitor and update the RAL Model”。根据是否使用外部predictor，有两种应用方式：Implicit Prediction和Explicit Prediction。

隐式预测（Implicit Prediction）：用户使用寄存器模型中memory map默认的predictor，当开启其预测功能之后，如果用户在测试用例中通过寄存器模型的API（下篇文章会介绍都有哪些API）去发起硬件寄存器访问操作，该操作会自动被predictor捕捉，并在该操作完成之后自动同步到寄存器模型的寄存器中。下图为了方便展示，将原本同属于寄存器模型中的memory map、registers和adapter分开画了。

显式预测（Explicit Prediction）：用户基于UVM提供的基类uvm_reg_predictor实现preditor，并将monitor的总线事务传递给该predictor，同时将其关联到寄存器模型的memory map和对应总线事务的adapter适配器。工作逻辑是这样的：该predictor相当于可以根据memory map监测总线上的寄存器访问行为，并将该行为通过adapter转换成寄存器事务，最终用于更新寄存器模型。

Explicit Prediction相对于Implicit Prediction，除了监视通过寄存器模型API对寄存器的访问操作，还可以覆盖到其他测试序列（sequence）通过总线对寄存器的直接访问，这一点会使它更加通用。

相应的代码示例，也将在下一篇UVM系列文章中提供，欢迎关注。

参考资料

[1] Accellera Systems Initiative. "Universal Verification Methodology (UVM) 1.2 Class Reference" (2014).

[2] Accellera Systems Initiative. "Universal Verification Methodology (UVM) 1.2 User's Guide" (2015).

作者：JKZHAN
文章来源：芯片学堂

推荐阅读

• SystemVerilog | UVM | Sequence的仲裁和锁定，还有要避开UVM的bug
• SystemVerilog | UVM | Driver-Sequencer是这样握手的
• SystemVerilog | UVM | 事务级激励Sequence item这样构建才实用

更多IC设计技术干货请关注IC设计技术专栏。
迎添加极术小姐姐微信（id:aijishu20)加入技术交流群，请备注研究方向。