UVM：phase机制

在Systemverilog搭建的平台中&＃xff0c;还记得每个组件都需要有个task run();吗&＃xff0c;该方法用于启动仿真&＃xff0c;同时由test控制仿真的结束。而UVM提供了一套仿真运行规范&＃xff0c;所有由UVM搭建的testbench都要在该规范下运行仿真。

主要介绍整个UVM框架的构建过程和testbench仿真过程

UVM框架的产生和运行&＃xff0c;全部从testbench中的一句run_test("my_test");开始&＃xff0c;那么这一句子程序内部到底发生了什么呢&＃xff1f;&＃xff0c;这是本文的主要内容。

run_test("my_test");中的"my_test"是用户uvm_test扩展来的自定义test。
当然也可以写成run_test("");在仿真时在transcript写道&＃43;UVM_TESTNAME &＃61;my_test指定要运行的test
例如在questasim的transcript写vsim -novopt work.tb -classdebug &＃43;UVM_TESTNAME&＃61;my_test&＃xff0c;等价于run_test(my_test);

1.1. uvm_test_top的例化

第一件事很简单&＃xff0c;UVM树的树根——uvm_root类对象uvm_top创建my_test类对象uvm_test_top。

uvm_test_top是my_test类对象&＃xff0c;UVM自动取的无法改变。

uvm_top是uvm_pkg就已经存在的静态对象&＃xff0c;可对tb作全局控制。

所以在仿真中&＃xff0c;uvm_top没有创建时间&＃xff0c;uvm_test_top、env等component均是在0时刻创建

上源码

tb中的run_test("my_test");实际在执行

//...\questasim64_2020.1\verilog_src\uvm-1.2\src\base\uvm_globals.svh
task run_test (string test_name&＃61;"");uvm_root top; //uvm_top例化uvm_coreservice_t cs;cs &＃61; uvm_coreservice_t::get();top &＃61; cs.get_root();top.run_test(test_name);
endtask


可见在本质上是在执行uvm_root::run_test("my_test");

//...\questasim64_2020.1\verilog_src\uvm-1.2\src\base\uvm_root.svh
task uvm_root::run_test(string test_name&＃61;"");uvm_report_server l_rs;uvm_coreservice_t cs &＃61; uvm_coreservice_t::get(); uvm_factory factory &＃61; cs.get_factory(); //例化全局唯一factory...uvm_component uvm_test_top; ...$cast(uvm_test_top, factory.create_component_by_name(test_name,"", "uvm_test_top", null)); //例化my_test类对象uvm_test_top...fork begin...uvm_phase::m_run_phases(); //运行所有组件的phase方法endjoin_none#0;...wait (m_phase_all_done &＃61;&＃61; 1); //等待所有phase执行完毕...l_rs &＃61; uvm_report_server::get_server();l_rs.report_summarize(); //报告总结if (finish_on_completion)$finish; //全部运行结束后&＃xff0c;结束仿真endtask


注意若component的parent设为null&＃xff0c;UVM将自动将其作为uvm_top的子组件

所以接下来将关注点聚焦到uvm_phase::m_run_phases();&＃xff0c;这就是UVM的phase机制

1.2. 9大phase

UVM中引入phase机制能够更加清晰地实现UVM树的层次例化&＃xff0c;同时将仿真过程层次化。

具体而言&＃xff0c;uvm_top从时间和空间两个维度规定了执行顺序。时间上&＃xff0c;仿真时不同phase按照某种时间顺序&＃xff0c;顺序执行。空间上&＃xff0c;仿真时同一phase不同组件按照某种层次顺序执行。

这一切都是UVM自动完成的。不同时间&＃xff0c;做不同的事情&＃xff0c;这就是UVM的phase哲学

phase流程如下图所示顺序执行&＃xff0c;注意function不消耗仿真时间&＃xff0c;#0时刻立即返回结果&＃xff1b;task可消耗仿真时间&＃xff1b;且各phase之间是顺序执行的

即一定是先例化uvm_top&＃xff0c;之后例化uvm_test_top&＃xff0c;之后全部component按照一定顺序实现build_phase之后&＃xff0c;全部component再按照一定顺序实现connect_phase()等等&＃xff0c;直到最终的$finish();

也就是说phase执行结束之后立即结束仿真。

initial begin run_test("my_test");uvm_report_info("tb","simulation finished",UVM_LOW); //此句不执行&＃xff01;
end


所有phase中只有run_phase();是task任务&＃xff0c;可消耗时间&＃xff0c;其他方法均为function 不能消耗时间&＃xff0c;立即返回结果。

每个phase的功能如下表所示

build_phase

最常见的就是子component的实例化&＃xff0c;如果将实例化放在其他phase就会报错。

由于build_phase决定了tb中各component的例化&＃xff0c;因此必须按照一定次序例化&＃xff0c;否则就会出错。

例如先执行drv.build_phase再执行i_agt.build_phase就会出错&＃xff0c;因为drv得先在i_agt.build_phase中例化。

实际上&＃xff0c;各component的build_phase顺序为自顶向下深度优先&＃xff0c;字母表顺序

其实就是深度优先遍历&＃xff0c;每向下一层选择子component是根据对象按照字母表顺序选择的&＃xff0c;而不是按照树的深度优先搜索算法每下一层都选择最左边的节点。

注意别把build_phase执行顺序跟组件例化的顺序搞混了&＃xff01;
在env::build_phase会将i_agt、mdl、scb和o_agt全部例化&＃xff0c;然后执行env.i_agt::build_phase&＃xff0c;然后执行的是env.i_agt.drv::build_phase而不是env.mdl::build_phase&＃xff0c;但是env.mdl已经例化了~~

例如下图UVM树

在执行build_phase时&＃xff0c;实际执行为

//uvm_top和uvm_test_top已经有了
//所以build_phase的执行顺序为&＃xff1a;uvm_test_top→env→i_agt→drv→mon→sqr→mdl→o_agt→mon→scb
//莫忘记super.build_phase(uvm_phase phase);
program build_phase;
begin function uvm_top.uvm_test_top.build_phase(uvm_phase phase);super.build_phase(uvm_phase phase); env &＃61; my_env::type_id::create("env",uvm_top.uvm_test_top);//...function uvm_top.uvm_test_top.env.build_phase(uvm_phase phase);super.build_phase(uvm_phase phase);i_agt &＃61; my_agent::type_id::create("i_agt",uvm_top.uvm_test_top.env);o_agt &＃61; my_agent::type_id::create("o_agt",uvm_top.uvm_test_top.env);scb &＃61; my_scoreboard::type_id::create("scb",uvm_top.uvm_test_top.env);mdl &＃61; my_model::type_id::create("mdl",uvm_top.uvm_test_top.env);//...function uvm_top.uvm_test_top.env.i_agt.build_phase(uvm_phase phase);super.build_phase(uvm_phase phase);drv &＃61; my_driver::type_id::create("drv",uvm_top.uvm_test_top.env.i_agt);mon &＃61; my_monitor::type_id::create("mon",uvm_top.uvm_test_top.env.i_agt);sqr &＃61; my_sequencer::type_id::create("sqr",uvm_top.uvm_test_top.env.i_agt);//...function uvm_top.uvm_test_top.env.i_agt.drv.build_phase(uvm_phase phase); super.build_phase(uvm_phase phase);function uvm_top.uvm_test_top.env.i_agt.mon.build_phase(uvm_phase phase);super.build_phase(uvm_phase phase);function uvm_top.uvm_test_top.env.i_agt.sqr.build_phase(uvm_phase phase);super.build_phase(uvm_phase phase);function uvm_top.uvm_test_top.env.mdl.build_phase(uvm_phase phase);super.build_phase(uvm_phase phase);function uvm_top.uvm_test_top.env.o_agt.build_phase(uvm_phase phase);super.build_phase(uvm_phase phase);mon &＃61; my_monitor::type_id::create("mon",uvm_top.uvm_test_top.env.o_agt);//...function uvm_top.uvm_test_top.env.o_agt.mon.build_phase(uvm_phase phase);super.build_phase(uvm_phase phase);function uvm_top.uvm_test_top.env.scb.build_phase(uvm_phase phase);super.build_phase(uvm_phase phase);
end
endprogram


各component例化和父节点都连好之后&＃xff0c;就可以执行别的phase了。

connect_phase

主要是各component的通信连接。

实际上除了build_phase、final_phase和run_phase&＃xff0c;其他phase的执行顺序均为自底向上

//connect_phase的执行顺序为自底向上&＃xff1a;drv→mon→mon→sqr→i_agt→mdl→o_agt→scb→env→uvm_test_top
program connect_phase;
begin function uvm_top.uvm_test_top.env.i_agt.drv.connect_phase(uvm_phase phase);function uvm_top.uvm_test_top.env.i_agt.mon.connect_phase(uvm_phase phase);function uvm_top.uvm_test_top.env.i_agt.sqr.connect_phase(uvm_phase phase);function uvm_top.uvm_test_top.env.o_agt.mon.connect_phase(uvm_phase phase);function uvm_top.uvm_test_top.env.i_agt.connect_phase(uvm_phase phase);function uvm_top.uvm_test_top.env.mdl.connect_phase(uvm_phase phase);function uvm_top.uvm_test_top.env.o_agt.connect_phase(uvm_phase phase);function uvm_top.uvm_test_top.env.scb.connect_phase(uvm_phase phase);function uvm_top.uvm_test_top.env.connect_phase(uvm_phase phase);function uvm_top.uvm_test_top.connect_phase(uvm_phase phase);
end
endprogram


start_of_simulation_phase

可用于对仿真进行设定&＃xff0c;比如set_timeout就出现FATAL之前的最大仿真时间

//...\questasim64_10.6c\verilog_src\uvm-1.2\src\base\uvm_root.svh
class uvm_root;//...extern function void set_timeout(time timeout, bit overridable&＃61;1);
endclass


run_phase

注意该phase为task型&＃xff0c;消耗仿真时间&＃xff0c;允许使用延迟、时钟等语句

run_phase执行顺序是&＃xff1a;各component全部按照fork…join并行执行

即全部的component的run_phase并行执行&＃xff0c;且待全部的component的run_phase都执行完毕后再执行function extract_phase();

program run_phase;
fork //各组件以fork...join的形式执行run_phasetask uvm_top.uvm_test_top.env.i_agt.drv.run_phase(uvm_phase phase);task uvm_top.uvm_test_top.env.i_agt.mon.run_phase(uvm_phase phase);task uvm_top.uvm_test_top.env.i_agt.sqr.run_phase(uvm_phase phase);task uvm_top.uvm_test_top.env.o_agt.mon.run_phase(uvm_phase phase);task uvm_top.uvm_test_top.env.i_agt.run_phase(uvm_phase phase);task uvm_top.uvm_test_top.env.mdl.run_phase(uvm_phase phase);task uvm_top.uvm_test_top.env.o_agt.run_phase(uvm_phase phase);task uvm_top.uvm_test_top.env.scb.run_phase(uvm_phase phase);task uvm_top.uvm_test_top.env.run_phase(uvm_phase phase);task uvm_top.uvm_test_top.run_phase(uvm_phase phase);
join
endprogram


实际上&＃xff0c;在执行run_phase;时&＃xff0c;各component还并行执行着另外12个phase&＃xff0c;即

fork run_phase;begin //下面这12个phase&＃xff0c;每个phase都是各component按照fork...join的关系执行构成的programpre_reset_phase; reset_phase; post_reset_phase;pre_configure_phase; configure_phase; post_configure_phase;pre_main_phase; main_phase; post_main_phase;pre_shutdown_phase; shutdown_phase; post_shutdown_phase; end
join


由于未来将会废除这12个phase&＃xff0c;所以此处就不展开来讲

1.4. 总结

还以上图UVM树为例&＃xff0c;总结UVM的编译顺序

begintask run_test (string test_name&＃61;""); //在testbench执行run_test(string test_name &＃61; "");来自于...\questasim64_2020.1\verilog_src\uvm-1.2\src\base\uvm_globals.svhbeginuvm_root uvm_top; //例化uvm_root类对象uvm_top//...task uvm_top.run_test(test_name);beginuvm_factory factory &＃61; cs.get_factory(); //例化全局唯一factory//...$cast(uvm_test_top, factory.create_component_by_name(test_name,"", "uvm_test_top", null)); //例化string(test_name)类对象uvm_test_top并设定uvm_test_top.parent &＃61; null;表示uvm_test_top是uvm_top的子组件//...task uvm_phase::m_run_phases(); //启动phasebegin//...build_phase;connect_phase;end_of_elaboration_phase;start_of_simulation_phase;run_phase;extract_phase;check_phase;report_phase;final_phase;$finish();endend endend

2. run_phase的objection 机制

所有的phase中只有run_phase可占用仿真时间&＃xff0c;所有run_phase决定着何时结束仿真&＃xff0c;那么run_phase应该运行多久呢&＃xff1f;UVM使用且只使用objection机制控制仿真的结束。

objection机制很简单&＃xff0c;当testbench进入run_phase阶段后&＃xff0c;即所有component执行run_phase();方法时&＃xff0c;至少有一个component挂起objection&＃xff0c;则开始消耗仿真时间&＃xff0c;直到所有的component全部落下objection&＃xff0c;则进入extract_phase

也就是说所有的component都落下objection时&＃xff0c;或者是run_phase阶段没有任何component在消耗仿真时间语句前挂起objection&＃xff0c;则只执行到第一个消耗时间的语句前&＃xff0c;立即进入extract_phase。

只有挂起了objection的才能够落下objection&＃xff0c;挂起objection的方法为phase.raise_objection(this);&＃xff0c;落下objection的方法为phase.drop_objection(this);

举个例子

class my_test extends uvm_test;...task run_phase(uvm_phase phase);uvm_report_info("my_test","first code wasting no time",UVM_LOW);#1ps;phase.raise_objection(this);uvm_report_info("my_test","after raise",UVM_LOW);#1us;uvm_report_info("my_test","before drop",UVM_LOW);phase.drop_objection(this);endtask
endclass


上述代码中run_phase执行第一句不消耗时间的语句uvm_report_info("my_test","first code wasting no time",UVM_LOW);之后遇到#1ps;&＃xff0c;发现消耗时间但还没有提起objection&＃xff0c;如果此时其他component和sequence都不拉起objection&＃xff0c;UVM会退出run_phase并进入extract_phase

2.1. 在virtual task sequence::body();中使用objection 机制

此处介绍UVM中经常怎么使用objection机制。

run_phase中主要工作就是提供激励、监测数据、检测数据等等&＃xff0c;所以激励决定着仿真的开始和结束&＃xff0c;当激励消失之后就可以落下objection了。

而控制transaction的产生和发送请求的是sequence&＃xff0c;sequencer只负责sequence和driver之间的握手。

但是sequence来自于uvm_object&＃xff0c;而uvm_object并没有build_phase、connect_phase、run_phase等的方法&＃xff0c;那sequence如何使用objection机制呢&＃xff1f;

实际上uvm_sequence类是继承于uvm_sequence_base类的&＃xff0c;uvm_sequence_base类有uvm_phase类的starting_phase属性可用来控制objection机制。源码如下

//...\questasim64_2020.1\verilog_src\uvm-1.2\src\seq\uvm_sequence.svh
virtual class uvm_sequence #(type REQ &＃61; uvm_sequence_item,type RSP &＃61; REQ) extends uvm_sequence_base;//...\questasim64_2020.1\verilog_src\uvm-1.2\src\seq\uvm_sequence_base.svh
class uvm_sequence_base extends uvm_sequence_item;...&＃96;ifdef UVM_DEPRECATED_STARTING_PHASEuvm_phase starting_phase; //uvm_phase属性&＃xff0c;可用于在sequence中使用objection机制bit m_warn_deprecated_set;&＃96;endif ...virtual task body();virtual task start (uvm_sequencer_base sequencer,uvm_sequence_base parent_sequence &＃61; null,int this_priority &＃61; -1,bit call_pre_post &＃61; 1); //start方法fork-join调用pre_start();、pre_body();、body()、post_body();和post_start();方法&＃xff0c;详见sequence机制...
endclass


由于virtual uvm_sequence::body()可控制transaction的例化、随机化和发送&＃xff0c;所以可在my_sequence中的body()方法中使用uvm_phase类的starting_phase对象来控制objection机制&＃xff0c;且在body()中第一句提起objection、最后一句落下objection&＃xff0c;例程如下

class case0_sequence extends uvm_sequence #(my_transaction);my_transaction m_trans;function new(string name&＃61; "case0_sequence");super.new(name);endfunction virtual task body();if(starting_phase !&＃61; null) starting_phase.raise_objection(this); //提起objectionrepeat (10) begin&＃96;uvm_do(m_trans)end#100;if(starting_phase !&＃61; null) starting_phase.drop_objection(this); //激励10次m_trans后再过#100后&＃xff0c;落下objectionendtask&＃96;uvm_object_utils(case0_sequence)
endclass


2.2. run_phase中各组件的运行

run_phase一旦启动&＃xff0c;所有的验证组件和dut会同时开始运行&＃xff0c;每个组件or模块不断地输入、处理再输出。

在每个agent中&＃xff0c;sequencer无脑地向driver发送数据&＃xff0c;每个driver不断地判断dut端口的时序&＃xff0c;一有机会就驱动dut或者接受dut数据。dut就将被驱动的数据吸收&＃xff0c;经过自身的处理&＃xff0c;从output端口发送出去。而monitor就不断地将这些有用的数据记录下来&＃xff0c;发送给refmod或scoreboard。refmod则不断地计算预期数据&＃xff0c;算完了就发给scoreboard&＃xff0c;scoreboard就不断地判断、比对。

注意上述过程是有顺序的&＃xff01;看上去大家都在run&＃xff0c;但是每个组件都会阻塞在某一处&＃xff0c;直到开放。

我们从transaction的历程来分析整个testbench的运行

transaction 的旅程

如下图所示&＃xff0c;红色箭头和红色字体表示transaction的阻塞性运动方向和方法&＃xff0c;绿色箭头和绿色字体表示transaction的非阻塞性运动方向和方法。

monitor到scoreboard一般是非阻塞的uvm_analysis_port#(T)::write(T t)方法
refmod中mailbox写成绿色put是指使用空间较大的mailbox

可以看到run_phase开启时&＃xff0c;每个component阻塞在朝向它的箭头&＃xff0c;driver阻塞在get_next_item(req)上&＃xff0c;monitor阻塞在&＃64;(posedge clk iff..)&＃xff08;需要向dut驱动transaction以达到采样条件&＃xff09;&＃xff0c;refmod阻塞在从Master_monitor的FIFO中进行uvm_blocking_get_port#(T)::get(T t)上&＃xff0c;scoreboard阻塞在从refmod的mailbox进行get和从Slave monitor的FIFO中进行uvm_blocking_get_port#(T)::get(T t)上。

而这一切都取决从sequence的uvm_do_on_with()发起第一个req开始一个一个解除阻塞

monitor与scoreboard之间的数据丢失问题

思考下面几个问题

● 第一个问题&＃xff1a;scoreboard收到的数据&＃xff0c;是不是都是同一次的&＃xff1f;

就是说&＃xff0c;一个dut至少有一个输入和输出吧&＃xff08;其实就是Master agent和Slave agent&＃xff09;&＃xff0c;那master monitor向scoreboard发送监测到的数据&＃xff0c;slave monitor也发&＃xff0c;那么scoreboard每次get到的数据都是同一次的嘛&＃xff1f;

一般来说&＃xff0c;是的。因为monitor一定是按照先后顺序向scoreboard发送数据的&＃xff0c;顺序一定可以保证。

● 第二个问题&＃xff1a;有没有可能monitor遗漏总线数据

一般不会&＃xff0c;这个取决于refmod和scoreboard之间通信FIFO大小、以及dut输出的速度。

先说明&＃xff0c;对于dut来说&＃xff0c;一般是每一拍发一个数据&＃xff0c;而且虽然refmod里计算理想数据和scoreboard作数据比对都是task任务&＃xff0c;可以消耗仿真时间。

但是scoreboard计算和refmod的计算的耗时一般为0&＃xff0c;一般不会耗时&＃xff0c;不会出现refmod和scoreboard拿到trans了还阻塞了多于一个clk的情况。

那么什么时候monitor会遗漏总线数据呢&＃xff1f;

试想这么一种情况&＃xff0c;从master给dut每拍灌数据&＃xff0c;每个输入得经过1000000拍之后&＃xff0c;dut的slave那端才输出数据。

refmod算完理想数据之后&＃xff0c;就会给scoreboard&＃xff0c;如果这俩component之间通信的FIFO大小为1&＃xff0c;或者仅仅是传递个参数。

那么scoreboard确实会按时收到refmod发来的数据&＃xff0c;但是slave monitor人家不给数据啊&＃xff0c;所以scoreboard无法进行数据比对&＃xff0c;会一直阻塞。

这样的话要么&＃xff0c;refmod阻塞、master monitor阻塞&＃xff0c;开始丢数。要么refmod阻塞&＃xff0c;master monitor write来的数丢失。要么refmod给scoreboard的参数不断被覆盖。

总结下来就是阻塞链条&＃xff1a;dut不输出→scb阻塞→refmod阻塞→master_agent.monitor阻塞→master_agent.driver不阻塞&＃xff0c;monitor丢数

但是要注意&＃xff0c;一定不会存在slave monitor丢失数据的情况&＃xff0c;除非refmod和scoreboard拿了trans之后卡死&＃xff0c;然而刚才讲到这个不可能

● 第三个问题&＃xff1a;如何保证不会遗漏总线数据&＃xff1f;用阻塞且size大于1的FIFO

上述阻塞链条中有一个环节解决了&＃xff0c;后面就全解决了。可以考虑的点在“refmod阻塞”和“monitor阻塞”这两个环节&＃xff0c;解决其中之一就OK。

refmod阻塞是因为scb不从refmod这里拿数&＃xff0c;所以阻塞&＃xff0c;那么就可以使用一个空间较大的FIFO作为refmod和scb之间的缓冲器。

monitor阻塞是因为向refmod发数发不进去&＃xff0c;所以也是使用一个空间较大的FIFO即可。

注意了&＃xff0c;一定要用阻塞FIFO。考虑一下用队列行不行&＃xff1f;
用队列不可以&＃xff01;pop_front()方法是非阻塞的&＃xff01;即使队列为空pop_front()也能给你返回个默认值出来。
非阻塞的问题在于&＃xff0c;你怎么确定是scb先pop_front()还是refmod先push_back()&＃xff1f;是refmod先pop_front()还是monitor先push_back()&＃xff1f;
万一pop_front()先于push_back()&＃xff0c;那就不可以了。