12、IC验证面试88问——phase机制、TLM、AP、sequencer、仲裁机制、vif、cb机制

Q51：main_phase要如何跳转到reset_phase？

在 main_phase 执行过程中，突然遇到 reset 信号被置起，可以用 jump() 实现从mian_phase 到 reset_phase 的跳转。

Q52：UVM 组件的通信方式 TLM 的接口分类和用法，peek 和 get的差异。

UVM 中采用事务级(transaction)传输机制进行组件间的通信，可以大大提高仿真的速度和使得我们简化组件间的数据传输，简化工作，TLM 独立于组件之外，降低组件间的依赖关系。
UVM 接口主要由 port、export、imp ;
驱动这些接口方式有 put、get、peek、transport、analysis 等。
其中 peek 是查看端口内部的数据事务但是不删除，get 是获取后立即删除。我们一般会先使用 peek 进行获取数据，但不删除(保证 put 端不会立马又发送一个数据)，处理完毕后再用 get 删除。
imp 只能作为终点接口，transport 表示双向通信，analysis 可以连接多个 imp(类似于广播)。

Q53：Analysis port 是否可以不连或者连多个 imp？

都可以。
Analysis port 类似于广播，其可以同时对多个 imp 进行事务通信，只需要在每一个对应的 imp 端口申明 write()函数即可。对比 put,get,peek port，他们都只能进行一对一传输，且也必须申明对应的函数如 put()、get()、peek()、can_put()/do_put()等。FiFo 是可以不用申明操作函数的，其内部封装了很多的通信端口，如 analysis_export 等，我们只需要将端口与其连接即可实现通信。

Q54：Sequence 和 item（uvm_sequece，uvm_sequence_item）以及 sequence 的分类。

1. item 是基于 uvm_object 类，这表明了它具备 UVM 核心基类所必要的数据操作方法，例如 copy、 clone、compare、record 等。
2. item 对象的生命应该开始于 sequence 的 body（）方法，而后经历了随机化并穿越 sequencer 最终到达 driver，直到被 driver 消化之后，它的生命一般来讲才会结束。
3. item 与 sequence 的关系：一个 sequence 可以包含一些有序组织起来的 item 实例，考虑到 item 在创建后需要被随机化，sequence 在声明时也需要预留一些可供外部随机化的变量，这些随机变量一部分是用来通过层级传递约束来最终控制 item 对象的随机变量，一部分是用来对 item 对象之间加以组织和时序控制的。
4. Sequence 的分类:
   （1） 扁平类（flat sequence)：这一类往往只用来组织更细小的粒度，即
   item 实例构成的组织。
   （2） 层次类( hierarchical sequence)：这一类是由更高层的 sequence用来组织底层的 sequence,进而让这些 sequence 或者按照顺序方式，或者按照并行方式，挂载到同一个 sequencer 上。
   （3）虚拟类（virtual sequence)：这一类则是最终控制整个测试场景的方式，鉴于整个环境中往往存在不同种类的 sequencer 和其对应的sequence，我们需要一个虚拟的 sequence 来协调顶层的测试场景。之所以称这个方式为 virtual sequence，是因为该序列本身并不会固定挂载于某一种sequencer 类型上，而是将其内部不同类型 sequence 最终挂载到不同的目标sequencer 上面。这也是 virtual sequence 不同于 hierarchical sequence的最大一点。

Q55：Sequence 和 sequencer 的关系。

sequence 机制用于产生激励，它是 UVM 中最重要的机制之一。sequence机制有两大组成部分：sequence 和 sequencer。
在整个验证平台中 sequence 处于一个比较特殊的位置。sequence 不属于验证平台的任何一部分，但是它与 sequencer 之间有着密切的关系。
只有在 sequencer 的帮助下，sequence 产生的 transaction 才能最终送给 driver；同样，sequencer 只有在 sequence 出现的情况下才能体现出其价值，如果没有 sequence，sequencer 几乎没有任何作用。
除此之外，sequence 与 sequencer 还有显著的区别。从本质上说，sequencer 是一个 uvm_component,而 sequence 是一个 uvm_object。与my_transaction 一样，sequence 也有其生命周期。它的生命周期比transaction 要更长一点，其内部的 transaction 全部发送完毕后，它的生命周期也就结束了。

Q56： Sequencer 的仲裁特性（set_arbitration）及锁定机制（lock和 grab）

1. 仲裁特性
   在实际使用中，我们可以通过uvm_sequencer::set_arbitration(UVM_ SEQ_ARB_TYPE val）函数来设置仲裁模式这里的仲裁模式，UVM_SEQ_ARB_TYPE有下面几种值可以选择：
   UVM_SEQ_ARB_FIFO：默认模式。来自于sequences的发送请求，按照FIFO先进先出的方式被依次授权，和优先级没有关系。
   UVM_SEQ_ARB_WEIGHTED：不同sequence的发送请求，将按照它们的优先级权重随机授权。
   UVM_SEQ_ARB_RANDOM:不同的请求会被随机授权，而无视它们的抵达序和优先级。
   UVM SEQ ARB_STRICT FIFO:不的请求，会按照它们的优先级以及抵达序米依次授权，因此与优先级和抵达时间都有关。
   UVM SEQARB STRICT RANDOM: 不同的请求，会技照它们的最高优先级随机授权，与抵达时同无关。
   UVM_SEQARB_USER:用户可以自定义仲方法user_priority_arbitration()来裁定哪个sequence的请求被优先授权。
2. 锁定机制
   uvm_sequencer提供了两种锁定机制，分别通过lock()和grab()方法实现，这两种方法的区别在于：
   lock()与unlock()这一对方法可以为sequence提供排外的访问权限，但前提条件是，该sequence首先需要按照sequencer的仲裁机制获得授权。而一旦sequence获得授权，则无需担心权限被收回，只有该sequence主动解锁(unlock)它的sequencer，才可以释放这一锁定的权限。lock()是一种阻塞任务，只有获得了权限，它才会返回。
   grab()与ungrab()也可以为sequence提供排外的访问权限，而且它只需要在sequencer下一次授权周期时就可以无条件地获得授权。与lock方法相比，grab方法无视同一时刻内发起传送请求的其它sequence，而唯一可以阻止它的只有已经预先获得授权的其它lock或者grab的sequence。
   这里需要注意的是，由于“解铃还须系铃人“，如果sequence使用了lock()或者grab()方法，必须在sequence结束前调用unlock()或者ungrab()方法来释放权限，否则sequencer会进入死锁状态而无法继续为其余sequence授权。

Q57：Virtual sequence 和 virtual sequencer 中 virtual 含义。

Virtual 含义就是其 sequencer 并不需要传递 item，也不会与 driver 连接，其只是一个去协调各个 sequencer 的中央路由器。通过 virtual sequencer我们可以实现多个 agent 的多个 sequencer 他们的 sequence 的调度和可重用。virtual sequence 可以组织不同 sequencer 的 sequence 群落。

Q58：为什么会有 sequence、sequencer 以及 driver，为什么要分开实现，这样做的好处是什么？

在 UVM 中有 sequence 机制，以往如果我们使用 SV 进行 TB 搭建时，我们一般会采用 driver 一个类进行数据的参数,转换,发送,或者使用 generator和 driver 两个进行，这种方式可重用性很低，而且代码臃肿。
但是在 UVM 中我们通过将 sequence、sequencer、driver、sequence_item 拆开，相互独立而又有联系，因此我们只需关注每一个类需要做的工作就可以，可重用性高。我在学习 sequence 时，我经常把sequence 比作蓄水池，sequence_item 就是水，sequencer 就是一个调度站，driver 就是总工厂，通过这种方式进行处理，我们的总工厂不需要管其他，只需处理运送过来的水资源就可以，而 sequencer 只需要调度水资源，sequence 只需要产生不同的水资源。

Q59：如何在 driver 中使用 interface，为什么？

Interface 如果不进行 virtual 声明的话是不能直接使用在 dirver 中的，会报错，因为 interface 声明的是一个实际的物理接口。一般在 dirver中使用 virtual interface 进行声明接口，然后通过 config_db 进行接口参数传递，这样我们可以从上层组件获得虚拟的 interface 接口进行处理。
config_db 传递时只能传递 virtual 接口，即 interface 的句柄，否则传递的是一个实际的物理接口，这在 driver 中是不能实现的，且这样的话不同组件中的接口一一对应一个物理接口，那么操作就没有意义了。

Q60：你了解 uvm 的 factory 机制和callback 机制吗?

1. factory机制
   Factory 机制也叫工厂机制，其存在的意义就是为了能够方便的替换 TB 中的实例或者已注册的类型。一般而言，在搭建完 TB 后，我们如果需要对 TB进行更改配置或者相关的类信息，我们可以通过使用 factory 机制进行覆盖，达到替换的效果，从而大大提高 TB 的可重用性和灵活性。要使用 factory机制先要进行：
   （1） 将类注册到 factory 表中；
   （2） 创建对象，使用对应的语句 （type_id::create）；
   （3） 编写相应的类对基类进行覆盖。
2. callback 机制
   其作用是提高 TB 的可重用性，其还可进行特殊激励的产生等。
   与 factory 类似，两者可以有机结合使用。与 factory 不同之处在于callback的类还是原先的类，只是内部的 callback 函数变了，而 factory 是产生一个新的扩展类进行替换。
   （1）UVM 组件中内嵌 callback 函数或者任务；
   （2）定义一个常见的 uvm_callback class；
   （3）从 UVM callback 空壳类扩展 uvm_callback 类；
   （4） 在验证环境中创建并登记 uvm_callback。