芯片验证 | UVM的objection机制

TrustZone_Hcoco

已于 2024-05-02 15:55:41 修改

阅读量801

点赞数 10

文章标签：半导体资料 SV UVM IC

于 2024-05-02 15:54:06 首次发布

本文链接：https://blog.csdn.net/weixin_45264425/article/details/138392663

版权

了解完phase机制后，发现这不了解objection极其不合适，于是好吧好吧，再学习一点。

以下内容全部来自白皮书。

1 objection与task phase

objection字面的意思就是反对、异议。在验证平台中，可以通过drop_objection来通知系统可以关闭验证平台。

当然，在撤销之前首先要raise_objection。想象一下，如果读者与别人交流时事先并没有提出异议，然后忽然说：我撤销刚才的反对意见（objection）。

那么，事先并没有提出任何反对意见的你一定会令对方迷惑不已，所以，为了良好的沟通，在drop_objection之前，一定要先raise_objection：

task main_phase(uvm_phase phase);
   phase.raise_objection(this);
   …
   phase.drop_objection(this);
endtask

在进入到某一phase时，UVM会收集此phase提出的所有objection，并且实时监测所有objection是否已经被撤销了，当发现所有都已经撤销后，那么就会关闭此phase，开始进入下一个phase。当所有的phase都执行完毕后，就会调用$finish来将整个的验证平台关掉。

如果UVM发现此phase没有提起任何objection，那么将会直接跳转到下一个phase中。假如验证平台中只有（注意“只有”两个字）driver中提起了异议，而monitor等都没有提起，代码如下所示：

task driver::main_phase(uvm_phase phase);
  phase.raise_objection(this);
  #100;
  phase.drop_objection(this);
endtask
task monitor::main_phase(uvm_phase phase);
  while(1) begin
  …
  end
endtask

很显然，driver中的代码是可以执行的，那么monitor中的代码能够执行吗？

答案是肯定的。当进入到monitor后，系统会监测到已经有objection被提起了，所以会执行monitor中的代码。

当过了100个单位时间之后，driver中的objection被撤销。此时，UVM监测发现所有的objection都被撤销了（因为只有driver raise_objection），于是UVM会直接“杀死”monitor中的无限循环进程，并跳到下一个phase，即post_main_phase()。

假设进入main_phase的时刻为0，那么进入post_main_phase的时刻就为100。如果driver根本就没有raise_objection，并且所有其他component的main_phase里面也没有raise_objection，即driver变成如下情况：

task driver::main_phase(uvm_phase phase);
  #100;
endtask

那么在进入main_phase时，UVM发现没有任何objection被提起，于是虽然driver中有一个延时100个单位时间的代码，monitor中有一个无限循环，UVM也都不理会，它会直接跳转到post_main_phase，假设进入main_phase的时刻为0，那么进入post_main_phase的时刻还是为0。

UVM用户一定要注意：如果想执行一些耗费时间的代码，那么要在此phase下任意一个component中至少提起一次objection。

上述结论只适用于12个run-time的phase。对于run_phase则不适用。由于run_phase与动态运行的phase是并行运行的，如果12个动态运行的phase有objection被提起，那么run_phase根本不需要raise_objection就可以自动执行，代码如下：

文件：src/ch5/section5.2/5.2.1/objection1/my_case0.sv
14 task my_case0::main_phase(uvm_phase phase);
15   phase.raise_objection(this);
16   #100;
17   phase.drop_objection(this);
18 endtask
19 20 task my_case0::run_phase(uvm_phase phase);
21   for(int i = 0; i < 9; i++) begin
22     #10;
23     `uvm_info("case0", "run_phase is executed", UVM_LOW)
24   end
25 endtask

在上述代码运行结果中，可以看到“run_phase is executed”被输出了9次。反之，如果上述run_phase与main_phase中的内容互换：

文件：src/ch5/section5.2/5.2.1/objection2/my_case0.sv
14 task my_case0::main_phase(uvm_phase phase);
15   for(int i = 0; i < 9; i++) begin
16     #10;
17     `uvm_info("case0", "main_phase is executed", UVM_LOW)
18   end
19 endtask
20 21 task my_case0::run_phase(uvm_phase phase);
22   phase.raise_objection(this);
23   #100;
24   phase.drop_objection(this);
25 endtask

由运行结果中可以看到，没有任何“main_phase is executed”输出。因此对于run_phase来说，有两个选择可以使其中的代码运行：

第一是其他动态运行的phase中有objection被提起。在这种情况下，运行时间受其他动态运行phase中objection控制，run_ phase只能被动地接受。

第二是在run_phase中raise_objection。这种情况下运行时间完全受run_phase控制。

component、phase与objection是UVM运行的基础，其相互关系也是比较难以理解的。如果读者看了上面的例子依然对这三者的关系很迷惑，那么可以参照接下来这个有趣的例子。

如图5-4所示为一个env与model、scb组成的大楼，每一层就是一个phase（为了方便起见，图中并没有将12个动态运行的phase全部列出，而只列出了reset_phase等4个phase）。这个建筑物的每一层都有三个房间，

其中最外层最大的就是env，而其中又包含了model与scb两个房间，换句话说，由于env是model和scb的父结点，所以model与scb房间其实是房中房。在env、model、scb三个房间中，分别有一个历史遗留的井run_phase（OVM遗留的），可以直通楼顶。

在每层的每个房间及各个房间的井中，都有可能存在着僵尸（objection）及需要通电才能运转的机器（在每个phase中写的代码）。整大楼处于断电的状态。

有一棵叫UVM的植物，在经历start_of_simulation_phase之后，于0时刻进入到最顶层（12层）：pre_reset_phase。

在进入后，它首先为本层所有房间及所有井（run_phase）通电，如果房间及井中有机器，那么这些机器就会运转起来。

这棵植物在通电完毕后开始检测各个房间中有没有僵尸（是否raise_objection），如果任意一个房间中有僵尸，那么就开始消灭这些僵尸，一直到所有僵尸消失（drop_objection）。

当所有的僵尸被消灭后，它就断掉这一层各个房间的电，所有正在运转的机器将会停止运转，然后这棵UVM植物进入下一层。需要注意的是，它只断掉所有房间的电，而没有断掉所有的井（run_phase）中的电，所以各个井中如果有机器，那么它们依然在正常运转。

如果所有的房间中都没有僵尸，那么它直接断电并进入下一层，在这种情况下，所有的机器只发出一声轰鸣声，便被紧急终止了。这棵UVM植物一层一层地消灭僵尸，一直到消灭完底层post_shutdown_phase中的僵尸。

此时，12个动态运行phase全部结束，它们中的僵尸全部被消灭完毕。这棵UVM植物并不是立即进入到extract_phase，而是开始查看所有的井（run_phase）中是否有僵尸，如果有那么就开始消灭它们，一直到所有的僵尸消失，否则直接断掉井中的电，所有井中正在运转的机器停止运转。当run_phase中的僵尸也被消灭完毕后，开始进入extract_phase。

所以，欲使每一层中的机器（代码）运转起来，只要在这一层的任何一个房间（任意一个component）中加入一个僵尸（raise_objection）即可。如果僵尸永远不能消失（phase.raise_objection与phase.drop_objection之间是一个无限循环），那么就会一直停留在这一层。

2 参数phase的必要性

在UVM中所有phase的函数/任务参数中，都有一个phase：

task main_phase(uvm_phase phase);

这个输入参数中的phase是什么意思？为什么要加入这样一个东西？看了上一小节的例子，应该能够回答这个问题了。因为要便于在任何component的main_phase中都能raise_objection，而要raise_objection则必须通过phase.raise_objection来完成，所以必须将phase作为参数传递到main_phase等任务中。

可以想象，如果没有这个phase参数，那么想要提起一个objection就会比较麻烦了。

这里比较有意思的一个问题是：类似build_phase等function phase是否可以提起和撤销objection呢？

文件：src/ch5/section5.2/5.2.2/my_case0.sv
35 function void my_case0::build_phase(uvm_phase phase);
36   phase.raise_objection(this);
37   super.build_phase(phase);
38   phase.drop_objection(this);
39 endfunction

运行上述代码后系统并不会报错。不过，一般不会这么用。phase的引入是为了解决何时结束仿真的问题，它更多面向main_phase等task phase，而不是面向function phase。

3 控制objection的最佳选择

在整棵UVM树中，树的结点是如此之多，那么在什么地方控制objection最合理呢？driver中、monitor中、agent中、scoreboard中抑或是env中？

在第2章的例子中，最初是在driver中raise_objection，但是事实上，在driver中raise_objection的时刻并不多。这是因为driver中通常都是一个无限循环的代码，如下所示：

task driver::main_phase(uvm_phase phase);
  while(1) begin
    seq_item_port.get_next_item(req);
    …//drive the interface according to the information in req
  end
endtask

如果是在while(1)的前面raise_objection，在while循环的end后面drop_objection：

task driver::main_phase(uvm_phase phase);
  phase.raise_objection(this);
  while(1) begin
    seq_item_port.get_next_item(req);
    …//drive the interface according to the information in req
  end
  phase.drop_objection(this);
endtask

由于无限循环的特性，phase.drop_objection永远不会被执行到。

一种常见的思维是将raise_objection放在get_next_item之后，这样的话，就可以避免无限循环的问题：

task driver::main_phase(uvm_phase phase);
  while(1) begin
    seq_item_port.get_next_item(req);
    phase.raise_objection(this);
    …//drive the interface according to the information in req
    phase.drop_objection(this);
  end
endtask

但是关键问题是如果其他地方没有raise_objection的话，那么如前面所言，UVM不等get_next_item执行完成就已经跳转到了post_main_phase。

在monitor和reference model中，都有类似的情况，它们都是无限循环的。因此一般不会在driver和monitor中控制objection。

一般来说，在一个实际的验证平台中，通常会在以下两种objection的控制策略中选择一种：

第一种是在scoreboard中进行控制。在2.3.6节中，scoreboard的main_phase被做成一个无限循环。如果要在scoreboard中控制objection，则需要去除这个无限循环，通过config_db::set的方式设置收集到的transaction的数量pkt_num，当收集到足够数量的transaction后跳出循环：

task my_scoreboard::main_phase(uvm_phase phase);
  phase.raise_objection(this);
  fork
    while (1) begin
      exp_port.get(get_expect);
      expect_queue.push_back(get_expect);
  end
  for(int i = 0; i < pkt_num; i++) begin
    act_port.get(get_actual);
    …
  end
join_any
phase.drop_objection(this);
endtask

上述代码中将原本的fork…join语句改为了fork…join_any。当收集到足够的transaction后，第二个进程终结，从而跳出fork…join_any，执行drop_objection语句。

第二种，如在第2章中介绍的例子那样，在sequence中提起sequencer的objection，当sequence完成后，再撤销此objection。

以上两种方式在验证平台中都有应用。其中用得最多的是第二种，这种方式是UVM提倡的方式。 UVM的设计哲学就是全部由sequence来控制激励的生成，因此一般情况下只在sequence中控制objection。

4 set_drain_time的使用

无论任何功能的模块，都有其处理延时。如图5-5a所示，0时刻DUT开始接收输入，直到p时刻才有数据输出。

在sequence中，n时刻发送完毕最后一个transaction，如果此时立刻drop_objection，那么最后在n+p时刻DUT输出的包将无法接收到。

因此，在sequence中，最后一个包发送完毕后，要延时p时间才能drop_objection：

在sequence中，n时刻发送完毕最后一个transaction，如果此时立刻drop_objection，那么最后在n+p时刻DUT输出的包将无法接收到。

因此，在sequence中，最后一个包发送完毕后，要延时p时间才能drop_objection：

virtual task body();
  if(starting_phase != null)
    starting_phase.raise_objection(this);
  repeat (10) begin
    `uvm_do(m_trans)
  end
  #100;
  if(starting_phase != null)
    starting_phase.drop_objection(this);
endtask

UVM为所有的objection设置了drain_time这一属性。所谓drain_time，用5.2.1节中最后的例子来说，就是当所有的僵尸都被消灭后，UVM植物并不马上进入下一层，而是等待一段时间，在这段时间内，那些正在运行的机器依然在正常地运转，时间一到才会进入下一层。drain_time的设置方式为：

文件：src/ch5/section5.2/5.2.4/base_test.sv
24 task base_test::main_phase(uvm_phase phase);
25   phase.phase_done.set_drain_time(this, 200);
26 endtask

phase_done是uvm_phase内定义的一个成员变量：

来源：UVM源代码
uvm_objection phase_done; // phase done objection

当调用phase.raise_objection或者phase.drop_objection时，其实质是调用phase_done的raise_objection和drop_objection。

当UVM在main_phase检测到所有的objection被撤销后，接下来会检查有没有设置drain_time。

如果没有设置，则马上进入到post_main_phase，否则延迟drain_time后再进入post_main_phase。

如果在post_main_phase及其后都没有提起objection，那么最终会前进到final_phase，结束仿真。

5 objection的调试

与phase的调试一样，UVM同样提供了命令行参数来进行objection的调试：

<sim command> +UVM_OBJECTION_TRACE

对上一节的例子加入此命令行参数后的部分输出如下：

# UVM_INFO @ 0: main_objection [OBJTN_TRC] Object uvm_test_top.env.i_agt.sqr.
case0_sequence raised 1 objection(s): count=1  total=1
# UVM_INFO @ 10000: main_objection [OBJTN_TRC] Object uvm_test_top.env.i_agt.
sqr.case0_sequence dropped 1 objection(s): count=0  total=0

在调用raise_objection时，count=1表示此次只提起了这一个objection。可以使用如下的方式一次提起两个objection：

文件：src/ch5/section5.2/5.2.5/my_case0.sv
10   virtual task body();
11     if(starting_phase != null)
12       starting_phase.raise_objection(this, "case0 objection", 2);
13     #10000;
14     if(starting_phase != null)
15       starting_phase.drop_objection(this, "case0 objection", 2);
16   endtask

raise_objection的第二个参数是字符串，可以为空，第三个参数为objection的数量。drop_objection的后两个参数与此类似。

此时，加入UVM_OBJECTION_TRACE命令行参数的输出结果变为：

# UVM_INFO @ 0: main_objection [OBJTN_TRC] Object uvm_test_top.env.i_agt.sqr.
case0_sequence raised 2 objection(s) (case0 objection): count=2  total=2
# UVM_INFO @ 10000: main_objection [OBJTN_TRC] Object uvm_test_top.env.i_agt.
sqr.case0_sequence dropped 2 objection(s) (case0 objection): count=0  total=0

除了上述有用信息外，还会输出一些冗余的信息：

# UVM_INFO @ 0: main_objection [OBJTN_TRC] Object uvm_test_top.env.i_agt.sqr
added 2 objection(s) to its total (raised from source object , case0 objection):
count=0  total=2
# UVM_INFO @ 0: main_objection [OBJTN_TRC] Object uvm_test_top.env.i_agt added
2 objection(s) to its total (raised from source object , case0 objection): count=0
total=2
…
# UVM_INFO @ 10000: main_objection [OBJTN_TRC] Object uvm_test_top.env.i_agt.
sqr subtracted 2 objection(s) from its total (dropped from source object , case0
objection): count=0  total=0
# UVM_INFO @ 10000: main_objection [OBJTN_TRC] Object uvm_test_top.env.i_
agt subtracted 2 objection(s) from its total (dropped from source object , case0
objection): count=0  total=0

这是因为UVM采用的是树形结构来管理所有的objection。当有一个objection被提起后，会检查从当前component一直到最顶层的uvm_top的objection的数量。

上述输出结果中的total就是整个验证平台中所有活跃的（被提起且没有被撤销的）objection的数量。