systemverilog中进程管理-1-线程的发起

在实际的硬件中，时序逻辑通过时钟沿来激活，组合逻辑的输出则随着输入的变化而变化。所有这些并发的活动在verilog的寄存器传输级上是通过initial和always块语句，实例化和连续赋值语句来模拟的。

每个线程总是会跟相邻的线程通信。systemverilog中常见的线程间的通信有标准的verilog事件event，事件控制@，wait语句，systemverilog信箱和旗语等。
线程是可以独立运行的程序。

线程的理解：
1.线程需要被触发，可以结束或者不结束；
2.在module中的 initial 和 always ，都可以看成独立的线程，他们在仿真 0 时刻开始，而选择结束或者不结束；
3.硬件模型中由于都是always 语句块，所以可以看成是多个独立运行的线程，而这些线程会一直占用仿真资源；
4.软件测试平台中的验证环境都需要有initial 语句块去创建，而在仿真过程中，验证环境中的对象可以创建和销毁，因此，软件测试端的资源占用是动态的
线程的执行轨迹呈树状结构，任何线程都有父线程；当子线程终止时，父线程可以继续执行；当父线程终止时，其所开辟的所有子线程都应当会终止;
5.软件环境中的initial块对语句有两种方式:(１）begin … end：内部语句以顺序方式执行；（２）fork … join：内部语句以并发方式执行。

线程的发起：

方式1：由initial发起
initial发起的顺序执行的线程

initial begin
   uvm_config_db#(virtual my_if)::set(null, "uvm_test_top.env.i_agt.drv", "vif", input_if);
   uvm_config_db#(virtual my_if)::set(null, "uvm_test_top.env.i_agt.mon", "vif", input_if);
   uvm_config_db#(virtual my_if)::set(null, "uvm_test_top.env.o_agt.mon", "vif", output_if);
end

initial发起的并行执行的线程

initial begin
  fork
      forever begin
         uvm_config_db#(real)::wait_modified(uvm_root::get(), "uvm_test_top", "clk_half_period"); 
      end
      forever begin
         #(clk_half_period*1.0ns) clk = ~clk;
      end
  join
end

方式２：final关键字发起
initial是在仿真0时刻自动执行的，而final procedure刚好相反，是在仿真结束的时候之后才会执行。
final procedure是不消耗仿真时间的，且可以有多个final procedure，多个final procedure的执行顺序是随机的。

方式3：always/always_comb/always_latch/always_ff
使用关键字：always/always_comb/always_latch/always_ff

方式4：each dynamic process

方式5：fork…join/join_any/join_none:能够从它的每一个并行语句中产生并发进程。
这三种并行执行的进程区别可以参考我写的一篇文章>https://www.cnblogs.com/fulai-hou/articles/15473316.html

systemverilog中进程管理-1-线程的发起

猜你喜欢