испытательный стенд нескольких архитектур

Question

извините, что я новичок на этом сайте, но я искал ответы почти на 2 дня подряд.

Я новичок в vhdl, и задание попросило сделать простой 16-битный ALU. Для этого ALU требуется 2 архитектуры: поведенческая, а также RTL-дизайн. У меня есть код для этого полного, насколько мне известно.

Я не могу понять, как написать тестовый стенд, который позволит мне запустить симуляцию для обеих архитектур в modelsim. У меня есть как файлы (тестовый стенд, так и ALU), которые компилируются отлично, однако я получаю ошибки в симуляции, говоря, что «неинициализированный inout-порт не имеет драйвера»

Я не уверен, какой код показывать для этой проблемы, Просто покажу вам начало моего туберкулеза.

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 
     ); 

Я в основном отчаянно хочу, чтобы это было сделано вовремя.

Спасибо.

Answer 1

Он выглядит отлично, за исключением того, что 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 
    ); 

Если вы остаетесь с компонентом декларации, нет необходимости создавать отдельные имена компонентов для каждой из моделей. Это спецификация конфигурации, которая связывает имя архитектуры с сущностью.

Я рекомендую вам забыть о спецификациях конфигурации и использовать экземпляр прямого объекта для простых случаев и объявления конфигурации для более сложных случаев.

Answer 2

Я рекомендую использовать явное сопоставление портов, чтобы полностью понять, что происходит в ваших экземплярах компонентов. Так, например:

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»? Не могли бы вы сделать это? Это может быть немного легче для вас.