Ваша проблема не может быть воспроизведена без [Пример минимального, полного и проверяемого].Здесь, по крайней мере, включая объявление объекта для ripple_carry_adder и фактические полные предупреждения:
При добавлении, например:
library ieee;
use ieee.std_logic_1164.all;
entity ripple_carry_adder is
generic ( g_WIDTH: natural := 4); -- a default value for convenience
port (
i_add_term1: in std_logic_vector (g_WIDTH - 1 downto 0);
i_add_term2: in std_logic_vector (g_WIDTH - 1 downto 0);
o_result: out std_logic_vector (g_WIDTH downto 0)
);
end entity;
предупреждений (во всей их полноте):
ghdl -a ripple_carry_adder.vhdl
ghdl -e ripple_carry_adder
ripple_carry_adder.vhdl:34:5:warning: component instance "i_full_adder_inst" of 'full_adder' is not bound
[-Wbinding] ripple_carry_adder.vhdl:13:14:warning: (in default configuration of ripple_carry_adder(rtl)) [-Wbinding]
Здесь сообщается нам название сущности, не связанной.Строка 13 - это объявление компонента для full_adder.Строка 34 - это экземпляр компонента, который при попытке создать индикацию неявного связывания в конфигурации компонента не найден.
Не является незаконным разрабатывать проект с несвязанными компонентами, что приводит к открытию индикации связывания.Разрешение несвязанных компонентов может быть полезно при инкрементной разработке в дизайне сверху вниз.
См. IEEE Std 1076-2008
3.4.3 Конфигурация компонента:
Если данный экземпляр компонентаunbound в соответствующем блоке, тогда любая явная конфигурация компонента для этого экземпляра, которая не содержит явного указания привязки, будет содержать неявное указание привязки по умолчанию (см. 7.3.3).Точно так же, если данный экземпляр компонента не связан в соответствующем блоке, тогда любая неявная конфигурация компонента для этого экземпляра будет содержать неявное указание привязки по умолчанию.
Вы не предоставляете объявление конфигурации сконфигурация компонента, обеспечивающая указание привязки.Конфигурация неявного компонента будет содержать указание привязки по умолчанию.
7.3.3 Указание привязки по умолчанию
В определенных обстоятельствах указание привязки по умолчанию будет применяться при отсутствии явного указания привязки,Индикация привязки по умолчанию состоит из аспекта объекта по умолчанию, вместе с аспектом общей карты по умолчанию и аспектом карты порта по умолчанию, в зависимости от ситуации.
Если ни одно видимое объявление сущности не имеет такого же простого имени, как у экземпляра экземпляра, то аспект сущности по умолчанию открыт.Объявление видимой сущности - это первое объявление сущности, если оно есть, в следующем списке:
a) Объявление сущности, которое имеет такое же простое имя, как и у экземпляра, созданного в качестве экземпляра, и которое является непосредственно видимым (см. 12.3),
b) Объявление сущности, которое имеет то же простое имя, что и имя экземпляра компонента, и которое было бы непосредственно видимым в отсутствие непосредственно видимого (см. 12.3) объявления компонента с таким же простымname как объявление сущности или
c) Объявление сущности, обозначаемое LC, где L - целевая библиотека, а C - простое имя создаваемого экземпляра компонента.Целевая библиотека - это логическое имя библиотеки, содержащей единицу разработки, в которой объявлен компонент C.
Эти проверки видимости выполняются в момент отсутствия явного указания привязки, которое приводит к применению указания привязки по умолчанию.
Во время разработки (здесь часть статического связываниясвязывание и загрузка) сборки модели, инструмент VHDL будет искать объявление сущности с тем же именем (здесь full_adder).
Если во время разработки будет найдена сущность с архитектурой для full_adder, она будетбыть привязанным указанием привязки по умолчанию:
ghdl -a full_adder.vhdl
ghdl -a ripple_carry_adder.vhdl
ghdl -e ripple_carry_adder
Нет предупреждений и с помощью тестового стенда, если модель запускает выходные данные full_adder, вы увидите действительные уровни сигналов.(Без тестового стенда моделирование только покажет, что нет ошибок составного элемента сопоставления, и все типы верны. Порядок анализа full_adder и ripple_carry_adder не важен, поскольку оба они анализируются до того, как будет разработан ripple_carry_adder.
Предупреждения говорят о том, что либо имя вашего компонента не совпадает с видимым именем объекта, возможно, объект не был проанализирован в справочной библиотеке.
Вот полный_прием, который я создал для демонстрации:
library ieee;
use ieee.std_logic_1164.all;
entity full_adder is
port (
i_bit1: in std_logic;
i_bit2: in std_logic;
i_carry: in std_logic;
o_sum: out std_logic;
o_carry: out std_logic
);
end entity full_adder;
architecture foo of full_adder is
begin
o_sum <= i_carry xor i_bit1 xor i_bit2;
o_carry <= (i_carry and i_bit1) or
(i_carry and i_bit2) or
(i_bit1 and i_bit2);
end architecture;
Также могут быть ошибки при разработке.Объявление компонента и объявление сущности должны совпадать, формалы, найденные в родовом аспекте карты или аспекте карты порта в экземпляре, должны соответствовать объявлению сущности, режимы должны согласовываться, должен быть соответствующий элемент для каждого элемента составного формальности.и актуально в списке ассоциаций....