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: Tue, 9 Nov 2010 10:31:02 -0700
Subject: RE: [sv-ec] Interface Class discussion today

If I wasn't clear, I meant that as part of the proposal we would add a clar=
ification to 8.19 which would apply to all types of classes with virtual fu=
nction overrides. I am also opposed to exceptions being haphazardly added.

-Brandon

From: Gordon Vreugdenhil [mailto:gordonv@model.com]
Sent: Tuesday, November 09, 2010 10:24 AM
To: Tipp, Brandon P
Cc: Alsop, Thomas R; sv-ec@eda.org
Subject: Re: [sv-ec] Interface Class discussion today

Brandon,

I'm not disagreeing with the intent of what to do but we do need to
write up the rules in 8.19 a much more precise manner. What is there
has already led to issues. That is my only point -- that rewrite is
required in order to make it clear how the MI stuff is supposed to
work. I would absolutely oppose a different set of rules or a
clarification that only applied to the interface class proposal.

Gord.

On 11/8/2010 11:53 AM, Tipp, Brandon P wrote:
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<mailto: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<http://www.mailscanner.info/>, and is
believed to be clean.
--
--------------------------------------------------------------------
Gordon Vreugdenhil                                503-685-0808
Model Technology (Mentor Graphics)                gordonv@model.com<mailto:=
gordonv@model.com>
-- 
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.