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.

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?

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.

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