Испытательный стенд нескольких архитектур
Извините, я новичок на этом сайте, но я искал ответы почти 2 дня подряд.
Я новичок в VHDL, и назначение попросило сделать простой 16-битный АЛУ. Для этого ALU требуется 2 архитектуры: поведенческая, а также дизайн RTL. У меня есть код для этого, насколько я понимаю.
Что я не могу понять, так это как написать тестовый стенд, который позволит мне запустить симуляцию для обеих архитектур в modelsim. У меня есть оба файла (тестовый стенд и ALU), которые хорошо компилируются, однако я получаю ошибки в симуляции, говорящие, что "неинициализированный входной порт не имеет драйвера"
Я не уверен, какой код показать для этой проблемы, поэтому я просто покажу вам начало моего туберкулеза.
LIBRARY ieee;
USE ieee.std_logic_1164.ALL;
USE ieee.numeric_std.ALL;
ENTITY tb IS
END tb;
ARCHITECTURE behavior OF tb IS
signal Clk,Res : std_logic := '0';
signal A,B : signed(15 downto 0) := (others => '0');
signal R1, R2 : signed(31 downto 0) := (others => '0');
signal Op : unsigned(2 downto 0) := (others => '0');
constant Clk_period : time := 10 ns;
component ALU_16_First
port(A, B: signed(15 downto 0):=(others => '0'); R: inout signed(31 downto 0):= (others => '0'); Op: in unsigned(2 downto 0) := (others => '0'); Clk, Res: Std_logic);
end component ALU_16_First;
component ALU_16_RTL
port(A, B: in signed(15 downto 0):= (others => '0');
R: inout signed(31 downto 0):= (others => '0'); Op: in unsigned(2 downto 0) := (others => '0'); Clk, Res: Std_logic);
end component ALU_16_RTL;
for ALU_Behaviorial: ALU_16_First use entity work.simple_alu(Behavioral);
for ALU_RTL: ALU_16_RTL use entity work.simple_alu(RTL);
BEGIN
-- Instantiate the Unit Under Test (UUT)
ALU_Behaviorial : ALU_16_First PORT MAP (
A,
B,
R1,
Op,
Clk,
Res
);
ALU_RTL: ALU_16_RTL PORT MAP (
A,
B,
R2,
Op,
Clk,
Res
);
Я в основном отчаянно пытаюсь сделать это вовремя.
Благодарю.
2 ответа
Это выглядит хорошо, за исключением того, что порт R находится на выходе (как заметил Рассел). Если по какой-то причине вам требуется, чтобы порт R был двунаправленным, убедитесь, что он назначен на 'Z' в течение соответствующего времени в тестовом стенде:
testProc : process
begin
...
R <= (others => 'Z') ;
В будущем вы можете сэкономить некоторое время, используя непосредственную реализацию объекта вместо объявления компонента, спецификации конфигурации и создания экземпляра компонента:
ALU_Behaviorial : use work.simple_alu(Behavioral)
PORT MAP (
A => A_tb,
B => B_tb,
R => R1_tb,
Op => Op_tb,
Clk => Clk_tb,
Res => Res_tb
);
Если вы останетесь с объявлением компонента, нет необходимости создавать отдельные имена компонентов для каждой из моделей. Именно ваша спецификация конфигурации связывает имя архитектуры с сущностью.
Я рекомендую вам забыть о спецификациях конфигурации и использовать непосредственное создание сущностей для простых случаев и объявления конфигурации для более сложных случаев.
Я рекомендую использовать явное сопоставление портов, чтобы полностью понять, что происходит в ваших экземплярах компонентов. Так, например:
ALU_Behaviorial : ALU_16_First PORT MAP (
A => A_tb,
B => B_tb,
R1 => R1_tb,
Op => Op_tb,
Clk => Clk_tb,
Res => Res_tb
);
_tb сигналы - это ваши тестовые сигналы. Теперь убедитесь, что ваши входные данные для ваших компонентов (A_tb, B_tb, R1_tb, Op_tb, Clk_tb, Res_tb) управляются архитектурой вашего тестового стенда. Где ваш тестовый стенд управляет этими входами?
Кроме того, есть ли веская причина, по которой вы решили сделать R1 "inout"? Не могли бы вы просто сделать это? Это может быть немного проще для вас.