Subject: RE: [sv-ec] Ext-3 Virtual Interfaces
From: David W. Smith (David.Smith@synopsys.com)
Date: Mon Nov 24 2003 - 10:33:56 PST
Hi Jay,
The timing was based on the fact that we had answered all questions at the
last meeting and thought we had all issues in. Clearly this was not the case
and we will take the time to make sure we get closure.
Regards
David
-----Original Message-----
From: owner-sv-ec@eda.org [mailto:owner-sv-ec@eda.org] On Behalf Of Jay
Lawrence
Sent: Monday, November 24, 2003 5:37 AM
To: Arturo Salz; sv-ec@server.eda.org
Subject: RE: [sv-ec] Ext-3 Virtual Interfaces
Thanks for the comments Arturo. Obviously I don't understand this proposal
after reading it 3 or 4 times, which is reason enough to vote NO on email
and have it better explained in today's meeting.
David, you've only got 10 minutes on the agenda for this today. It sounds
like it will need more discussion/explanation than that.
Jay
===================================
Jay Lawrence
Senior Architect
Functional Verification
Cadence Design Systems, Inc.
(978) 262-6294
lawrence@cadence.com
===================================
-----Original Message-----
From: Arturo Salz [mailto:Arturo.Salz@synopsys.com]
Sent: Monday, November 24, 2003 3:02 AM
To: Jay Lawrence; sv-ec@server.eda.org
Subject: Re: [sv-ec] Ext-3 Virtual Interfaces
Jay et al,
My comments are embedded below.
Arturo
----- Original Message -----
From: "Jay Lawrence" < <mailto:lawrence@cadence.com> lawrence@cadence.com>
To: " <mailto:sv-ec@server.eda.org> sv-ec@server.eda.org" <
<mailto:sv-ec@eda.org> sv-ec@eda.org>
Sent: Friday, November 21, 2003 9:37 AM
Subject: [sv-ec] Ext-3 Virtual Interfaces
Neil et al.,
This proposal does 2 general things.
It allows an "interface" to be passed as an argument to tasks and
functions, and it defers the binding of an interface in a class instance
until the constructor is called.
That statement is incorrect. A virtual interface is not just a deferred
binding
of an interface in a class instance. That particular case happens to be one
of the examples because it is a common modeling idiom. A virtual interface
is a data type that allows declaring variables of that interfacce type (not
an
instance of that interface type). Thus, a virtual interface can be bound to
an
interface instance, it can be passed as an argument, it can be stored, and
its binding can be changed or removed.
Tasks and Functions as arguments
--------------------------------
It is unclear to me whether the addition of "interface" as a data type
to tasks, functions, and methods was intended as a global change
throughout SystemVerilog, or only in the context of classes. I don't
think we can allow them inside classes unless they are also allowed in
general tasks and functions.
Again, this is incorrect. The proposal does not restrict the use of virtual
interfaces to classes. It does state that a virtual interface can be used as
a class property, but that is not a restrictive clause. Virtual interfaces
are
most certainly allowed in general tasks and functions. The proposal
states that explicitly, and Section 19.8.1 includes an example of such a
task.
I believe that adding "interface" to all tasks and functions would be
very powerful. In particular the same modeling style that Neil espouses
with classes could be applied in general to tasks/functions declared in
packages.
We agree. The proposal does support such usage.
Deferred binding of interface in a class
----------------------------------------
I have 2 different related issues with this concept:
1) If this deferring of associating an object in a class can only happen
with interfaces, then we should probably just use the term interface
instead of virtual.
2) If this deffing of associating an object in a class can happen with
other objects (for instance a register), then we should associate a type
with the "virtual".
Neither one of these is correct. The first point is wrong since virtual
interfaces are not limited to classes. Firthermore, it ignores the fact
that using the term "interface" becomes ambiguous with the syntax
for generic interfaces. Perhaps the different semantics may be
disambiguated based on the context, but context disambiguating
rules are undesirable because they simply shift the ambiguity to the
user ane result in more confusion. We chose the virtual keyword to
designate the special semantics explicitly.
The second point seems to be an enhancement request to add this
type of capability to other objects, without specifying what those objects
might be or how they would work. Regardless of the merits of such an
enhancement, it does not diminish or negate the current proposal.
Extension 3 was proposed in response to an explicit customer request.
The suggestion that the virtual keyword be allowed with other objects is
merely an idea that needs more thought. The current proposal is limited
to interfaces because it addresses the requirements, its mechanics and
semantics are well understood, and it is implemented.
If case #1 above holds, on modules we already allow:
module cpuMod(interface b, input bit clk);
...
endmodule
Why wouldn't we just substitute the word "interface" everywhere you use
"virtual". It would be much more descriptive for what is actually
happening.
typedef interface A_Bus.STB SYNCTB;
task request( SYNCTB s );
s.sb.req <= 1;
endtask
Whether the term interface or virtual best describes what is happening,
is a matter of opinion. We settled on the term virtual because the term
interface seemed to create more confusion.
An interface is not a data type. A virtual interface is a data type. Using
the
term interface looks too much like an interface declaration, especially when
declaring virtual interfaces at the module or the compilation-unit level.
The declaration
module cpuMod(interface b, input bit clk);
has a very different meaning. It defines 'b' as a port of type interface,
any
interface. The specific interface is determined by the module instantiation.
Virtual interfaces always refer to an explicit interface type: the
declaration
task foo ( interface b );
is illegal. Whether we use "virtual interface X" or just "virtual X" is a
valid
topic for discussion. We felt the shorter form was sufficient.
If case #2 above holds then why wouldn't we also support something like:
Class C
virtual interface A_Bus bus
virtual Packet packet;
function new( virtual SBus s, virtual Packet p );
bus = s; // initialize the virtual interface
packet = p; // initialize the virtual register
endfunction
...
Endclass;
This would allow late binding of all data objects for a class (it
essentially alias them in the constructor instead of copying the value).
I'm confused by the above example. First, In Verilog it's poor form to
differentiate a type and a variable only by capitalization. Second,
what is Packet? Is it a class? Is it a user-define type?
If Packet is a class or some user-defined type then the assignment
"packet = p" is already allowed and use of the virtual keyword for this
is superfluous. Conversely, an interface cannot currently be assigned
this way. So use of "virtual A_Bus" brings something new to the
language.
I'ld like to better understand the intent here before voting in the
affirmative in the pending email vote therefore I'll be voting "NO"
today with discussion to follow on Monday.
Jay
===================================
Jay Lawrence
Senior Architect
Functional Verification
Cadence Design Systems, Inc.
(978) 262-6294
<mailto:lawrence@cadence.com> lawrence@cadence.com
===================================
This archive was generated by hypermail 2b28 : Mon Nov 24 2003 - 10:36:27 PST