介绍：
寄存器位数的绝数量、它们的访问类型、属性和它们所控制的功能在现代设计中可能是惊人的。尽管内部脚本和寄存器生成器已经商业化了好几年，这些生成器可能能够生成用于RTL和验证的寄存器模型，但大多数都缺少几个关键领域，不能提供100%的功能覆盖。本白皮书讨论了全面和自动化的Register验证的必要性。由Agnisys首创的解决方案，我们将描述的解决方案满足需求，并保证在整个过程中寄存器规范与它们的实现相匹配。
问题：
例如，如果你有一个32位地址总线，你可以访问2^32内存映射寄存器。
如果每个寄存器本身是32位宽，那么总的寄存器位将是(32 * 2^32)或2^37或137,438,953,472。如果地址总线是64位呢?即使没有使用所有的地址，使用的地址位置的数量也在不断增加，因为设计者可能需要在他们的设计中添加越来越多的功能和可重新配置性。因此，IP和SoC的大小是不断增长的，管理与寄存器相关的大数据体的任务也随之增长。
现有的寄存器生成器可能能够接受格式化文本文件(如Word或Excel文档、SystemRDL或IP-XACT XML文件)形式的规范，并为寄存器映射生成RTL和UVM代码，以便在可能的其他输出格式之间进行验证。通常使用Perl/Python脚本来实现这一点。然而，一旦设计验证(DV)工程师得到模型，他们的工作还没有结束，而是刚刚开始。然后DV工程师需要创建完整的验证环境，并将生成的模型集成到其验证环境中。此外，工程师必须创建测试和序列，这不仅基于对寄存器及其属性的访问，而且还取决于设计的功能。
在此之上，特殊类型的寄存器和与许多设计寄存器相关的特殊功能加剧了这项复杂的任务。
下面是一些特殊类型的寄存器的列表:
-
Interruptregisters
-
Counterregisters
-
Shadowregisters
-
Aliased registers
-
RO-WO pair registers atsame address
-
Muxedregisters
-
Wideregisters
-
Triggered Bufferedregisters
-
Modalregisters
-
Multiple bus domainregisters
-
Constrainedregister
Figure 1: Register Example:InterruptRegister
UVM用于寄存器验证的使用非常广泛，因为它提供了无数内建特性，这些特性有助于地址映射中的寄存器验证。然而，尽管UVM是一种有效的方法，但对于新团队来说，设置完整的集成环境通常是一项困难且非常耗时的任务。
而且，如果对规范进行了更改，则意味着对这个由关联文件、环境和测试组成的复杂网络进行更耗时的修改。
形式验证技术为寄存器检查提供了一种替代基于仿真的验证的方法。这种技术的优点是，它提供了寄存器正确性的详尽证明，而且实际上寄存器检查可以更早地进行，甚至在仿真环境准备好和集成之前就可以进行。使用形式验证工具提供的反例可以方便地调试故障。
形式验证有其独特的要求。它需要从规范和SystemVerilog断言中准确地捕获所有寄存器字段的属性，以执行检查。此外，还需要一个顶层文件来将断言与DUT模块绑定在一起——这确保了在断言被绑定时DUT RTL保持不受干扰。
此外，还需要一个单独的脚本来配置和运行正式的工具。
综上所述，寄存器的验证是一个重大的挑战。寄存器是软件与底层电路进行通信的接口。在芯片上完成的每一个配置都是通过在控制寄存器中设置一个或多个位来完成的。处理配置位的顺序和创建测试用例来详尽地测试它们是具有挑战性的。同样，需要高级的SVA知识，才能准确地为每种类型的寄存器字段及其访问策略生成正式检查。设计规范的任何更改都需要更新这些属性和断言。
即使在验证项目中涉及到一个大型的团队，要编写的测试用例的大小和数量可能会非常大，以至于所涉及的时间和金钱可能会变得非常昂贵。如果采用了缩短时间和测试的捷径，就会给项目带来更大的风险。
为什么自动化的寄存器验证?
有人可能会说，如果使用“寄存器生成器”(即使它是通过Perl/Python脚本转换完成的)来创建一个寄存器模型和RTL，那么还需要验证生成的寄存器吗?正如本文的读者可能可以证明的那样，整个验证环境仍然是必需的。这通常是手工完成的。
并不是所有内容都是自动生成的，在生成的RTL和手动创建的RTL之间存在接口点。这些接口点需要验证。例如，手工制作的“外部”寄存器、内存实例或与自动生成的寄存器接口的应用程序逻辑的其余部分。
此外，验证环境应该由软件的中间层（Agents）和应用程序硬件中间层（Agents）组成。而且我们应该注意到，应用程序硬件的中间层不是固定的，它们依赖于设计规范。例如，如果工程师将位字段的硬件访问从只读更改为可读，则需要对硬件的中间层进行更改。
接下来，需要将生成的寄存器模型集成到验证环境中。生成的模型必须有关于寄存器、位域、它们的访问和地址的结构信息。此外，它应该是全面的，还应该是带有illegal bins的cover group和cover point，否则不能有意义地确定测试的质量和完整性。来自软件和硬件应用程序逻辑的事务（Transaction），必须编写测试用例来测试与寄存器相关联的各种特殊功能。
运行所有这些测试会产生大量的仿真数据，因此需要一个动态测试计划。
我们说动态是因为设计规范中的变化需要反映在测试计划中。例如，添加新字段或更改访问可能需要额外的测试。一旦所有测试都运行完毕，这样的测试计划必须自动更新，否则项目将面临错过关键测试的风险，这可能会导致bug进入芯片。
形式验证环境由设计规范中描述的与寄存器访问策略相关的属性、断言和序列组成。将属性和断言与DUT/RTL绑定的顶级模块以及编译和运行正式工具的命令脚本也是环境的一部分。与仿真的情况一样，设计规范中的任何更改都会导致正式验证环境中的一个或多个组件的更改。
传统的解决方案：
从最近对芯片、IP设计人员和验证工程师的调查中可以明显看出，使用UVM创建验证环境的任务需要大量的工作。根据一些客户的说法，这项工作大约占工程师时间的70%。然而，创建这样一个环境的自动化方法在商业上是不可用的。
“从头开始”创建UVM环境需要大量的时间和细致的注意，即使工程师最初是这样做的，每次规范发生变化时都手动维护它也是一种负担。因此，随着半导体设计和IP技术的不断进步，Register验证的自动化已经成为一项关键要求。
SoC的复杂性在不断增加。因此，通过手工方法，相应的地址映射变得无法管理。旧的手工执行验证或仅自动生成验证环境的某些部分/组件的技术不再足够或充分。唯一成功的策略是自动Register验证
如何自动化一个完整的注册验证环境：
好消息是，所有这些都可以在很大程度上实现自动化，这样验证团队就不必花时间开发所需的验证环境、测试和测试计划。自动寄存器验证解决方案的要求是什么?自动寄存器验证解决方案应该包含以下功能:
A .它可以采用MSWord/ MSExcel/ FrameMaker形式的地址映射规范，或者像SystemRDL或IP-XACT或RALF这样的文本标准。
B .根据设计规范，为基于仿真的环境创建以下内容:
1.生成RTL模型(SystemVerilog / SystemC)
2.生成UVM参考模型(SystemVerilog / SystemC)
3.考虑额外的信息，如用于地址映射的寄存器总线、最小可寻址单元、每个寄存器、寄存器组、内存或块的hdl_paths。
4.为注册总线生成Agent。这些Agent必须包括相应的驱动程序和监视器。
5.生成硬件端Agent，包括硬件端驱动程序和监视器。硬件端驱动程序帮助仿真由应用程序逻辑发送到地址映射的事务。硬件监视器用于捕获与使用正确值更新UVM Regmodel相同的事务。
6.生成硬件端预测器，该预测器从硬件监视器获取这些事务，并根据寄存器字段的访问策略预测UVM模型中的正确值。
7.生成一个UVM环境类，其中包含上述所有组件
8.根据每个寄存器的软件访问和额外的特殊行为生成sequences 。
9.生成UVM测试类以运行上述所有sequences 。
10. 生成连接生成的RTL模块和总线接口的顶层模块。
11. 生成一个“Makefile”来运行仿真并从仿真数据库收集结果
12. 生成一个验证计划，能够对这些仿真结果进行反标，以便工程师能够分析结果。
C.对于一个形式验证环境，创建以下内容:
1.生成SystemVerilog属性和断言来检查寄存器访问策略
2.生成顶层文件来绑定DUT RTL以及第三方设计IP与断言。
3.创建一个make-file或TCL命令脚本来运行形式验证的引擎。
下面是一个自动生成的、完整的集成验证环境。
Figure 2:Components of Automatic RegisterVerification
Agnisys解决方案：
自动Register验证(ARV™)工具自动产生UVM的testbench，包括:bus agents, monitors, drivers, adaptors, predictors, sequencers 和sequences，使工程师能够在第一次运行中完成Register验证。
ARV自动生成UVM的sequences ，用于涵盖所有可能的输入场景的高级验证，并生成HTML格式的有效验证报告。该报告由一个Register验证计划组成，该计划显示了Register验证进度的总结报告，以及与Register组件相对应的功能范围和测试状态。报告还显示了所有的Register基本要素，包括相应的度量组，该元素的总体覆盖率以及通过或失败的相关测试细节。
Figure 3: Components of Automatic RegisterVerification
ARV帮助自动验证特殊寄存器，如锁寄存器、间接寄存器、约束寄存器和所有寄存器访问等。ARV覆盖率报告以表格形式显示了所有的内容摘要，指定了Register模型摘要、它们的总体覆盖率和使用的测试数量以及状态。
有了ARV-Sim™功能，工程师只需要做以下工作:
1.创建任何格式的Register规范，如SystemRDL、Word、Excel或IP-XACT。
2.使用自动ARV模块以Register规范作为输入来生成上述所有组件、文件和集成环境。
3.如果来自另一个源的RTL也要验证，则在顶层模块上执行自定义拼接。
4.使用生成的Makefile运行仿真。
5.用自动生成的验证计划分析结果。
使用ARV-Formal™模块，DV工程师只需要做以下工作:
1.创建任何格式的Register规范，如SystemRDL、Word、Excel或IP-XACT。
2.使用ARV-Formal模块自动生成所有属性和断言文件、与DUT的顶层绑定以及运行formal工具的脚本。
3.选择性的包含断言，以检查第三方设计IP块使用的标准总线的协议遵从性
4.使用自动生成的脚本运行形式验证工具。
5.使用形式验证工具提供的反例调试任何失败。详尽地验证所有的寄存器访问策略，节省大量的精力和时间。
结论：
本白皮书展示了手动Register验证的挑战和自动进行Register验证的好处。
我们的使命是授权工程师专注于产品验证和设计，而不是把时间花在可以完全自动化的事情上。从我们的角度来看，SoC团队可以选择开发一个有限的、难以维护的内部工具，或者使用一个得到充分支持的、被国际SoC巨头公司充分验证和利用的全面商业产品。