RE: [sv-ec] fork...join_none in functions, and final blocks

>From: "Warmke, Doug" <doug_warmke@mentor.com>

>Could you please clarify the difference between your terms
>"kind" of a process and "original ancestry" of a process?

Let's start with what the proposal for 1615 says.  One place says
"provided that the process calling the function originates in an
initial block."  Another says calling the function is illegal in
"any context other than procedural code originating in an initial
block."

I asked why it would not be legal to call it from a thread created
by another fork.  Arturo replied that the intent of the phrase
"process originating in an initial block" was to include all processes
forked from an initial block process.  So his intent was to allow
calling from threads forked from an initial block (or forked from
threads forked from an initial block), but not from a thread forked
from an always block.  There was some discussion of wording to make
that clearer, but nothing was done.

So what I mean by "original ancestry" is what Arturo is describing:
the root process that led to the creation of the calling process.
What I mean by the kind of the process itself is how the calling
process itself was created (e.g. initial block, always block, fork).


>Also, if you could give a few examples of things that were supposed
>to be disallowed, and things that are reasonable, that would be
>helpful to my understanding of this topic.

Some of the things that were supposed to be disallowed are listed, such
as continuous assignments, nonblocking assignments, always_comb blocks,
and static variable declaration initializers.  Another unlisted example
would be a force statement.  But the claimed restriction on these does
not follow if Arturo's interpretation is taken.  A nonblocking assignment
or force statement could have "originated in an initial block", but still
should not be allowed.

On the other side, I don't see why a process forked by an always block
should be disallowed from forking more subprocesses with a function call.
We already allowed the "originating" process to fork child subprocesses,
so I don't see why there would be any problem with grandchild processes
forked by the child.  None of the reasons for disallowing certain
processes to fork could apply to a process that was itself created by a
fork, no matter what its ancestry.

Both of these issues would be resolved by specifying the restriction in
terms of the process executing the fork..join_none, not its original
ancestry.  Any forked subprocess is OK to fork more.  A force process
is not.  In both cases, it should be independent of the original ancestry.
This also seems simpler to understand and describe.

Does this clarify my statements sufficiently?

The other issue is that it should be expressed in terms of which processes
can execute fork..join_none, not which ones can do it via a function call.
Then the restriction would rule out fork..join_none being executed by a
final block, whether directly or via a function call.  Most of the problem
cases can only execute it via a function call anyway, so that changes
nothing for them.  And in any other case, either there is a problem with
the process executing a fork..join_none, or there isn't.  I don't see why
it should matter whether it was via a function call or not.

Steven Sharp
sharp@cadence.com