数字IC验证面试（常问题88道）

• run_phase和main phase（动态运行）都是task phase，且是并行运行的，后者称为动态运行(run-time)的phase。

• 如果想执行一些耗费时间的代码，那么要在此phase下任意一个component中至少提起一次objection，这个结论只适用于12个run-time的phase。对于run_phase则不适用，由于run_phase与动态运行的phase是并行运行的，如果12个动态运行的phase有objection被提起，那么run_phase根本不需要raise_objection就可以自动执行。

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

• UVM中采用事务级传输机制进行组件间的通信，可以大大提高仿真的速度和使得我们简化组件间的数据传输，简化工作，TLM独立于组件之外，降低组件间的依赖关系。UVM 接口主要由port、export、imp;驱动这些接口方式有put、get、peek、transport、analysis 等。

• 其中peek是查看端口内部的数据事务但是不删除，get是获取后立即删除。我们一般会先使用peek进行获取数据，但不删除(保证put端不会立马又发送一个数据)，处理完毕后再用get删除。

• lmp只能作为终点接口，transport表示双向通信，analysis可以连接多个imp(类似于广播)。

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

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的分类:

• 扁平类（flat sequence)：这一类往往只用来组织更细小的粒度，即item实例构成的组织。

• 层次类( hierarchical sequence)：这一类是由更高层的sequence用来组织底层的sequence,进而让这些sequence或者按照顺序方式，或者按照并行方式，挂载到同一个sequencer上。

• 虚拟类（virtual sequence)：这一类则是最终控制整个测试场景的方式，鉴于整个环境中往往存在不同种类的sequencer和其对应的sequence，我们需要一个虚拟的sequence来协调顶层的测试场景。之所以称这个方式为virtual sequence，是因为该序列本身并不会固定挂载于某一种sequencer类型上，而是将其内部不同类型sequence最终挂载到不同的目标sequencer上面。这也是virtual sequence不同于hierarchical sequence的最大一点。

• 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也有其生命周期。它的生命周期比my_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_SEQ_ARB_STRICT_RANDOM: 不同的请求，会按照它们的最高优先级随机授权，与抵达时间无关。
• UVM_SEQ_ARB_USER: 用户可以自定义仲故方法user. priority. ,arbitration0来裁定哪个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群落。

• 在UVM中有sequence机制，以往如果我们使用SV进行TB搭建时，我们一般会采用driver 一个类进行数据的参数,转换,发送,或者使用genetor和driver两个进行，这种方式可重用性很低，而且代码臃肿;

• 但是在UVM中我们通过将sequence、sequencer、driver、sequence_item拆开，相互独立而又有联系，因此我们只需关注每一个类需要做的工作就可以，可重用性高。我在学习sequence时，我经常把sequence 比作蓄水池，sequence_item就是水，sequencer就是一个调度站，driver就是总工厂，通过这种方式进行处理，我们的总工厂不需要管其他，只需处理运送过来的水资源就可以，而sequencer只需要调度水资源，sequence只需要产生不同的水资源。

• Interface如果不进行virtual声明的话是不能直接使用在dirver中的,会报错，因为interface声明的是一个实际的物理接口。一般在dirver中使用virtual interface进行申明接口，然后通过config_db进行接口参数传递，这样我们可以从上层组件获得虚拟的interface接口进行处理。

• Config_db传递时只能传递virtual接口，即interface的句柄，否则传递的是一个实际的物理接口，这在 driver中是不能实现的，且这样的话不同组件中的接口一一对应一个物理接口，那么操作就没有意义了。

Factory机制也叫工厂机制，其存在的意义就是为了能够方便的替换TB中的实例或者已注册的类型。一般而言，在搭建完TB后，我们如果需要对TB进行更改配置或者相关的类信息，我们可以通过使用factory 机制进行覆盖，达到替换的效果，从而大大提高TB的可重用性和灵活性。要使用factory机制先要进行：

1. 将类注册到factory表中

2. 创建对象，使用对应的语句 （type_id::create）

3. 编写相应的类对基类进行覆盖。

Callback机制其作用是提高TB的可重用性,其还可进行特殊激励的产生等，与factory类似，两者可以有机结合使用。与factory不同之处在于 callback的类还是原先的类，只是内部的callback函数变了，而factory是产生一个新的扩展类进行替换。

1. UVM组件中内嵌callback函数或者任务

2. 定义一个常见的uvm_callbacks class

3. 从UVM callback空壳类扩展uvm_callback类

4. 在验证环境中创建并登记uvm_callback

• field_automation机制：可以自动实现copy、compare、print等三个函数。当使用uvm_field系列相关宏注册之后，可以直接调用以上三个函数，而无需自己定义。这极大的简化了验证平台的搭建，尤其是简化了driver和monitor，提高了效率。

• 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中第一个消耗仿真时间的语句之前。

• 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);

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

• 启动sequence有很多的方法:常用的方法有使用default sequence进行调用，其会将对应的sequence 与 sequencer绑定，当dirver请求获得req时，sequencer就会调用对应的sequence去运行body函数，从而产生req。

• 除此之外，还可以使用start函数进行，其参数主要就是对应的需要绑定的sequencer和该类的上层sequence。如此，就可以实现启动sequence的功能。

• 注意:一般仿真开始结束会在sequence 中 raise objection和 drop objection

• 首先，我们要了解寄存器对于设计的重要性，其是模块间交互的窗口，我们可以通过读寄存器值去观察模块的运行状态,通过写寄存器去控制模块的配置和功能改变。

• 然后，为什么我们需要RAL呢?由于前面寄存器的重要性，我们可以知道，如果我们不能先保证我们寄存器的读写正确，那么就不用谈后续 DUT是否正确了，因此，寄存器的验证是排在首要位置的。

• 那么我们应该用什么方法去读写和验证寄存器呢?采用RAL寄存器模型去测试验证，是目前最成功的方法吧，寄存器模型独立于TB之外，我们可以搭建一个测试寄存器的agent，去通过前门或者后门访问去控制DUT的寄存器,使得 DUT按照我们的要求去运行。

• 除此之外，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

        5. 从上面的差别可以看出，后门访问较前门访问更便捷更快一些，但如果单纯依赖后门访问也不能称之为“正道”。

        6. 实际上，利用寄存器模型的前门访问和后门访问混合方式，对寄存器验证的完备性更有帮助。

Q67. 后门访问的路径怎么配置

后门访问

• 示例中通过uvm_reg_block::add_hdl_path()， 将寄存器模型关联到了DUT一端， 而通过uvm_reg::add_hdl_path_slice完成了将寄存器模型各个寄存器成员与HDL -侧的地址映射。
• 另外， 寄存器模型build0函敗最后以lock_model()结尾， 该函数的功能是结束地址映射关系，并且保证模型不会被其它用户修改。
• 在寄存器模型完成了HDL路径映射后，我们才可以利用uvm_reg或者uvm_reg_sequence自带的方法进行后门访问。后门访问也有几类方法提供:

1. uvm_reg::read()/write()在调用读方法时雷要注明UVM_BACKDOOR的访间方式。
2. uvm_reg_sequence::read_reg()/wite reg()在使用时也需要注明UVM_BACKDOOR的访间方式。
3. 另外，uvm_regpeek()/poke()两个方法，也分别对应了读取寄存器(peek)和修改寄存器(poke) 两种操作。而用户无需指定访问方式尾UVM_BACKDOOR，因为这两个方法本米就只针对于后门访问。

Q68. 如果寄存器的地址不匹配的错误怎么测试出来

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

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

mirror、desired、actual value（）

1. 我们在应用寄存器模型的时候，除了利用它的寄存器信息，也会利用它来跟踪寄存器的值。寄存器有很多域，每一个域都有两个值。

2. 寄存器模型中的每一个寄存器，都应该有两个值，一个是镜像值( mirrored value) , 一个是期望值(desired value） 。

3. 期望值是先利用寄存器模型修改软件对象值，而后利用该值更新硬件值;镜像值是表示当前硬件的已知状态值。

4. 镜像值往往由模型预测给出，即在前门访问时通过观察总线或者在后门访问时通过自动预测等方式来给出镜像值

5. 镜像值有可能与硬件实际值不一致

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

• 如果用户想使用自动预测的方式，还需要调用函数uvm_reg_map::set_auto predict()

• 两种预测方式的显著差别在于，显式预测对寄存器数值预测更为准确，我们可以通过下面对两种模式的分析得出具体原因。自动预测

1. 如果用户没有在环境中集成独立的predictor，而是利用寄存器的操作来自动记录每一次寄存器的读写数值，并在后台自动调用predict()方法的话，这种方式被称之为自动预测。

2. 这种方式简单有效，然而需要注意,如果出现了其它一些sequence直接在总线层面上对寄存器进行操作（跳过寄存器级别的write/read操作,或者通过其它总线来访问寄存器等这些额外的情况，都无法自动得到寄存器的镜像值和预期值。显式预测

3. 更为可靠的一种方式是在物理总线上通过监视器来捕捉总线事务，并将捕捉到的事务传递给外部例化的predictor，该predictor由UVM参数化类uvm_reg_predictor例化并集成在顶层环境中。

4. 在集成的过程中需要将adapter与map的句柄也一并传递给predictor,同时将monitor采集的事务通过analysis port接入到predictor一侧。

5. 这种集成关系可以使得，monitor一旦捕捉到有效事务，会发送给predictor，再由其利用adapter的桥接方法，实现事务信息转换，并将转化后的寄存器模型有关信息更新到map中。

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

Q72. AMBA总线中AHB/APB/AXI协议的区别

AHB(Advanced High-performance Bus)高级高性能总线。APB(Advanced Peripheral Bus)高级外围总线AXI (Advanced eXtensible Interface)高级可拓展接口