InterfaceConcepts < P1076

P1076 Web>Vhdl2019CollectedRequirements>Whiteboards>InterfaceWhiteboard>InterfaceConcepts (2015-06-24, BrentHahoe) (raw view)EditAttach
---+ New Interface Port/Parameter Mode Requirements

From an RTL perspective...

   * A new 'interface' construct with a primary aim to capture customized mode structures (viz. !SystemVerilog *modport*) to be used within port and parameter lists.

   * The customized mode structures will be used with objects of composite types or a new proposed composite objects object, i.e. something capable of containing *signal* objects and/or *variable* objects and/or *constant* objects and/or *file* objects.

   * The main focus of this latter requirement is for VHDL-AMS who have the need for the new interface construct to be able to bundle *signal* objects with *quantity* objects and/or *terminal* objects. 
      * Could we use the *group* construct to handle these bundles?

   * Interfaces will normally be declared within packages to be visible across objects of the entity class (as opposed to *entity* objects only).
<sticky><pre><verbatim>
   interface CPU_if is
      generic(
         DATA_WIDTH   : Integer;
         ADDR_WIDTH   : Integer;
         TOTAL_SLAVES : Integer
      );

      subtype DATA_st       is Std_Logic_Vector(DATA_WIDTH - 1 downto 0);
      subtype ADDR_st       is Std_Logic_Vector(ADDR_WIDTH - 1 downto 0);
      type    SLAVE_SEL_at  is array TOTAL_SLAVES - 1 downto 0 of Std_Logic;
      type    SLAVE_DATA_at is array TOTAL_SLAVES - 1 downto 0 of DATA_st ;

      modport MASTER_mp is
         signal DATA       : buffer DATA_st;
         signal ADDR       : buffer ADDR_st;
         signal R_W        : buffer Std_Logic;
         signal SLAVE_SEL  : buffer SLAVE_SEL_at;
         signal SLAVE_DATA : in     SLAVE_DATA_at;

      end modport MASTER_mp;

      modport SLAVE_mp is
         MASTER_mp'converse;

      end modport SLAVE_mp;

   end interface CPU_if:
</verbatim></pre></sticky>
   * In FPGA architectures, internal tri-state buses are unavailable and therefore the 'SLAVE_DATA' has to be an array of individual data buses that the master has to demux internally dependent on which slave is being accessed. This requires the slave to only drive back one element of the array and leave all other elements undriven. As the whole array is connect via the new *modport* construct we need a new mode to indicate that the slave is not driving all other parts of the array. This also negates the use of the new *conjugate* attribute as it is not a true opposite of the master interface.

   * The slave *modport* now requires the addition of a *generic* section in order to define the mode of the slave's data and select array ports.

   * Each slave must have its own select signal driven from master to slave.

   * Each slave must drive its own data bus back to the master which needs to multiplex it internally.
<sticky><pre><verbatim>
      modport SLAVE_mp is
         generic(
            SLAVE_SEL_g : Integer
         );
         signal DATA       : in        DATA_st;
         signal ADDR       : in        ADDR_st;
         signal R_W        : in        Std_Logic;
         signal SLAVE_SEL  : composite SLAVE_SEL_at(
                                          SLAVE_SEL_g : in;
                                          others      : null
                                       );
         signal SLAVE_DATA : composite SLAVE_DATA_at(
                                          SLAVE_SEL_g : buffer;
                                          others      : null
                                       );
      end modport SLAVE_mp;
</verbatim></pre></sticky>
   * Clarifications at the meeting on June 11, 2015: 
      * The intent here is to 
         * only select one element of the SLAVE_SEL and SLAVE_DATA vector signals for a particular slave, the one element specific to the slave (the *null* mode is not strictly required for the SLAVE_SEL_at array).
         * provide assurance that only the selected element of the vector is driven. This information could be used to relax the rule that driving one element of a composite means driving the composite: here the driver would only be for the selected element.
      * Are there other approaches to get the intended behavior without having to change the driver model for composites? Would it be possible to adapt a loop generate to generate separate objects for the different slaves?

   * This requires the addition of a new *composite* mode to indicate that the mode function is to be decomposed into the array structure.

   * The new *null* mode provides a termination mode for the interface at the slave port.

   * Internally within the slave entity a *null* mode is not visible and therefore cannot be driven nor read.

   * We need a new entity class object (to handle bundles of objects rather than just types) in order to be able to route from one interface terminus to another. 
      * Maybe we call it a *bundle* and define it using the *group* construct?

   * In defining a *modport* using a bundle of objects, we now also need to use the new *composite* mode if we want to use a *record* type structure.
<sticky><pre><verbatim>
      type CPU_r is
         record
            DATA_l        : DATA_st;
            ADDR_l        : ADDR_st;
            R_W_l         : Std_Logic;
            SLAVE_SEL_al  : SLAVE_SEL_at;
            SLAVE_DATA_al : SLAVE_DATA_at;

      end record CPU_r;

      modport MASTER_mp is
         signal CPU : composite CPU_r(
                                   DATA_l        : buffer;
                                   ADDR_l        : buffer;
                                   R_W_l         : buffer;
                                   SLAVE_SEL_al  : buffer;
                                   SLAVE_DATA_al : in
                                );
      end modport MASTER_mp;

      modport SLAVE_mp is
         generic(
            SLAVE_SEL_g : Integer
         );
         signal CPU : composite CPU_r(
                                   DATA_l        : in;
                                   ADDR_l        : in;
                                   R_W_l         : in;
                                   SLAVE_SEL_al  : composite SLAVE_SEL_at(
                                                                SLAVE_SEL_g : in;
                                                                others      : null
                                                             );
                                   SLAVE_DATA_al : composite SLAVE_DATA_at(
                                                                SLAVE_SEL_g : buffer;
                                                                others      : null
                                                             )
                                );
      end modport SLAVE_mp;
</verbatim></pre></sticky>

   * With this *record* use of the *modport*, the new attribute MASTER_mp'<b>converse</b> cannot be used. However, the proposed MASTER_mp'<b>monitor</b> attribute would still be useful.

   * This requires the inclusion of the [[InterfaceAttributes][Interfaces: Attributes for Interfaces]] proposal.
Topic revision: r5 - 2015-06-24 - 16:58:06 - BrentHahoe
P1076