UVM基础总结——基于《UVM实战》示例

一、前言

工作一直在做SoC验证，更关注模块间的连接性和匹配性，所以相比于擅长随机约束激励的UVM来说，定向测试的概念更容易debug。当然前提是IP已经被充分验证。因此觉得接触UVM的机会较少。到现在发现即使在SoC验证中依然有它的用武之地。比如验证可独立于CPU工作的IP、快速对系统性能进行评估、重用IP级别的验证环境，甚至是一些通用的VIP也有基于UVM编写的。基于这些考量，也逐渐开始接触。《UVM实战》是很多验证工程师的启蒙，本文借用书中开头的示例简单梳理下UVM的基本知识。

二、UVM基础概述

关于UVM的知识网络上已经铺天盖地了，下边的内容只是自己的一些认识和随记。UVM其实就是基于SV语言写的用于验证的代码库和对应的验证规范。下图是UVM验证环境的整体结构（图来源见参考文献1）。图中注释介绍了每个组成部分的作用。《UVM实战》书中给我留下最深刻的印象就是用子弹、弹夹和手枪分别类比transaction sequence和sequencer，这也是UVM环境灵活的重要原因之一。这是激励的产生机制，至于响应的采集和响应任务会交给monitor和scoreboard。后者中的期望数据或者参考数据的来源比较灵活，函数、文件或是reference model的响应均可。

以上是UVM的空间维度，这一概念也被抽象成如下的树状结构。各个部分必然存在信息交互。sequence和sequencer之间传递的是transaction，实际上component之间也是transaction级别的通信，叫做TLM （transaction level model）最常见的就是monitor中uvm_analysis_port通过uvm_tlm_analysis_fifo连接到reference model或scoreboard中的uvm_blocking_get_port。这样可以确保transaction能够传递给目的组件。

另一方面UVM在时间维度上也做了规范。phase机制明确划分了各个阶段所要完成的任务。其中比较重要的是run phase这一消耗仿真时间的task phase以及ojbection的概念。只有每个phase中所有raise的objection都被drop后才会执行下一个phase的任务。搭建空间与时间维度桥梁的也是Phase--build phase是在树状结构中自上而下执行，其他不消耗仿真时间的phase都是自下而上运行。run phase则自上而下启动同事运行。所有phase的顺序见图3（图来源见参考文献2）

弄明白这三张图，也就是组件、组件间通信和phase机制，基本上可以看懂别人写的代码了。

三、验证环境示例

各个UVM object和component:

• sequence:

• transaction:

• sequencer:

• driver:

• monitor:

• agent:

• reference model:

• scoreboard:

• base test:

• Interface:

• testbench top:

需要注意是在定义class前，如果这个class会使用到其他class，最好在前面加type class。例如在class my_sequence extends uvm_sequence前一行加上type class my_transaction。否则如果my_sequence在my_transaction之前编译，就会报错。虽然可以通过在testbench top中先include my_transaction.sv解决，但是大大降低了代码的重用性。

四、测试用例及仿真

 1 `ifndef MY_CASE0__SV 2 `define MY_CASE0__SV 3 class case0_sequence extends uvm_sequence #(my_transaction); 4 my_transaction m_trans; 5  6 function  new(string name= "case0_sequence"); 7 super.new(name); 8 endfunction  9 10 virtual task body();11 if(starting_phase != null) 12 starting_phase.raise_objection(this);13 repeat (10) begin14 `uvm_do(m_trans)15 end16 #100;17 if(starting_phase != null) 18 starting_phase.drop_objection(this);19 endtask20 21 `uvm_object_utils(case0_sequence)22 endclass23 24 25 class my_case0 extends base_test;26 27 function new(string name = "my_case0", uvm_component parent = null);28 super.new(name,parent);29 endfunction 30 extern virtual function void build_phase(uvm_phase phase); 31 `uvm_component_utils(my_case0)32 endclass33 34 35 function void my_case0::build_phase(uvm_phase phase);36 super.build_phase(phase);37 38 uvm_config_db#(uvm_object_wrapper)::set(this, 39 "env.i_agt.sqr.main_phase", 40 "default_sequence", 41 case0_sequence::type_id::get());42 endfunction43 44 `endif my_case0

所用的测试用例都扩展自自定义的base_test，后者又来自uvm_test。base_test例化整个UVM environment，用例中主要要做的事情就是启动sequence, 包括调用start任务手动启动和自动启动方式，具体见参考文献3.这里是最常见的自动启动方式：用uvm_config_db将要启动的sequence设置为sequencer main_phase的default_sequence.

每个sequence中都有个叫body的task，当sequence被启动时会自动调用这个task。通过`uvm_do宏来产生transaction。更灵活的方式是先后使用`uvm_create()和`uvm_send()实现这一功能，并在两者间控制transaction的各个field。只有当消耗仿真时间的driver调用了item_done()后一次transaction的发送才算结束。

五、总结

我们不创造知识，我们只是知识的搬运工。将知识灵活运用，创造出合理高效可重用的VIP，验证环境乃至整个验证流程方法是IC验证的核心技能，这些技能都是为尽可能快速发现潜在问题这一核心任务做的准备。