My initial reaction to looking at the aggregate in your default for pair_in was that there were too many "others", so I wrote one myself using the post type declaration itself:
library ieee; use ieee.std_logic_1164.all; package some_record is type ifx_t is record data : std_logic_vector(127 downto 0); address : std_logic_vector (19 downto 0); WrReq : std_logic;-- RdReq : std_logic; -- end record; type Array_ifx_t is array (0 to 2) of ifx_t; -- positional association in an aggregate used for initialization: signal pair_in: ifx_t := ((others => '0'), (others => '0'),'0','0'); end package;
And it has been successfully analyzed. The unit has two types of association: positional or named. The above expression is positional by default. With a named association:
signal pair_in: ifx_t := -- named association of record elements: ( data => (others => '0'), address => (others =>'0'), WrReq => '0', RdReq => '0' );
You will notice that this bears a supernatural resemblance to the value expression found in the declaration of the Morten constant declaration, and actually tells the compatibility history for the total expression.
A record type compatible aggregate contains a value expression that is compatible with each record type element. This is done for the data and addresses of the array elements, providing aggregates for the default values, while WrReq and RdReq are directly provided with default values.
An additional instruction found in the original attempt would be appropriate if pair_in was a composite type consisting of an array consisting of elements of the ifx_t record ifx_t .
LRM (for example, IEEE Std 1076-1993) has a section "Expressions", a subsection "Aggregates" with an additional subdivision "Aggregates recording".
There is also a section called “Types”, a subsection “Composite types”, with an additional division “Types of records”.
user1155120
source share