In reply to dave_59:
This is allowed because: Solocal_prm remains [I]active while the process forked is active even after foo() returns. And it doesn’t matter if prm_out gets passed by reference or not. So it’s a little more complex than just a call stack determining the lifetime of an automatic.
But let’s go back to your original post and modify this example
module top;
function automatic foo;
bit prm;
fork
begin : forked
tsk1(prm);
$display("prm %b exists till this process ends %t",prm, $time);
end
join_none
endfunction
task automatic tsk1(ref bit prm_out);
#10 prm_out = 1;
fork
tsk2(prm_out);
join_none
endtask
task automatic tsk2(ref bit prm_out); // this is illegal
#10 prm_out = 0;
endtask
initial foo;
endmodule
For this to work, the compiler would need to know the lifetime of prm goes beyond the lifetime of the forked process. Generally, it’s not a good idea to have to look inside the task you are calling in determining the behavior of code outside the task call.
Hi Dave,
referring to explanation you have given above, i have some more questions.
- based on the rule on “scope and lifetime, section 6.21” stated above, lifetime of local_prm in first example will be extended to 10 ns. So the simulator will not de-allocate the memory till 10ns. But how will this be achieved? Will compiler, while compiling the code for tsk1 figure out that local_prm needs to be active till 10ns and put this information in compiled code (using a timestamp?), which simulator will use at runtime?
- Also in second example also, considering the scope and lifetime rule, will compiler have to figure out that lifetime of prm needs to be extended till 10ns +10ns so that it can be accessed by tks2. Is this what you are referring to when you say “For this to work, the compiler would need to know the lifetime of prm goes beyond the lifetime of the forked process. Generally, it’s not a good idea to have to look inside the task you are calling in determining the behavior of code outside the task call.”
- The difference between first example (which works) and second one (illegal) is that tsk1 is spawning one more task tsk2. So will same problem occur if tsk2 is spawned using just fork-join and not fork-join_none.
regards,
-sunil