RE: [sv-ec] opinions on $exit

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).


> -----Original Message-----
> From: Steven Sharp [mailto:sharp@cadence.com]
> Sent: Wednesday, March 15, 2006 4:59 PM
> To: sharp@cadence.com; sv-ec@eda.org; Rich, Dave
> Subject: RE: [sv-ec] opinions on $exit
> 
> 
> >From: "Rich, Dave" <Dave_Rich@mentor.com>
> 
> >It is legal for a program to call a function or task that is not
defined
> >in a program. I think the term "design module" should be replaced
with
> >"outside a program block" since you can have task defined in an
> >interface, a package, or $unit.
> 
> Yes, I understand this.
> 
> 
> >The LRM or BNF never explicitly limited $exit to be inside program
> >blocks. It only loosely defined their behavior when call from a
program
> >block.
> 
> I understand this also.  However, I tend to agree with Arturo that
> they should only be allowed in programs.
> 
> 
> >Anyway, the new proposal should hopefully clarify a few of those
issues.
> 
> I see two reasonable approaches:
> 
> 1. Allow $exit to be called outside program blocks, and define their
>    behavior when called from a thread that does not come from a
program
>    block.  This could be a no-op, as you suggested.
> 
> 2. Only allow $exit to be called from a program block.  In this case
>    there is no need to define their behavior when called from a thread
>    that does not come from a program block, since it cannot happen.
> 
> Neither approach requires any special cases for tasks declared in
> packages.  With approach 1, $exit can be called from anywhere, so
there
> is no special case for packages.  With approach 2, $exit can be called
> only from a program block.  A task in a package is either a program
task
> or it isn't, so there is still no special case for it.
> 
> I prefer approach 2, as I think it is cleaner.
> 
> Steven Sharp
> sharp@cadence.com