VHDL 201x Interface Implementation Proposal

Updates

• 2016/04/21
  • replaced 'element' keyword with record/array.
  • added resolution to object feature table.

References

• VHDL 2008 LRM Hyperlinked BNF Productions (N.B. must be logged in)

• VHDL 2008 LRM Glossary Section (N.B. must be logged in)

Introduction

VHDL has supported the concept of a composite object for implementing an interface bundle (via record and array types) since its inception. However, it has lacked the ability to individually control the mode of the object's elements across interface boundaries and the addition of this functionality has been the main initial driving force for this new interface proposal.

A new mode view structural concept has been proposed to provide either a named or in-place structural specification of the mode of a composite object's elements.

In all previous VHDL LRM revisions, composite structures have been associated with types.

This can be qualified as a software derived point of view and quite rightly, the LRMs for VHDL have expanded these composite type definitions into composite object structures for hardware implementation (i.e. each element of a composite type - associated with an object - is interpreted as a discrete object in its own right and necessarily of the same object class).

For example, the elements of a signal with a composite type are implicitly defined as each of an object of class signal in their own right.

This is a requirement for synthesis to operate but has also been defined such that simulators can model these structures in a matching manner.

However, the requirement to handle heterogeneous interfaces adds another dimension to composite structures and that is the ability to bundle objects of different object classes together (e.g. signals with variables).

It is proposed that a new composite object class be defined - bundle - and in order to associate this with a composite type, that these types be expanded to explicitly define the object class of each element.

Objectives

• This implementation seeks to define an interface using existing composite types with a single object class.

• This implementation seeks to define an heterogeneous interface concept using a new composite object class (bundle) associated with a new 'composite structure' semantic which will be able to define the object class of each element.

• This implementation seeks to define a method to individually control the I/O mode of composite elements of both of these types of interface objects at the interface boundary of an entity and at the interface boundaries of function and procedure subprograms. (+ block structures?)

• This implementation seeks to define a zero-delta bidirectional connection method for the new bundle composite object class.

Composite Structures - Record & Array Types

The language already provides composite structures in the form of record and array types which can be associated with any of the existing object classes.

They lack the flexibility, within interface boundaries, of independent control of the mode functionality of their structural elements.

In terms of a hardware description language, these composite types are handled as composite objects and so their semantics is redefined as composite structures, but their syntax remains largely unaltered.

   composite_structure_definition ::=
        array_structure_definition
      | record_structure_definition

The Bundle - A New Explicit Composite Object

The standard object declaration requires a bundle declaration as a new object.

   object_declaration ::=
        constant_declarationoptional. Note also that a *bundle* can contain elements of object class *bundle*.
      | signal_declaration
      | variable_declaration
      | file_declaration
      | bundle_declaration

   bundle_declaration ::=
      bundle identifier_list : composite_structure_indication [ := expression ] ;

This is a new object of class bundle which is always associated with a 'composite structure definition' (in VHDL2008 a 'composite type definition').

Its distinguishing feature is to allow heterogeneous grouping of objects, i.e. elements of its composite structure being of differing object class.

• ¹ A bundle object accesses its composite elements in the standard manner:
  A record element is accessed using the 'dot' notation.
  An array element is accessed using a bracketed index or range subtype.
• ² A bundle object exhibits an event if at least one of its elements is of object class signal.
• ³ A bundle object equivalence check shall be done on an element and associated subtype and object class basis.
• ¹¹ A bundle cannot be assigned directly due to the possible object class differences of its elements.
  Assignments need to be similar to a mapping and a possible solution is the suggested new bidirectional assignment operator <=>.
  This may also be achievable by a new construct - the map function or map procedure.
• ¹² A bundle object can be mapped as long as it does not incur a generated delta delay (e.g. via the inertial keyword?).
• ¹³ A bundle object must be associated with a protected type if at least one of its elements is associated with a protected type.
• ²¹ A bundle object must be associated with a resolved type if at least one of its elements is associated with a resolved type.

Record Structures

   record_structure_definition ::=
      record
             element_object_declaration
           { element_object_declaration }
         | null ;
      end record [ record_structure_simple_name ]

The structure semantic serves to highlight the fact that these are now defined as composite objects and are not just a type.

The 'record structure definition' has been altered to allow for zero element structures as proposed here.

The format chosen follows that of ADA described here.

The 'element object declaration' takes a similar form to the normal 'object declaration'. The differentiating point is that in each 'element object declaration', the object class keyword is now optional. Note also that a bundle can contain elements of object class bundle.

   element_object_declaration ::=
        element_constant_declaration
      | element_signal_declaration
      | element_variable_declaration
      | element_file_declaration
      | element_bundle_declaration

   element_constant_declaration ::=
      [ constant ] identifier_list : subtype_indication [ := expression ] ;

   element_signal_declaration ::=
      [ signal ] identifier_list : subtype_indication [ signal_kind ] [ := expression ] ;

   element_variable_declaration ::=
      [ [ shared ] variable ] identifier_list : subtype_indication [ := expression ] ;

   element_file_declaration ::=
      [ file ] identifier_list : subtype_indication [ file_open_information ] ;

   element_bundle_declaration ::=
      [ bundle ] identifier_list : composite_structure_indication [ := expression ] ;

The elements of a record now become full object declarations.

If the object class keyword is missing, the element object class defaults to the object class of the instance to which the record structure is associated with.

Apart from the 'identifier list' and the 'subtype indication', all other parts are optional, which then means that the default 'element object declaration' remains identical to the existing 'element declaration' of a record type.

Array Structures

The 'array structure definition' specifies the unbounded array and the constrained array:

   array_structure_definition ::=
        unbounded_array_structure_definition
      | constrained_array_structure_definition

   unbounded_array_structure_definition ::=
      array ( 
             index_subtype_definition
         { , index_subtype_definition }
             ) of element_object_indication

   constrained_array_structure_definition ::=
      array index_constraint
         of element_object_indication

   element_object_indication ::=
        element_constant_indication
      | element_signal_indication
      | element_variable_indication
      | element_file_indication
      | element_bundle_indication

   element_constant_indication ::=
      [ constant : ] subtype_indication [ := expression ] ;

   element_signal_indication ::=
      [ signal : ] subtype_indication [ signal_kind ] [ := expression ] ;

   element_variable_indication ::=
      [ [ shared ] variable :  ] subtype_indication [ := expression ] ;

   element_file_indication ::=
      [ file : ] subtype_indication [ file_open_information ] ;

   element_bundle_indication ::=
      [ bundle : ] composite_structure_indication [ := expression ] ;

Ports and Modes

Interface Declarations

   interface_object_declaration ::=
        interface_constant_declaration
      | interface_signal_declaration
      | interface_variable_declaration
      | interface_file_declaration
      | interface_bundle_declaration

   interface_constant_declaration ::=
      [ constant ] identifier_list : [ in ] subtype_indication [ := static_expression ]

   interface_signal_declaration ::=
        [ signal ] identifier_list : [ mode ] subtype_indication [ bus ] [ := static_expression ]
      | [ signal ] identifier_list :   view composite_structure_indication ( mode_view_clause ) [ bus ] [ := static_expression ]

   interface_variable_declaration ::=
        [ variable ] identifier_list : [ mode ] subtype_indication [ := static_expression ]
      | [ variable ] identifier_list :   view composite_structure_indication ( mode_view_clause ) [ := static_expression ]

   interface_file_declaration ::=
      file identifier_list : subtype_indication

   interface_bundle_declaration ::=
        [ bundle ] identifier_list : [ mode ] composite_structure_indication [ := static_expression ]
      | [ bundle ] identifier_list :   view composite_structure_indication ( mode_view_clause ) [ := static_expression ];

Composite Mode Views

The proposed solution is to introduce a new semantic which can provide a mode view of the composite object. This new view object will enable the mode of each element of a composite type to be defined in a hierarchical manner.

This will be used on object class declarations associated with an entity interface i.e. an entity or a procedure. The ports of a function are by definition inputs and therefore can use the existing format where the mode applies to the whole of the composite type.

   mode_view_clause ::=
           mode_view_indentifier [ ( generic_map_aspect ) ]
         | formal_composite_view_clause

   mode_view_declaration ::=
      view identifier of composite_structure_indication is
         [ formal_generic_clause ]
           formal_composite_view_clause
      end view [ mode_view_simple_name ] ;

   composite_view_clause ::=
           record_view_definition
         | array_view_definition

   mode ::= in | out | inout | buffer | linkage | null

Record Mode Views

   record_view_definition ::=
        view_object_declaration
      { view_object_declaration }

   view_object_declaration ::=
        view_constant_declaration
      | view_signal_declaration
      | view_variable_declaration
      | view_file_declaration
      | view_bundle_declaration

   view_constant_declaration ::=
      [ constant ] identifier_list : in [ subtype_indication ] [ := static_expression ] ;

   view_signal_declaration ::=
        [ signal ] identifier_list : mode [ subtype_indication ] [ bus ] [ := static_expression ] ;
      | [ signal ] identifier_list : view composite_structure_indication ( mode_view_clause ) [ bus ] [ := static_expression ] ;

   view_variable_declaration ::=
        [ variable ] identifier_list : mode [ subtype_indication ] [ := static_expression ] ;
      | [ variable ] identifier_list : view composite_structure_indication ( mode_view_clause ) [ := static_expression ] ;

   view_file_declaration ::=
      file identifier_list : subtype_indication ;

   view_bundle_declaration ::=
        [ bundle ] identifier_list : mode [ composite_structure_indication ] [ := static_expression ] ;
      | [ bundle ] identifier_list : view composite_structure_indication ( mode_view_clause ) [ := static_expression ] ;

Array Mode Views

   array_view_definition ::=
        view_object_indication
      { view_object_indication }

   view_object_indication ::=
        view_constant_indication
      | view_signal_indication
      | view_variable_indication
      | view_file_indication
      | view_bundle_indication

   view_constant_indication ::=
      [ constant ] array_element_choice : in [ subtype_indication ] [ := static_expression ] ;

   view_signal_indication ::=
        [ signal ] array_element_choice : mode [ subtype_indication ] [ bus ] [ := static_expression ] ;
      | [ signal ] array_element_choice : view composite_structure_indication ( mode_view_clause ) [ bus ] [ := static_expression ] ;

   view_variable_indication ::=
        [ variable ] array_element_choice : mode [ subtype_indication ] [ := static_expression ] ;
      | [ variable ] array_element_choice : view composite_structure_indication ( mode_view_clause ) [ := static_expression ] ;

   view_file_indication ::=
      file array_element_choice : subtype_indication ;

   view_bundle_indication ::=
        [ bundle ] array_element_choice : mode [ composite_structure_indication ] [ := static_expression ] ;
      | [ bundle ] array_element_choice : view composite_structure_indication ( mode_view_clause ) [ := static_expression ] ;

Proposed Additional Syntax

• 
  UNDER CONSTRUCTION

• This is an attempt to define the proposed syntax in form of BNF productions.

• This is a simplex format in that it does not include all the modifications to existing productions defining where these new productions may syntactically be used.
• The BNF productions do not define all syntax options in their entirety and will therefore be elaborated with associated text.

• interface_signal_declaration: This is required for an entity based signal view syntax as an option to that of the signal mode used in the definition of an interface port.

• The mode view is defined using the composite type identifier to reference a view associated with that type. The view is referenced as a mode view clause.

• mode_view_clause: The mode view clause defines two options.

   mode_view_clause ::=
         mode_view_indentifier [ ( generic_map_aspect ) ]
         | formal_composite_element_clause

• The first references a named mode view declaration with an option to include a generic map. This is to enable the passing of an entity based generic through to the named mode view.

   use work.cpu_bus_2m8s_pkg.all
   entity master_ent is
      generic (
         slave_id_jg  : slaves_total_jrt;
         master_id_jg : masters_total_jrt
      );
      port (
         rst_i       : in     std_logic
         clk_i       : in     std_logic;
         cpu_bus_rif : view   master_r(
                                 master_rvw(
                                    generic map(
                                       slave_id_jg  => slave_id_jg,
                                       master_id_jg => master_id_jg
         )                       )  )  );
     end entity master_ent;

• The second object allows for an unnamed mode view to be declared in place within the entity declaration and is defined as a composite element clause.

   use work.cpu_bus_2m8s_pkg.all
   entity arbiter_ent is
      generic(
         slave_id_jg : slaves_total_jrt
      );
      port(
         rst_i       : in     std_logic;
         clk_i       : in     std_logic;
         cpu_bus_rif : view   cpu_bus_r(
                                 element(
                                    arbiter_al : view arbiter_a(
                                                         element(
                                                            others : view   arbiter_r;
                                                               element(
                                                                  master_rl   : in     master_r;
                                                                  bus_req_l   : in     std_logic;
                                                                  bus_grnt_l  : buffer std_logic

         rst_i       : in     std_logic
         clk_i       : in     std_logic;
         cpu_bus_rif : view   master_r(
                                 master_rvw(
                                    generic map(
                                       slave_id_jg  => slave_id_jg,
                                       master_id_jg => master_id_jg
         )                       )  )  );
     end entity master_ent;

• The second object allows for an unnamed mode view to be declared in place within the entity declaration and is defined as a composite element clause.

   use work.cpu_bus_2m8s_pkg.all
   entity arbiter_ent is
      generic(
         slave_id_jg : slaves_total_jrt
      );
      port(
         rst_i       : in     std_logic;
         clk_i       : in     std_logic;
         cpu_bus_rif : view   cpu_bus_r(
                                 element(
                                    arbiter_al : view arbiter_a(
                                                         element(
                                                            others : view   arbiter_r;
                                                               element(
                                                                  master_rl   : in     master_r;
                                                                  bus_req_l   : in     std_logic;
                                                                  bus_grnt_l  : buffer std_logic
--  [[Main.[[iBrentHahoe][BrentHayhoe]]][ [[i Brent Hahoe][Brent Hayhoe]]  - 2016-04-19]] 

---++ Comments