日志

UVM寄存器篇之一：寄存器模型概览（上）

已有 5658 次阅读| 2018-5-20 13:25 |个人分类:验证系统思想|系统分类:芯片设计

对于硬件有了解的读者，都知道寄存器是模块之间互相交谈的窗口。一方面可以通过读出寄存器的状态，获取硬件当前的状况，另外一方面也可以通过配置寄存器，使得寄存器工作在一定的模式下。而在验证的过程中，寄存器的验证也排在了验证清单的前列，因为只有首先保证寄存器的功能正确，才会使得硬件与硬件之间的交谈是“语义一致”，否则如果寄存器配置的结果与寄存器配置内容不同，那么硬件无法工作在想要的模式下，同时寄存器也可能无法正确反映硬件的状态。

本章我们关于UVM寄存器模型的介绍中，会将之前的设计MCDF中的寄存器模块简化出来，通过硬件的寄存器模型、访问的总线UVC以及寄存器模型之间建立一个小的验证环境，以此贯穿本章的内容：

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

硬件中的各个功能模块都可以由处理器来配置功能以及访问状态，而与处理器的对话即是通过寄存器的读写来实现的。寄存器的硬件实现是通过触发器，而每一个比特位的触发器都相应代表了寄存器功能描述（function specification）表上的一位。一个寄存器一般由32个比特位构成，将单个寄存器拆分之后，又可以分为多个域（field），不同的域往往代表着某一项独立的功能。单个的域可能由多个比特位构成，也可能由单一比特位构成，这取决于该域的功能模式可配置的数目。而不同的域，对于外部的读写而言，又大致可以分为WO（write-only，只写），RO（read-only，只读）和RW（read and write，读写），除过这些常见的操作属性以外，还有一些特殊行为（quirky）的寄存器，例如写后擦除模式（clean-on-read，RC），只写一次模式（write-one-to-set，W1S）。我们在本章中主要讲通用属性的实现和使用，对于quirky属性，读者可以参考UVM cookbook。

MCDF中的寄存器模块描述如下：

地址0x00 通道1控制寄存器 32bits 读写寄存器

bit(0)：通道使能信号。1为打开，0位关闭。复位值为1。

bit(2:1)：优先级。0为最高，3为最低。复位值为3。

bit(5:3)：数据包长度，解码对应表为， 0对应长度4， 1对应长度8，2对应长度16，3对应长度32，其它数值（4-7）均暂时对应长度32。复位值为0。

bit(31:6)：保留位，无法写入。复位值为0。

地址0x04 通道2控制寄存器 32bits 读写寄存器

同通道1控制寄存器描述。

地址0x08 通道3控制寄存器 32bits 读写寄存器

同通道1控制寄存器描述。

地址0x10 通道1状态寄存器 32bits 只读寄存器

bit(7:0)：上行数据从端FIFO的可写余量，同FIFO的数据余量保持同步变化。复位值为FIFO的深度数。

bit(31:8)：保留位，复位值为0。

地址0x14 通道2状态寄存器 32bits 只读寄存器

同通道1状态寄存器描述。

地址0x18 通道3状态寄存器 32bits 只读寄存器

同通道1状态寄存器描述。

如果将它们用寄存器位图来表示，那么地址0x00和0x10的寄存器可以描述如下：

通常来将，一个寄存器有32位宽，寄存器按照地址索引的关系是按字对齐的（word-align），上图中的寄存器有多个域，每个域的属性也可以不相同，reserved域表示的是该域所包含的比特位暂时保留以作日后功能的扩展使用，而目前保留域的读写操作不起任何作为，即无法写入而读出值也是它的复位值。上面的这些寄存器按照地址排列，即可构成寄存器列表，我们称之为寄存器块（register block）。实际上，寄存器块中除了包含寄存器，也可以包含存储器，因为它们的属性都近乎于读写功能，以及表示为同外界通信的接口。我们如果将这些寄存器有机地组合在一起，那么按照上面寄存器的地址描述，MCDF的寄存器功能模块即包含这样一个register block：

在验证MCDF寄存器模块的过程中，我们首先需要理清上面关于寄存器相关的概念，即一个寄存器，可以由多个域构成，而单个域可以包含多个比特位；一个功能模块中的多个寄存器和存储可以组团构成一个寄存器模型（register model）。在上图中读者可以发现除了DUT中的寄存器模块（由硬件实现），还有属于验证环境的寄存器模型。从这两个模块包含的寄存器信息而言，是高度一致的，属于验证环境的寄存器模型也可以抽象出一个层次化的寄存器列表，该列表所包含的地址、域、属性等信息都与硬件一侧的寄存器内容一致。而由软件来建立的寄存器模型对于软件开发和功能验证都有帮助。对于功能验证而言，可以通过将原本的总线级别的寄存器访问方式抽象为由寄存器模型访问的方式，这种方式使得寄存器后期的地址修改（例如基地址更改）或者域的添加都不会对已有的激励构成影响，从而提高已有测试序列的复用程度。同时，寄存器模型在验证过程中还有其它的优势，我们将会在后面的《寄存器模型的常规方法》中重点介绍。

那么，上面提到的软件建立的寄存器模型如何可以保证与硬件实现的寄存器内容属性保持精确一致呢？这离不开一份中心化管理的寄存器描述文件，很多公司目前在使用XML格式的寄存器描述文件，也有的一些公司在使用Excel（CSV）或者DOC等格式来保存寄存器的描述。为什么寄存器描述应该被中心化管理呢？这种管理也被称之为唯一源方式（single-source mode）管理，与之相似的是我们在设计验证流程刚开始的环节中就介绍到设计人员与验证人员都应该与功能描述文档为唯一的功能实现及测试标准。这两者之间相同的地方时都采用了唯一源的管理方式来尽量降低出现实现分歧的可能，只不过与功能描述文档不同的是，寄存器描述文档从根本上有条件可以使用更加结构化的文档描述方式，这也是为什么可以通过XML或者Excel（CSV）等数据结构化的方式来实现寄存器的功能描述。

通过数据结构化的存储方式，寄存器描述文档可以在硬件和软件开发过程中被多次以不同方式来使用：

系统工程师会撰写并维护寄存器描述文件，而后归置到中心化存储路径供其他工程师开发使用。
硬件工程师会利用寄存器描述文件生成寄存器硬件模块（包含各个寄存器的硬件实现和总线访问模块）。
验证工程师会利用寄存器描述文件来生成基于UVM的寄存器模型，以供验证过程中的激励使用、寄存器测试和功能覆盖率收集。
软件工程师会利用该文件生成用于软件开发的寄存器配置的头文件（header file），从而提高软件开发的可维护性。
寄存器描述文件也可以用来生成文档，用可读性更好的方式来方便阅读。

验证工程师需要的基于UVM的寄存器模型，既可以手写，也可以由脚本实现转换。路桑推荐读者找到合适自己的一种自动转换的流程，原因很简单因为手动转换会有潜在的错误，而且寄存器越多出现错误的可能性越大，这样会使得后期调试的难度更大，因为verifier首先需要定位寄存器模型的错误时来自于转换过程还是硬件自身。除此之外，路桑推荐一个寄存器生成器（脚本）的原因还包括：

一个广义的寄存器生成器（register generator），应该依据统一格式的寄存器描述文件，来生成UVM寄存器模型（为验证），或者硬件寄存器模块（被集成到设计中），或者生成头文件（C语言）用来开发软件等。
一个稳定的寄存器不但可以保证从文本信息到寄存器模型的无错误转换，还可以在转换过程中通过语义检查发现寄存器描述文件违规的情况帮助修正寄存器描述文件内容。
如果寄存器描述文件内容有更新，寄存器生成器可以再次生成需要的寄存器相关格式，这对于流程化作业非常方便。
对于验证所需的寄存器模型而言，一个更有效的做法是可以通过封装已有的寄存器生成器，使得可以通过指定多个寄存器和其对应基地址（base address），继而生成一个层次化的top register block，包含多个child register block。通过这种方式可以将更大的子系统或者系统级的寄存器模型归纳在一起，便于系统化的操作管理。

目前现有的EDA厂商都提供各自的寄存器生成器，例如MentorGraphics的Register Assistant、Synopsys VCS工具自带的寄存器模型生成脚本ralgen等。这些商业工具一般都需要一个统一的寄存器描述格式，而目前工业中主要推广的格式当属IP-XACT（IEEE-1685）。

http://www.accellera.org/downloads/standards/ip-xact/

关于IP-XACT，实际上它不单可以用来描述寄存器，任何结构化的内容都可以用它来描述，而这种XML格式的数据内容可以用来开发、实现和验证电子系统。任何与IP-XACT类似的硬件描述结构化的数据方式都是为了便于生成器（generator）来快速构建一个准确的、灵活的硬件和软件开发环境。而在IP-XACT还没有成为IEEE标准之前，大公司和小公司都有各自数据格式化的方法，也许他们采用了基于XML而不同于IP-XACT规范的数据格式、也许采用了Excel(CSV)、DOC或者其它方式，那么对于目前行业中依然没有采用IP-XACT规范的开发流程，路桑给出几点建议来帮助接下里实现脚本自动化生成UVM寄存器模型的方法：