让我们再一次了解UVM方法的核心目的——可重用性和可配置性是UVM支持动态和静态组件的两个主要方面。RAL（Register Abstraction Layer）同样是是朝着同一方向的努力。
让我们了解为什么需要UVM RAL，以及它如何帮助支持UVM的核心目标？
要理解这一点，让我们先看看编写UVM寄存器testcase需要什么？
UVM testcase启动了UVM sequence，作为其的一部分，该UVM sequence必须包含有关我们想要访问的寄存器地址（WRITE或READ）和相应数据（在WRITE的情况下）的信息。
在上述UVM sequence片段中，它定义了tx sequence item然后UVM sequence驱动的cmd、addr和data类型。由于我们知道DUT（包含要验证的寄存器的设计）可以在block级别、子系统级别或SoC级别，因此如果要发挥UVM的主要作用，我们应该能够在不同的抽象级别重复使用激励。但正如我们所知，地址在block级别、子系统级别和SoC级别会有所不同。因此，主要问题是——如何在不同的抽象级别重复使用激励（即testcase或UVM sequence），因为不同的地址需要在不同的抽象级别提供？
为了解决这种情况，“register map”是这个谜题中的一个重要元素，它有助于映射特定的寄存器名称，即R0到特定抽象级别的正确预期地址，只需使用寄存器的名称和所需操作，即用它read或write（如下图所示）。
下图显示了RAL实现的机制，其中testcase/sequence只是使用寄存器名称，例如R0用于驱动WRITE或READ事务。寄存器名称被映射到register map中的地址，包含相应寄存器的register block连接到UVM agent，而UVM agent又连接到特定接口以访问DUT内所需的寄存器。
那么，为什么我们需要UVM RAL？？
以下是一些好处——
- trstcase/sequence的可重复使用性。
- register coverage
- 预定义寄存器sequence可用性作为UVM基类的一部分
- DUT寄存器的后门访问
- 为register验证提供标准化的方法
