HeterogeneousInterfaceRequirements < P1076

P1076 Web>Vhdl2019CollectedRequirements>Whiteboards>InterfaceWhiteboard>HeterogeneousInterfaceRequirements (2015-06-23, ErnstChristen) (raw view)EditAttach
---+ [[P1076.HeterogeneousInterfaces][Heterogeneous Interfaces]]

[[Main.ErnstChristen][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 [[http://www.eda.org/vasg/docs/Interfaces.pdf][Interfaces]], [[Main.JimLewis][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<span style="color: mediumblue;" class="WYSIWYG_COLOR"><span style="color: green;" class="WYSIWYG_COLOR"> Should support both synthesis and verification</span></span>

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? <span style="color: green;" class="WYSIWYG_COLOR">Read: data items should be grouped (not: data items related to a group)</span>
   * 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) <span style="color: green;">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.<br /></span>
   * 4. Support a "procedure like" call interface (SB3). Perhaps a procedure, but could be something else. <span style="color: green;" class="WYSIWYG_COLOR">(See comment to 2.)</span>
   * 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) <span style="color: green;" class="WYSIWYG_COLOR">There was a consensus to reject this requirement.</span>
   * 7. Contractual relationship that defines the "procedures" required of an implementation. (SB6)
   * 8. Support hierarchical connectivity between entities (SB7)
   * 9. <span style="text-decoration: underline;">Interface</span> should be extendable and/or parameterizable via generics (SB8)
   * 10. Ability to specify delay at the interface (SB9) <span style="color: green;" class="WYSIWYG_COLOR">Seems to come from the SV interface capabilities; not critical.</span>
   * 11. Support limited access to data items such that the value can only be accessed by a method in the <span style="text-decoration: underline;">interface</span>. <span style="color: green;" class="WYSIWYG_COLOR">Questionable, reject</span>
   * 12. <span style="text-decoration: underline;">Interface</span> should be configurable to select and/or remap any of the above during a given elaboration <span style="color: green;" class="WYSIWYG_COLOR">Vague, interpret as needed</span>
   * 13. An entity port list can have multiple <span style="text-decoration: underline;">interfaces</span> (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?) <span style="color: green;" class="WYSIWYG_COLOR">The goal is to have a smooth transition when going from one level of abstraction to another</span>
   * 15. Support mixed models in system (system-level mixed with rtl-level of a given interface. ?gate-level?) <span style="color: green;" class="WYSIWYG_COLOR">Same comment as 14.</span>
   * 16. Support modeling of multiple independent operations <span style="color: green;" class="WYSIWYG_COLOR">Emphasis is on bus operations</span>
   * 17. Avoid known quirks and issues with implementations in other languages<span style="color: green;" class="WYSIWYG_COLOR"> SV interfaces should serve as a guideline, but the proposal should be lightweight</span>

A recent reflector discussion has added a requirement to be able to easily define alternate interfaces from an existing interface. This has been summarized [[P1076.InterfaceAttributes][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 [[P1076.ProtectedTypeEntity][Protected Type on Entity Interface]]. This document revives part of section 2 Encapsulation in [[Main.PeterAshenden][Peter Ashenden's]] [[http://www.eda.org/vasg/docs/ESC-WP-012-oo-revisited-Rev-1_peter_ashenden.pdf][Object Orientation Revisited]], in particular subsection 2.2. [[Main.PeterAshenden][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. <span style="color: green;" class="WYSIWYG_COLOR">VHDL-AMS doesn't allow quantity declations in packages; ensure this isn't a problem</span>
   * 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 <span style="text-decoration: underline;">interfaces</span>. This implies that the port list may contain more than one <span style="text-decoration: underline;">interface</span>.
   * 22. Ability to compose an <span style="text-decoration: underline;">interface</span> from interface objects, both atomic ports and subinterfaces
   * 23. Ability to decompose an <span style="text-decoration: underline;">interface</span> into its elements
   * 24. Ability to associate an <span style="text-decoration: underline;">interface</span> port as a formal with an interface actual
   * 25. Ability to define different variants of an <span style="text-decoration: underline;">interface</span>. 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 <span style="text-decoration: underline;">interface</span> 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 <span style="text-decoration: underline;">interface</span>. <span style="color: green;" class="WYSIWYG_COLOR">Is this really a requirement? Implementations use port collapsing, so the default expression becomes questionable.</span>

At the meeting on May 28, 2015, the following additional requirements were identified:
   * <span style="color: green;" class="WYSIWYG_COLOR">27. The language extension for heterogeneous interfaces should not prevent optimizations done by modern implementations<br /></span>
   * <span style="color: green;" class="WYSIWYG_COLOR">28. It should be possible to use interfaces as parameters of concurrent procedure calls<br /></span>

---++ 2.2. Use Cases

In his [[http://www.eda.org/vasg/docs/Interfaces.pdf][white paper]], [[Main.JimLewis][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. <span style="color: green;" class="WYSIWYG_COLOR">Would be nice for a bundle, but not a strong requirement</span>
   * Are there any operations to be supported on an <span style="text-decoration: underline;">interface</span> 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. <span style="color: green;" class="WYSIWYG_COLOR">Agreed, operations on an interface as a whole do not make sense</span>
   * What are the requirements for <span style="text-decoration: underline;">interface</span> methods? <span style="color: green;" class="WYSIWYG_COLOR">Basic requirement is support for bus operations</span>
   * Are there other important use cases where an <span style="text-decoration: underline;">interface</span> 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
P1076