12-12-2016 12:10 AM
I have tested this with Vivado 2016.1, will test and update later with 2016.3, but as I can find no reference to this issue anywhere I suspect it's not known to Xilinx.
Consider the following example code:
entity top is
data_i : in std_logic_vector(7 downto 0);
data_o : out std_logic_vector(7 downto 0)
architecture Behavioral of top is
type vector_array is array(natural range <>) of std_logic_vector;
signal va : vector_array(0 to 1)(7 downto 0);
constant len : natural := va'ELEMENT'LENGTH;
subtype vr is natural range len downto 0;
data_o <= (vr => data_i(vr), others => '0');
This should fail to compile, having set len to 8, and vr to the range 8 downto 0; however, instead from looking at the generated netlist it seems that len has been set to 1. Oh dear. If I try to use va'ELEMENT'RANGE the results are even stranger.
From every account and example I've seen (I don't yet have access to a copy of the 2008 standard), vr'ELEMENT should behave just like vr(ix) where ix is some valid index into vr'RANGE (and should still work even if vr'RANGE is empty); in this example, vr'ELEMENT should behave like the type std_logic_vector(7 downto 0). I can't tell what Vivado thinks it's doing here, my guess is that vr'ELEMENT is behaving somewhat like std_logic.
12-12-2016 01:27 AM - edited 12-12-2016 01:36 AM
This is a known issue in 2016.1
As a workaround in 2016.1, you can use va(0)'length
constant len : natural := va(0)'LENGTH;
From VHDL-2008 LRM,
A'LENGTH [(N)] : parameter is a locally static expression of type universal_integer, the value of which shall not exceed the dimensionality of A. If omitted, it defaults to 1.
In 2016.1, this treats this as being omitted and defaulting to 1.
From 2016.3, vivado will provide an error that the attribute is not supported.
12-12-2016 01:48 AM
Fixed in 2016.3? Are you sure about this? I've fixed the obvious bug in the code, changing the definition of vr to
subtype vr is natural range len-1 downto 0;
but leaving the rest unchanged, and I've loaded the project into Vivado 2016.3 ... and I get the following error:
ERROR: [Synth 8-5882] found unsupported attribute [top.vhd:15]
ERROR: [Synth 8-421] mismatched array sizes in rhs and lhs of assignment [top.vhd:15]
Don't think I understand this error message. If I change 'ELEMENT to (0), as suggested above, I get the expected result, so it's definitely a problem with ELEMENT.
As you say, 'ELEMENT is more or less an alias for (0) ... except for one major difference: 'ELEMENT is valid even if 0 is not in range, indeed even if the range is empty.
You say "you will observe error message indicating that lhs and rhs lengths are not equal", which is indeed what I see ... but this makes no sense to me. What does this error message mean? Is it just a cryptic way of repeating the "found unsupported attribute" message?
I guess changing a broken implementation to "unsupported" is a step forward. I could not find any erratum referencing this issue, but searching for "ELEMENT attribute" is remarkably fruitless!
12-12-2016 01:54 AM
Ok, I've read your reply more carefully.
12-12-2016 01:54 AM
12-12-2016 02:00 AM
On the plus side, I guess it seems we agree on the expected semantics of 'ELEMENT, which spares me some painful spelunking into the standards document. On the other hand, why on earth are your language people unable to implement this apparently very straightforward feature?!
02-06-2019 12:53 PM
The element attribut work correctly, the problem is the support of back-to-back attribute