Weird XST error initializing record type on reset

[Don Otknow]

Hello,

I just had an odd error with XST. I have a record and code to
initialize it in a process:

architecture behavioral of vectors is

type six_vectors is record
vect_a : std_logic_vector(15 DOWNTO 0);
vect_b : std_logic_vector(15 DOWNTO 0);
vect_c : std_logic_vector(15 DOWNTO 0);
vect_d : std_logic_vector(15 DOWNTO 0);
vect_e : std_logic_vector(15 DOWNTO 0);
vect_f : std_logic_vector(15 DOWNTO 0);
end record;

signal six_vect_inst : six_vectors;

begin

some_process : process(rst,clk)
begin
if rst = '1' then
six_vect_inst <= (others => (others => '0'));
elsif clk'event and clk='1' then
do_some_stuff
end if;
end process;

end behavioral;

This doesn't work. XST gives me:

FATAL_ERROR:Simulator:CompilerAssert.h:40:1.64.18.3.18.1 - Internal
Compiler Error in file ../src/VhdlExpr.cpp at line 2582 Process will
terminate.

I read in a related error report on a Xilinx site that user-defined
types would cause ISE 12.1 to throw these types of errors. So I
changed the code to:

some_process : process(rst,clk)
begin
if rst = '1' then
six_vect_inst.vect_a <= (others => '0');
six_vect_inst.vect_b <= (others => '0');
six_vect_inst.vect_c <= (others => '0');
six_vect_inst.vect_d <= (others => '0');
six_vect_inst.vect_e <= (others => '0');
six_vect_inst.vect_f <= (others => '0');
elsif clk'event and clk='1' then
do_some_stuff
end if;
end process;

and it worked fine. Does anyone have any insight into why these cases
are handled so differently?

 

[Bart Fox]

Am 11.03.11 00:41, schrieb Don Otknow:

and it worked fine. Does anyone have any insight into why these cases
are handled so differently?
I think the "(others => (others =>" works only for arrays like:

type six_vectors is array(0 to 5) of : std_logic_vector(15 DOWNTO 0);

For records I define an default constant beside:

constant default_six_vectors: six_vectors := (
vect_a => (others => '0'),
vect_b => (others => '0'),
vect_c => (others => '0'),
vect_d => (others => '0'),
vect_e => (others => '0'),
vect_f => (others => '0')
);

You can use this default constant in your reset path.
And you can easily mix diffrent data types in your record.
Also you can never forget to reset an value in this record if you use
the constant. The compiler will complain if the default constant is not
complete.

regards
Bart

 

[Marc Guardiani]

On Friday, March 11, 2011 12:34:34 AM UTC-5, Bart Fox wrote:

Am 11.03.11 00:41, schrieb Don Otknow:
and it worked fine. Does anyone have any insight into why these cases
are handled so differently?
I think the "(others => (others =>" works only for arrays like:
type six_vectors is array(0 to 5) of : std_logic_vector(15 DOWNTO 0);

For records I define an default constant beside:

constant default_six_vectors: six_vectors := (
vect_a => (others => '0'),
vect_b => (others => '0'),
vect_c => (others => '0'),
vect_d => (others => '0'),
vect_e => (others => '0'),
vect_f => (others => '0')
);

You can use this default constant in your reset path.
And you can easily mix diffrent data types in your record.
Also you can never forget to reset an value in this record if you use
the constant. The compiler will complain if the default constant is not
complete.

regards
Bart

But regardless of how one might butcher the syntax, the compiler should never crash as it did for the OP.

-- Marc

 

[Alan Fitch]

On 11/03/11 05:34, Bart Fox wrote:

Am 11.03.11 00:41, schrieb Don Otknow:
and it worked fine. Does anyone have any insight into why these cases
are handled so differently?
I think the "(others => (others =>" works only for arrays like:
type six_vectors is array(0 to 5) of : std_logic_vector(15 DOWNTO 0);

Perhaps surprisingly, others is allowed for records: here's a quote from
the 2002 LRM

"If the type of an aggregate is a record type, the element names given
as choices must denote elements of that record type. If the choice
others is given as a choice of a record aggregate, it must represent at
least one element. An element association with more than one choice, or
with the choice others, is only allowed if the elements specified are
all of the same type. The expression of an element association must have
the type of the associated record elements."

regards
Alan

<snip>

regards
Bart

--
Alan Fitch

 

[Bart Fox]

Am 12.03.11 00:47, schrieb Alan Fitch:

On 11/03/11 05:34, Bart Fox wrote:
Am 11.03.11 00:41, schrieb Don Otknow:
and it worked fine. Does anyone have any insight into why these cases
are handled so differently?
I think the "(others => (others =>" works only for arrays like:
type six_vectors is array(0 to 5) of : std_logic_vector(15 DOWNTO 0);
Perhaps surprisingly, others is allowed for records: here's a quote from
Thanks for pointing that out.

This seems to be another one on my list: What XST should do, but it fails.

regards
Bart

 

[Bart Fox]

Am 11.03.11 00:41, schrieb Don Otknow:

This doesn't work. XST gives me:

FATAL_ERROR:Simulator:CompilerAssert.h:40:1.64.18.3.18.1 - Internal
Compiler Error in file ../src/VhdlExpr.cpp at line 2582 Process will
terminate.
Ok, I have checked this case:

Modelsim (6.5) do it right, XST (12.2) do it right, the problem is only
ISIM, the simulator....

regards,
Bart