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> -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean.Received on Tue Nov 16 10:01:07 2010
This archive was generated by hypermail 2.1.8 : Tue Nov 16 2010 - 10:01:26 PST