5. Things Reflected upon for VHDL-2008 revision, and then we ran out of time.

These are not solutons for going forward

5.1. Composites: Resolving Values vs. Specifying Element Direction

An interface at the minimum is a composite object. The composite must pass through a port in an entity. It has individual elements that can be either in, out, or inout with respect to the current design. Hence, a method to resolve drivers or specify element direction is needed. The following four methods will be considered:

• Require all elements to be resolved types
• Pass an undriven value up through the hierarchy
• Last driven value wins semantics
• Specify the mode (direction) of each element of a composite

5.1.1. Require All Elements to be Resolved Subtypes - currently supported

This approach uses resolved subtypes to allow multiple drivers on an interface object. In this method, all composite objects are inout on entity ports. Each element must be of a resolved subtype (such as std_logic). The composite is initialized so that all elements get a non-driving value ( 'Z'). To drive a value across the interface, only one driver can be providing an active (non-Z) value at a time. An example of a record and initialization value is shown in the section titled "Single Record + Package". This approach is limiting in that it requires a resolved type that has a representation for non-driven (such as 'Z' from std_logic). As a result elements that would be better to be represented as integer (such as TbErrCnt) and time (UartBaudPeriod) must be converted to either unsigned or std_logic_vector.

5.1.2. Pass an Undriven Value Through the Hierarchy - can do, but

This is an approach to work around having to use explicitly resolved subtypes. In this method, all composite objects are inout on entity ports. Elements of a composite that are not driven by a given model shall be made undriven (?through initialization, explicit assignment, or disconnect?). It may be necessary to either mark the subtype of the element (with an indication to use a default resolution method) or create a new object class that permits this (interface). The intent is that an undriven composite element behaves as if it were marked with mode in. In many ways this abuses the sense of inout. As a result, if a new interface object class is created, perhaps it should not require a mode at all.

5.1.3. Last Driven Value Wins - cannot do. Is not what we want! (Kludge)

This is another approach to work around having to use resolved subtypes. Create a new object class that maintains delta cycle assignment semantics of signals (so it has events), but rather than have multiple drivers, it only retains the last value assigned (similar to a variable). In this case, when a new value is deposited on an element of a composite object, that value becomes the effective value of the element.

5.1.4. Specify the Mode (direction) of Each Element of a Composite - cannot currently do

This approach specifies the direction of each element of a composite. As such it avoids the need for resolved subtypes (except when the element is inout) and avoids the abuse of the mode inout. This can be accomplished in a similar manner to SystemVerilog modports.

5.2. Packaging / Structure

There are often subprograms that are associated with operations on the composite object that is part of the interface. A couple of options for this are:

• Package + Record
• Class

What is the difference between a package and a class? Class:

• Inherits from a base class.
• If an externally defined extended class is visible then definitions inherited from base class are visible.
• If an externally defined extended class is visible then the base class is also visible?
• Subprograms defined in the extended class hide homographs in the base class.
• ?If a subprogram that is defined only in the base class is called for an extended class and that subprogram in turn calls a subprogram that is defined in both the extended class and the base class, then the subprogram from the ?extended? (or is it ?base?) class is called.
• Is a class a type? Can it be overloaded outside of the class definition?
• Could a class be a simple extension of a record declaration?

Package:

• Visibility of declarations in a package is gained by referencing the package
• Package can combine multiple extensions on a single type.
  Consider a basic math package such as numeric_std. In a separate package overloading can be provided for sin/cos functions. In another separate package overloading for square root can be provided. A program can reference all the packages and get the accumulated subprograms.