Re: [sv-ec] Interface Class discussion today

I will not have time to work on proposals before the new year at the
earliest.

The only reason that I mentioned that they should be functions is that
the methods had return types which isn't legal for tasks. In general
void functions more correctly express non-blocking intent and should
be used even for "put" if the "put" doesn't block.

Gord.

On 11/16/2010 10:00 AM, Alsop, Thomas R wrote:
>
> Hi Gord,
>
> Are you going to give us a first re-write of 8.19. Just want to know
> if you want me to make an attempt at clarifying this or if you have
> time. For the Mantis items that you opened (3278 and 3279), I linked
> them to 1356. The issues there are clear. Is there any further
> discussion needed in the ec meeting before a proposal is made? I am
> waiting for feedback on these two issues before I make the example
> changes below and to clarify the parameter type resolution and
> covariant solution.
>
> BTW, does it matter that the methods below are tasks or functions?
>
> Thanks, -Tom
>
> *From:*Gordon Vreugdenhil [mailto:gordonv@model.com]
> *Sent:* Tuesday, November 09, 2010 9: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 = logic);
>
> pure virtual function void put(T MyPutSignal);
>
> endclass
>
> interface class GetImp#(type T = logic);
>
> pure virtual function T get();
>
> endclass
>
> class Fifo#(type T_in = logic,
>
> type T_out = logic,
>
> DEPTH = 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 their argument list, only the final types of the parameters need to
> agree with each other, not agreement of parameter names. I believe
> that I have done this before with virtual classes.
>
> When you say that it won't work, are you referring to this line in the
> SV spec 8.19?
>
> Later, when subclasses override virtual methods, they shall
>
> follow the prototype exactly by having matching return types and
> matching argument names, types, and
>
> directions. It is not necessary to have matching default expressions,
> but the 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 necessarily require that parameter types have the same name.
> Obviously matching "exactly" isn't completely strict since an
> exception is already allowed for default expressions. As part of this
> proposal we can also add the exception 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
> method 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 = *logic*,
> *type* T_out = logic,
> DEPTH = 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 = *logic, string *MyPutSignal = "a");
>
> *pure virtual task void* put(T MyPutSignal);
>
> *endclass*
>
> *interface class*GetImp#(*type* T = *logic*);
>
> *pure virtual task *T get();
>
> *endclass*
>
> *class*Fifo#(*type* T = *logic*, DEPTH = 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 = *logic*, DEPTH = 1, *string *MyPutSignal =
> "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 types, 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 examples.
>
>
> --
> 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>
>
>
>
>
> --
> --------------------------------------------------------------------
> Gordon Vreugdenhil 503-685-0808
> Model Technology (Mentor Graphics)gordonv@model.com <mailto:gordonv@model.com>
>
>
>
> --
> --------------------------------------------------------------------
> Gordon Vreugdenhil 503-685-0808
> Model Technology (Mentor Graphics)gordonv@model.com <mailto:gordonv@model.com>

-- 
--------------------------------------------------------------------
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.