VHDL中的延时问题

4 篇文章 0 订阅

VHDL中的延时问题【转】

VHDL中的延时问题

1。VHDL中的delta延时大于零,但小于任何指定的延时(指定的延时包括after指定的惯性延时和transport指定的传输延时)。因此,在一个确定的仿真时刻t,开启有限多个仿真周期(即一个delta延时)不会使仿真时刻向前推进,就是说不论有多少个delta延时,都认为是在t时刻。为什么能够这样认为呢,请看2。


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+Yafter 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端完全再现。对应的物理情况就是传输线。举个例

子:

脉冲a持续5ns。b信号为a信号惯性延时,由于a持续时间未保持10ns,被吃掉;c信号为a信号传输延时,延时成功。 


脉冲a持续15ns。b信号为a信号惯性延时,a持续时间超过10ns,延时成功;c信号为a信号传输延时,延时成功。

  • 8
    点赞
  • 25
    收藏
    觉得还不错? 一键收藏
  • 0
    评论
Delta Delay是指信号在不同路径到达某个节点时所引起的延迟差异。根据引用[1],在计算Setup时,Delta Delay不会受到CRPR(Clock Relationship Path Rule)机制的影响;而在计算Hold时,Delta Delay会受到CRPR机制的影响。 根据引用,时序窗口是指信号在通过不同路径到达某条Net时,最长路径延时和最短路径延迟之间的差值。Delta Delay的计算会考虑信号线A1、A2和A3对信号线V的影响。在计算信号线V的Delta Delay时,将其分成三个阶段:第一阶段,A1和A2同时对V造成影响,Delta Delay为0.26;第二阶段,A1对V造成影响,Delta Delay为0.14;第三阶段,A3对V造成影响,Delta Delay为0.23。根据最差情况的原则,信号线V的Delta Delay取最大值0.26。 需要注意的是,根据引用,如果两条Net相关的clock是异步的,处理方式会有所不同。如果设置为Async,则计算Delta Delay时采用无限时序窗口,考虑最悲观的情况。如果设置为Logic Exclusive,则只有在有重叠窗口的情况下才计算Delta Delay。如果设置为Physical Exclusive,则不考虑串扰的影响,不计算Delta Delay。如果设置为False Path,则处理方式与同步情况相同。 综上所述,Delta Delay是指信号在不同路径到达某个节点时所引起的延迟差异。在计算Setup时,Delta Delay不受CRPR影响;而在计算Hold时,Delta Delay受到CRPR影响。Delta Delay的计算会考虑时序窗口以及信号线之间的相互影响。对于异步的情况,处理方式会有所不同,根据具体的设置来确定是否计算Delta Delay。<span class="em">1</span><span class="em">2</span><span class="em">3</span> #### 引用[.reference_title] - *1* *2* *3* [STA | 9. 串扰,窗口以及CRPR对Delta Delay的处理方式](https://blog.csdn.net/graymount/article/details/106294128)[target="_blank" data-report-click={"spm":"1018.2226.3001.9630","extra":{"utm_source":"vip_chatgpt_common_search_pc_result","utm_medium":"distribute.pc_search_result.none-task-cask-2~all~insert_cask~default-1-null.142^v93^chatsearchT3_2"}}] [.reference_item style="max-width: 100%"] [ .reference_list ]

“相关推荐”对你有帮助么?

  • 非常没帮助
  • 没帮助
  • 一般
  • 有帮助
  • 非常有帮助
提交
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值