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

From: Joao Geada <jgeada_at_.....>
Date: Sat Apr 29 2006 - 07:56:04 PDT
I see things slightly differently:

I've always believed that, fundamentally, interfaces should be a cross
between modules and classes.
A completely new kind of thing, rather than just a limited module. In my
view, an interface must be
able to describe (from the most generic level through to detailed
implementation) both the
protocol (incl the logic implementing that protocol) being carried by a set
of wires and the
wires themselves. In a sense it would be a design concept separating data
transport from all the
details necessary to get that data carried at the right performance with the
right expectactions
from A to B (and C, ...)

In this view, the tasks and functions described in the interface are the
means to access the protocol
without having to be tied to a particular actual implementation. Each
instance of the interface
represents an instance of the "bus", and a reference to this instance just
implies connectivity to
said bus (that is much like it is in the standard now)

In addition, to fully flesh this idea out, interfaces would have to be able
to have "private" parts
describing the implementation of the protocol. This private part would
consist of pretty much anything
you can put into a module, but *none* of these items would be visible
outside the interface. No hierarchical
references, nothing. This implementation part would be accessible only
through the defined interface ports
and/or the exposed tasks/functions. And yes, this means even testbenches
would have to talk to the interface
of the interface to get information. [I'd let the VPI interface have read
access to all the private stuff;
yes, it is a backdoor, but important for debuggers, etc]

Continuing with this view, it then becomes required that interface have
inheritance, just like class inheritance.
In my opinion virtual interfaces are almost completely useless, even though
they introduce significant
complexity: there is currently no way to narrow down what kind of an
interface is expected. I think it
is essential to be able to structure interfaces into a hierarchy of
capabilities
(eg GenericBus -> SerialInterface -> USB -> Wireless USB)
so that each part of the system (be it testbench or design) can be written
at the most generic level
appropriate. This would improve reuse, permit easier design/testbench
structuring and would enable
higher level design and (just as important) provide a refinement path to
take a high level design
into a realizable implementation.

Being realistic, this view was on the losing end of a debate a long time ago
and it is way
too late to get this approach into the language now. But I still dream :-)

--
Joćo 
Received on Sat Apr 29 07:55:42 2006

This archive was generated by hypermail 2.1.8 : Sat Apr 29 2006 - 07:55:54 PDT