Subject: Re: [sv-ec] ERR-4
From: Neil Korpusik (Neil.Korpusik@Sun.com)
Date: Tue Aug 26 2003 - 15:37:00 PDT
If the goal is for fork/join_none and fork/join_any to be consistent with the
V2K fork/join, the following should be true:
a. Sharing of automatic variables
Automatic variables potentially used by spawned sub-processes should all
be available to and shared by all such sub-processes regardless of the
variation of fork/join that spawned those sub-processes.
b. Lifetime of automatic variables
These automatic variables can't "go away" until all of the sub-processes
that use those automatic variables complete. The lifetime of these
automatic variables must equal or exceed the lifetime of the consuming
sub-processes.
It has been stated that this may be "nasty" to implement and could
possibly be inefficient. Right now there is a hole in the SV3.1
specification with regards to automatic variables used by sub-processes
spawned by fork/join_none and fork/join_any. Automatic variables may
cease to exist while sub-processes that use them still exist. I would
rather have a construct that always works in a consistent manner even if
it may happen to be inefficient in certain situations than to have an
efficient construct that just plain doesn't work in certain situations.
Coding guidelines serve to help steer people away from coding in an
inefficient manner. The SV LRM could mention the possible inefficiency.
c. Local copy of automatic variables
If a local copy of an automatic variable is to be automatically created by
a spawned sub-process there needs to be a new mechanism defined to provide
that capability. The default behavior for automatic variables used by
sub-processes spawned by any variant of fork/join should be consistent
with the existing V2K fork/join.
Vera provides a mechanism which allows users to specify variables that
should have a local copy created within spawned sub-processes. This hasn't
been discussed in any of the email traffic and it may not be the most
appropriate mechanism for System Verilog. The point is that even in Vera
the default behavior is for automatic variables to be shared among the
spawned sub-processes as is the case for fork/join in V2K. I see no
reason to change that behavior for fork/join_none and fork/join_any in SV.
The current proposal contained in ERR-4 creates a situation where
automatic variables are shared by sub-processes spawned by fork/join but
a local copy is made for automatic variables used by sub-processes spawned
by fork/join_any and fork/join_none. This inconsistency should be
disallowed.
Neil
---------------------------------------------------------------------
Neil Korpusik Tel: 408-720-4852
Member of Technical Staff Fax: 408-720-4850
Frontend Technologies - ASICs & Processors (FTAP)
Sun Microsystems
email: neil.korpusik@sun.com
---------------------------------------------------------------------
> X-Unix-From: sharp@cadence.com Fri Aug 22 14:30:37 2003
> Date: Fri, 22 Aug 2003 17:29:41 -0400 (EDT)
> From: Steven Sharp <sharp@cadence.com>
> Subject: Re: [sv-ec] ERR-4
> To: sharp@cadence.com, David.Rich@synopsys.com
> Cc: Shalom.Bresticker@motorola.com, sv-ec@eda.org
> MIME-Version: 1.0
> Content-MD5: snBfhI6ppKKk/waCrlaOnw==
> X-Received: By mailgate2.Cadence.COM as OAA02667 at Fri Aug 22 14:29:46 2003
>
>
> >As we discussed in Monday's SV-EC meeting, these fork-join any and none
> >constructs create situations that don't exist in Verilog, so there is
> >nothing to be consistent with.
>
> The fact that these are new constructs does not mean that there is no
> requirement for them to be consistent with the rest of the language.
> The scoping semantics are a general feature of the language which are
> orthogonal to any particular statement type (aside from the fact that
> some statement types introduce scopes, which are consistent with the
> scoping rules). They are definitely something to be consistent with.
>
> If these new constructs have a design flaw, then it should be fixed
> in a way that is consistent with the existing language.
>
> >Look at this complete example:
>
> I understand the problem with the construct. But the "fix" that you
> have proposed is grossly inconsistent with the existing scoping semantics
> of the language. It is also inconsistent with any other language that
> I am aware of. You should design a real fix to the problem that is
> consistent with the existing language.
>
> >The V2K spec says "Because variables declared in automatic tasks are
> >deallocated at the end of the task invocation, they shall not be used in
> >certain constructs that might refer to them after that point." That is
> >OK in V2K because you can't refer to automatic variables outside their
> >scope, and any automatic variable referenced from within a fork/join is
> >guaranteed to be still active.
>
> There are other existing Verilog constructs that could have referenced
> automatic variables after they stopped being active. There is a list of
> some specific ones in V2K, but this statement is intended to ensure that
> all of them are covered. This was to cover any accidental omissions, as
> well as any appropriate constructs that might be added in the future.
>
> > In SV, "might" will require clarification
> >as the above example shows.
>
> These new types of subprocesses would definitely fall within the intent
> of that statement in the V2K LRM.
>
> >1. Disallow references to any automatic variables outside the scope of a
> >fork/join_any/none. The would make it extremely difficult to pass any
> >data to a forked process from a re-entrant task or using a variable from
> >a loop iterating statement. It basically requires setting up a mailbox
> >for each piece of automatic data used by the forked process(es).
>
> As written, the V2K restriction would prevent references to *any*
> automatic variables in a fork/join_any/none, regardless of scope.
> However, fork/join_any/none are different from the other subprocesses
> because they can declare new variables local to the subprocess. As
> you note, only references to variables outside the scope of the subprocess
> create the issue that the restriction was intended to prevent. So
> this would be consistent with the intent of the restriction.
>
> As you point out, this still presents a problem with passing data into
> the subprocess. The construct could be modified to provide a mechanism
> for doing this.
>
> For example, with syntax more like the SV 3.0 process statement, it
> would be straightforward to add an argument list after the "process"
> keyword, similar to a task call. This list would be evaluated for
> passing into the subprocess before the parent process continued. This
> would solve both the problem of passing in an automatic variable value,
> and of making sure that the proper value of a loop index was used.
> Inout and output arguments could also be allowed, to encapsulate getting
> values back from subprocesses. Of course, an inout or output argument
> could not be passed an automatic variable, as this would violate the
> restriction. The process statement could also access objects from
> surrounding scopes, as long as they were not automatics.
>
> Another variation would be to define the process statement as spawning
> only a task enable, not arbitrary statements. Tasks already have the
> necessary argument passing capabilities. This might be too restrictive
> for some uses, however.
>
> Note that having a separate process statement for each subprocess would
> also make it easy to extend the syntax to provide a process id back
> (e.g. "pid = process ..."). This would take care of the concerns that
> Kevin Cameron has expressed with getting a process id back without
> kludgy mechanisms for the child getting it and having to communicate
> it back to the parent. As with the arguments, the process id would
> be returned before the parent process continued execution.
>
> I don't see any easy way to extend the fork/join_any/none approach to
> subprocesses similarly. Perhaps that was a wrong turn in the design
> process.
>
> If the problems with this construct can't be fixed in any way consistent
> with the existing language, perhaps a significant redesign is needed.
> Even if nobody likes the specific suggestions I have made, they do show
> that the same capabilities can be provided in a way that avoids these
> problems and is consistent with the existing language. So there is no
> excuse for an approach that isn't.
>
> >2. End the lifetime of each variable when the last process that
> >references it dies. This could get quit involved to implement. And still
> >this does not solve the problem created by a fork/join_none in a looping
> >block.
>
> Yes, that would be nasty to implement. It is also different from the
> existing V2K rule. It is not a serious inconsistency, since this is a
> specialized rule applying only to subprocesses and automatic variables.
> It also wouldn't be a backward compatibility problem, since it only
> changes the behavior of something that is not allowed in V2K currently.
> But again, it would be nasty to implement and could severely impact the
> performance of reentrant tasks and functions. And it doesn't solve your
> problem with zero-delay loops referencing the correct index.
>
> >If I were to modify the above example to use a normal fork/join, the
> >user would see 1,2,3 displayed. I think that is the behavior the user
> >expects for fork/join_any/join_none, and that is what the original
> >proposal gives the user.
>
> I think the user would also expect to be able to write to a variable
> in one of the subprocesses and see the effects in the same variable from
> another subprocess in the same scope. That is the behavior that the
> user expects for a normal fork/join and for all other statements in the
> language, and that is what your original proposal does not give the user.
>
> Steven Sharp
> sharp@cadence.com
>
This archive was generated by hypermail 2b28 : Tue Aug 26 2003 - 15:39:46 PDT