Разница между назначением сигнала внутри процесса и назначением фактического вывода

Question

Итак, по моему собственному исследованию я понимаю, что если мы назначим сигнал внутри процесса, он будет обновляться после процесса. Теперь, если мы напрямую назначим выход, значение будет также обновляться после процесса или нет? Я прилагаю две версии, как простой пример, чтобы продемонстрировать, что я имею в виду.

Версия 1:

library IEEE; 
use IEEE.STD_LOGIC_1164.ALL; 

entity testing is 
port(
    clk : in std_logic; 
    a : in std_logic; 
    b : in std_logic; 
    c : out std_logic 
); 

end testing; 

architecture arch of testing is 

signal temp: std_logic; 

begin 

process(clk) 

begin 

    if(rising_edge(clk)) then 

     if(a = '1' and b = '1') then 

      temp <= '1' 

     end if; 

    end if; 

end process; 

c <= temp; 

end arch; 

Теперь другая версия:

library IEEE; 
use IEEE.STD_LOGIC_1164.ALL; 

entity testing is 
port(
    clk : in std_logic; 
    a : in std_logic; 
    b : in std_logic; 
    c : out std_logic 
); 

end testing; 

architecture arch of Intermediate is 

begin 

process(clk) 

begin 

    if(rising_edge(clk)) then 

     if(a = '1' and b = '1') then 

      C <= '1'; 

     end if; 

    end if; 

end process; 

end arch; 

Есть ли разница времени здесь? Будет ли C идти быстрее во второй версии, чем по сравнению с первой версией?

Answer 1

C будет назначаться (слегка) ранее в вашем втором примере по сравнению с вашим первым. Кроме того, используется меньшее количество ресурсов, так как в вашем втором примере нет промежуточного регистра (temp).

В первом примере, temp будет назначен по заднему фронту тактового сигнала, и C является одновременным назначением (то есть. Как только temp изменения, C изменений). Однако на практике это назначение происходит через некоторое «небольшое количество времени» после изменения temp из-за распространения сигнала.

В вашем втором примере вы прямо назначаете C, что будет происходить на краю падающих часов.

Я знаю пример, который вы предоставили несколько надуманным, но вы могли бы добиться того же с:

process(clk) 
begin 
    if rising_edge(clk) then 
     c <= a and b; 
    end if; 
end process; 

Answer 2

Цикл моделирования возобновляет каждый процесс выполнения каждого, пока не приостановлено ждать. Дальнейшие события для текущего времени вызывают дельта-циклы, иначе время симуляции переходит к следующему запланированному событию. Циклы моделирования продолжаются до тех пор, пока не произойдет или не остановится.

Параллельные операторы имеют эквивалентные разработанные процессы или блоки и процессы. Разработанная иерархия проектов представляет собой совокупность процессов, сообщающихся через сигнальные события.

c может произойти один дельта-цикл позже в первом примере из-за последовательных назначений сигналов без промежуточной задержки. Циклы Delta не потребляют simulation time, скорее создают видимость параллелизма для последовательных операторов.

Версия 1 имеет второй процесс из оператора одновременного присваивания сигнала и использует дополнительный сигнал, представляющий большее время выполнения для модели и использование большего количества ресурсов. Версия 1 не представляет собой значительную нагрузку сама по себе. За счет большого количества таких процессов или большого количества событий разница в времени выполнения модели и использовании памяти может быть измеримой.

Где вы обычно видите промежуточный сигнал , где значение сигнала оценивается локально в дополнение к управлению портом. Вам не разрешено считывать значение выходного сигнала интерфейса. (Конструктивные единицы независимо анализируются, фактическое значение фактического значения не известно во время анализа. Фактические данные связаны с разработкой. Порты представляют собой формы в ассоциации портов.)

См. IEEE Std 1076-2008, 11. Параллельные заявления 10.5.2 Простые заявления о назначении сигнала; 10.2 Задержка ожидания; 14. Разработка и исполнение; особенно 14.5. Разработка части отчета и 14.5.5. Другие параллельные заявления; 14.7 Выполнение модели, в частности 14.7.5 Исполнение модели; 6.5.2 Объявление объектов интерфейса; 6.5.7.3 аспекты карты порта; 14.3.5. Аспект карты порта.

Answer 3

Сначала следующее не совсем правильно, но это верно для большинства РТЛ процессов:

сигнал внутри процесса не обновляется до окончания процесса заканчивается

Фактическое правило это:

Сигнал не обновляется до следующего цикла дельта.

WRT процесс, процесс не допускает прохождения дельта-циклов, если процесс не приостанавливается при ожидании или не прекращается и не приостанавливается в списке чувствительности. Большинство RTL-процессов имеют либо списки чувствительности, либо имеют только один оператор ожидания наверху, поэтому для RTL-кода мы приходим к вашей «не совсем правде».

WRT к заданию на C:

c <= temp; 

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

process (temp) is 
begin 
    c <= temp; 
end process ; 

Это поможет вам понять, что происходит WRT вашего простого правила RTL.