Subject: Re: [sv-ec] ERR-4
From: Steven Sharp (sharp@cadence.com)
Date: Fri Aug 22 2003 - 14:29:41 PDT
>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 : Fri Aug 22 2003 - 14:31:16 PDT