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

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.


-- 
--------------------------------------------------------------------
Gordon Vreugdenhil,  Staff Engineer               503-685-0808
Model Technology (Mentor Graphics)                gordonv@model.com