On 27 Nov 2013, at 12:56 pm, Christophe <[email protected]> wrote:
> Hello,
>
> This looks like the classical VHDL case where you should use explicit index
> for the vector, otherwise the tool (GHDL in this case, but true for every
> tools) can't be sure how to interpret the value, and thus complains.
>
> constant out_vectors : outvec_type := (
> 0 => X"00000000"
> );
>
> Works on my side with the 'fix'.
A named association in the aggregate works (see the examples below).
What's missing is a aggregate value in the expression for the default value
that matches
the type on the left hand side of the assignment operator.
---
library ieee;
use ieee.std_logic_1164.all;
entity fum is
-- skip to entity declarative items:
constant out_vectors_nb : natural := 1;
constant out_vector_bytes : natural := 4; -- <- added declaration
type outvec_type is array (0 to out_vectors_nb-1) of
std_logic_vector(out_vector_bytes * 8 - 1 downto 0);
constant out_vectors : outvec_type := (X"00000000");
end entity;
architecture foo of fum is
begin
end architecture;
---
%% ghdl -a fum.vhdl
fum.vhdl:11:44: can't match bit string literal
"00000000000000000000000000000000" with type array subtype "outvec_type"
edit line 11:
constant out_vectors : outvec_type := (others => X"00000000");
and:
%% ghdl -a fum.vhdl
%%
et. voila! (it runs, too.)
As does:
constant out_vectors : outvec_type := (0 => X"00000000") ;
or:
constant out_vectors : outvec_type := (X"00000000", others => (others =>
'0'));
(And this one works because the others choice doesn't have to be realizable).
Note that for out_vectors_nb = 2
constant out_vectors : outvec_type := (0 => X"00000000", 1 => x"00000000")
;
as does:
constant out_vectors : outvec_type := (others => X"00000000");
and both supply a aggregate value to a composite type on the left hand side.
Anyway the working examples should give Adrien a way of going forward.
What Adrien may actually be complaining about is that for out_vectors_nb = 2
constant out_vectors : outvec_type := (X"00000000",X"00000000");
works, while having one element (a bit string in place of a subaggregate) in
the aggregate doesn't. (the error message).
>From IEEE Std 1076-1993:
7.3.2.2 Array aggregates
For an aggregate of a one-dimensional array type, each choice must specify
values of the index type, and the expression of each element association must
be of the element type. An aggregate of an n-dimensional array type, where n is
greater than 1, is written as a one-dimensional aggregate in which the index
subtype of the aggregate is given by the first index position of the array
type, and the expression specified for each element association is an
(n-1)-dimensional array or array aggregate, which is called a subaggregate. A
string or bit string literal is allowed as a subaggregate in the place of any
aggregate of a one-dimensional array of a character type.
Apart from a final element association with the single choice others,the rest
(if any) of the element associations of an array aggregate must be either all
positional or all named. A named association of an array aggregate is allowed
to have a choice that is not locally static, or likewise a choice that is a
null range, only if the aggregate includes a single element association and
this element association has a single choice. An others choice is locally
static if the applicable index constraint is locally static.
---
There's extra credit if you can figure out why from the first paragraph ghdl is
correct.
Hint: the aggregate (X"00000000") isn't a subaggregate, it's an aggregate, and
no, throwing another pair of enclosing parens doesn't cut it, without perhaps
the superfluous others subaggregate which does work:
constant out_vectors : outvec_type := (X"00000000",others => X"00000000");
(And it works for both out_vectors_nb = 1 and greater than 1).
This is a case of a literal reading of the LRM telling us it isn't explicitly
permitted. I found two VHDL analyzers that don't allow what isn't explicitly
permitted (this case) out of a sample of two.
Notice that if I add another element to the aggregate, then the bit string is a
subaggregate.
The language is the same in 1076-2000/-2002 and2008 (which also allows slice
association, the two paragraphs are moved down).
I haven't searched for a Sense of the VASG finding on the subject to the
contrary, and in absence of such (and no indication it was to be fixed), ghdl
is doing the correct thing.
You'd also find that a qualified expression doesn't work:
constant out_vectors : outvec_type := outvec_type'(0 => X"00000000") ;
Generating the same (original) error message and serves to isolate the issue to
the aggregate.
To paraphrase - 'VHDL isn't pretty.'
_______________________________________________
Ghdl-discuss mailing list
[email protected]
https://mail.gna.org/listinfo/ghdl-discuss
