Compiler complains about non-synthesizable aggregate

[filmil]

Hello all:

VisualElite VHDL compiler complains about the following lines:

type state_type is
record
a, b, d, f : integer range 0 to 4;
end record;
constant INITIAL_STATE : state_type := (a => 1, b => 1, d => 0, f =>
0);

saying: "Record aggregates are not supported for synthesis". Is this
warning important? I am only using aggregates as shorthands for
grouping signals together, and this should have no implications to
synthesis. Should I care?

f

 

[akfami]

Hi Filmil,

Yes, records are not supported for synthesis.

If you want to group the similar aggregates then use array instead
of records.

Regards,
akfami

 

[Andy]

Hi Filmil,

Yes, records are not supported for synthesis.

If you want to group the similar aggregates then use array instead
of records.

Regards,
akfami

NO, records ARE supported, if you use the right tools! I know
Symplify Pro allows them. Contact your vendor and tell them you want
it, and that "brand S" has it.

That being said, records for top level ports (i.e. the pins) are not a
great idea since the gate level post-route code will have
std_logic_vector instead.

Also, whenever all the elements are the same (sub)type, an array is
usually a better choice, since you can step through the elements with
a loop, etc.

Andy

 

[Mike Treseler]

NO, records ARE supported, if you use the right tools! I know
Symplify Pro allows them. Contact your vendor and tell them you want
it, and that "brand S" has it.

Records work for quartus and ise synthesis as well.
Sometimes "not supported for synthesis" means
not supported by synopsys.

-- Mike Treseler

 

[filmil]

NO, records ARE supported, if you use the right tools! I know

This is a valuable information. I will be using Synplify Pro for
synthesis, and I wanted to make sure that nothing unexpected surfaces.

That being said, records for top level ports (i.e. the pins) are not a
great idea since the gate level post-route code will have
std_logic_vector instead.

If I understood correctly, you say I will lose the type information
post-route, and will only be able to see std_logic_vector instead of
the original records. And this makes following the design somewhat
more difficult.

Also, whenever all the elements are the same (sub)type, an array is
usually a better choice, since you can step through the elements with
a loop, etc.

Duly noted.

Thanks,
f