Re: [sv-ec] Example for class extension paradigm

Gord

My comments are inlined below in purple.

    Arturo

----- Original Message ----- 
From: "Gordon Vreugdenhil" <gordonv@Model.com>
To: "Arturo Salz" <Arturo.Salz@synopsys.COM>
Cc: "SV_EC List" <sv-ec@eda.org>
Sent: Wednesday, April 27, 2005 11:23 AM
Subject: Re: [sv-ec] Example for class extension paradigm




Arturo Salz wrote:

> Gord,
> 
> You have completely misrepresented my position. I fully
> support the usage you have described in your example.
> If the methodology described in your example is what you
> wish to allow, then we should explicitly allow such usage in 
> the LRM and move on.


Perhaps I am confused.

I thought that you didn't want any class type sharing
between program and design regions; ie. no handles that
can refer to either a design object or a program object.
Clearly that is necessary in the example I gave.

No. That is not what I said. I repeatedly said during the meeting 
that our intention is not to disallow sharing of basic types or
classes anywhere in the language. And, I propose that the LRM 
not explicitly disallow such uses.

Your example is incomplete and trivial because it does not 
require arbitrary crossing between the Active and Reactive regions.
That is the gist of our discussion; it is not about using classes 
in either domain, and it is not about inheritance or classes in 
general. It is about the restrictions that we have imposed in the 
system to maintain a well ordered set of regions.

Your example is an abstract piece of code that is completely 
inadequate to demonstrate the need to provide code residing in
a module (heck, there is not even a module in the example) direct 
access to the Reactive region and vice-versa. As it relates to classes,
I have been proposing that we use the type system to enforce these 
scheduling region restrictions. Some of these restrictions are:
1- classes declared in programs are not visible in modules.
2- classes declared in modules that exhibit scheduling behavior (that 
    is they contain tasks with Active region semantics) should not be
    extensible in programs. Likewise, classes in programs that exhibit
    blocking Reactive region semantics should not be extensible in
    programs (but this is covered by point 1).
The purpose of these restrictions is to provide a basic level of race
protection whose violations can be easily caught by the compiler, while at 
the same time giving users a simple set of rules describing what is allowed. 
Sometimes, the goal of providing a simple set of rules results in a more 
prohibitive system than is absolutely necessary; the challenge is finding 
the proper balance between simplicity and safety. Allowing every conceivable 
behavior will simply convert it into a race debug problem for the user.

Can you clarify the rules by which a package class type
(which by other statements is a "design" class) is permitted
to be extended in the program region?  In other words,
what constitutes a "pure" class and how is that differentiated
from our concept of a "schedulefree" class?

A "pure" class is class that contains only data members, and functions 
with no side effects outside the class, that is, no access to data external
to the class. Such classes can be safely extended in either a program or 
a module domain without breaking the existing well-ordered region execution.

This is a simple example, yes.  I am trying to discern
exactly the rules that you are operating under since they
have yet to be specified.


I think that this kind of example can be extended to
included blocking behavior by extending the "packet"
to a "protocol".  In such cases, as long as the program
didn't actually invoke blocking methods things would
still be clean but would not be allowed under my new
approximation to understanding your rules.

Again, as I said before. Adding blocking behavior does not address 
the basic question, which is what modeling schema require a single 
type that provides unrestricted access across the various execution 
regions. Your entire example can be done completely in a program 
or completely in a module. I fail to see the need for an object that 
requires simultaneous access to both the Active and the Reactive 
region semantics. The issue of re-use, that is, not having to write the 
same code for Active or Reactive region execution is perfectly addressed 
by the parameterized class proposal (that proposal is immature and 
may need more work, but the basic idea is clear).

Gord.



> You'll note that the base class packet below is a "pure" 
> class in that it contains only data and functions with no 
> side effects outside the class. I have no objection in
>  allowing such a usage.
> 
> I believe that any real and useful modeling mechanisms are
> supported by the existing rules.
> 
>     Arturo
> 
> ----- Original Message ----- 
> From: "Gordon Vreugdenhil" <gordonv@Model.com>
> To: "SV_EC List" <sv-ec@eda.org>
> Sent: Wednesday, April 27, 2005 9:54 AM
> Subject: [sv-ec] Example for class extension paradigm
> 
> 
> The following is a simple example as requested in the face-to-face.
> It isn't complete but the conceptual model should be clear.
> 
> 
> package pkt;
>      class packet;
>         int data;
>         virtual function int get(); return data; endfunction
>         virtual function void put(int x); data = x; endfunction
>      endclass
> endpackage
> 
> 
> // module code here that creates and uses packets for
> // some high-level abstract version of the system
> 
> program foo;
>      import pkt::*;
>      class error_packet extends packet;
>         int read_count;
>         int write_count;
>         static int next_err_id = 0;
>         int err_id;
>         function new();
>           err_id = next_err_id++;
>           read_count = 0;
>           write_count = 0;
>         endfunction
>         function int get();
>            read_count++;
>            return data;
>         endfunction
>         function void put (int x);
>            write_count++;
>            data = 0; // inject bad packet value
>         endfunction
>       endclass
> 
>       // now create error packets and inject into system under
>       // whatever conditions are desired
> 
>       // err_id allows debug to track packets through the system
>       // read/write counts are passive monitors
> 
> endprogram
> 
> 
> My understanding of Arturo's intent is to make such forms of
> design illegal since he wants completely separate design and
> program class hierarchies (common base types should be illegal).
> We don't believe that this is a good idea in that there
> are information hiding aspects to object polymorphism
> that make it desirable for one component of a system to
> add behavior that another component *should not* be aware
> of.
> 
> For transaction monitoring, error injection, protocol
> wrappers, etc. it is important that the system (dut)
> be able to use a basic form of classes and the program
> should be able to extend that beyond the basic protocol
> to layer other test functionality on top of the basic
> protocol.  This form of design permits the test abstractions
> to be cleanly hidden from the system.  It is easy to
> extend this paradigm through type parameters to make it
> even more general.
> 
> Gord.

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