(r1) BrentHayhoeSimpleRecordBasedBundle < P1076

P1076 Web>Vhdl2019CollectedRequirements>Whiteboards>InterfaceWhiteboard>BrentHayhoeSimpleRecordBasedBundle (revision 1) (raw view)~~EditAttach~~
---+ Simple *record* based interface

One reason that the interface proposal was initially put forward: engineers want to put their structural level signal interconnects into record structures in order to simplify coding these levels and also improve the communication of design intent.

However complex we make the new interface and bundle constructs we should make sure there is still the option to have, as far as possible, a simplified form to facilitate this initial request.

So a simple *record* type and *bundle* template declaration:

<sticky><verbatim>
   type rec_type is record
      e1 : std_logic;
      e2 : std_logic_vector(gen downto 0);
   end record rec_type;

   bundle b_template is
      signal s : rec_type;
   end bundle b_template;
</verbatim></sticky>

followed by a simple *bundle* object declaration to use in routing between interface termini:

<sticky><verbatim>
   bundle b_object : b_template;
</verbatim></sticky>

I believe this is what many engineers will want to be able to do in the first instance. I think there will be comments that the *bundle* template is an unwanted overhead, but I cannot see a way around it.

---+ Defining the modes for the interface

The *bundle* can be thought of as analogous to the existing *group* template declaration and *group* declaration.

The *bundle* template declaration defines the structure in terms of object classes in the bundle. The *bundle* declaration then associates the template with the named *bundle* declaration,  analogous to a signal, constant or variable declaration associating that object with a type.

Next the *modport* or maybe the more appropriate *bundle* *view* should be defined within the new *interface* construct, bearing in mind that an interface will require at least one *bundle* to be of use:

<sticky><verbatim>
   interface i is
      generic(
         ...
      )
      port(
         ...
      )
      bundle view b_master of b_template is
         signal s : composite rec_type(
                        e1 : in  std_logic;
                        e2 : out std_logic_vector(gen downto 0)
                      );
      end bundle view b_master ;

      bundle view b_slave of b_template is
         bundle view b_master'converse;
      end bundle view b_master ;
   end interface i;
</verbatim></sticky>

The *converse* attribute will give a *bundle* *view* for 'b_slave' where *record* element 'e1' will be of mode *out* and that of 'e2' mode *in*.

The complexity of generics, ports and subprograms is now handled within the new *interface* construct.

N.B. if a generic needs to be used within the *record* in the *bundle* *view*, it will have to be declared within the *interface* construct to utilize its generics.

---+ Declaring an entity with interface bundles

We need to instantiate the interface and it is suggested that we handle this similarly to instantiating packages.

<sticky><verbatim>
   interface if is new work.i
      generic map(
         ...
      )
      port map(
         ...
      );
</verbatim></sticky>

This postulates the question: Should an *interface* construct be a primary design unit?

Using it in an entity.

<sticky><verbatim>
   entity e is
      generic(
         ...
      );
      port(
         ...
      );
      interface(
         bundle b_port : view b_master
      );
  end entity e;
</verbatim></sticky>

and then instantiating the component:

<sticky><verbatim>
   e_inst : e
      generic map(
         ...
      )
      port map(
         ...
      )
      interface map(
         b_port => b_object
      );
</verbatim></sticky>

It has been suggested that providing a separate entity *interface* declaration section and corresponding *interface* *map* section for instantiation will aid compiler parsing problems.

---+ Conclusions

   * The new connection *bundle* object is required for VHDL-AMS but could prove useful in standard VHDL (pure optimism!)

   * A *bundle* cannot be directly associated to a *type* like a *signal*, or *variable*, or other connection objects can.

   * Analogous to a *record* or an *array* being a composite type, a *bundle* is a composite connection object.

   * A *bundle* requires a template declaration in a manner similar to a *group* template declaration.

   * A named *bundle* declaration associates the template to the composite *bundle* object in the same way as other connection objects are associated to a *type*.

   * A *bundle* should be the only connection object used in an *interface*.

   * An *interface* construct should probably be defined as a primary entity object (cf. a *package*)

   * An *interface* construct should handle the *generic* and *port* requirements for the interface.

   * An *interface* construct should contain the various *bundle* *view* declarations for the interface.

   * The *bundle* *view* construct requires a new *composite* and possibly a new *null* mode in order to define the directional aspects of an interface *bundle*.

   * The entity interfaces of an *entity*, *function*, *procedure* (and maybe the new *interface* construct itself) should have a new *interface* port interface (along with that of a *generic* and *port*) to aid compiler parsing.

   * An instance of these entity objects would have an additional *interface* *map* section.
Topic revision: r1 - 2015-07-09 - 14:40:57 - TWikiGuest
P1076