Interface and Bundle Requirements

Accepted Requirements (draft)

The interface construct was originally prompted by the requirement for better support in order to enhance/solve the directional record problem encountered by engineers trying to simplify and improve structural interconnects between entity instantiations.

1. RTL Requirements- Light Weight -
   1. Must be synthesis capable
   2. Composite/Collection of objects
      • signal - required
   3. Create by declation, instantiation, ...
   4. Method to access elements/subelements that is independent of method or location of declaration
   5. Declare / specify on entity interface or subprogram interface
   6. Associate/Map on entity instance or subprogram call
   7. ?Generics
   8. Method for sizing unconstrained elements
   9. ?Support Shared Globals (Clk, Reset, ...) - similar to SV interfaces
      1. How do we handle globals like clk and reset? How does this impact events?
   10. Events - do we care whether events are on individual objects or as a composite
       1. What does event mean if the object is out mode?
       2. What about a collection of clocks?
       3. What about a collection of busses?
   11. Assignment to entire collection? TBD
       1. What if modes/directions are not all out or inout
       2. Would need use cases to validate if all out or inout is useful
       3. ?No because then a record could be used instead
   12. Composition
       1. Collecting other collections
       2. Collecting other modes
       3. ?Shared Globals (Clk, reset, ...)
   13. Access Control / Decomposition - similar to ModPort
       1. Direction control of objects
       2. support conjugate and monitor (all in) capability (via attribute or other)
       3. ?Shared Globals (Clk, reset, ...)
       4. ??Access to Subprograms
       5. ??Exclusion of objects
       6. Must support a access control/Decomposition declaration/specification
       7. ?Can access control happen directly on interface?
   14. Decomposition within a program (architecture / procedure)
       1. Assign to items of the collection
       2. Read individual items of the collection
   15. ??Subprograms
2. Behavioral Requirements
   1. Composite/Collection of objects
      • signal - required
      • shared variable - required (???regular variables???)
      • constant - ???
      • file - ???
      • terminal - required - (VHDL-AMS)
      • quantity - required - (VHDL-AMS)
      • bundle - required
   2. Create by declation, instantiation, ...
   3. Method to access elements/subelements that is independent of method or location of declaration
   4. Declare / specify on entity interface or subprogram interface
   5. Associate/Map on entity instance or subprogram call
   6. Support Generics
   7. Method for sizing unconstrained elements
   8. Support Shared Globals (Clk, Reset, ...) - similar to SV interfaces
      1. How to handle globals like clk and reset?
   9. Events - want events on individual objects
      1. What does event mean if the object is out mode?
      2. What about a collection of clocks?
      3. What about a collection of busses?
   10. Assignment? Only to elements within the collection
   11. Composition
       1. Collecting other collections
       2. Collecting other modes
       3. Shared Globals
   12. Access Control / Decomposition - similar to ModPort
       1. Directions of objects
       2. support conjugate and monitor (all in) capability (via attribute or other)
       3. ?Shared Globals (Clk, reset, ...)
       4. ?Access to Subprograms
       5. ???Import/Export of subprograms - big change -
          1. impure subprograms need to access ports of a local entity
       6. Exclusion of objects
       7. Must support a access control/Decomposition declaration/specification
       8. ?Can access control happen directly on interface?
   13. Decomposition within a program (architecture / procedure)
       1. Assign to items of the collection
       2. Read individual items of the collection
   14. Subprograms
       1. access interface internals
   15. Avoid compiler issues when integrating
       port ( A : MyMode MyType) ; -- VHDL already has this in some areas.
       port ( A : <MyMode> MyType) ; -- A fix, but there are many variations
       port ( A : MyType(MyMode)) ; -- A fix, but there are many variations
   16. Internal to a model, use an identifier to dynamically associate with one of 2 identical interfaces
   17. Virtual Interface
       1. Change interface instance
       2. Dynamically plug in a different testbench

Use Cases

1. Interface.doc 1.0.: Preface
2. Interface.doc 2.0.: Introduction
3. Interface,doc 3.1.: Transaction Based Testbench
4. Interface.doc 3.2.: RTL Bundles
5. Interface.doc 3.2.: RTL Simple Interface
6. Interface.doc 4.0.: Current Capabilities
7. Interface.doc 5.0.: Implementation Considerations
8. Interface.doc 6.0.: Interface Implementation
9. Interface.doc 7.0.: Historical Discussion
10. Proposal: Records with Directional Subtypes
11. Proposal: "Bus" port mode for bidirectional port signals
12. Proposal: Interface Construct and Port Mode Configurations
13. Proposal: Packages as an Interface Construct
14. IR2067: Logical link interface abstraction
15. IR2089: Directional Records
16. VHDL-200x FT17: Composite interface mode
17. Use Case: Minimal RTL Signal Based Interface

Delete the following after review of the above Accepted list:

Heterogeneous Interface Requirements

WG Minuted Requirements

• WG meeting - 14 May 2015:
• WG meeting - 28 May 2015:
• WG meeting - 11 June 2015:
• WG meeting - 9 July 2015:

WG meeting - 9 July 2015:

• Requirement: Bundles
  • Drivers
  • Individual Directions
  • Hierarchical composability
  • Events: on separate elements / subelements
  • Objects in a bundle: Signals, Shared Variables, AMS ...
  • Views of connection to bundle - simlar to ModPort