6. Interface Implementation

6.1. Base-line Implementation

Interfaces are a methodology. As such to implement them, it is permissible to leverage existing constructs. Since this revision effort has a goal of minimizing additional keywords, it seems reasonable to first try to use or extend current language features.

This proposal extends records to create a simple interface. Concurrency in this approach will be implemented in an entity/architecture. The record allows definition of a composite type. Records are extended with OO features using a use clause and specifying a type. IO direction of elements is declared using a port declaration. Records are extended to allow subprograms to be declared within the construct. The syntax definition is as follows:

   record_type_definition ::=
      record
         element_or_extension_declaration
         {element_or_extension_declaration}

         {port_or_subprogram_declaration}

      end record [ record_type_simple_name ]

   element_or_extension::= element_declaration | extension_declaration

   element_declaration ::= identifier_list : element_subtype_definition ;

   element_subtype_definition ::= subtype_indication

   extension_declaration ::= use identifier_list ;

   identifier_list ::= identifier { , identifier }

   port_or_subprogram_declaration ::= record_port_declaration | subprogram_body

   record_port_declaration ::=
      port identifier [use identifier] ( record_port_list ) ;

   record_port_list ::= interface_list

   interface_list ::= interface_element { ; interface_element }

   interface_element ::= interface_declaration

   interface_declaration ::=
      interface_constant_declaration
      | interface_signal_declaration
      | interface_variable_declaration
      | interface_file_declaration
      | use record_identifier.record_port_identifier

The following example adapts the transaction-based interface implemented with a single record and a package. Note that the types used in the record have been changed to something that is easier to work with.

   type RdyRdyHandShaking is record
      CmdRdy : std_logic ;
      CmdAck : std_logic ;

      Port SourcePort (
         CmdRdy : out std_logic ;
         CmdAck : in std_logic
      ) ;

      Port ModelPort (
         CmdRdy : in std_logic ;
         CmdAck : out std_logic
      ) ;

      procedure SourceRdy ( Rec : SourcePort RdyRdyHandShaking) is
         . . .
      begin
         . . .
      end procedure SourceRdy ;
      procedure ModelRdy ( Rec : ModelPort RdyRdyHandShaking) is
         . . .
      begin
         . . .
      end procedure ModelRdy;

   end record RdyRdyHandShaking ;

   type UartTbRecType is record
      use RdyRdyHandShaking ;

      Data : std_logic_vector (7 downto 0);
      StatusMode : StatusMode_EnumType ;
      TbErrCnt : integer ;
      UartBaudPeriod : time ;
      NumDataBits : integer ;
      ParityMode : ParityMode_EnumType
      NumStopBits : integer ;

      Port UartTbSourcePort (
         Use RdyRdyHandShaking.SourcePort ;
         Data : inout std_logic_vector (7 downto 0) := (others = ‘Z’) ;
         StatusMode : out StatusMode_EnumType ;
         TbErrCnt : out integer ;
         UartBaudPeriod : out time ;
         NumDataBits : out integer ;
         ParityMode : out ParityMode_EnumType
         NumStopBits : out integer
      ) ;
      Port UartTbModelPort (
         Use RdyRdyHandShaking.ModelPort ;
         Data : inout std_logic_vector (7 downto 0) := (others = ‘Z’) ;
         StatusMode : in StatusMode_EnumType ;
         TbErrCnt : in integer ;
         UartBaudPeriod : in time ;
         NumDataBits : in integer ;
         ParityMode : in ParityMode_EnumType
         NumStopBits : in integer
      ) ;
      procedure UartTransmit ( Rec : UartTbSourcePort UartTbRecType, Data :
      std_logic_vector(7 downto 0) ) is
         . . .
      begin
         . . .
      end procedure UartTransmit;
   end record ;

6.2. To be resolved

The following is a list of todo and/or items that need further consideration:

• Needs an example showing the solution to issues in variant bundles
• Is use of “use” ok or should a alternate be used such as “extends”?
• Should there be record bodies?
  Current proposal indirectly suggests packages should allow subprogram bodies.
• Should a class be a primary unit and, hence, cannot be an extension of a record?
• Support limited access to data items such that the value can only be accessed by a method in the interface.
  Alternatives seem to be either a keyword such as “private” or a “record body”.
• Contractual relationship that defines the “procedures” required of an implementation. (SB6)
  How do we create virtual subprograms? Include a subprogram declaration in a record and require that to use a record type in a declaration, the record must an implementation for all subprograms.
• Including assertions with the interface. Assertions could be included in a separate entity/architecturethat has the record as an in so it can monitor all values in the record.
• Interoperability with other transaction based approaches (SystemC)
• Interface should be extendable and/or parameterizable via generics (SB8)
• Ability to specify delay at the interface (SB9)
  Do we want this? Alternatives, make it an optional part of a record port declaration or create a delay declaration. If it was made part of a record port declaration, perhaps entities could be extended in a similar way. I am not sure I want this as delays are often more complicated than one value. For example, propagation delay may have different values depending on whether it is rising or falling. It may also be unclocked and be dependent on several different signals (such as RAM DataOut being dependent on Address setup, chip select, and output enable).
• How do we configure a design that contains bundles and/or interfaces?
  The composite type for the interface will need to be passed as a type generic to an entity. Some how this type generic needs to be based on a base class (with virtual/abstract subprograms). Any type that gets mapped to the type generic would need to be derived from the base class in order to be valid.
• Can we merge the interface concept with the OO and constrained random features?
• Many other things that escape me at this point.