简化UVM寄存器模型的使用教程
当我开始使用uvm ral时，我无法理解uvm基类库对更新desired和mirror 寄存器的解释。觉得使用的术语并不能准确地反映里面的真实的意思。花了一些时间后，我想出了一个表格，它可以帮助我理解寄存器模型api 的行为，以及如何最好地调用它们。
在介绍表格之前，我们先来看看寄存器模型的创建过程：
创建寄存器格式规范将规范转换为 uvm 寄存器模型使用寄存器模型创建寄存器格式规范：有许多寄存器格式可用于描述dut的寄存器规范。您可能熟悉广泛使用的 synopsys ralf 格式。下图说明了使用 synopsys ralgen 工具将 ralf 格式转换为寄存器模型的流程。虚线表示您可以为不同的方法生成寄存器模型：
使用寄存器模型：寄存器模型具有一组用于desired和mirror寄存器值的变量。uvm文档使用了术语desired 和mirror， 但我在下面将它们称为main和mirror以避免混淆。mirror变量的目的是始终保持或表示rtl的值，以便它可以用作scoreboard。有很多 api 可对这些变量进行操作。此处的目的是阐明在仿真期间调用这些api时main变量和mirror变量会发生什么。
让我们看一下可用的 api。我将它们分为三组：active、passive和indirect。
active： 在总线上通过物理事务做读写操作。read()、write()、update() 和 mirror() 是active api，它们使用物理接口在 dut 上运行。您可以选择使用后门机制，在这种情况下它不会消耗仿真周期。与使用前门访问相同的rtl寄存器行为一致。
passive：仅使用寄存器模型操作。set()、get() 和 predict() 是直接在模型上操作的passive api。调用passive peek() 不会在读取过程中改变寄存器值。例如，读取以清除寄存器——执行 peek() 时寄存器不会被清除。
indirect： 有一组 api 可以间接在 dut 上运行，它们是 peek() 和 poke()。请注意 peek() 和 poke() api 只是后门访问。尽管 poke 可以更新 rtl 寄存器，但它不能模拟物理读取期间可能发生的实际寄存器行为。例如，写1来清除寄存器。
让我们简要介绍一下广泛使用的 api 定义。您可以在 uvm 类参考指南中找到更多详细信息。
read()：使用前门或后门访问从 dut 寄存器中读取值。
write()：使用前门或后门访问更新 dut 寄存器。
update()： 如果您使用 set() 更改了主寄存器变量中的任何值，则可以使用这种方法（批量更新）将所有这些寄存器写入 dut。您可以调用单独的 write() 方法来实现相同的结果。
mirror()： mirror 维护dut寄存器值的副本。mirror() 方法读取寄存器，如果启用检查，则可选择将回读值与当前镜像值进行比较。 可以使用物理接口（前门）或 peek()（后门）机制执行镜像。
peek()： 使用后门访问机制从dut寄存器中读取值。
poke()：使用后门访问机制将指定值写入dut寄存器。
predict()：您可以使用此方法将镜像变量值更改为期望值。
我进行了一些实验，下表显示了当从testbench执行任何这些 api 时，寄存器模型和 dut 中发生的情况。
缩写
umv – 更新主变量，umrv – 更新镜像变量，ap – auto predict
rdr – 读取dut寄存器，udr – 更新dut寄存器，rmv – 读取main变量
fd – 前门，bd – 后门，* – 检查是否使用了 uvm_chek， na – 不适用
要记住的几点
没想到 peek() 和 poke() 方法会无条件更新镜像值。查看uvm源码后，发现在peek()和poke()方法内部无条件调用do_preedit()方法。我还注意到使用后门机制的 write() 和 read() 方法会在调用 do_predict() 时更新镜像寄存器，而无需检查此 get_auto_predict() 方法的输出。我看到这个有条件调用的唯一地方是具有前门访问的 write() 和 read() 方法。
在与专家讨论后，了解到这样设计是有意的，是为了确保镜像变量中具有最新的寄存器值。类似地，使用后门访问的 read()/write() 也会更新镜像寄存器——这也是有意的。因为使用了后门，所以不会在物理接口上观察到（当auto predict关闭时）更新寄存器模型的事务。因此，它必须在所有情况下进行更新。
作者：vidyashankar ramaswamy
来源：
https://blogs.synopsys.com/vip-central/2015/01/06/using-uvm-register-model/
arm架构和x86架构区别 linux是x86还是arm
国产手机设计与小米mix比肩，也只有荣耀magic了
中国电信已顺利完成了Cat 1模组的测试入库
Nexperia(安世半导体)：如何选择符合应用散热要求的半导体封装
5G行业跃迁，4G智能手机还有消费市场吗？
简化UVM寄存器模型的使用教程
关于一些显示电缆连接器的使用指南
AI/机器学习项目构建“终极指南”如何正确的开展ML/AI系统
简述磁性材料密度测试教程
RISC-V给异构计算带来新活力
FreeRTOS在英飞凌TriCore TC33x系列上的移植和使用
如何修改Linux系统的SSH端口
Pintech品致诚邀您参加2022年9月3日在上海举办的亚洲电源、电机、电动车技术创新发展论坛
别样风格， 荣耀V9开箱图赏
麒麟与中国芯磨合顺利 全国产化电脑亮相
面向医疗系统的DC/DC 转换器应用方案
中国半导体设备业的市场规模与发展状况
高通骁龙865为什么没有采用7nm EUV
5＋X组合,轻松承载数据中心多样化应用
红外感应调光ic方案升级版SM2083替换亚成微RM9010分析
在介绍表格之前，我们先来看看寄存器模型的创建过程：
创建寄存器格式规范将规范转换为 uvm 寄存器模型使用寄存器模型创建寄存器格式规范：有许多寄存器格式可用于描述dut的寄存器规范。您可能熟悉广泛使用的 synopsys ralf 格式。下图说明了使用 synopsys ralgen 工具将 ralf 格式转换为寄存器模型的流程。虚线表示您可以为不同的方法生成寄存器模型：
使用寄存器模型：寄存器模型具有一组用于desired和mirror寄存器值的变量。uvm文档使用了术语desired 和mirror， 但我在下面将它们称为main和mirror以避免混淆。mirror变量的目的是始终保持或表示rtl的值，以便它可以用作scoreboard。有很多 api 可对这些变量进行操作。此处的目的是阐明在仿真期间调用这些api时main变量和mirror变量会发生什么。
让我们看一下可用的 api。我将它们分为三组：active、passive和indirect。
active： 在总线上通过物理事务做读写操作。read()、write()、update() 和 mirror() 是active api，它们使用物理接口在 dut 上运行。您可以选择使用后门机制，在这种情况下它不会消耗仿真周期。与使用前门访问相同的rtl寄存器行为一致。
passive：仅使用寄存器模型操作。set()、get() 和 predict() 是直接在模型上操作的passive api。调用passive peek() 不会在读取过程中改变寄存器值。例如，读取以清除寄存器——执行 peek() 时寄存器不会被清除。
indirect： 有一组 api 可以间接在 dut 上运行，它们是 peek() 和 poke()。请注意 peek() 和 poke() api 只是后门访问。尽管 poke 可以更新 rtl 寄存器，但它不能模拟物理读取期间可能发生的实际寄存器行为。例如，写1来清除寄存器。
让我们简要介绍一下广泛使用的 api 定义。您可以在 uvm 类参考指南中找到更多详细信息。
read()：使用前门或后门访问从 dut 寄存器中读取值。
write()：使用前门或后门访问更新 dut 寄存器。
update()： 如果您使用 set() 更改了主寄存器变量中的任何值，则可以使用这种方法（批量更新）将所有这些寄存器写入 dut。您可以调用单独的 write() 方法来实现相同的结果。
mirror()： mirror 维护dut寄存器值的副本。mirror() 方法读取寄存器，如果启用检查，则可选择将回读值与当前镜像值进行比较。 可以使用物理接口（前门）或 peek()（后门）机制执行镜像。
peek()： 使用后门访问机制从dut寄存器中读取值。
poke()：使用后门访问机制将指定值写入dut寄存器。
predict()：您可以使用此方法将镜像变量值更改为期望值。
我进行了一些实验，下表显示了当从testbench执行任何这些 api 时，寄存器模型和 dut 中发生的情况。
缩写
umv – 更新主变量，umrv – 更新镜像变量，ap – auto predict
rdr – 读取dut寄存器，udr – 更新dut寄存器，rmv – 读取main变量
fd – 前门，bd – 后门，* – 检查是否使用了 uvm_chek， na – 不适用
要记住的几点
没想到 peek() 和 poke() 方法会无条件更新镜像值。查看uvm源码后，发现在peek()和poke()方法内部无条件调用do_preedit()方法。我还注意到使用后门机制的 write() 和 read() 方法会在调用 do_predict() 时更新镜像寄存器，而无需检查此 get_auto_predict() 方法的输出。我看到这个有条件调用的唯一地方是具有前门访问的 write() 和 read() 方法。
在与专家讨论后，了解到这样设计是有意的，是为了确保镜像变量中具有最新的寄存器值。类似地，使用后门访问的 read()/write() 也会更新镜像寄存器——这也是有意的。因为使用了后门，所以不会在物理接口上观察到（当auto predict关闭时）更新寄存器模型的事务。因此，它必须在所有情况下进行更新。
作者：vidyashankar ramaswamy
来源：
https://blogs.synopsys.com/vip-central/2015/01/06/using-uvm-register-model/
arm架构和x86架构区别 linux是x86还是arm
国产手机设计与小米mix比肩，也只有荣耀magic了
中国电信已顺利完成了Cat 1模组的测试入库
Nexperia(安世半导体)：如何选择符合应用散热要求的半导体封装
5G行业跃迁，4G智能手机还有消费市场吗？
简化UVM寄存器模型的使用教程
关于一些显示电缆连接器的使用指南
AI/机器学习项目构建“终极指南”如何正确的开展ML/AI系统
简述磁性材料密度测试教程
RISC-V给异构计算带来新活力
FreeRTOS在英飞凌TriCore TC33x系列上的移植和使用
如何修改Linux系统的SSH端口
Pintech品致诚邀您参加2022年9月3日在上海举办的亚洲电源、电机、电动车技术创新发展论坛
别样风格， 荣耀V9开箱图赏
麒麟与中国芯磨合顺利 全国产化电脑亮相
面向医疗系统的DC/DC 转换器应用方案
中国半导体设备业的市场规模与发展状况
高通骁龙865为什么没有采用7nm EUV
5＋X组合,轻松承载数据中心多样化应用
红外感应调光ic方案升级版SM2083替换亚成微RM9010分析