Interface Semantics Discussion

Interface construction within VHDL is largely supported by composite types, which include array types and record types.

These allow multiple elements to be grouped together with either a common type (arrays) or different types (records).

These types can be associated with objects, of class constant, signal, or variable.

Interface Requirements

  1. The ability to control directionality of composite type objects at interface boundaries.
  2. The ability to add into, or strip out from a composite type object, individual elements (e.g. clocks and resets) with zero delta delays incurred.
  3. The ability to group together objects of class signal and subclass shared variable as a named interface construct (heterogeneous interface).

The Element Mode Problem

The main problem is encountered when the objects, of class signal and variable are declared( as a composite type) at an entity or procedure interface and this is the ability to assign different modes to each element (or subelement).

Objects of class variable are routeable within their process or subprogram environment through the interfaces of other subprogram instantiations.

Objects of class signal are also routeable hierarchically above these levels through the interfaces of entity instantiations and block statements as well as subprogram interfaces.

This problem can be addressed with the new (port) view construct concept.

Access of Objects via Package Scope

However objects of class signal can be declared within a package which can then be accessed globally via their scope alone, i.e. they are not necessarily routed.

In this way they are similar to the object subclass shared variable which is only accessible via its scope and more specifically through the methods declared by its associated protected type. They are not routeable.

For verification environments, a heterogenous mechanism to allow the association of these objects could be something like the group construct. This is not viable as the group construct specifically precludes a shared variable from inclusion within a group.

A new similar heterogenous interface grouping construct could allow this function, but it is probably sensible to limit this grouping to shared variables and global signals (and if required signals with variables). Is it worth adding a new keyword to define a new subclass of signal declared in package as a global signal ?

-- Brent Hayhoe - 2016-08-18

Comments

Topic revision: r2 - 2016-08-19 - 12:18:10 - BrentHahoe
 
Copyright © 2008-2025 by the contributing authors. All material on this collaboration platform is the property of the contributing authors.
Ideas, requests, problems regarding TWiki? Send feedback