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

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.

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