RE: [sv-ec] Update proposal for 1371 $exit

>[DR>] This is the Verilog 1364 definition of disable and the definition
>used for disable fork. All sub processes are terminated and execution
>goes to the statement that follows the block. As with an explicit
>disable of an initial block (i.e. its top-level named block), there is
>no way to re-enable it.

The effect of a Verilog disable on fork..join_none/join_any subprocesses
has never been specified.  And since it is explicitly undefined whether
nonblocking assignments get disabled, I don't think you can claim that
all subprocesses are terminated by a Verilog disable.

I think that we should be explicit and say that it acts as if a disable
fork were executed by each initial block.  Then we can rely on the
existing specification of disable fork, which already describes how
it kills all the forked subprocesses.


>Finally, how does this interact with Seven Sharp's proposal to consider
>only a thread's existing scheduling region? Your proposal might be to be
>at odds with that concept in the sense that the run-time would need to
>maintain a thread's origin.
>
>[DR>] You're going to have to maintain the thread's origin if you want
>$exit to work if called from a thread created by fork/join_none. Or at
>least the program block that originated the thread.

For $exit, we already have to maintain the origin for another reason.
It is not sufficient to know whether a thread came from a program.  You
have to know which program it came from, so you can exit the correct
program.  So you need very specific origin information.  Just knowing
whether a particular thread is executing in a program-like region is
not going to help (except maybe as a shortcut to skip some work if
the $exit was executed from a non-program-like region and should be
treated as a no-op).

This assumes that $exit acts on the program from which the thread
dynamically originated.  The alternative would be that it acts on the
program in which the $exit statically appears.  In this case, it makes
no sense to allow $exit outside a program, since it would never have
any effect there.  But I have always assumed the dynamic definition
was desired.

The main reason for using the current region to control the scheduling
to future regions is not applicable here.  Any thread can schedule, even
if it did not originate in a module or program.  There are other ways
that a thread can originate, and some of them may want to act like a
module thread and others like a program thread.  But $exit is only
defined for a program, and you can specify that any thread that did
not originate in a program will ignore it.  There is no reasonable way
to have a PLI-created thread "act like a program" for $exit.  What
other processes would you consider as belonging to the same program?

Mind you, I still think it would be simpler to restrict $exit to
appear inside programs.  Then it should be impossible for any non-
program thread to execute it, and the problem goes away.


Steven Sharp
sharp@cadence.com


-- 
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.