RE: [sv-ec] opinions on $exit

>From: "Rich, Dave" <Dave_Rich@mentor.com>

>Take the following scenario: A program block calls a task in another
>program block that contains a $exit. Which program block exits? 
>
>If we make it clear that the program block originating the thread that
>executes $exit is the one that terminates, then the formal location of
>the $exit call is no longer relevant. So 1) becomes just as clean as 2).

For program threads, sure.  The unclean part is allowing non-program
threads to call $exit, which does not have defined behavior.

You have suggested that this be treated as a no-op.  This is simple,
but is not a good answer.  It is too different from the behavior in
a program thread.  If you put a $exit in a task, you don't expect the
thread to continue running after that point.  Allowing it to be called
by a thread that will ignore the $exit is just asking for a logic bug.
If a non-program thread is allowed to execute $exit, it should not
violate the assumptions that are made when $exit is put into the code.

There are a number of ways $exit could be defined for a non-program
thread.  It could just terminate that thread, which would at least
avoid that thread continuing unexpectedly.  Or it could terminate
the root thread that created that thread.  But that gets us into some
of the poorly defined situations that come up with fork in functions.
The thread hierarchy is not fully defined when some Verilog constructs
become involved.  You might have to disallow $exit in functions to
avoid some of those (e.g. an exit from inside a nonblocking assignment,
continuous assignment, or force).  Terminating a continuous assignment
process (including ones for port connections), or always block, partway
through simulation would violate basic assumptions about how those
processes behave.

The only way to have $exit terminate a non-program thread without
causing these problems is to have $exit behave like $finish when
called from a non-program thread.  There would be some sense to this,
since $exit called from a program block includes the behavior of
"call $finish if I was the last live program block".  It is the
closest non-program equivalent to "I'm done", which is what $exit
means.  It is certainly a lot closer than ignoring it.

From an implementation viewpoint, this might require extra work to
track the parentage of non-program threads, to allow $exit to determine
whether the thread calling it was a program thread or not.  Otherwise
this work would be required only for program threads.  This might have
some minor negative performance impact, or require extra analysis from
the tool to avoid it.

Put all that together, and I regard it as less clean than just limiting
$exit to programs.

BTW, any proposal needs to be clear that it is the top-level or root
thread of the thread executing $exit that matters.  If program1 calls
a task in program2 that spawns a thread that calls $exit, it should
exit program1.  If the proposal just talks about the thread that calls
$exit, someone could claim that the thread calling $exit in this case
was created inside program2, even though its root thread came from
program1.

Steven Sharp
sharp@cadence.com