Record Introspection & Indexing
Proposal Editing Information
- Who Updates: Brent Hayhoe
- Date Proposed: 2014-03-09
- Date Last Updated:
- Priority:
- Complexity:
- Focus:
- LCS:
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 -
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:
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:
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. --
PeterFlake - 2014-12-18
<Brent Hayhoe> - Ah yes, I take it that you're referring to the likes of:
if (my_sig.i'subtype'base = std_logic) then
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.
</Brent Hayhoe> - 2014-12-18
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;
Gives the results:
# 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
On at least one simulator. Can we use this to resolve the 'base issue?
--
RobGaddi - 2016-05-05
Supporters
--
Brent Hayhoe - 2014-03-09
--
PatrickLehmann - 2016-02-11
Comments