TWiki
>
P1076 Web
>
Vhdl2019CollectedRequirements
>
RecordMemberAttribute
(revision 7) (raw view)
Edit
Attach
---+!! 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][<Brent Hayhoe>]] - 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][</Brent Hayhoe>]] - 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%
Edit
|
Attach
|
P
rint version
|
H
istory
:
r11
|
r9
<
r8
<
r7
<
r6
|
B
acklinks
|
V
iew topic
|
Raw edit
|
More topic actions...
Topic revision: r1 - 2020-02-17 - 15:34:37 -
TWikiGuest
P1076
Log In
or
Register
P1076 Web
Create New Topic
Index
Search
Changes
Notifications
RSS Feed
Statistics
Preferences
Webs
Main
P1076
Ballots
LCS2016_080
P10761
P1647
P16661
P1685
P1734
P1735
P1778
P1800
P1801
Sandbox
TWiki
VIP
VerilogAMS
Copyright © 2008-2024 by the contributing authors. All material on this collaboration platform is the property of the contributing authors.
Ideas, requests, problems regarding TWiki?
Send feedback