RE: [sv-ec] Multiple Inheritance Proposal

<forwarding bounced email from brandon.p.tipp@intel.com>

From: "Tipp, Brandon P" <brandon.p.tipp@intel.com>
To: Gordon Vreugdenhil <gordonv@model.com>,
         "Alsop, Thomas R"
        <thomas.r.alsop@intel.com>
CC: "sv-ec@eda.org" <sv-ec@eda.org>,
         "Tipp, Brandon P"
        <brandon.p.tipp@intel.com>
Date: Mon, 16 Aug 2010 16:09:28 -0700
Subject: RE: [sv-ec] Multiple Inheritance Proposal

I just saw Tom's response, and he had the exact opposite answer that I do because he
started off contradicting my first assumption... Is that really how it works in SV?
When you extend a parameterized class you still have visibility into the extended
class's parameter? I've seen this work in SV:

class B #(T type = int);
endclass
class A #(T type = int) extends B(.T(T));
endclass

I would think that if the parameter T from class B is visible inside class A, then
there should be a collision that shouldn't compile today.

See the answers that I was working on below...
======================================================

Your questions are focused on the visibility of a parameter from a parameterized
class by a class which implements the parameterized class. I don't see this as
being any different than what already exists in SV. I believe that a class which
extends a parameterized class (or parameterized virtual class or parameterized
pure virtual class) has no visibility of that parameter.

class myA implements A #(.p(5));
   // there is no visibility of p inside this class
   // therefore myA is free to re-define p
endclass : myA

If I'm mistaken, and myA has visibility of "p", then that would affect my
answers below. See below for answers to your specific examples.

-----Original Message-----
From: Gordon Vreugdenhil [mailto:gordonv@model.com]
Sent: Monday, August 16, 2010 2:40 PM
To: Alsop, Thomas R
Cc: sv-ec@eda.org; Tipp, Brandon P
Subject: Re: [sv-ec] Multiple Inheritance Proposal

Tom and Brandon,

Thanks for the initial directions.

Just to check my understanding of what you posted, given:

    pure virtual
    class A#(p = 1);
       pure virtual function int f();
    endclass

    pure virtual
    class B#(p = 1);
       pure virtual function int g();
    endclass

It would be impossible for any class to implement
both a specialization of A and a specialization of
B since both classes have a symbol (the parameter)
named "p".

Is that a correct implication of the intent?
=======================================================================
[Tipp, Brandon P] I believe that this case should be acceptable. Any class which implements A or B or both will have no visibility into the parameter p, so there is no collision.

The intent of the rule is to avoid collisions with methods (and potentially data members) defined within the class, especially since SV doesn't support method overloading. This restriction is to help
simplify eda tools while enforcing what I would consider to be a good coding guideline.
=======================================================================

Essentially it becomes the user's responsibility to make
sure that all names are distinct between any set of
classes which participate in an "implements" clauses.

As a second question, if a class "implements" A#(5),
what is the compatibility rule for symbols? For
methods, I assume that the rules are essentially
the "overriding" rules, but what about other symbols?

For example, given my defn of "A" above, which of the
following would be legal (clearly some are not correct
in terms of intent, but what is legal and what is the
rule constraining legality):

1)
     class myA implements A#(7);
       function int f(); return 1; endfunction
     endclass

2)
     class myA implements A#(7);
       localparam p = 5;
       function int f(); return 1; endfunction
     endclass

3)
     class myA implements A#(7);
       static int p = 5;
       function int f(); return 1; endfunction
     endclass

4)
     class myA implements A#(7);
       typedef int p;
       function int f(); return 1; endfunction
     endclass
=======================================================================
[Tipp, Brandon P] I think that all of the above should be legal since myA should not have visibility into A::p.
=======================================================================

5)
     class myA extends B#(7) implements A#(5);
       function int f(); return 1; endfunction
       function int g(); return 1; endfunction
     endclass

=======================================================================
[Tipp, Brandon P] This should not compile/elaborate: The rule is that a class may extend 0 or 1 class or virtual class; you cannot extend a pure virtual class. I don't see any problem with this however:
     class myA implements B#(7), A#(5);
       function int f(); return 1; endfunction
       function int g(); return 1; endfunction
     endclass
=======================================================================

6)
     class myA extends B#(7) implements A#(7);
       function int f(); return 1; endfunction
       function int g(); return 1; endfunction
     endclass
=======================================================================
[Tipp, Brandon P] Same as above for the same reason.
=======================================================================

I have some additional intent and expectation questions
but would like to understand the visibility assumptions
and constraints that you expect first.

Gord

--
--------------------------------------------------------------------
Gordon Vreugdenhil                                503-685-0808
Model Technology (Mentor Graphics)                gordonv@model.com
-- 
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.