日志

高级UVM寄存器建模

热度 2已有 5452 次阅读| 2016-11-5 16:56 |个人分类:验证前沿资讯|系统分类:芯片设计

高级UVM寄存器建模

对于一个复杂设计，其有效寄存器模型，要能够模拟任意数量的寄存器域操作、副作用以及不同寄存器间的交互作用。UVM提供了标准的基类库，用户可以借此实现设计者所设想的寄存器行为，但是在UVM所给出的关于寄存器模型的文档里，其中的例子、规则以及一些建议存在有一定的误导性，如果未能仔细分辨的话，你的寄存器模型可能会性能很差，甚至无法使用。0所以这里讲了一些UVM寄存器建模操作，主要用于方面大家实现一些复杂的寄存器模型。

UVM 寄存器概述

在验证中，寄存器模型就是一些类的集合，这些类模拟了DUT中的存储器，以及寄存器的存储器映射行为。这些类主要用于产生验证工程师想要的一些特定激励，进行功能检查。UVM提供了一组基类，可用于扩展实现一些复杂的寄存器模型。寄存器模型的基本结构如下图所示。

寄存器模型本身是一组有DUT特性的文件。基于所需的寄存器数量和其特定的结构，寄存器模型一般可以由包含寄存器信息的文本文件（如XML文件）产生。在验证环境中，顶层的寄存器模块与其他验证组件并行初始化，如下图所示。
需要注意的是可复用的接口组件并不包含寄存器模型的调用（因为这会影响可移植性），但是封闭环境会实现接口组件和模型间的任何必要的交互关系。寄存器模型和验证环境中其余组件的信息交互主要通过adapter和predictor这两个组件完成。
uvm_reg_adapter用于转换寄存器模型的读写方法以及特定接口的transaction。
uvm_reg_predictor基于monitor观测到的transactions更新寄存器模型。
另外，UVM寄存器模型支持active和passive两种操作方式，通常在验证环境里，两种操作方式会同时用到。如下图所示，在active环境时，寄存器的操作由寄存器模型的读写发起。通过adapter 转换sequence items（如下图路径1）。Passive操作指的是激励没有直接使用寄存器模型的寄存器操作，例如，有接口组件sequence直接通过virtual sequencer执行，而没有调用寄存器模型访问方法（如下图路径2）。或者说寄存器直接由总线事务配置，例如嵌入式CPU运行固件（如下图路径3）。
寄存器模型操作
A.寄存器访问API
每个域都有相应的预计镜像值、复位状态以及进行附加操作（比如随机化）的钩子，如下图
对于非易失的寄存器域，基于所有的active和passive的总线操作，镜像值提供了寄存器域的当前状态。本文的内容即是针对非易失寄存器域的。寄存器的操作可以总结为：
    write, poke, set-update and randomize-update都是active类型操作，镜像值和DUT寄存器值都会跟新。
    read, peek and mirror都是active类型操作，会基于DUT寄存器的值，来更新镜像值。
    复位 and predict 是passive类型操作，镜像值的更新独立于模型激励。
B.钩子和回调
在UVM寄存器模型中，钩子和回调用于改变寄存器的行为。寄存器和域基类提供了一系列空的虚方法钩子（如pre_write, post_write, pre_read ,post_read)。寄存器模型开发者为了实现特定功能，可以在寄存器操作执行的特定点处调用这些方法。

回调基类也有许多空的虚方法（如pre_write，post_write，pre_read，post_read，post_predict，encode , decode），但是只有用特定的域或者寄存器注册回调方法（callback会被加入到一个列表里）后，回调才可以执行。开发者可以扩展基类获取用户自定义的callback类，然后根据自己的需求，执行其中的一个或者多个虚方法。
C.域访问规则
UVM提供了复杂的预定义域访问规则，总结如下表，域访问规则通常在build里通过configure方法设置。
需要对域访问规则进行说明的是，他们都是是独立的，域的行为可以根据对寄存器的操作来调控，同时，这一行为独立于其他域和寄存器。如下图是域访问规则示意图。
D.寄存器域的交互
实际上，在项目里，我们很多时候需要在不同的寄存器域间交互操作，而不仅仅是完全独立的域访问。UVM提供了一些机制，使用户能够使用一些钩子或回调，来开发这种高级的寄存器操作关系。一般情况，会建立一些从一个寄存器域映射到另一个寄存器域的句柄，并在更高的层次上（如register block）建立连接关系。下图显示了两个域的交互关系，他们来自不同的寄存器，两个寄存器域的操作（读和写）以及域值能够影响另一个域的行为。
寄存器模型示例
下面给出一些寄存器模型的例子，来示例一些特定类型的寄存器的行为和相互作用。（每种例子有多种具体操作，见原文）
A. 用户自定义的访问规则Write-to-Reset
当WC（write-to-clear ）和WS（write-to-set）可以作为预定义的域访问规则使用的时候，一些设备可能会要求用户自定义一种新的域访问规则，执行write-to-reset的行为。这时，寄存器域使用写操作设置到其当前的复位值（使用configure或者set_reset初始化，并设置不是全1或者全0，否则使用预定义的规则就可以了）。这种访问规则也有一些其他类似的变化规则，比如read-to-reset,write-1-to-reset, write-0-to-reset,等，下图描述了这种规则的基本机制。
 
B.域的交互—Locked/Protected Field
寄存器经常会有这样的需求，当其他域有特定值的时候，保持某些域是被锁住，或者被保护的。这种锁定可以是相对固定的（比如我们配置好寄存器，然后在整个应用阶段锁定他们）或者暂时的（比如我们配置设备操作其他方面时，会保持一些寄存器暂时锁定）。锁定的值可以使一位或者多位密钥。下图是基本操作示意。
C.域交互——触发缓冲写入Triggered Buffered Writes
另一种会有常见的要求，特别在有许多伪静态配置的寄存器的应用中，会要求寄存器的写入要被缓存起来，直到一个触发器域或者寄存器被访问（有时有特定的关键值，或者甚至是特定序列写入时触发）时，才将其应用到DUT的功能性部分。当触发器写入的时候，缓存寄存器域的值被拷贝到active状态的寄存器，并且操作继续。基本的机制如下图。
D.寄存器模型外的副作用
寄存器的副作用不局限于域之间的交互，而且反映在许多其他验证环境行为方面。例如，UVM文档描述寄存器模型的随机化，然后使用更新的方法把随机配置的寄存器应用于DUT，但是这样的话忽略了许多接口验证组件的配置对象域也需要更新，这样才能响应DUT寄存器的操作。直接从sequences完成验证组件配置更新并不推荐，因为这在被动环境里就无法完成。下图解释了，为了管理通用或者遗留验证组件的配置变量，我们如何使用callback监视寄存器操作。
总结说明
所有文中列出的例子都在实际项目中有用到，实际上，在项目的演变中，我们才开始尝试结合UVM，开发最好用的寄存器模型，并不是完全按照UVM文档里提供的操作。篇幅所限，本文在这里所列的内容也只是一个概述，更详细的内容，以及对寄存器性能的分析可查看原文。
 Advanced UVM Register Modeling.pdf(1.21 MB)