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

I had noticed that allowing these in functions would indirectly allow
them in final blocks too, because of the way the final block limitation
was worded.  But there were enough bigger issues that I didn't get around
to bringing it up.

As Arturo says, the threads spawned by a fork..join_none in a final block
would never execute.  They are not allowed to execute until their parent
process blocks (or terminates).  But all final blocks are effectively
executed as a single process, and when it terminates, the simulation is
over.

It does seem like an unnecessary pitfall for users if they are allowed
to write this useless construct.  The proposal for Mantis item 1615
already limits the processes that are allowed to execute a fork..join_none
via a function call.  I think this should be modified so that it also
disallows executing fork..join_none from a final block (either directly
or via a function call).

There are some problems with the existing text for 1615 that I think
need to be cleaned up with a further proposal.  I think that the limit
on executing fork..join_none should be expressed in terms of the kind
of process executing it, not the original ancestry of that process.
Expressing it in terms of the original ancestry actually allows things
that were supposed to be disallowed, and disallows some things that are
reasonable.  

At the same time, the wording can be changed so that it doesn't matter
whether the fork..join_none was executed in a function or not.  All of
the really problematic cases could only execute a fork..join_none from
a function anyway, so this changes nothing for them.  But stating it
this way would prevent final blocks from executing fork..join_none
directly, in addition to executing it via a function.

Steven Sharp
sharp@cadence.com