3. Previous Work

3.1. Proposals for Interface Concept in VHDL

3.1.1. Suave and Follow-up Work

In the Sauve project, Peter Ashenden and Phil Wilsey propose various extensions to VHDL, some of which have been included in IEEE Std 1076-2008. Relevant to this discussion are the proposed extensions to the VHDL type system to adopt the object-oriented features of Ada-95. Record types are enhanced in various ways to enable deriving a new type D from an existing type E. If E is a tagged type, D may have elements not present in E. Following object-oriented principles, a subprogram S with a formal parameter P of type E can operate on objects of types E and D. Assuming a second subprogram S2 whose signature differs from that of S only in the type of P, which for S2 is D, then a function call with an actual of type D will execute S2 or S depending on whether S2 is visible or not. Abstract types are intended to be used as the root of a type derivation hierarchy, and abstract subprograms define a signature but have no body; they are intended to be overridden by a subprogram defined for a derived type.

Peter Ashenden extends this work in Object Orientation Revisited. VHDL protected types are reviewed, their relationship with class types is explored and extensions proposed. One of these extensions is the proposed introduction of an interface, modeled after the Java interface concept. "An interface declares the specifications for methods that a class must subsequently implement, but has no elements. The interface methods are implicitly abstract methods." A class type derived from an interface then provides an implementation for the methods defined in the interface. We note that this kind of interface does not bundle ports, but defines an abstract container for methods. Any bundling is implied by a class type that implements the interface.

3.1.2. Interfaces

This white paper by Jim Lewis was already mentioned above as the source of many requirements. It proposes to extend record types in two directions:

• Element declarations in the record type may be interspersed with extension declarations that specify the record type to be an extension of the type referred to in the extension declaration. Multiple extension declarations are allowed, thereby supporting multiple inheritance.
• Addition of record port declarations and subprogram declarations after all element declarations and extension declarations. A record port declaration specifies the port direction of the elements; multiple record port declarations may exist to defined alternative views of the interface. Subprogram declarations define methods of the type.

3.1.3. Records with Directional Subtypes

Peter Flake builds on earlier work, in particular FT17 Composite Interface Mode and IR2089 Directional Records, and proposes the use of a record type to represent an interface. Its elements are the ports of the design entity, more specifically their name and type. An extension of the subtype capability would then allow a user to define a subtype that combines the record type with a list of modes, one for each port.

3.1.4. Interface Construct and Port Mode Configurations

This contribution by Brent Hayhoe’s proposes an interface construct as a declarative region associated with a composite type. The interface specifies a mode for each element of the associated type, i.e. it defines a view of the type specific to a particular use in a model. The interface can appear in a port list just like interface signals.

3.1.5. Add "Bus" Mode for Bidirectional Port Signals

Brian Drummond’s proposal adds a new mode, tentatively called bus, to specify that the effective mode of the port be determined based on how the port object is driven and read: in if not driven, out if just driven, and inout if both driven and read. We observe that in this case the effective mode cannot be determined until the design is elaborated, which may prevent (or make harder) some optimizations done by commercial tools. There is neither a bundling of ports (other than that a port with mode bus can be of a record type) nor methods.

3.1.6. Protected Types with Public Signals

This idea suggests "allow[ing] public signals in a protected type declarative region", which would "allow protected type to be an abstract communication channel with similar capabilities to an interface in SystemVerilog." No details beyond this outline have been described. The protected type obviously has capabilities to define methods, and the public signals may allow some bundling in a way yet to be determined.

3.1.7. Logical link interface abstraction

This is IR2067 submitted in 2007. It proposes to introduce an interface construct that includes a generic clause and a port clause. The interface is then referred to in a port declaration in an entity or component (conceptually similar to a type, but the proposed syntax differs). There are no facilities for defining behavior in an interface.

3.1.8. Recent Email Discussions

3.1.8.1. March 5, 2015, Ernst Christen

Note: There is no corresponding twiki page, so the correspondence is here in its entirety. [...] In VHDL-AMS a port clause has been enhanced to include interface_quantity_declaration and interface_terminal_declaration, in addition to interface_signal_declaration. The syntax for these is: interface_quantity_declaration ::= quantity identifier_list : [ in | out ] subtype_indication [ := static_expression ] interface_terminal_declaration ::= terminal identifier_list : subnature_indication which parallels interface_signal_declaration ::=

[ signal ] identifier_list : [ mode ] subtype_indication [ bus ] [ := static_expression ] A quantity represents an unknown in a system of differential-algebraic equations that has to be solved simultaneously. Interface terminals allow a user to describe signal flow. A local terminal represents a node at which KCL/KVL hold, generalized to include non-electrical energy domains. An interface terminal becomes part of such a node through its association with an actual. The nature of a terminal defines its properties: the subtype of the across quantity (or potential, for electrical: voltage), the subtype of the through quantity (or flow, for electrical: current), and the reference terminal of the nature (i.e. ground). Natures exist as scalars, arrays and records, paralleling types. A subnature relates to a nature in a similar way as a subtype relates to a type. A collection of natures for electrical, thermal, mechanical, fluidic, and radiant systems has been standardized as 1076.1.1. The port clause of an entity whose architecture determines the power dissipated in the branch between the two terminals may now look as follows: port ( terminal plus, minus: electrical; -- electrical decl. in ieee.electrical_systems quantity power: out REAL; signal enable: in std_logic:= '0' ); The reserved word signal is added here for clarity. In port clauses of 1076-compliant descriptions it is usually omitted, but allowed. Getting back to the interface discussion, I noticed several emails in which a record type was used as the basis for an interface, e.g. >
> type r_cpu_bus is record
> adr: std_logic_vector(15 downto 0); -- Address
> dat: std_logic_vector(15 downto 0); -- Data between master and slave
> cs: std_logic_vector(7 downto 0); -- ChipSelect-bus from master
> we: std_logic; -- Write enable from master
> en: std_logic; -- Enable from master
> ack: std_logic; -- Acknowledge from slave
> err: std_logic; -- Error from slave
> end record r_cpu_bus;
The interface then derives from this and specifies just the mode of each record element: > interface i_cpu_bus of r_cpu_bus is
> port master(
> adr: out;
> dat: inout;
> cs: out;
> we: out;
> en: out;
> ack: in;
> err: in
> );
> port slave(master'converse);
> end interface i_cpu_bus;

In other words, the interface declaration augments the type to include modes. This is then used in a port clause: > entity cpu_master is
> port(
> rst: in std_logic;
> clk: in std_logic;
> cpu_bus: i_cpu_bus.master
> );
> end entity cpu_master;
Since the interface declaration appears in the port clause as an atomic piece, the interface object that is declared there has to be of a certain object class, in this case a signal. I am advocating that an interface be more flexible than this, that it should be extensible to allow the inclusion of terminals and quantities. This precludes a type as a starting point, and it makes the interface concept a new construct that bundles object declarations, something like interface r_cpu_bus is adr: std_logic_vector(15 downto 0); -- Address dat: std_logic_vector(15 downto 0); -- Data between master and slave cs: std_logic_vector(7 downto 0); -- ChipSelect-bus from master we: std_logic; -- Write enable from master en: std_logic; -- Enable from master ack: std_logic; -- Acknowledge from slave err: std_logic; -- Error from slave terminal t1: electrical_vector(7 downto 0); -- Added to demonstrate VHDL-AMS quantity q: inreal -- Added to demonstrate VHDL-AMS end interface r_cpu_bus; where object class signal is implied if omitted. An interface declared for a procedure could also include interface constants, interface variables and interface files. This can now be configured for a specific application: configuration r_cpu_bus_master of r_cpu_bus is adr: out; dat: inout; cs: out; we: out; en: out; ack: in; err: in; q: in; end configuration r_cpu_bus_master; and instantiated in a port clause: port ( rst: in std_logic; clk: in std_logic; interface r_cpu_bus_master ); or, as a direct instantiation: port ( rst: in std_logic;

clk: in std_logic; interface r_cpu_bus (adr: out, ...) ); These port clauses are equivalent to expanding the interface in place, i.e. the 'INSTANCE_NAME of a port that is part of the interface is the same as if the ports had been declared in the traditional way. In other words, the interface behaves as a macro. The drawback is that an interface can only be instantiated once, and there is a potential for name clashes. The alternative would be to give the interface instance a name, e.g. port ( rst: in std_logic; clk: in std_logic; ifc: r_cpu_bus_master ); and similar for a direct instantiation without configuration. Now, name spaces are preserved. Also, if a configuration is used, a 'CONVERSE attribute (or whatever its name will be) is possible, but it would be a stretch to also do this for a direct instantiation of the interface. I also thought about parameterizing the object class, as I suggested, which would allow changing a signal to a terminal in the configuration (or instantiation), but I reached the conclusion that the ROI is too small since it would add a lot of complexity particularly to a direct instantiation of an interface. This proposal adds the following items to the language

• The reserved word interface
• The interface declaration
• The interface configuration
• The interface instantiation

but there are obviously many open questions, for example:

• Where to declare interfaces and their configurations: in a package, as separate design units, elsewhere?
• Should it be possible to include a mode already in an interface declaration? If so, should it be possible to override it in a configuration or instantiation?
• Should it be possible to also parameterize the initial values? It's a trade-off between flexibility and complexity.
• Genericity, i.e. allowing type parameters for an interface (and once genericity is part of 1076.1, nature parameters)
• Detailed semantics for everything

3.1.8.2. March 6, 2015, Ernst Christen

[...] > According to your syntax, we could add object class like constant (?),
> variable or signal (the latter being the default). That would be nice,
> but don't forget that variable and signal are almost always
> incompatible. One possible solution is to not allow object declaration
– 10 – > from an interface where not possible (this would include quantity).
I added interface constant, interface variable and interface file to accommodate the formal parameters of subprograms. Depending on where an interface is instantiated (in a port list, a parameter list, a generic list, ...), semantic rules would have to exclude certain interface declarations, just like it's done for an interface list that is the basis of a generic clause, a port clause, and a formal parameter list. Some ideas are sketched out below. As a general concern, I feel that defining functionality by example is prone to lead to misunderstandings. I am guilty of this as much as the next person. Of course, working out every detail is not worthwhile in the early stages, but at least some context should be provided. Here is my attempt to make what I proposed somewhat more formal (with reserved words in bold): interface_unit_declaration ::= interface identifier is interface_list end [interface] [interface_simple_name] ; I use interface_unit_declaration because there is already an interface_declaration in VHDL. Let's for now postulate it is a package declarative item. I am not sure yet how to make it useful if declared elsewhere (except as a separate design unit, but this doesn't sound right). The interface elements in the interface_list are restricted depending on where the interface unit is instantiated: - in a port list: interface signal declaration, for 1076.1 also interface terminal declaration and interface quantity declaration - in a generic list: interface constant declaration, interface type declaration, interface subprogram declaration, interface package declaration, for 1076.1 also interface nature declaration - in a formal parameter list: interface signal declaration, interface constant declaration, interface variable declaration, interface file declaration It's possible to syntactically annotate the use of an interface list, by declaring it as port interface, generic interface, or parameter interface. No new reserved words, except interface are required. Doing this explicitly or just semantically is a choice to be made. Modes: There is a choice to be made whether an interface configuration should be able to override a mode appearing in one of the interface elements. If not, then interface object declarations must not have a mode. This is not a problem because in all interface object declarations with modes the mode is optional. I would argue that if an interface can be instantiated outside of an interface list then modes should not be allowed as part of the interface list. There may also be some other issues, for example a local signal may be declared as a register while an interface signal cannot. In addition, there is the staticness of an initial value expression: for an interface object the expression must be static, for a local object there is no such restriction. interface_unit_configuration ::=

configuration identifier of interface_simple_name is interface_unit_configuration_list end [configuration] [configuration_simple_name] ; The interface configuration may appear in a package. Should it be allowed somewhere else? I can think of an entity declaration, but it would have to precede the generic clause, or alternatively we would have to define an interface_unit_configuration as another interface element. This would also make it available in a subprogram declaration, but I haven't thought through the implications. interface_unit_configuration_list ::= interface_unit_configuration_element { ; interface_unit_configuration_element } interface_unit_configuration_element ::= interface_element_simple_name : interface_qualifier interface_qualifier ::= mode | type_name | subprogram_name | package_name The interface qualifier supports configuring the mode and the generic type, subprogram, or package, depending on the kind of the interface element. The allowable mode for an interface element depends on the object class of the interface element. To allow an interface to be used, the existing interface declaration has to be extended: interface_declaration ::= interface_object_declaration | interface_type_declaration | interface_subprogram_declaration | interface_package_declaration | interface_unit_declaration | ... This would also allow an interface to become part of an interface. There is an issue here: support for genericity. This would require combining an interface declaration containing generic types and possibly subprograms and packages with an interface declaration containing interface object declarations. I have not looked at how this could be done.

3.2. Interface Concept in Other Languages

In the subsections text quoted from LRMs. Rationales or papers uses a smaller font. The quotes have been modified to distinguish the interface concept from a generic use of the term.

3.2.1. Ada 2005, Java

The interface concept in a class based environment is present in both Ada-2005 and in Java.

• A Java interface seems to allow the declaration of both data members and abstract methods.

Programs can use interfaces to make it unnecessary for related classes to share a common abstract superclass or to add methods to Objects." This means interfaces have a capability to both bundle objects and to attach methods with them.

• From the Ada 2005 Rationale, 2.4 Interfaces:

Ada 2005 introduces the concept of an interface which is a tagged type with no components and no concrete operations. In other words, there are no bundling capabilities in an Ada interface.

3.2.2. SystemVerilog

From IEEE Std 1800-2012, 3.5 Interfaces: The interface construct [...] encapsulates the communication between design blocks, and between design and verification blocks [...]. At its lowest level, an interface is a named bundle of nets or variables. The interface is instantiated in a design and can be connected to interface ports of other instantiated modules, interfaces and programs. An interface can be accessed through a port as a single item, and the component nets or variables referenced where needed. [...] Additional power of the interface comes from its ability to encapsulate functionality as well as connectivity, making an interface, at its highest level, more like a class template. An interface can have parameters, constants, variables, functions, and tasks. [...]

3.2.3. SysML

The very brief overview of SysML interfaces is based on this paper. The SysML specification provides a precise model-based representation for interfaces and interactions. Interface specifications are described using SysML flow ports, operations, and signals which correlate to the system or component interface properties

3.3. Review

Interface concepts that are part of an OO framework (3.1.1, 3.1.2, 3.1.6, 3.2.1) are type based, i.e. they are extensions of the type system. This means that the data elements of an interface (the ports bundled by the interface) must have uniform execution semantics. The same is true for type based proposals that are not based on OO, such as 3.1.3 or 3.1.4. The conclusion comes from the way interface objects are declared in VHDL: object_class identifier_list : [ mode ] type_or_nature [ := default_expression ] where object_class is one of signal, quantity, terminal, constant, variable, shared variable, file. We conclude that any type-based approach to define an interface concept cannot support heterogeneous interfaces. Conversely, approaches that could support heterogeneous interfaces, such as 3.1.7 or 3.1.8 , do not fit well into the OO framework of tagged types etc. proposed in Suave. More to come...

4. Proposal for a VHDL Interface Concept

TBD