Subject: [sv-ec] Ext-3 Virtual Interfaces
From: Jay Lawrence (lawrence@cadence.com)
Date: Fri Nov 21 2003 - 09:37:32 PST
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.
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.
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.
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".
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
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'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
lawrence@cadence.com
===================================
This archive was generated by hypermail 2b28 : Fri Nov 21 2003 - 09:38:55 PST