UCInterfaceDocImplemConsider < P1076/Ballots

P1076/Ballots Web>CollectedRequirements>P1076BallotsInterfaceAndBundleEnhancements>UCInterfaceDocImplemConsider (2016-11-15, BrentHahoe) (raw view)EditAttach
---+ 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. %BR% 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.
Topic revision: r4 - 2016-11-15 - 18:23:41 - BrentHahoe
P1076/Ballots