Un agregado obtiene su tipo de contexto. No escribe, convierte un tipo desconocido en un tipo sin signo.
Puede usar una expresión calificada para especificar el tipo del agregado:
library ieee;
use ieee.std_logic_1164.all;
use ieee.numeric_std.all;
entity foo is
end entity;
architecture fum of foo is
signal some_unsigned: unsigned (7 downto 0);
begin
some_unsigned <= unsigned( '1' & unsigned'(((17-10-1) downto 0 => '0')));
end architecture;
(También tenía uno entre muchos paréntesis de cierre ')'.
Esto analiza, elabora y simula (aunque no hace nada interesante, la simulación nos indica la longitud de la mano izquierda y la derecha de las asignaciones).
Y a menos que me equivoque, el apóstrofe agregado va exactamente donde aparece la barra vertical en su mensaje de error ncvhdl:
illegal type conversion operand [7.3.5].
unsigned( '1' & unsigned'(((17-10-1) downto 0 => '0')));
|
(con apóstrofe agregado para la expresión calificada mostrada)
Y para simplificar toda la expresión:
library ieee;
use ieee.std_logic_1164.all;
use ieee.numeric_std.all;
entity foo is
end entity;
architecture fum of foo is
signal some_unsigned: unsigned (7 downto 0);
begin
some_unsigned <= ( '1' & unsigned'(((17-10-1) downto 0 => '0')));
end architecture;
Esto también funciona, porque solo hay un "&" funciona como una sobrecarga de operador definida que tomará un std_ulogic ('1') y un unsigned.
Lukkio pregunta:
Entonces, por ejemplo, una expresión como b <= a + (3 downto 0 => '1') donde 'b' y 'a' están sin firmar, ¿es válida?
Puedo agregar otra arquitectura al ejemplo del código de entidad foo:
architecture fie of foo is
signal a,b: unsigned (3 downto 0);
begin
b <= a + (3 downto 0 => '1');
end architecture;
(y funciona).
El agregado obtiene su tipo de contexto. IEEE 1076-1993, 7.3.2 Agregados, párrafo 7:
El tipo de un agregado se podrá determinar únicamente a partir del contexto en el que aparece el agregado, excluyendo el agregado en sí, pero utilizando el hecho de que el tipo del agregado será un tipo compuesto. El tipo de un agregado a su vez determina el tipo requerido para cada uno de sus elementos.
El contexto aquí es la función "+" con un operando izquierdo sin signo y un valor de retorno sin firmar y sabiendo que tiene que ser un tipo de matriz.
El tipo del operando de la mano izquierda a no está firmado. El tipo de resultado se determina por el tipo de la asignación target b . Podemos determinar a partir del agregado que se trata de una matriz dimensional única.
Solo hay una sobrecarga de operador disponible en el único paquete proporcionado en la cláusula de contexto que es elegible. Eso es "+" [sin firmar, sin firmar, devolver sin firmar] en el paquete numeric_std.
Sin ambigüedad en cuanto a qué operador de sobrecarga y los tipos de sus argumentos y resultados, el tipo de expresión agregada debe estar sin signo, determinado a partir del contexto.
También tenga en cuenta que podemos determinar su subtipo por la restricción de índice proporcionada en la elección del agregado.