讲个SystemVerilog disable语句的坑

前言

记录个使用SystemVerilog disable语句时遇到的坑，这个坑有点反直觉，以至于我当时有点不信，觉得可能是EDA仿真工具的问题。后来查看了SystemVerilog手册和使用不同EDA工具进行验证，才慢慢接受了。结论是：SystemVerilog disable block_name或task时，会把hierarchy一致的block_name或task的线程都停掉。

正文

为了阐述这个问题，先看以下代码例子：

class disable_class extends uvm_object;
    int gcnt = 10;
    function new(string name = "disable_class");        super.new(name);    endfunction : new
    task abc();        begin : thread1            $display("%m %s time[%0t] thread1 begin new", get_name(), $time);            #100ns            $display("%m %s time[%0t] thread1 end new", get_name(), $time);        end    endtask
    task main();        fork            begin : thread1                $display("%m %s time[%0t] thread1 begin", get_name(), $time);                #6ns;                $display("%m %s time[%0t] thread1 end", get_name(), $time);            end            begin : thread2                #gcnt;                disable thread1;                $display("%s time[%0t] thread2 end, %m", get_name(), $time);            end            abc();        join        $display("%s time[%0t] main task end", get_name(), $time);    endtask : main
endclass : disable_class

disable_class类中main task()使用fork…join启动了3个线程：

thread1为延迟6ns后退出；

thread2延迟gcnt时间后，使用disable把thread1停掉，至于thread2有没有机会把thread1停掉，得看变量gcnt的值。如果gcnt小于6ns，那么在执行到disable thread1语句时，thread1早就结束了。如果gcnt大于6ns，那么thread2还是可以把thread1停掉的；

thread3调用task abc()，abc()任务里面定义了名为thread1的block块，延迟100ns后退出；

测试代码如下：

disable_class dc1 = new("dc1");disable_class dc2 = new("dc2");dc1.gcnt = 2;dc2.gcnt = 8;fork    dc1.main();    dc2.main();    begin : thread1         $display("m example time[%0t] thread1 begin", $time);         #20ns         $display("%m example time[%0t] thread1 end", $time);    endjoin

disable_class类例化了两次，使用dc1和dc2句柄指向它们。dc1句柄的gcnt为2，dc2句柄的gcnt为8。然后使用fork启动了三个线程，前两个线程分别调用了dc1和dc2的main() task。第三个定义了名称thread1的block块，延迟20ns后退出。

仿真结果如下：

example_pkg::disable_class.main.thread1 dc1 time[0.000ns] thread1 beginexample_pkg::disable_class.abc.thread1 dc1 time[0.000ns] thread1 begin newexample_pkg::disable_class.main.thread1 dc2 time[0.000ns] thread1 beginexample_pkg::disable_class.abc.thread1 dc2 time[0.000ns] thread1 begin newexample_pkg::example_agent.run_phase.thread1 example time[0.000ns] thread1 begindc1 time[2.000ns] thread2 end, example_pkg::disable_class.main.thread2dc2 time[8.000ns] thread2 end, example_pkg::disable_class.main.thread2example_pkg::example_agent.run_phase.thread1 example time[20.000ns] thread1 endexample_pkg::disable_class.abc.thread1 dc1 time[100.000ns] thread1 end newdc1 time[100.000ns] main task endexample_pkg::disable_class.abc.thread1 dc2 time[100.000ns] thread1 end newdc2 time[100.000ns] main task end

在0ns时，dc1的main()/abc() task、dc2的main()/abc() task和测试代码thread1其开始执行并打印出响应消息。

在2ns时，dc1的thread2结束，根据disable_class类可知，这时候thread1被disable了，因此dc1的thread1的“$display("%m %s time[%0t] thread1 end", get_name(), $time);”代码无法被执行到。这里就有个疑问了：dc2的thread1是否也会被disable吗？答案是也会被disable的。因此仿真结果中，虽然dc1 thread2执行了disable thread1，但dc2中thread1也无法打印出”thread1 end”相关的消息了。这里就是本文的重点了，在$display打印中我们用%m，把thread1的hierarchy也打印出来，我们可以发现，dc1和dc2虽然是两个不同的句柄，但是它们thread1的层次还是一模一样的，都是example_pkg::disable_class.main.thread1。SystemVerilog disable block_name的方式会把所有hierarchy一致的block_name都停掉的，故而我们可以看到20ns和100ns的example_pkg::example_agent.run_phase.thread1和example_pkg::disable_class.abc.thread1都没有被disable掉（因为虽然它们block_name都是thread1，但是它们hierarchy不一致的）。

总结

SystemVerilog disable block_name或task时，会把hierarchy一致的block_name或task的线程都停掉。不管一个class例化多少次，这些句柄内部的block_name和task的hierarchy还是一样的，因此只要其中任何一个句柄调用了disable block_name或task，那么其它句柄的对应线程也会被disable掉。这些行为如果我们提前知道，并就想利用这个特性做达成某些功能倒还好，但如果提前不了解，可能会产生很多意想不到的错误行为。其实为了精准的控制线程状态，推荐大家可以用process的内置方法(self(), status(), kill(), await()等等)来进行。