(r7) RecordMemberAttribute < P1076

P1076 Web>Vhdl2019CollectedRequirements>RecordMemberAttribute (revision 7) (raw view)~~EditAttach~~
---+!! Record Introspection & Indexing

%TOC%

---++ Proposal Editing Information
   * Who Updates: [[Main.BrentHahoe][Brent Hayhoe]]
   * Date Proposed: 2014-03-09
   * Date Last Updated:
   * Priority:
   * Complexity:
   * Focus:
   * LCS:
      * [[TopLCS2016_069a][LCS-2016-069a]]
      * [[TopLCS2016_069b][LCS-2016-069b]]

---++ Requirement Summary

An element/member attribute for records plus additional attributes similar to those associated with array types (the other composite type).

The ability to reference record elements in a manner similar to the indexing of array types.

---++ Related Issues:

Original requirement - [[http://www.eda-twiki.org/isac/IRs-VHDL-2002/IR2076.txt][ISAC IR-2076]]

---++ Proposal

---+++ 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:

<sticky><pre>
   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).
</pre></sticky>

---+++ Code Examples

Given the following record type:

<sticky><pre>
   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;
</pre></sticky>

which would imply the following enumerated type:

<sticky><pre>
   type std_record'elements is (
         element1,
         element2,
         element3,
         element4
      );
</pre></sticky>

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

<sticky><pre>
   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;
</pre></sticky>

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:

<sticky><pre>
   subtype sub_std_record is
      std_record range element1 to element3;

   signal my_sub_sig : sub_std_record;
</pre></sticky>

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?):

<sticky><pre>
   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');
</pre></sticky>

Notice the retention of the dot notation?

---++ Use Cases

Other relevant proposals:

   * [[P1076.BlockInterfaces][Interfaces / Record IO]]
   * [[P1076.InterfaceConstructandPortModeConfigurations][Interface Construct and Port Mode Configurations]]
   * [[P1076.NewBusModeForBidirectionalPortSignals][Add "Bus" mode for bidirectional port signals]]
   * [[P1076.RelatedRecords][Closely related record types]]
   * [[P1076.RecordIntrospection][Record Introspection]]
   * [[P1076.EnumAttributes][Attributes for Enumerated Types]]
   * [[P1076.EmptyRecord][Syntax regularization - Empty records]]

---++ Arguments FOR

---++ Arguments AGAINST

---++ General Comments

The feature needs to have more than just the enumerated type to be useful. The code samples contain a use of the 'BASE attribute that is currently illegal. I am also against the idea of record slices and the [ ] notation. -- Main.PeterFlake - 2014-12-18

[[Main.BrentHahoe][&lt;Brent Hayhoe&gt;]] - Ah yes, I take it that you're referring to the likes of:

<sticky><pre>
      if (my_sig.i'subtype'base = std_logic) then
</pre></sticky>

and the lack of a suffix attribute.

Does anyone know of any reasons why this mode of use of the BASE attribute should not be allowed in the next revision?

And slices of records: well, I added that as a moot point.

[[Main.BrentHahoe][&lt;/Brent Hayhoe&gt;]] - 2014-12-18

<sticky><pre>
library ieee;
use ieee.std_logic_1164.all;

entity temp is
end entity temp;

architecture Behavioral of temp is
  signal x : std_logic_vector(3 downto 0);
begin
  process
  begin
      report x'simple_name;
      report x'subtype'simple_name;
      report x'subtype'base'simple_name;
      report x'subtype'base'base'simple_name;
      wait;
  end process;
end architecture;
</pre></sticky>

Gives the results:

<sticky><pre>
# Loading work.temp(behavioral)
# ** Note: x
# Time: 0 ns Iteration: 0 Instance: /temp
# ** Note: _anon
# Time: 0 ns Iteration: 0 Instance: /temp
# ** Note: std_ulogic_vector
# Time: 0 ns Iteration: 0 Instance: /temp
# ** Note: std_ulogic_vector
# Time: 0 ns Iteration: 0 Instance: /temp
</pre></sticky>

On at least one simulator. Can we use this to resolve the 'base issue?

-- Main.RobGaddi - 2016-05-05
---++ Supporters

-- [[Main.BrentHahoe][Brent Hayhoe]] - 2014-03-09

-- Main.PatrickLehmann - 2016-02-11

---+ Comments

%COMMENT%
Topic revision: r1 - 2020-02-17 - 15:34:37 - TWikiGuest
P1076