RE: [sv-ec] Interface Class discussion today

<forwarding bounced email from Tipp, Brandon>

-------- Original Message --------
From: "Tipp, Brandon P" <brandon.p.tipp@intel.com>
To: Gordon Vreugdenhil <gordonv@model.com>
CC: "Alsop, Thomas R" <thomas.r.alsop@intel.com>,
         "sv-ec@eda.org"
        <sv-ec@eda.org>,
         "Tipp, Brandon P" <brandon.p.tipp@intel.com>
Date: Mon, 8 Nov 2010 12:53:40 -0700
Subject: RE: [sv-ec] Interface Class discussion today

If I can summarize, the question is if this is legal?

interface class PutImp#(type T =3D logic);
   pure virtual function void put(T MyPutSignal);
endclass

interface class GetImp#(type T =3D logic);
   pure virtual function T get();
endclass

class Fifo#(type T_in =3D logic,
             type T_out =3D logic,
             DEPTH =3D 1) implements PutImp#(T_in), GetImp#(T_out);
    T_in [DEPTH-1:0] myFifo;
    virtual function void put(T_in a);
       // Put implementation
    virtual function T_out get();
       // Get implementation

The question is that the prototype of put doesn't look exactly the same in =
Fifo and PutImp because the name T has been changed to T_in.
This should be legal. For function prototypes that use parameter types in t=
heir argument list, only the final types of the parameters need to agree wi=
th each other, not agreement of parameter names. I believe that I have don=
e this before with virtual classes.

When you say that it won't work, are you referring to this line in the SV s=
pec 8.19?
Later, when subclasses override virtual methods, they shall
follow the prototype exactly by having matching return types and matching a=
rgument names, types, and
directions. It is not necessary to have matching default expressions, but t=
he presence of a default shall match.
I find this to be somewhat ambiguous with respect to parameter types. The =
spec states that it must have matching argument types, but that doesn't nec=
essarily require that parameter types have the same name. Obviously matchi=
ng "exactly" isn't completely strict since an exception is already allowed =
for default expressions. As part of this proposal we can also add the exce=
ption that parameter type names do not need to match exactly, but the final=
  types must exactly match.

-Brandon

From: Gordon Vreugdenhil [mailto:gordonv@model.com]
Sent: Monday, November 08, 2010 12:29 PM
To: Gordon Vreugdenhil
Cc: Alsop, Thomas R; sv-ec@eda.org; Tipp, Brandon P
Subject: Re: [sv-ec] Interface Class discussion today

Oh, those should both be "function" and not "task" throughout Tom's
original and my modification.

Gord

On 11/8/2010 11:28 AM, Gordon Vreugdenhil wrote:

Tom, here is what I had in mind. Now, clearly, the rules for virtual metho=
d overrides
don't work for implementing "virtual taks void put (T_in a)" since the name=
  of
the type T_in is not identical to the name of the type T in the base.
class Fifo#(type T_in =3D logic,
             type T_out =3D logic,
             DEPTH =3D 1) implements PutImp#(T_in), GetImp#(T_out);
    T_in [DEPTH-1:0] myFifo;
    virtual task void put(T_in a);
       // Put implementation
    virtual task T_out get();
       // Get implementation
endclass

Gord

On 11/8/2010 11:01 AM, Alsop, Thomas R wrote:
For discussion today... I tried adding another type to the PutImp below and=
  I want to walk through it to get clarification on if this makes sense, if =
this is what was asked for and how to put rules behind it, as requested two=
  weeks ago. More to come. -Tom

interface class PutImp#(type T =3D logic, string MyPutSignal =3D "a");
   pure virtual task void put(T MyPutSignal);
endclass

interface class GetImp#(type T =3D logic);
   pure virtual task T get();
endclass

class Fifo#(type T =3D logic, DEPTH =3D 1) implements PutImp#(T), GetImp#(T=
);
    T [DEPTH-1:0] myFifo;
    virtual task void put(T, a);
       // Put implementation
    virtual task T get();
       // Get implementation
endclass

class MyQueue(type T =3D logic, DEPTH =3D 1, string MyPutSignal =3D "a");
    T [DEPTH-1:0] PipeQueue[$];
    virtual function void deleteQ();
        // Delete implementation
    endfunction
endclass

class Fifo extends MyQueue#(T, DEPTH), implements PutImp#(T), GetImp#(T);
    virtual task void put(T, b);
       // Put implementation
    virtual task T get();
       // Get implementation
endclass

Need more interesting types instead of just 'T'. Pass in two different typ=
es, have put and get use two different types working in each case. Why not=
  explicitly state this?. So we need rules behind them and not just example=
s.

-- 
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.