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

> -----Original Message-----
> From: Steven Sharp [mailto:sharp@cadence.com]
> Sent: Friday, January 26, 2007 5:47 PM
> To: Arturo.Salz@synopsys.com; sv-ec@eda-stds.org; Rich, Dave
> Subject: 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.
[DR>] The 1364 LRM says "All activities enabled within the named block
or task shall be terminated as well." That was originally intended to
include NBAs but one vendor's implementation was unwilling to accept
that, so the exception for NBAs was added. Without an explicit
exception, disable should apply to fork/join_none. Of course, there's
always room for clearer wording, but I would wait for the merged
document to address this.
> 
> 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.
[DR>] OK, I can put it in terms of a disable fork.

> 
> 
> >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).
[DR>] Yes, I meant at least the *specific* program block that originated
the thread.
> 
> 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?
[DR>] Only those processes that originated from the initial block of a
program or a descendant of one of those processes by way of a fork/*.
> 
> 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.
[DR>] Simpler for the implementer, but not the user. The users want to
be able to define classes in packages, or use IP defined in packages
that might have the $exit call.
> 
> 
> Steven Sharp
> sharp@cadence.com


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