Re: [sv-ec] Class extension and scheduling (Issue 240)

Some comments on Gordon's writeup.

Issue 1.
Proposal 1

  The end of Section 17.2 says

     "Type and data declarations within the program are local to the program
     scope and have static lifetime."

     "References to program variables from outside any program block shall be
     an error."

     This proposal appears to change the first of these two restrictions.
     I'm assuming that you are not proposing to change the second restriction.

  If I understood your description, this proposal implies:

      A class handle may be declared within the design, a program or a package
      with no restrictions on where the corresponding class has been
      declared (program, design, package). The scheduling semantics of method
      calls shall be based solely on the location of the thread making the call.
      Neither the location of the class declaration nor the location of the
      handle declaration shall have any effect on the scheduling semantics of
      method calls.

      When a class handle is declared within a program it may only be accessed
      from within a program block.

  I don't understand why you use the phrase "Any task re-activations following
  a suspension". I assume we are discussing all method calls.

Neil




Gordon Vreugdenhil wrote:
> All,
> 
> Sorry for the length of this.  I've pulled together
> a few approaches based on internal discussions here.
> 
> There are two main issues in Arturo's note -- the
> issue involving scheduling regions and the much more
> general issue of class extensions.  These are really
> independent issues and are addressed separately
> in this writeup as "Issue 1" and "Issue 2".
> 
> For "Issue 1" we have the basic framework for two
> alternative solutions described.  Obviously either
> require work to turn them into LRM proposals, but
> before doing so, we'd like to have a clear sense
> of agreeement about direction.
> 
> For "Issue 2", we have a number of problems with the
> arguments made for wide ranging restrictions on
> class extensions.
> 
> Please respond via the reflector since I am not the
> sole author of this and others may want to chime in.
> 
> Gord
> 
> ================
> 
> 
> 
> Preliminary note
> 
> LRM Clause 17 needs to clarify that whereever it talks
> about module-based code, it really should be talking
> about module *and* interface-based code since modules
> and interfaces are part of the SV "design code" subset.
> A good way to do this is to replace the word "module"
> with the word "design" in certain key locations.
> 
> 
> 
> Issue 1 - Scheduling regions
> 
> 
> In terms of scheduling of suspendable tasks in classes,
> there appears to be an unfortunate coupling of
> "declaration" and "thread semantics".  Users would
> generally expect that scheduling semantics follow the
> kind of region that the thread (caller) is in.
> Currently, even without classes, one cannot simply
> inspect a function or task in a module and know whether
> parts of the code are in the reactive region or active
> region.  For example, if a task contains a conditional
> wait, the code following the condional wait will
> evaluate in the reactive region if the wait isn't take
> and the caller is a program.  In other cases the code
> following the wait will be evaluated in the active
> region.  Classes only exacerbate the confusion since
> extension permits declarations to extend and,
> currently, to extend across regions.
> 
> 
> Since the region in which code is evaluated is not
> known in all cases, the simplest solution seems to be
> to decouple the scheduling from the location in which
> subroutine code is defined and to completely normalize
> based on the scheduling semantics of the thread making
> the call.
> 
> Proposal I
> 
>    Any task re-activations following a suspension shall
>    follow the scheduling region of the thread making the
>    call.
> 
> This is a clean model.  There is no need to couple
> scheduling regions with subroutine declarations.  There
> are no issues that cause reasoning about types to be
> contaminated with reasoning about scheduling regions.
> Package and interface class code is completely
> reusable and flexible.
> 
> 
> 
> Although we believe that the above proposal has the most
> merit, since this is a new conceptual approach to the
> problem, we would also be willing to consider restrictions
> to the current declaration based approach in order to
> resolve the issues.
> 
> 
> The basis of Proposal II is that we should define that
> a class has an associated scheduling region kind.  This
> kind is determined based on the scope in which the
> class is declared.  There are design region kinds and
> program region kinds of scheduling.
> 
> All tasks, functions, and classes declared in package
> scope have neutral scheduling semantics until they are
> imported into a design scope or a program scope.  At
> that time they inherit the scheduling region kind
> associated with the importing scope.  This allows for
> truly re-usable code that can be of value in any kind
> of declartive scope.
> 
> 
> Proposal II
> 
>    It shall be an error for a class handle to be declared
>    in a scope which has an incompatible scheduling region
>    kind with the scheduling region kind that encloses the
>    class type declaration.
> 
> This means that it is illegal to pass a class type
> declared in design code to a program, either through a
> parameter association list or an interface port association.
> This further renders it impossible for a program to
> attempt to extend a class declared in a module.
> 
> 
> 
> Miscellaneous
> 
> We should remove the concept of "anonymous program"
> from the BNF.  There is no text in the LRM related to
> this concept, so fait accompli there.
> 
> 
> There is unacceptable looseness around var and ref
> program ports.  The LRM clearly states that when a
> program writes to a design variable, it must use an
> NBA.  And a program variable must be written with a
> blocking assignment.  These semantics are full of
> loopholes, and don't serve much practical purpose.  The
> best course of action would be to lift these
> restrictions.  (Described in the final paragraph of
> 17.2).
> 
>    Some loopholes:
>      1. blocking write to a var or ref program port that is
>         connected to a design variable actual
>      2. write to an interface variable through an interface port.
>      3. indirect write to a module or interface variable via a task
>         or function call
> 
> One problem with disallowing program variables from
> being written with NBA's is that it is difficult to use
> class Verilog de-racing coding style to eliminate
> TB<->TB process races.
> 
> 
> 
> 
> 
> Issue 2 - Class extension restrictions
> 
> We strongly oppose any restriction on class extensions
> within the same scheduling region.
> 
> The following arguments are made in terms of cross
> module class extension; the same arguments apply for
> cross program class extension and for interface-module
> extensions.  The only acceptable restrictions for
> extension should impact program extension of a module
> or interface class type due to the semantic issues of
> scheduling when extending the class type across
> regions.
> 
> 
> 
> (A)
> Any in-region restriction does not treat "class" as a
> first-class type.  Other types can be used in a cross
> module manners and arbitrarily restricting this for
> classes will reduce the ability to write general
> designs.
> 
> (B)
> The argument regarding confusion of type equivalence is
> not an argument that applies just to classes.  All
> existing instantiations of types have the same
> attributes.  In addition, this would still exist for
> classes since classes would still be able to be derived
> (from package types) within modules and would be able
> to be directly declared in modules.  Instantiations of
> those types are not equivalent.  Extending classes
> between modules does not make that issue any different.
> 
> (C)
> The discussion has not addressed class types in interfaces
> and propagation of class types between interfaces and
> modules.  Since other types are permitted to be used
> without restriction in such scenarios, it seems that
> class types should as well.  In addition, allowing class
> extension through interfaces seems to be a natural way
> to extend functionality, particularly since interfaces
> are not extensible themselves.
> 
> (D)
> Cross module extension of classes via type parameters
> does not introduce issues that are much more difficult
> than any other form of type parameter flow for separate
> compilation.  Virtually all of the issues involved in
> the separate compilation of such modules must be resolved
> even without support for class extension.
> 
> (E)
> Class extension in generate conditions and generate loops
> also causes "scope" issues in the same manner as
> cross module extension.  Restricting class extension in
> these contexts reduces ones ability to have conditional
> and iterative specialization of types to generalize design.
> 
> (F)
> The performance issues are not so significant that they
> should constrain semantics to this degree.  We do not
> believe that there are requirements in the general case
> of class extension that are incompatible with high
> performance implementations.  Considering the fundamental
> impact of other decisions, such as having automatics
> outlive their scope of declaration (requiring
> non-stacked allocation for such variables), the
> performance issues that have been raised seem pretty
> minor, even if we would conceed that they are
> fundamental.  In addition, there is no performance
> impact in cases where class extension is simple so any
> performance penalty is paid only in complex scenarios.
> 
> 
> Summary
> 
> Restricting class extensions in the manner proposed is a very
> substantial semantic restriction that reduces the regularity
> and composibility of language constructs.  Since there
> is no compelling semantic or performance reason for such a
> restriction, we strongly oppose any such restriction.
> 
> 

-- 
---------------------------------------------------------------------
Neil Korpusik                                     Tel: 408-720-4852
Staff Engineer                                    Fax: 408-720-4850
Frontend Technologies - ASICs & Processors (FTAP)
Sun Microsystems
email: neil.korpusik@sun.com
---------------------------------------------------------------------