Fork/join_none inside a function

SystemVerilog
1

Hi,

Is fork/join_none inside a function legal according to LRM?
It seems obvious that fork/join and fork/join_any are not because they may consume time.
But I’m not so sure about fork/join_none.

I’ve tested it with 3 simulators and they all seem to work.
Should I consider it legal? Or is it a implementation-specific thing?

module top;
  
  function void f();
    fork
      #10 $display("%t", $realtime);
    join_none
  endfunction: f
  
  initial f();
  
endmodule: top

Best regards,
Jung Ik Moon

2

In reply to Jung Ik Moon:
https://verificationacademy.com/forums/systemverilog/calling-task-inside-function#reply-44899

3

In reply to dave_59:

Hi Dave,

So LRM already made it clear that it’s allowed.
Thanks for the answer.

Best regards,
Jung Ik Moon

4

In reply to Jung Ik Moon:

So LRM already made it clear that it’s allowed.

No, it says that tasks are not allowed.
1800-2017 wrote:
Functions have restrictions that make certain they return without suspending the process that enables them. The following rules shall govern their usage, with exceptions noted in 13.4.4:
A function shall not contain any time-controlled statements. That is, any statements containing #, ##, @, fork-join, fork-join_any, wait, wait_order, or expect.
A function shall not enable tasks regardless of whether those tasks contain time-controlling statements.

Ben systemverilog.us

5

In reply to ben@SystemVerilog.us:

Ben, see my link. This is the exception noted in 13.4.4

6

In reply to dave_59:

Thanks, but from a practical standpoint, it seems like the software would be ‘cleaner’ and more structured if we keep functions clean and avoid calling tasks from within.

From the very beginning of the development of rtl languages, we at Hughes picked VHDL because it is more structured and has rules to avoid funny stuff. Verilog is so flexible that it is easy to create weird code and get oneself into TROUBLE. Systemverilog inherited some of these quirks.
However, if one adopts good discipline in the use of the language then we can avoid a lot of problems.
Ben

7

In reply to ben@SystemVerilog.us:

I agree with you. But unfortunately, not so much that it was designed by committee, SystemVerilog was implemented by a number of vendors and some of their users exploited certain flexibilities. Specificly, they wanted to fork a process when calling the constructor of a class. And once that door was opened, it was difficult to close.