Record Indexing

OBSOLETE - Merged into Record Introspection & Indexing

Proposal Details

• Who Updates: Brent Hayhoe
• Date Proposed: 2014-03-09
• Date Last Updated:
• Priority:
• Complexity:
• Focus:

Current Situation

There is already a proposal for record introspection. However, this appears to be more concerned with conversion functions between record types and vector array types.

In order for any of the proposals concerned with improving the functionality of record types, we need the ability to be able to reference and scan the elements that make up a particular record type and operate on them in a similar manner to the way we index an array using the subtype that addresses the individual array elements.

Implementation details

In order to accomplish this, I propose that we change the definition of a record such that the declaration of a record type 'R' will cause an implicit declaration of an enumerated type 'E', being the set of record element names declared in 'R'.

Objects of type record will then be allowed to have their record elements indexed in a similar manner to that of arrays.

In order to achieve this, extra predefined attributes will need to be created that decorate record types:

   R'ELEMENTS         returns the implicit enumerated type E.
   R'LEFT             is the leftmost element of record R (or implicit enumerated type E).
   R'RIGHT            is the rightmost element of record R (or implicit enumerated type E).
   R'HIGH             is the highest element of record  R (or implicit enumerated type E).
   R'LOW              is the lowest element of record R (or implicit enumerated type E).
   R'RANGE            is the range R'LEFT *to* R'RIGHT or R'LEFT *downto* R'RIGHT .
   R'REVERSE_RANGE    is the range of R with *to* and *downto* reversed.
   R'LENGTH           is the integer value of the number of elements in record R (or implicit enumerated type E).

Code Examples

Given the following record type:

   type std_record is
      record
         element1 : std_logic;
         element2 : std_logic_vector;
         element3 : unsigned;
         element4 : integer;

   end record std_record;

   signal my_sig : std_record;

which would imply the following enumerated type:

   type std_record'elements is (
         element1,
         element2,
         element3,
         element4
      );

it would then allow the user to generate, for example, loops as shown below:

   for i in my_sig'subtype'base'elements loop
      if (my_sig.i'subtype'base = std_logic) then
         my_sig.i <= 'Z';

      elsif (   (my_sig.i'subtype'base = std_logic_vector)
             or (my_sig.i'subtype'base = unsigned)) then
         my_sig.i <= (others => 'Z');

      end if;
   end loop;

As a further outcome of this, we would now be able to declare subtypes of records in a similar manner to that of constrained array subtypes:

   subtype sub_std_record is
      std_record range element1 to element3;

   signal my_sub_sig : sub_std_record;

Will this be useful?

We can reference individual elements using the standard dot notation, but how could we handle this for ranges of elements?

We could access ranges in a similar manner to arrays, but use square ellipses in order to differentiate (this could cause problems for some tool manufacturers?):

   subtype sub_std_record is std_record.[element1 to element3];

   signal my_sub_sig : sub_std_record;

begin
   my_sub_sig.[element2 to element3] <= (others => 'Z');

Notice the retention of the dot notation?

Use Cases

Other relevant proposals:

• Interfaces / Record IO
• Interface Construct and Port Mode Configurations
• Add "Bus" mode for bidirectional port signals
• Closely related record types
• Record Introspection
• Attributes for Enumerated Types
• Record Member Attribute
• Syntax regularization - Empty records

Arguments FOR

Arguments AGAINST

General Comments

Supporters

-- Brent Hayhoe - 2014-03-09

Add your signature here to indicate your support for the proposal