Heterogeneous Interfaces

Ernst Christen, Mentor Graphics

1. Introduction

As part of the work on P1076-201x, several proposals have been made that aim at providing additional functionality for defining the connections of design entities. This contribution first documents a collection of requirements for the desired capability. It then reviews the existing proposals, earlier work on interfaces, and approaches used by other languages. Finally, it proposes language extensions that build on previous work but that also look beyond the needs of P1076.

In the following I have tried to distinguish between two different uses of the term interface. If the term is used as a noun to refer to a language construct, it is underlined, otherwise regular font is used (e.g. "The interface can appear in a port list just like interface signals"). Reserved words are in bold.

2. List of Requirements for Interfaces, Use Cases

In his 2006 white paper on Interfaces, Jim Lewis describes a number of requirements and use cases.These are listed in 2.1 and 2.2, with comments/additions from the WG meetings in green.

2.1. List of Requirements

The following requirements were collected in a spreadsheet by the Accellera VHDL-TC for the 2008 revision of the language:

  • FT17-1 More concise representation to specify complex interfaces (supporting for example transactors, complex buses) (perhaps by using a record type with element modes)
    • Should be considered with OO
    • Should be considered with transactions
    • Should be synthesizable
  • FT17-3 Ensure that it can create a synthesizable level of abstraction Should support both synthesis and verification

Additional requirements and considerations, also listed in the white paper, come from a reflector discussion (SB stands for Steve Bailey):

  • 1. Group related data items (SB1). Similar to a record? Read: data items should be grouped (not: data items related to a group)
  • 2. Define behavior in a manner that can be reused within the design (SB2)
  • 3. Support multiple levels of abstraction (signals vs. bus operations vs. groups of operations (init)) (SB3) It may be worthwhile to distinguish between the bundling aspects (by means of a bundle) and the OO aspects that also contain behavior (by means of an interface). Also look whether the VHDL group mechanism could be reused here.
  • 4. Support a "procedure like" call interface (SB3). Perhaps a procedure, but could be something else. (See comment to 2.)
  • 5. User of interface only needs to understand the call interface. Implementation could be serial or parallel transmission. (SB4)
  • 6. Procedure interface does not block the caller (SB5) There was a consensus to reject this requirement.
  • 7. Contractual relationship that defines the "procedures" required of an implementation. (SB6)
  • 8. Support hierarchical connectivity between entities (SB7)
  • 9. Interface should be extendable and/or parameterizable via generics (SB8)
  • 10. Ability to specify delay at the interface (SB9) Seems to come from the SV interface capabilities; not critical.
  • 11. Support limited access to data items such that the value can only be accessed by a method in the interface. Questionable, reject
  • 12. Interface should be configurable to select and/or remap any of the above during a given elaboration Vague, interpret as needed
  • 13. An entity port list can have multiple interfaces (interfaces here being more like a composite type and not a separate IO list).
  • 14. Support decomposition of the system (from system level to rtl level and/or ?gate-level?) The goal is to have a smooth transition when going from one level of abstraction to another
  • 15. Support mixed models in system (system-level mixed with rtl-level of a given interface. ?gate-level?) Same comment as 14.
  • 16. Support modeling of multiple independent operations Emphasis is on bus operations
  • 17. Avoid known quirks and issues with implementations in other languages SV interfaces should serve as a guideline, but the proposal should be lightweight

A recent reflector discussion has added a requirement to be able to easily define alternate interfaces from an existing interface. This has been summarized here.

  • 18. Ability to derive an interface from another using simple means, e.g. reversing modes in and out.

I would like to add the following requirements:

  • 19. Ability to support the needs of block verification and SoC verification
  • 20. Extensibility to support objects other than signals as ports. Let's call this a heterogeneous interface.
    • Shared variables, as proposed in Protected Type on Entity Interface. This document revives part of section 2 Encapsulation in Peter Ashenden's Object Orientation Revisited, in particular subsection 2.2. Peter observes that "a facility to declare interface variables of protected types for components and entities and to associate actual shared variables with such interface variables" is missing in VHDL. "We are limited to using a given shared variable only within a single design entity, or to making a shared variable global by declaring it in a package." He then proposes to extend the port interface list for an entity or component with an interface shared variable declaration.
    • Quantities and terminals, which are port kinds defined by VHDL-AMS. VHDL-AMS doesn't allow quantity declations in packages; ensure this isn't a problem
  • 21. Ability of a port list to contain an arbitrary sequence of traditional ports (i.e. signals, shared variables; for VHDL-AMS also quantities and terminals) and interfaces. This implies that the port list may contain more than one interface.
  • 22. Ability to compose an interface from interface objects, both atomic ports and subinterfaces
  • 23. Ability to decompose an interface into its elements
  • 24. Ability to associate an interface port as a formal with an interface actual
  • 25. Ability to define different variants of an interface. The intuitive discriminator of such variants is the collection of modes for the elements of the interface, including:
    • No modes, to allow the declaration of an interface in a way similar to an object declaration.
    • Different combinations of modes for different needs, e.g. master, slave, monitor. Such variants are intended for the declaration of formal ports of an entity or component.
  • 26. Ability to specify, in the declaration of an interface object, a default expression for each element of the interface. Is this really a requirement? Implementations use port collapsing, so the default expression becomes questionable.

At the meeting on May 28, 2015, the following additional requirements were identified:

  • 27. The language extension for heterogeneous interfaces should not prevent optimizations done by modern implementations
  • 28. It should be possible to use interfaces as parameters of concurrent procedure calls

2.2. Use Cases

In his white paper, Jim postulates that interfaces should be seen as part of a methodology rather than just a feature, and he describes two main use cases where interfaces would add benefit.

2.2.1. Transaction Based Testbench

In this use case, some of the behavior of a model with a given set of ports is pulled into the interface, but made available to the model as a procedure. As a result, the interface is not just an (ideal) connection, but has behavior of and by itself. The example given is that of a bus functional model where pulling behavior into the interface makes it possible to replace the interface and associated behavior with a different representation without affecting the core of each model, provided the procedures of the two representations have the same signature. Of course, behavior abstracted in this way is restricted to that describable in a procedure.

2.2.2. RTL Design

The description of this use case focuses on bundling ports, giving the bundle a name, and allowing the creation of variants of the bundle with different properties: different modes, or different subsets of the bundle. As an extension, methods could be added to a bundle, similar to what was described in the previous section, but the concern is raised that this might not scale beyond simple interfaces. Instantiation of a component in the interface is mentioned to address this concern. The conclusion is that simple bundling of ports would add a significant value, while the benefit of modeling behavior in the interface is questionable.

2.3. Open Questions

We should clarify the following questions:

  • Should the concept also be able to define the formal parameter list of a subprogram and the generic list of an entity header, block header, or package header? This would also require variables, constants, files, types, and subprograms to be part of the interface. Would be nice for a bundle, but not a strong requirement
  • Are there any operations to be supported on an interface as a whole, other than a port association? I doubt this to be the case, because an interface object can only be read (assigned to) if all its elements have mode in or inout (out or inout). For this reason I postulate that only the elements of the interface can be operands of an operator, never the interface as a whole. Agreed, operations on an interface as a whole do not make sense
  • What are the requirements for interface methods? Basic requirement is support for bus operations
  • Are there other important use cases where an interface concept would be useful?

2.4. Review

Considerations

This is from the WG meeting on May 28, 2015:

  • Focus on structural bundling: Need good and flexible bundling model
  • Composition/decomposition of interfaces: Is this only at the level of declaration, or also when using them (some kind of slicing)? Private/public data objects?
  • Creation of the data objects: declaration or instantiation? If instantiated, is it part of the design hierarchy? This matters in the context of external names.
  • Parameterization, e.g. to define a bus width. What about generic types?
  • Is there a benefit to define a homogeneous bundle, which would be more like tagged types in Suave?
  • When associating an interface, is association in parts a requirement? If so, what is the order of the elements of an interface? This would be relevant for positional association.
Topic revision: r4 - 2015-06-23 - 13:16:28 - ErnstChristen
 
Copyright © 2008-2024 by the contributing authors. All material on this collaboration platform is the property of the contributing authors.
Ideas, requests, problems regarding TWiki? Send feedback