特权同学

时序分析基础与时钟约束实例(1)

0
阅读(3812)
 

时序分析基础与时钟约束实例(1

文中实例配套SF-CY3开发套件。更多内容请参考《SF-CY3 FPGA套件开发指南》。

何谓静态时序分析(STAStatic Timing Analysis)?

首先,设计者应该对FPGA内部的工作方式有一些认识。FPGA的内部结构其实就好比一块PCB板,FPGA的逻辑阵列就好比PCB板上的一些分立元器件。PCB通过导线将具有相关电气特性的信号相连接,FPGA也需要通过内部连线将相关的逻辑节点导通。PCB板上的信号通过任何一个元器件都会产生一定的延时,FPGA的信号通过逻辑门传输也会产生延时。PCB的信号走线有延时,FPGA的信号走线也有延时。这就带来了一系列问题,一个信号从FPGA的一端输入,经过一定的逻辑处理后从FPGA的另一端输出,这期间会产生多大的延时呢?有多个总线信号从FPGA的一端输入,这条总线的各个信号经过逻辑处理后从FPGA的另一端输出,这条总线的各个信号的延时一致吗?之所以关心这些问题,是因为过长的延时或者一条总线多个信号传输时间的不一致,不仅会影响FPGA本身的性能,而且也会给FPGA之外的电路或者系统带来诸多问题。

言归正传吧,之所以引进静态时序分析的理论也正是基于上述的一些思考。它可以简单的定义为:设计者提出一些特定的时序要求(或者说是添加特定的时序约束),套用特定的时序模型,针对特定的电路进行分析。分析的最终结果当然是要求系统时序满足设计者提出的要求。

         下面举一个最简单的例子来说明时序分析的基本概念。假设信号需要从输入到输出在FPGA内部经过一些逻辑延时和路径延时。系统要求这个信号在FPGA内部的延时不能超过15ns,而开发工具在执行过程中找到了如图所示的一些可能的布局布线方式。那么,怎样的布局布线能够达到系统的要求呢?仔细分析一番,发现所有路径的延时可能为14ns15ns16ns17ns18ns,有两条路径能够满足要求,那么最后的布局布线就会选择满足要求的两条路径之一。

         静态时序分析的前提就是设计者先提出要求,然后时序分析工具才会根据特定的时序模型进行分析,即有约束才会有分析。若设计者不添加时序约束,那么时序分析就无从谈起。特权同学常常碰见一些初学者在遇到问题时不问青红皂白就认为是时序问题,实际上只有在添加了时序约束后,系统的时序问题才有可能暴露出来。

         下面我们再来看一个例子,我们假设有4个输入信号,经过FPGA内部一些逻辑处理后输出。FPGA内部的布线资源有快有慢之分,好比国道和高速公路。通过高速通道所需要的路径延时假设为3ns-7ns,但只有两条可用;而通过慢速通道的路径延时则>10ns

         默认情况下,离高速通道较近的din_2din_3路径被布线到了高速通道上,当前的4个信号在FPGA内部的延时为:

         din1 = 15ns, din2 = 4ns, din3 = 6ns, din4 = 13ns

但是,我们实际的系统需求是这样的:

         din1 < 10ns, din2 < 10ns, din3 < 20ns, din4 < 20ns

         按照前面给出的4个输入信号的默认布局布线情况来看,din1是无法满足时序要求的。

         如果我们按照实际的需求对FPGA进行如下的时序约束:

         din1 < 10ns, din2 < 10ns, din3 < 20ns, din4 < 20ns

         此时,FPGA将重新进行布局布线。

由于添加了时序约束,因此,FPGA的布局布线工具会根据这个实际需求,重新做布局布线后,我们看到,重新布局布线后的路径延时如下:

          din1 = 7ns, din2 = 4ns, din3 = 18ns, din4 = 13ns

         此时,FPGA内部的时序全部都能够满足要求。

         关于约束,我们要稍微提一下两种不恰当的约束方法,即欠约束和过约束。我们假设下面提到的两种情况下的原始系统实际时序要求都是一样的,即前面我们所说的:

din1 < 10ns, din2 < 10ns, din3 < 20ns, din4 < 20ns

但是下面这两种情况的约束不是完全按照实际系统时序需求来约束,我们来看看这些情况下会出现什么问题。

欠约束的情况(din1din2过约束):

         如果对本实例添加约束为 din1 < 20ns, din2 < 20ns, din3 < 20ns, din4 < 20ns

         此时,由于4条路径的延时都能够控制在20ns要求之内,所以当前的约束都能够达到目标。

         但是,相对于实际的情况,有两种情形:

         A. din1din2走了高速通道,那么当前约束也能够满足实际的时序要求;

         B. din1din2都没有走高速通道,或者有1条路径走了高速通道,那么结果是一样的,整个系统的时序无法满足要求。   

过约束的情况(din3din4过约束):

         如果对本实例添加约束为: din1 < 10ns, din2 < 10ns, din3 < 10ns, din4 < 10ns

         此时,由于能够走高速通道使得路径延时<10ns的路径只有2条,那么无论如何当前的约束都有2条无法达到目标。

         但是,相对于实际的情况,有两种情形:

         A. din1din2走了高速通道,那么当前约束也能够满足实际的时序要求;

         B. din1din2都没有走高速通道,或者有1条路径走了高速通道,那么结果是一样的,整个系统的时序无法满足要求。   

这个简单的例子当然不会是FPGA内部实际的情况,但是FPGA内部的各种资源若要得到均衡的分配,设计者就必须添加一定的约束(时序约束),将设计的需求传达给工具,那么才有可能指导工具进行资源的合理分配,保证系统的基本性能要求得以实现。

         时序欠约束和时序过约束都是不可取的,设计者应该根据实际的系统时序要求,添加合适的时序要求(可以稍微过约束),帮助设计工具达到最佳的时序性能。

         下面我们再来认识一些时序分析的几个最基本的概念,即时钟和建立时间、保持时间的关系。

         时钟这个并不陌生的词汇,特权同学也不大做文章,就先举个最典型的时钟模型献给大家。如图所示,理想的时钟模型是一个占空比为50%且周期固定的方波。为一个时钟周期,为高脉冲宽度,为低脉冲宽度,=+。占空比定义为高脉冲宽度与周期之比,即/

         所谓建立时间(),是指在时钟上升沿到来之前数据必须保持稳定的时间;所谓保持时间(),是指在时钟上升沿到来以后数据必须保持稳定的时间。一个数据需要在时钟的上升沿被锁存,那么这个数据就必须在这个时钟上升沿的建立时间和保持时间内保持稳定。

         这里,我们举一个二输入与功能的时序设计模型,如图所示。输入数据data1data2会在时钟的上升沿被分别锁存到reg2reg1的输出端,然后这两个信号分别经过各自的路径到达与门and的输入端,他们相与运算后信号传送到下一级寄存器reg3的输入端,对应他们上一次被锁存后的下一个时钟上升沿,reg3的输入端数据被锁存到了输出端。这个过程是一个典型的寄存器到寄存器的数据传输。下面我们就要以此为基础来探讨他们需要满足的建立时间和保持时间关系。

         下面这个波形,clk表示时钟源发出的时钟波形,它要分别达到上面例子中的源寄存器reg1reg2,以及达到目的寄存器reg3,所经过的时间是不一样的,因此我们看到波形中给出的时钟达到reg3的波形clk_r3相对于基准时钟clk的波形会略有一些偏差(稍微延时一些,这是真实情况的模拟)。Reg1outreg2out分别是数据data1data2被锁存到各自寄存器的输出端的波形,reg3in则是reg1outreg2out的波形经过路径延时和门延时后到达reg3in的波形,而reg3out则是在clk_r3的上升沿来到并锁存好有效的数据后,其寄存器输出端的波形。

         在这个波形中,我们看到clk_r3的前后各有一条虚线,前一条虚线到clk_r3的上升沿这段时间即建立时间,clk_r3的上升沿到后一条虚线即保持时间。前面对建立时间和保持时间下定义时提到过,在这段时间内不能够有数据的变化,数据必须保持稳定。而在这个波形中,也确实没有看到建立时间和保持时间内,reg3in的数据有任何的变化,因此我们可以稳定的将reg3in的数据锁存到reg3的输出reg3out中。

我们再来看下面这个波形,同样的一些信号,但我们发现reg3inclk_r3的建立时间内发生了变化,这带来的后果就是clk_r3上升沿锁存到的reg3in数据不确定,那么随后的reg3out值也会处于一个不确定状态。比如第一个时钟周期,原本reg3in应该是稳定的低电平,但是由于真个路径上的延时时间过长,导致了reg3inclk_r3的建立时间数据还未能稳定下来,在建立时间内出现了电平正处于从高到低的变化,即不稳定的状态,那么导致的后果就是reg3out的最终输出要么是高电平要么是低电平,而不是原本期望的低电平。

         我们再来看看保持时间违规的情况,如图所示,这次是数据传输得太快了,原本应该下一个时钟周期到达clk_r3的数据竟然在clk_r3的前一个时钟周期后的保持时间还未过去就来到了。因此,它出现的最终危害也是后端输出的reg3out处于不确定的状态。