Fork Join Execution with delta delay #0

SystemVerilog
1

Hi Team,

Please help me out the importance of #0 delay in systemveriog . How #0 delay the statement execution especially with fork join_none/join_any/join

I have tried the below code :

module test;
initial begin 
				$display("[%0t] Main Thread:: Fork join going to start",$time);
				fork
				print(20,"Thread1_0"); // thread 1
				print(30,"Thread1_1"); // thread 2
				print(10,"Thread1_2"); // thread 3
				join_none
				
				$display("[%0t] Main Thread:Fork join has finished",$time);
end 
task print(int _time,string t_name);
				#0;  //Delayed the statement execution by delta time 
				$display("[%0t] %d %s",$time,_time,t_name); 
endtask:print
endmodule:test

FIRST :: if we use #0 in the print task output is :

 [0] Main Thread:: Fork join going to start
# [0] Main Thread:Fork join has finished
# [0]          10 Thread1_2
# [0]          10 Thread1_2
# [0]          10 Thread1_2

SECOND ::if i wont use #0 the output is :

[0] Main Thread:: Fork join going to start
# [0] Main Thread:Fork join has finished
# [0]          20 Thread1_0
# [0]          30 Thread1_1
# [0]          10 Thread1_2

I have changed the task print to task automatic print after that also without #0 statement output is same as SECOND.

Please provide inputs in understanding .

Thanks in advance

2

Reentrant or recursive tasks (and functions) need to be declared so they have an automatic lifetime. Routines with static lifetimes have only one storage location for their arguments for all invocations.

Your #0, or any other delay, guarantees the remainder of the task sees overwritten argument values. Without the delay, there is no guarantee, but a single core simulation tool usually does not break up execution of procedural thread until it hits a blocking statement.

3

because of this #0 blocking statement thread 0 will be suspended for 0 time and thread 1 will call the print function followed by thread 3 since print arguments are static which will be override by thread 3 (last call) .

is my understanding correct??

4

Pretty close. Instead of saying, the threads will be suspended for zero time, it’s actually that Instead of saying, the threads will be suspended for zero time, it’s actually that all the forked threads are suspended to the inactive region. The last call could be any of the threads.