因此，通过我自己的研究，我明白，如果我们在一个过程中分配信号，则将在过程之后进行更新。现在，如果我们直接分配输出值，则该值也会在过程之后是否会更新？我将两个版本作为一个简单的示例来演示我的意思。
版本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在第二版中会更早吗？
首先，以下不是很正确，但是对于大多数RTL过程是正确的：
在过程之后，过程中的信号才能更新 完成
实际规则是：
信号直到下一个三角洲周期才更新。
wrt一个过程，一个过程不允许三角洲周期通过，除非该过程要么暂停等待或退出并暂停灵敏度列表。大多数RTL过程都具有敏感性列表，或者在顶部只有一个等待语句，因此，对于RTL代码，我们到达您的"不是完全真相"。
WRT到您分配给C：
c <= temp;
该分配中仍然有一个三角洲周期。如果有帮助，该语言通过以下转换来定义并发作业执行：
process (temp) is
begin
c <= temp;
end process ;
这将帮助您了解您的简单RTL规则正在发生的事情。
C将在第二个示例中（与第一个示例相比，略有）。另外，使用较少的资源，因为您的第二个示例中没有中间寄存器（TEMP）。
在您的第一个示例中，temp将在时钟的下降边缘分配，而C是并发分配（即temp更改后，C更改）。但是，实际上，由于信号传播，temp更改后发生了一些"少量时间"。
在您的第二个示例中，您将直接分配给C，该示例将发生在下落时钟边缘。
我知道您提供的示例是有些人为的，但是您可以通过以下方式实现同样的成就：
process(clk)
begin
if rising_edge(clk) then
c <= a and b;
end if;
end process;
模拟周期恢复执行每个过程，直到暂停等待。当前时间的更多事件导致三角洲周期，否则模拟时间将推进下一个预定事件。模拟周期一直持续到事件或停止。
并发语句具有等效的详细过程或块和过程。精心设计的设计层次结构是通过信号事件通信的过程集合。
c可能在第一个示例的稍后发生一个三角洲周期，因为连续的信号分配没有中间延迟。增量周期不会消耗仿真时间，而是产生顺序陈述的并发的外观。
版本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端口地图方面。