13、IC验证面试88问——机制、config机制、RAL模型

Q61：filed_automation机制和objection机制。

field_automation 机制：
可以自动实现 copy、compare、print 等三个函数。当使用 uvm_field 系列相关宏注册之后，可以直接调用以上三个函数，而无需自己定义。这极大的简化了验证平台的搭建，尤其是简化了 driver和 monitor，提高了效率。
objection 机制：
UVM 中通过 objection 机制来控制验证平台的关闭，需要在drop_objection 之前先 raise_objection。验证在进入到某一 phase 时，UVM会收集此 phase 提出的所有 objection，并且实时监测所有 objection 是否已经被撤销了，当发现所有都已经撤销后，那么就会关闭此 phase，开始进入下一个 phase。当所有的 phase 都执行完毕后，就会调用$finish 来将整个验证平台关掉。如果 UVM 发现此 phase 没有挂起起任何 objection，那么将会直接跳转到下一个 phase 中。
UVM 的设计哲学就是全部由 sequence 来控制激励生成，因此一般情况下只在 sequence 中控制 objection。另外还需注意，raise_objection语句必须在 main_phase 中第一个消耗仿真时间的语句之前。

Q62：Config_db 的作用，以及传递其使用时的参数含义

Config_db 机制主要作用就是传递参数使得 TB 的可配置性高，更加灵活。 Config_db 机制主要传递的有三种类型:

1. 一种是 interface 虚拟接口，通过传递 virtual interface 使得 dirver和 monitor 能够与 DUT 连接，并驱动接口和采集接口信号。
2. 第二种是单一变量参数，如 int,string,enum 等，这些主要就是为了配置某些循环次数， id 号是多少等等。
3. 第三种是 object 类，这种主要是当配置参数较多时，我们可以将其封装成一个 object 类，去包含这些属性和相关的处理方法,这样传递起来就比较简单明朗，不易出错。

Config_db 的参数主要由四个参数组成，如下所示，第一个参数为父
的根 parent ，第二个参数为接下来的路径，对应的组件，第三个是传递时
的名字（必须保持一致)，第四个是变量名。

uvm_config_db #(virtual interface)::set(uvm_root.get(),"uvm_test_top.c1","vif ",vif); 
uvm_config_db#(virtual interface) :: get(this,"”,"vif ",vif);

Q63. UVM 中各个 component 之间是如何组织运行的，串行还是并行，通过什么机制进行调度的?

Component 之间通过在 new 函数创建时指定 parent 参数指定子关系，通过这种方法来将 TB 形成一个树形结构。
UVM 中运行是通过 Phase 机制进行层次化仿真的。从组件来看各个组件并行运行，从 phase 上看是串行运行，有层次化的。
Phase 机制的 9 个 phase 是串行运行的，不同组件中的同一个 phase都运行完毕后才能进入下一个 phase 运行，同一个 phase 在不同组件中的运行也是由一定顺序的, build 和 final 是自顶向下。

Q64. UVM 如何启动一个 sequence?

启动 sequence 有很多的方法，常用的方法有：

1. 使用 default sequence 进行调用，其会将对应的 sequence 与sequencer 绑定，当 dirver 请求获得 req 时， sequencer 就会调用对应的sequence 去运行 body 函数，从而产生 req 。
2. 除此之外，还可以使用 start 函数进行，其参数主要就是对应的需要绑定的 sequencer 和该类的上层 sequence 。如此，就可以实现启动 sequence的功能。
   注意:一般仿真开始结束会在 sequence 中 raise objection 和 drop objection。

Q65：你所搭建的验证平台为什么要用RAL（寄存器）？

1. 首先，我们要了解寄存器对于设计的重要性，其是模块间交互的窗口，我们可以通过读寄存器值去观察模块的运行状态,通过写寄存器去控制模块的配置和功能改变。
2. 然后，为什么我们需要 RAL 呢?由于前面寄存器的重要性，我们可以知道，如果我们不能先保证我们寄存器的读写正确，那么就不用谈后续 DUT是否正确了，因此，寄存器的验证是排在首要位置的。
3. 那么我们应该用什么方法去读写和验证寄存器呢?采用 RAL 寄存器模型去测试验证，是目前最成功的方法吧，寄存器模型独立于 TB 之外，我们可以搭建一个测试寄存器的 agent ，去通过前门或者后门访问去控制 DUT 的寄存器,使得 DUT 按照我们的要求去运行。
4. 除此之外， UVM 中内建了很多 RAL 的 sequence ，用于帮助我们去检测寄存器，除此之外，还有一些其他的类和变量去帮助我们搭建，以提高 RAL的可重用性和便捷性还有更全的覆盖率。

Q66： 前门访问和后门访问的区别。

前门访问和后门访问的比较：

1. 前门访问，顾名思义指的是在寄存器模型上做的读写操作，最终会通过总线 UVC 来实现总线上的物理时序访问，因此是真实的物理操作。
2. 后门访问，指的是利用 UVM DPI (uvm_hdl_read()、uvm_hdl_deposit()),将寄存器的操作直接作用到 DUT 内的寄存器变量，而不通过物理总线问。
3. 前门访问在使用时需要将 path 设置为 UVM_FRONTDOOR。
4. 在进行后门访问时，用户首先需要确保寄存器模型在建立时，是否将各个寄存器映射到了 DUT 一侧的 HDL 路径：使用 add_hdl_path。
   从上面的差别可以看出，后门访问较前门访问更便捷更快一些，但如果单纯依赖后门访问也不能称之为“正道”。实际上，利用寄存器模型的前门访问和后门访问混合方式，对寄存器验证的完备性更有帮助。

Q67： 后门访问的路径设置。

Q68： 后门访问的路径设置。

在通过前门配置寄存器 A 之后，再通过后门访问来判断 HDL 地址映射的寄存器 A 变量值是否改变，最后通过前门访问来读取寄存器 A 的值。

Q69：寄存器模型的常规方法（期望值、镜像值、真实值）

mirror、desired、actual value()

1. 我们在应用寄存器模型的时候，除了利用它的寄存器信息，也会利用它来跟踪寄存器的值。寄存器有很多域，每一个域都有两个值。
2. 寄存器模型中的每一个寄存器，都应该有两个值，一个是镜像值( mirrored value ) , 一个是期望值( desired value ） 。
3. 期望值是先利用寄存器模型修改软件对象值，而后利用该值更新硬件值;镜像值是表示当前硬件的已知状态值。
4. 镜像值往往由模型预测给出，即在前门访问时通过观察总线或者在后门访问时通过自动预测等方式来给出镜像值。
5. 镜像值有可能与硬件实际值不一致。

Q70. Prediction 的分类（自动预测和显式预测）

UVM 提供了两种用来跟踪寄存器值的方式，我们将其分为自动预测 （ auto prediction ）和显式预测( explicit )。

1. 如果用户想使用自动预测的方式，还需要调用函数uvm_reg_map::set_auto predict()
2. 两种预测方式的显著差别在于，显式预测对寄存器数值预测更为准确，我们可以通过下面对两种模式的分析得出具体原因。
3. 自动预测：如果用户没有在环境中集成独立的 predictor ，而是利用寄存器的操作来自动记录每一次寄存器的读写数值，并在后台自动调用 predict() 方法的话，这种方式被称之为自动预测。
   这种方式简单有效，然而需要注意,如果出现了其它一些 sequence 直接在总线层面上对寄存器进行操作（跳过寄存器级别的 write/read 操作,或者通过其它总线来访问寄存器等这些额外的情况，都无法自动得到寄存器的镜像值和预期值。
4. 显式预测： 更为可靠的一种方式是在物理总线上通过监视器来捕捉总线事务，并将捕捉到的事务传递给外部例化的 predictor ，该 predictor 由 UVM 参数化类 uvm_reg_predictor 例化并集成在顶层环境中。
   在集成的过程中需要将 adapter 与 map 的句柄也一并传递给 predictor ,同时将 monitor 采集的事务通过 analysis port 接入到 predictor 一侧。
   这种集成关系可以使得， monitor 一旦捕捉到有效事务，会发送给predictor ，再由其利用 adapter 的桥接方法，实现事务信息转换，并将转化后的寄存器模型有关信息更新到 map 中。

默认情况下，系统将采用显式预测的方式，这就要求集成到环境中的总线 UVC monitor 需要具备捕捉事务的功能和对应的 analysis port ，以便于同 predictor 连接。