本节书摘来自华章社区《UVM实战》一书中的第2章，第2.4节UVM的终极大作：sequence，作者 张 强，更多章节内容可以访问云栖社区“华章社区”公众号查看
2.4 UVM的终极大作：sequence
2.4.1 在验证平台中加入sequencer
sequence机制用于产生激励，它是UVM中最重要的机制之一。在本书前面所有的例子中，激励都是在driver中产生的，但是在一个规范化的UVM验证平台中，driver只负责驱动transaction，而不负责产生transaction。sequence机制有两大组成部分，一是sequence，二是sequencer。本节先介绍如何在验证平台中加入sequencer。一个sequencer的定义如下：
代码清单 2-58
4 class my_sequencer extends uvm_sequencer #(my_transaction);
5
6 function new(string name, uvm_component parent);
7 super.new(name, parent);
8 endfunction
9
10 `uvm_component_utils(my_sequencer)
11 endclass
sequencer的定义非常简单，派生自uvm_sequencer，并且使用uvm_component_utils宏来注册到factory中。uvm_sequencer是一个参数化的类，其参数是my_transaction，即此sequencer产生的transaction的类型。
sequencer产生transaction，而driver负责接收transaction。在前文的例子中，定义my_driver时都是直接从uvm_driver中派生：
代码清单 2-59
class my_driver extends uvm_driver;
但实际上，这种定义方法并不多见，由于uvm_driver也是一个参数化的类，应该在定义driver时指明此driver要驱动的transaction的类型：
代码清单 2-60
文件：src/ch2/section2.4/2.4.1/my_driver.sv
3 class my_driver extends uvm_driver#(my_transaction);
这样定义的好处是可以直接使用uvm_driver中的某些预先定义好的成员变量，如uvm_driver中有成员变量req，它的类型就是传递给uvm_driver的参数，在这里就是my_transaction，可以直接使用req：
代码清单 2-61
22 task my_driver::main_phase(uvm_phase phase);
23 phase.raise_objection(this);
24 vif.data <= 8'b0;
25 vif.valid <= 1'b0;
26 while(!vif.rst_n)
27 @(posedge vif.clk);
28 for(int i = 0; i < 2; i++) begin
29 req = new("req");
30 assert(req.randomize() with {pload.size == 200;});
31 drive_one_pkt(req);
32 end
33 repeat(5) @(posedge vif.clk);
34 phase.drop_objection(this);
35 endtask
这里依然是在driver中产生激励，下一节中将会把激励产生的功能从driver中移除。
在完成sequencer的定义后，由于sequencer与driver的关系非常密切，因此要把其加入agent中：
代码清单 2-62
4 class my_agent extends uvm_agent ;
5 my_sequencer sqr;
6 my_driver drv;
7 my_monitor mon;
8
9 uvm_analysis_port #(my_transaction) ap;
…
19 endclass
20
21
22 function void my_agent::build_phase(uvm_phase phase);
23 super.build_phase(phase);
24 if (is_active == UVM_ACTIVE) begin
25 sqr = my_sequencer::type_id::create("sqr", this);
26 drv = my_driver::type_id::create("drv", this);
27 end
28 mon = my_monitor::type_id::create("mon", this);
29 endfunction
30
31 function void my_agent::connect_phase(uvm_phase phase);
32 super.connect_phase(phase);
33 ap = mon.ap;
34 endfunction在加入sequencer后，整个UVM树的结构变成如图2-9所示的形式。
2.4.2 sequence机制
在加入sequencer后，整棵UVM树如图2-9所示，验证平台如图2-2所示，是一个完整的验证平台。但是在这个验证平台框图中，却找不到sequence的位置。相对于图2-2所示的验证平台来说，sequence处于一个比较特殊的位置，如图2-10所示。
sequence不属于验证平台的任何一部分，但是它与sequencer之间有密切的联系，这点从二者的名字就可以看出来。只有在sequencer的帮助下，sequence产生出的transaction才能最终送给driver；同样，sequencer只有在sequence出现的情况下才能体现其价值，如果没有sequence，sequencer就几乎没有任何作用。sequence就像是一个弹夹，里面的子弹是transaction，而sequencer是一把枪。弹夹只有放入枪中才有意义，枪只有在放入弹夹后才能发挥威力。
除了联系外，sequence与sequencer还有显著的区别。从本质上来说，sequencer是一个uvm_component，而sequence是一个uvm_object。与my_transaction一样，sequence也有其生命周期。它的生命周期比my_transaction要更长一些，其内的transaction全部发送完毕后，它的生命周期也就结束了。这就好比一个弹夹，其里面的子弹用完后就没有任何意义了。因此，一个sequence应该使用uvm_object_utils宏注册到factory中：
代码清单 2-63
4 class my_sequence extends uvm_sequence #(my_transaction);
5 my_transaction m_trans;
6
7 function new(string name= "my_sequence");
8 super.new(name);
9 endfunction
10
11 virtual task body();
12 repeat (10) begin
13 `uvm_do(m_trans)
14 end
15 #1000;
16 endtask
17
18 `uvm_object_utils(my_sequence)
19 endclass
每一个sequence都应该派生自uvm_sequence，并且在定义时指定要产生的transaction的类型，这里是my_transaction。每一个sequence都有一个body任务，当一个sequence启动之后，会自动执行body中的代码。在上面的例子中，用到了一个全新的宏：uvm_do。这个宏是UVM中最常用的宏之一，它用于：①创建一个my_transaction的实例m_trans；
②将其随机化；③最终将其送给sequencer。如果不使用uvm_do宏，也可以直接使用start_item与finish_item的方式产生transaction，6.3.4节将讲述这种方式。对于初学者来说，使用uvm_do宏即可。
一个sequence在向sequencer发送transaction前，要先向sequencer发送一个请求，sequencer把这个请求放在一个仲裁队列中。作为sequencer，它需做两件事情：第一，检测仲裁队列里是否有某个sequence发送transaction的请求；第二，检测driver是否申请transaction。
1）如果仲裁队列里有发送请求，但是driver没有申请transaction，那么sequencer将会一直处于等待driver的状态，直到driver申请新的transaction。此时，sequencer同意sequence的发送请求，sequence在得到sequencer的批准后，产生出一个transaction并交给sequencer，后者把这个transaction交给driver。
2）如果仲裁队列中没有发送请求，但是driver向sequencer申请新的transaction，那么sequencer将会处于等待sequence的状态，一直到有sequence递交发送请求，sequencer马上同意这个请求，sequence产生transaction并交给sequencer，最终driver获得这个transaction。
3）如果仲裁队列中有发送请求，同时driver也在向sequencer申请新的transaction，那么将会同意发送请求，sequence产生transaction并交给sequencer，最终driver获得这个transaction。
driver如何向sequencer申请transaction呢？在uvm_driver中有成员变量seq_item_port，而在uvm_sequencer中有成员变量seq_item_export，这两者之间可以建立一个“通道”，通道中传递的transaction类型就是定义my_sequencer和my_driver时指定的transaction类型，在这里是my_transaction，当然了，这里并不需要显式地指定“通道”的类型，UVM已经做好了。在my_agent中，使用connect函数把两者联系在一起：
代码清单 2-64
31 function void my_agent::connect_phase(uvm_phase phase);
32 super.connect_phase(phase);
33 if (is_active == UVM_ACTIVE) begin
34 drv.seq_item_port.connect(sqr.seq_item_export);
35 end
36 ap = mon.ap;
37 endfunction
当把二者连接好之后，就可以在driver中通过get_next_item任务向sequencer申请新的transaction：
代码清单 2-65
22 task my_driver::main_phase(uvm_phase phase);
23 vif.data <= 8'b0;
24 vif.valid <= 1'b0;
25 while(!vif.rst_n)
26 @(posedge vif.clk);
27 while(1) begin
28 seq_item_port.get_next_item(req);
29 drive_one_pkt(req);
30 seq_item_port.item_done();
31 end
32 endtask在如上的代码中，一个最显著的特征是使用了while(1)循环，因为driver只负责驱动transaction，而不负责产生，只要有transaction就驱动，所以必须做成一个无限循环的形式。这与monitor、reference model和scoreboard的情况非常类似。
通过get_next_item任务来得到一个新的req，并且驱动它，驱动完成后调用item_done通知sequencer。这里为什么会有一个item_done呢？当driver使用get_next_item得到一个transaction时，sequencer自己也保留一份刚刚发送出的transaction。当出现sequencer发出了transaction，而driver并没有得到的情况时，sequencer会把保留的这份transaction再发送出去。那么sequencer如何知道driver是否已经成功得到transaction呢？如果在下次调用get_next_item前，item_done被调用，那么sequencer就认为driver已经得到了这个transaction，将会把这个transaction删除。换言之，这其实是一种为了增加可靠性而使用的握手机制。
在sequence中，向sequencer发送transaction使用的是uvm_do宏。这个宏什么时候会返回呢？uvm_do宏产生了一个transaction并交给sequencer，driver取走这个transaction后，uvm_do并不会立刻返回执行下一次的uvm_do宏，而是等待在那里，直到driver返回item_done信号。此时，uvm_do宏才算是执行完毕，返回后开始执行下一个uvm_do，并产生新的transaction。
在实现了driver后，接下来的问题是：sequence如何向sequencer中送出transaction呢？前面已经定义了sequence，只需要在某个component（如my_sequencer、my_env）的main_phase中启动这个sequence即可。以在my_env中启动为例：
代码清单 2-66
48 task my_env::main_phase(uvm_phase phase);
49 my_sequence seq;
50 phase.raise_objection(this);
51 seq = my_sequence::type_id::create("seq");
52 seq.start(i_agt.sqr);
53 phase.drop_objection(this);
54 endtask
首先创建一个my_sequence的实例seq，之后调用start任务。start任务的参数是一个sequencer指针，如果不指明此指针，则sequence不知道将产生的transaction交给哪个sequencer。
这里需要引起关注的是objection，在UVM中，objection一般伴随着sequence，通常只在sequence出现的地方才提起和撤销objection。如前面所说，sequence是弹夹，当弹夹里面的子弹用光之后，可以结束仿真了。
也可以在sequencer中启动sequence：
代码清单 2-67
task my_sequencer::main_phase(uvm_phase phase);
my_sequence seq;
phase.raise_objection(this);
seq = my_sequence::type_id::create("seq");
seq.start(this);
phase.drop_objection(this);
endtask
在sequencer中启动与在my_env中启动相比，唯一区别是seq.start的参数变为了this。
另外，在代码清单2-65的第28行使用了get_next_item。其实，除get_next_item之外，还可以使用try_next_item。get_next_item是阻塞的，它会一直等到有新的transaction才会返回；try_next_item则是非阻塞的，它尝试着询问sequencer是否有新的transaction，如果有，则得到此transaction，否则就直接返回。
使用try_next_item的driver的代码如下：
代码清单 2-68
task my_driver::main_phase(uvm_phase phase);
vif.data <= 8'b0;
vif.valid <= 1'b0;
while(!vif.rst_n)
@(posedge vif.clk);
while(1) begin
seq_item_port.try_next_item(req);
if(req == null)
@(posedge vif.clk);
else begin
drive_one_pkt(req);
seq_item_port.item_done();
end
end
endtask相比于get_next_item，try_next_item的行为更加接近真实driver的行为：当有数据时，就驱动数据，否则总线将一直处于空闲状态。
2.4.3 default_sequence 的使用
在上一节的例子中，sequence是在my_env的main_phase中手工启动的，作为示例使用这种方式足够了，但是在实际应用中，使用最多的还是通过default_sequence的方式启动sequence。
使用default_sequence的方式非常简单，只需要在某个component（如my_env）的build_phase中设置如下代码即可：
代码清单 2-69
19 virtual function void build_phase(uvm_phase phase);
20 super.build_phase(phase);
…
30 uvm_config_db#(uvm_object_wrapper)::set(this,
31 "i_agt.sqr.main_phase",
32 "default_sequence",
33 my_sequence::type_id::get());
34
35 endfunction这是除了在top_tb中通过config_db设置virtual interface后再一次用到config_db的功能。与在top_tb中不同的是，这里set函数的第一个参数由null变成了this，而第二个代表路径的参数则去除了uvm_test_top。事实上，第二个参数是相对于第一个参数的相对路径，由于上述代码是在my_env中，而my_env本身已经是uvm_test_top了，且第一个参数被设置为了this，所以第二个参数中就不需要uvm_test_top了。在top_tb中设置virtual interface时，由于top_tb不是一个类，无法使用this指针，所以设置set的第一个参数为null，第二个参数使用绝对路径uvm_test_top.xxx。
另外，在第二个路径参数中，出现了main_phase。这是UVM在设置default_sequence时的要求。由于除了main_phase外，还存在其他任务phase，如configure_phase、reset_phase等，所以必须指定是哪个phase，从而使sequencer知道在哪个phase启动这个sequence。
至于set的第三个和第四个参数，以及uvm_config_db#(uvm_object_wrapper)中为什么是uvm_object_wrapper而不是uvm_sequence或者其他，则纯粹是由于UVM的规定，用户在使用时照做即可。
其实，除了在my_env的build_phase中设置default_sequence外，还可以在其他地方设置，比如top_tb：
代码清单 2-70
module top_tb;
…
initial begin
uvm_config_db#(uvm_object_wrapper)::set(null,
"uvm_test_top.i_agt.sqr.main_phase",
"default_sequence",
my_sequence::type_id::get());
end
endmodule
这种情况下set函数的第一个参数和第二个参数应该改变一下。另外，还可以在其他的component里设置，如my_agent的build_phase里：
代码清单 2-71
function void my_agent::build_phase(uvm_phase phase);
super.build_phase(phase);
…
uvm_config_db#(uvm_object_wrapper)::set(this,
"sqr.main_phase",
"default_sequence",
my_sequence::type_id::get());
endfunction
只需要正确地设置set的第二个参数即可。
config_db通常都是成对出现的。在top_tb中通过set设置virtual interface，而在driver或者monitor中通过get函数得到virtual interface。那么在这里是否需要在sequencer中手工写一些get相关的代码呢？答案是否定的。UVM已经做好了这些，读者无需再把时间花在这上面。
使用default_sequence启动sequence的方式取代了上一节代码清单2-66中在sequencer的main_phase中手工启动sequence的相关语句，但是新的问题出现了：在上一节启动sequence前后，分别提起和撤销objection，此时使用default_sequence又如何提起和撤销objection呢？
在uvm_sequence这个基类中，有一个变量名为starting_phase，它的类型是uvm_phase，sequencer在启动default_sequence时，会自动做如下相关操作：
代码清单 2-72
task my_sequencer::main_phase(uvm_phase phase);
…
seq.starting_phase = phase;
seq.start(this);
…
endtask
因此，可以在sequence中使用starting_phase进行提起和撤销 objection：
代码清单 2-73
4 class my_sequence extends uvm_sequence #(my_transaction);
5 my_transaction m_trans;
…
11 virtual task body();
12 if(starting_phase != null)
13 starting_phase.raise_objection(this);
14 repeat (10) begin
15 `uvm_do(m_trans)
16 end
17 #1000;
18 if(starting_phase != null)
19 starting_phase.drop_objection(this);
20 endtask
21
22 `uvm_object_utils(my_sequence)
23 endclass从而，objection完全与sequence关联在了一起，在其他任何地方都不必再设置objection。
