2。在具体硬件中,进程是并行发生的,也就是说,数据总是不断的流进各个模块,模块间不会有先来后到。因此在一个时刻t,会同时有多个事件发生。但是仿真软件是在PC机上用C语言之类的串行机制实现的,所以就必须在串行机制下尽可能准确地仿真并行事件的发生。怎么办呢,就出现了delta延时的模型。在一个仿真周期(即一个delta延时)里,仿真器串行的处理各个事件,但我们把这个仿真周期看成一个整体认为这些事件宏观上是并行的。既然是并行的,就理所当然地认为还是在t时刻了。
3。一个process只要在时刻t它的敏感表中有事件发生,就开启一个仿真周期。一个仿真周期里,可以同时有多个process被激活,就看敏感表中是不是有事件。但是对于一个进程,不管它有多长,只要其中没有after 之类的具体时间延时,就认为需要花费一个delta延时完成,也就是说它的结果是在delta之后才更新的(可以理解成立刻算出来,但是等到delta之后才更新)。如果它的输出在delta后更新完又触发了另外一个process,那么就再开一个仿真周期,再花费delta执行。由1可知,不管开了多少个delta,都认为在时刻t并行发生。但是注意,一旦哪个进程中有after了,就认为新值在after指定时间更新,不考虑delta。
4。举个例子。
(i)下面两行在一个architecture中:
Z <= X+Y--(1)
A <= Z+B--(2)
这样两句话可以看成两个进程。现在的时刻为t1,此时X变化了,好,激活了(1),开一个仿真周期,立即计算Z=X+Y,但是要等到delta延时后Z的值更新。由于Z的值发生了变化,又激活了(2),好,再开一个仿真周期,算出A=Z+B,再等delta后A的值更新。因此,无论(1)(2)先写谁,都是这样的过程,总共花费2delta(还属于ti时刻)。穗缓
(ii)上面我们假设了X变化时B没有变。假如X变化时B也变化了,这时开一个仿真周期,在这个周期里(1)(2)同时被激活,Z和A的值同时计算(当然仿真器具体实现时有先后,但在delta内认为并行),等待delta后,Z和A同时更新,但一定要注意,这时的A值是利用Z更新前的值计算的。之后,Z的变化再次激活(2),这时计算的A就是用更新后的Z了,但是要再等待delta,A值才更新为最后的结果。和(i)对比,结果相同,时间花费也相同,都是2delta。
(iii)假如把(1)改成Z <= X+Y after 2ns,(2)不变,那么t1时刻X变化后,就认为在t1+2ns时刻Z值更磨租新,不考虑delta延时。之后,再过delta延时A值更新。所以总花费变为delta+2ns.
(iv)假如(1)(2)是在一个process中,那么情况是这样的。由于在一个process里只开一个仿真周期,所以(1)(2)总是在一个delta里完成,因此无论(1)(2)先写谁,最终的A值是利用Z的旧值计算的,就会出现错误的结果。这一点一定要注意。这也是为什么在一个process里给一个信号多次赋值,只会得到最后一个赋值的结猜游模果。因为每一次赋值都在等着delta时间结束才更新。
5。总结一下,就是在一个进程中内部和有after的语句可以理解为不再单开仿真周期。
6。再深究一下,信号赋值为什么要等待delta延时呢?2中说过,是由于要利用串行机制处理并行问题。除此之外,还由于信号本身用途和特点所决定。信号主要用于进程间通信,同时信号是需要驱动的,假如一个A进程需要读入 signal Z的值,B进程又在写入signal Z的值,那么仿真时就会有冲突。通过引入delta延时,使得读写错开一段delta时间,解决了信号在进程间同时读写的问题。
7。题外话,说明一下惯性延时和传输延时的区别。惯性延时就是说使输出能够得到正确的值,输入需要保持多久。比如
Z <= X after 2ns,说明X需要至少保持2ns,Z才会得到X的值,否则X的值可能被吃掉。对应的物理情况是要给电容留够充放电时间,太短的脉冲就可能被吃掉了。而传输延时没有吃不吃掉的问题,就是经过多长时间输入完全再现,不管脉冲多么短。比如:
Z<= transport X after 2ns,就是指X的值经过2ns后在Z端完全再现。对应的物理情况就是传输线。
延时分为两种,一种是惯性延迟(inertial),这也是默认的延迟;另一种是传输延迟(transport)。念掘惯性延迟常用于模拟元件延迟,它不能传播尖峰脉冲(比如 q <= a after 5 ns--如果a的保持高或者低的时神高孝间<5ns,那么a的变化将反应不到 q信号游稿上)。
传输延迟能够传输脉冲,用于模拟连线延迟。
你是想写一个分频程序吧,,错误蛮多的,variable只能用在进程中烂悉,不能在两个进程里面同时对猜掘一个信号,或者变量赋值,下面是我饥兆乎帮你修改的程序;library ieee
use ieee.std_logic_1164.all
use ieee.std_logic_unsigned.all
entity cf is
port(clk,trigger:in std_logic
delclk:out std_logic)
end cf
architecture behave of cf is
begin
process(clk,trigger)
variable count:integer range 0 to 100
begin
if trigger='1' then
count:=0delclk<='0'
elsif clk'event and clk='1' then
if count=100 then
count:=0
delclk<='1'
else count:=count+1
delclk<='0'
end if
end if
end process
end behave
欢迎分享,转载请注明来源:内存溢出
评论列表(0条)