[sv-bc] Proposal for virtual interfaces

At the meeting on 13 December 2010 I volunteered to work on a proposal to
improve the type checking of virtual interfaces. I have thought about two
alternatives that have been discussed, and I can see some strengths and
weaknesses in each of them, so I have tried to clarify both of them.

For a data type such as a class, the type definition and actual parameter
values are sufficient to determine the types of all components. For a design
unit this is not the case, because defparam statements may be used to alter
parameters. Furthermore, a design unit does not exist independently of its
instances, whereas a class exists before any instances (objects) are
created. Configurations can replace design units but not classes. The
generate construct means that elaboration depends very much upon parameters
to design units.

Virtual interfaces present a unique problem in that they have a data type
that refers to a design unit. A virtual interface may be assigned to
various interface instances in turn, and consequently the data types of the
interface components accessed can only be determined at run time. Run time
type determination creates an unacceptable overhead, so one of the interface
instances, with the same actual parameter values, is usually selected for
elaboration time type determination.

A better method would be for a virtual interface to have an "interface to an
interface" that has component data types which are determined at elaboration
time like those in a class. Then there could either be a strong typing
mechanism, where each interface instance is checked when it is elaborated,
or a weak typing mechanism, where the data types of the components on the
left hand side of the virtual interface assignment could be checked against
the corresponding components of the interface instance on the right hand
side of the virtual interface assignment.

There are two candidates for this "interface to an interface" construct: a
stand-alone modport and a pure interface. Either could be put in a package,
which would be needed for strong typing.

A modport is already a kind of "interface to an interface". However it does
not exist outside its interface and it does not include data types. Jonathan
Bromley has proposed stand-alone modports with parameters and data typed
items (see Mantis 1861). Such modports could be considered to be data
types. His proposal for receptacles in modules could be omitted, and
connectors in interfaces could be used with hierarchical names in
expressions. This would require the user to create local names and data
types in modports for such expressions, and the types would be checked at
interface instance elaboration. The local names would have to be used
instead of hierarchical names in code to access interface components.

Gordon Vreugdenhil has suggested the keyword "pure", which could be applied
to an interface by analogy with a pure virtual method. Such an interface
would have no sub-interfaces, external ports, generate blocks, processes,
tasks or functions. It would be necessary to introduce a means of giving a
data type to a hierarchical name, which would select an object yet to be
defined. One possibility would be to extend the alias declaration, but this
could have ramifications in existing parts of the language. It is safer to
create a new syntax.

pure_interface_declaration ::=

{ attribute_instance } pure interface interface_identifier

{ package_import_declaration } [ parameter_port_list ] {pure_interface_item
}

endinterface [ : interface_identifier ]

pure_interface_item ::=

  { attribute_instance } net_declaration

| { attribute_instance } data_declaration

| { attribute_instance } pure pure_net_or_data_declaration

| { attribute_instance } pure method_prototype

| { attribute_instance } modport_declaration

| { attribute_instance } extern_tf_declaration

pure_net_or_data_declaration ::=

                net_type ps_or_hierarchical_net_identifier constant_select

                {, ps_or_hierarchical_net_identifier constant_select } ;

data_type ps_or_hierarchical_net_identifier constant_select

                {, ps_or_hierarchical_net_identifier constant_select } ;

The pure interface should be used to define a virtual interface data type
and could also be used in a module port declaration. If a strong typing
mechanism is to be used, there needs to be a construct linking the ordinary
(instantiated) interface to the pure interface like the "extends" keyword
does with classes. One problem is that there would be some overlap between
a pure interface and an ordinary interface, and the question of whether a
pure interface could be instantiated and connected like an ordinary
interface would arise.

Although a pure interface could be considered to be a data type, it differs
from a class because it can contain wires (nets) and modports, and cannot
contain methods.

-- 
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.