Fork join_none inside for loop

In reply to dave_59:

Thanks Dave !!

In reply to dave_59:

Hi Dave,

I have a question in mind, how does this piece of code or logic suitable for clock-based and event based simulations.

I am particularly looking for to understand clock-based simulation on above explained code by you.

Can you give some information.

sreeni.

In reply to nivas:

It’s hard to answer your question because this is a long thread of responses and there’s no clock in any of these examples. Perhaps you should try asking as a new question.

In reply to dave_59:

I have a doubt :

module fork_test1;
  initial begin
    for (int j=0; j<3; j++)
      begin
        #1;
        fork

          $display(j);

        join_none

      end
  end
endmodule:fork_test1

the output for the above code is :

1
2
3

Why is that> Why it is not printing 0?

In reply to SanjanaDhiran:

https://verificationacademy.com/forums/systemverilog/fork-joinnone-delay#reply-93311

What is the difference between the following 2 codes:
code 1:


for (int i = 0; i<3;i=i+1) begin
    fork 
      automatic int k = i;
      $display(k);
   join_none
end

Code 2:


for (int i = 0; i<3;i=i+1) begin
    automatic int k = i;
    fork 
      $display(k);
   join_none
end

In reply to SanjanaDhiran:

There is no functional difference between the two codes you show. An instance of k gets created for each iteration of the for loop, and the lifetime of each k ends when the statement containing the $display finishes.

The only difference would be seen if there were more code inside the begin/end block. In code 1, the visibility of k is limited to inside the fork/join_none block.

In reply to dave_59:

Hello Dave, I modified the code. Now, send is not automatic .why it still displays driving 0,1,2… instead of driving 15,15,15,15…?
Thanks


module test;

  initial begin
    for(int i = 0; i < 16; i++)
      begin
        fork 
	    automatic int index =i  ;	    
          send(index);
	join_none 
      end
      wait fork;
  end
   
        function   send(  int j);

          $display("driving  %0d %t" , j, $realtime);
   endfunction /

        
endmodule


In reply to peter:

Because sand() is a function executing with no delays. In theory it’s possible for an iteration of a process to call send() and then switch to another process before executing the $display statement. But in practice, you will never see that happen on a single core simulation.

In reply to dave_59:

Hi Dave, sixteen send function should be executed parallelly according to the spec. If the
result shows 15,15,15,15… The result should satisfy the spec?

You mention that it’s possible for an iteration of a process to call send() and then switch to another process before executing the $display statement. it seems that it is different with the spec, because send is running sequential instead of parallel. Would you explain more about never see that happen on a single core simulation?

Thank you!!

In reply to peter:

15,15,15, … is a valid result. See Section 4.7 Nondeterminism