RE: [sv-bc] Instantiating gates, primitives and modules in interfaces

I am strongly sympathetic to Jay's and Kevin's views here.
Interfaces, and modports in their current form, make sense
only if you view interconnect as a traditional backplane 
with a bunch of identical sockets wired in parallel.  
Modports let you have more than one kind of 
socket on the backplane, but are of very little help
if you want uniquely-keyed sockets or more sophisticated
bus fabric arrangements.  Consequently, most people I've
talked to are inclined to use ordinary modules to create
bus fabric, and then perhaps use interfaces as a convenient
jacket for the point-to-point connections between each port
of the bus fabric and the corresponding bus port on a client 
module. That way you need one interface for each client that 
connects to a bus fabric.  This seems like a wasted 
opportunity - it ought to be easy to describe the bus
fabric, together with its "tentacles" that reach out to
each individual bus client, as an interface with a load
of modports on it.  Modport expressions and modports in
generate loops get you close to that, but if the bus 
fabric is complicated you would then need to be able to
instantiate other modules within it.

I would argue that the one and only unique characteristic
of interfaces is the modport; and I would further argue
that a modport should be something that is declared 
independently of its host interface, and can then be 
instantiated within an interface (or, perhaps, module).
Without modports as first-class objects, the generic
modport (where you declare a module's port as being
of type "interface.some_modport") is hopelessly weak;
there's limited type-checking of the modport that you 
try to map to such a port, and if you want the same
modport (interface aspect) to appear in more than one
interface, you're obliged to repeat the code in each.

The other two key features of interfaces are that you can 
have a port of interface type, which should be mapped
to an interface instance; and that you can create 
a variable that is a reference to an interface instance.
The latter (virtual interface - it's too late now to
bid for the more rational "ref interface" instead) is
an exceedingly useful thing for verification; but why
should it be restricted to interfaces?  In particular,
it would be great if we had a "virtual clocking" so 
that the variable could be bound to a chosen clocking
block instance rather than to the modport that
exports it; and I suspect there would be plenty
of interesting uses for "virtual program" and
"virtual module".  In this context, it's worth noting
that 'e' has only two fundamental sorts of object,
"units" and "structs" (cf. modules and classes);
units are statically instantiated, structs dynamically.
You can declare variables to reference either kind
of object.

I suggest that this discussion urgently needs some
well thought-out use cases before any further steps
are taken to alter the language.  I've already asked
for clarification about ways to achieve singleton
modports (I wonder if my message made it to the
reflector? I've had no response); I suspect there are
other sensible things that people might wish to do 
with interfaces and modports that have not yet been
adequately aired.  There are some very tricky issues
about partitioning the parameterisation of a bus-fabric
system - for example, if a slave wishes to occupy a 
certain address range, is that address range a property
of the slave or of the interface? - and I am fairly sure
that solving those problems in a robust and flexible 
manner requires interfaces to do more things for us 
than they do at present.  Kevin Cameron's frustration
about progressive refinement from a behavioural model
to an RTL model is another hobby-horse of mine too; 
once again it seems to me that interfaces nearly, but
not quite, do what you want.

-- 
Jonathan Bromley, Consultant

DOULOS - Developing Design Know-how
VHDL * Verilog * SystemC * e * Perl * Tcl/Tk * Project Services

Doulos Ltd. Church Hatch, 22 Market Place, Ringwood, Hampshire, BH24 1AW, UK
Tel: +44 (0)1425 471223                   Email: jonathan.bromley@doulos.com
Fax: +44 (0)1425 471573                           Web: http://www.doulos.com

This e-mail and any  attachments are  confidential and Doulos Ltd. reserves 
all rights of privilege in  respect thereof. It is intended for the use of 
the addressee only. If you are not the intended recipient please delete it 
from  your  system, any  use, disclosure, or copying  of this  document is 
unauthorised. The contents of this message may contain personal views which 
are not the views of Doulos Ltd., unless specifically stated.