入门资料FPGA时序分析报告基础与时钟约束实例.docx

入门资料FPGA时序分析报告基础与时钟约束实例.docx

《入门资料FPGA时序分析报告基础与时钟约束实例.docx》由会员分享，可在线阅读，更多相关《入门资料FPGA时序分析报告基础与时钟约束实例.docx（21页珍藏版）》请在冰豆网上搜索。

入门资料FPGA时序分析报告基础与时钟约束实例

入门：

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

2013-07-16

何谓静态时序分析（STA，StaticTimingAnalysis）？

首先，设计者应该对FPGA内部的工作方式有一些认识。

FPGA的内部结构其实就好比一块PCB板，FPGA的逻辑阵列就好比PCB板上的一些分立元器件。

PCB通过导线将具有相关电气特性的信号相连接，FPGA也需要通过内部连线将相关的逻辑节点导通。

PCB板上的信号通过任何一个元器件都会产生一定的延时，FPGA的信号通过逻辑门传输也会产生延时。

PCB的信号走线有延时，FPGA的信号走线也有延时。

这就带来了一系列问题，一个信号从FPGA的一端输入，经过一定的逻辑处理后从FPGA的另一端输出，这期间会产生多大的延时呢？

有多个总线信号从FPGA的一端输入，这条总线的各个信号经过逻辑处理后从FPGA的另一端输出，这条总线的各个信号的延时一致吗？

之所以关心这些问题，是因为过长的延时或者一条总线多个信号传输时间的不一致，不仅会影响FPGA本身的性能，而且也会给FPGA之外的电路或者系统带来诸多问题。

言归正传吧，之所以引进静态时序分析的理论也正是基于上述的一些思考。

它可以简单的定义为：

设计者提出一些特定的时序要求（或者说是添加特定的时序约束），套用特定的时序模型，针对特定的电路进行分析。

分析的最终结果当然是要求系统时序满足设计者提出的要求。

        下面举一个最简单的例子来说明时序分析的基本概念。

假设信号需要从输入到输出在FPGA内部经过一些逻辑延时和路径延时。

系统要求这个信号在FPGA内部的延时不能超过15ns，而开发工具在执行过程中找到了如图所示的一些可能的布局布线方式。

那么，怎样的布局布线能够达到系统的要求呢？

仔细分析一番，发现所有路径的延时可能为14ns、15ns、16ns、17ns、18ns，有两条路径能够满足要求，那么最后的布局布线就会选择满足要求的两条路径之一。

        静态时序分析的前提就是设计者先提出要求，然后时序分析工具才会根据特定的时序模型进行分析，即有约束才会有分析。

若设计者不添加时序约束，那么时序分析就无从谈起。

特权同学常常碰见一些初学者在遇到问题时不问青红皂白就认为是时序问题，实际上只有在添加了时序约束后，系统的时序问题才有可能暴露出来。

        下面我们再来看一个例子，我们假设有4个输入信号，经过FPGA内部一些逻辑处理后输出。

FPGA内部的布线资源有快有慢之分，好比国道和高速公路。

通过高速通道所需要的路径延时假设为3ns-7ns，但只有两条可用；而通过慢速通道的路径延时则>10ns。

        默认情况下，离高速通道较近的din_2和din_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

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

欠约束的情况（din1和din2过约束）：

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

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

        但是，相对于实际的情况，有两种情形：

        A.din1和din2走了高速通道，那么当前约束也能够满足实际的时序要求；

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

过约束的情况（din3和din4过约束）：

        如果对本实例添加约束为：

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

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

        但是，相对于实际的情况，有两种情形：

        A.din1和din2走了高速通道，那么当前约束也能够满足实际的时序要求；

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

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

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

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

        时钟这个并不陌生的词汇，特权同学也不大做文章，就先举个最典型的时钟模型献给大家。

如图所示，理想的时钟模型是一个占空比为50%且周期固定的方波。

为一个时钟周期，

为高脉冲宽度，

为低脉冲宽度，

=

+

。

占空比定义为高脉冲宽度与周期之比，即

/

。

        所谓建立时间（

），是指在时钟上升沿到来之前数据必须保持稳定的时间；所谓保持时间（

），是指在时钟上升沿到来以后数据必须保持稳定的时间。

一个数据需要在时钟的上升沿被锁存，那么这个数据就必须在这个时钟上升沿的建立时间和保持时间内保持稳定。

        这里，我们举一个二输入与功能的时序设计模型，如图所示。

输入数据data1和data2会在时钟的上升沿被分别锁存到reg2和reg1的输出端，然后这两个信号分别经过各自的路径到达与门and的输入端，他们相与运算后信号传送到下一级寄存器reg3的输入端，对应他们上一次被锁存后的下一个时钟上升沿，reg3的输入端数据被锁存到了输出端。

这个过程是一个典型的寄存器到寄存器的数据传输。

下面我们就要以此为基础来探讨他们需要满足的建立时间和保持时间关系。

        下面这个波形，clk表示时钟源发出的时钟波形，它要分别达到上面例子中的源寄存器reg1和reg2，以及达到目的寄存器reg3，所经过的时间是不一样的，因此我们看到波形中给出的时钟达到reg3的波形clk_r3相对于基准时钟clk的波形会略有一些偏差（稍微延时一些，这是真实情况的模拟）。

Reg1out和reg2out分别是数据data1和data2被锁存到各自寄存器的输出端的波形，reg3in则是reg1out和reg2out的波形经过路径延时和门延时后到达reg3in的波形，而reg3out则是在clk_r3的上升沿来到并锁存好有效的数据后，其寄存器输出端的波形。

        在这个波形中，我们看到clk_r3的前后各有一条虚线，前一条虚线到clk_r3的上升沿这段时间即建立时间，clk_r3的上升沿到后一条虚线即保持时间。

前面对建立时间和保持时间下定义时提到过，在这段时间内不能够有数据的变化，数据必须保持稳定。

而在这个波形中，也确实没有看到建立时间和保持时间内，reg3in的数据有任何的变化，因此我们可以稳定的将reg3in的数据锁存到reg3的输出reg3out中。

我们再来看下面这个波形，同样的一些信号，但我们发现reg3in在clk_r3的建立时间内发生了变化，这带来的后果就是clk_r3上升沿锁存到的reg3in数据不确定，那么随后的reg3out值也会处于一个不确定状态。

比如第一个时钟周期，原本reg3in应该是稳定的低电平，但是由于真个路径上的延时时间过长，导致了reg3in在clk_r3的建立时间数据还未能稳定下来，在建立时间内出现了电平正处于从高到低的变化，即不稳定的状态，那么导致的后果就是reg3out的最终输出要么是高电平要么是低电平，而不是原本期望的低电平。

        我们再来看看保持时间违规的情况，如图所示，这次是数据传输得太快了，原本应该下一个时钟周期到达clk_r3的数据竟然在clk_r3的前一个时钟周期后的保持时间还未过去就来到了。

因此，它出现的最终危害也是后端输出的reg3out处于不确定的状态。

 对于FPGA内部而言，通常我们把它的时序路径分为三类基本的约束路径，即：

● 输入信号 pin2reg 

● 内部信号 reg2reg 

● 输出信号 reg2pin

        我们逐个来看这三类基本路径分别约束的是那个部分的时序。

        reg2reg路径约束的对象是路径起始的源寄存器以及最终结束的目的寄存器都在FPGAn内部的路径。

如图所示，红色部分是从一个FPGA内部的寄存器到FPGA内部的另一个寄存器的路径，他们共用一个时钟（当然也有不共用一个时钟的reg2reg路径，这种路径的分析会复杂一些，这里不做深入讨论）。

对于reg2reg路径，我们只要告诉FPGA时序分析工具他们所使用时钟的频率（或时钟周期），那么FPGA内部通常就“心领神会”的让这条reg2reg的路径总延时不超过这个时钟频率。

        我们再来看pin2reg的路径模型，如图所示。

虽然和FPGA连接的外部芯片内部寄存器的状态我们无从知晓（一般芯片也不会给出这么detail的内部信息），但是一般芯片都会给出针对于这个芯片管脚的一些时序信息，如Tco、Tsu和Th等，我们其实也是用图示的这个模型来分析的。

在这个模型中，红色的大圈所覆盖的路径代表了和FPGA内部reg2reg分析一样的模型，pin2reg原则上只是reg2reg分析的一部分。

绿色圆圈则表示我们实际要告诉FPGA的pin2reg约束信息，或者应该这样说，我们希望进行路径延时控制的路径就是这段绿色圆圈覆盖的路径，但是我们需要通过整个reg2reg路径的情况，即根据绿色圆圈以外、红色圆圈以内这部分路径的延时情况去告诉FPGA内部pin2reg路径延时可以在什么样一个范围。

        最后，再看reg2pin的路径。

如图所示。

同样的，红色圆圈部分覆盖了FPGA内部的源寄存器开始，到FPGA外部芯片的目的寄存器为止的reg2reg的路径。

外部芯片通常也不会给出detail的信息，也是通过相对他们的管脚给出一些时序的信息。

而绿色圆圈所覆盖的路径则是我们需要去约束的reg2pin的延时。

它的延时信息同样是需要通过红色大圈以内、绿色小圈以外路径的情况来推测得出。

        本节的重点是reg2reg的时钟约束。

如图所示，一般的时序分析我们都可以来看看他们的数据路径（datapath）和时钟路径（clockpath）。

所谓数据路径，就是数据在整个传输起点到传输终点所走过的路径；所谓时钟路径，则是指时钟时钟达到各个寄存器的路径。

        如图所示，为了便于后续的时序余量分析和计算，我们提出了dataarrivalpath和datarequiredpath的概念。

Dataarrivalpath是指数据在两个寄存器间传输的实际所需时间；datarequiredpath则是指为了确保稳定、可靠且有效的传输，数据在两个寄存器间传输的理论所需时间（也就是最低必须满足的传输时间要求，对于建立时间是最大值，对于保持时间则是最小值）。

很明显，从图中，我们就可以看出dataarrivalpath传输的起点是时钟源，达到源寄存器，然后是实际的数据从源寄存器到目的寄存器时间；而datarequiredpath的传输起点也是源时钟，但却是达到目的寄存器，然后再考虑目的寄存器的建立时间和保持时间要求（图中未示意）。

        如图所示，对于上面所提出的dataarrivalpath和datarequiredpath，我们做了一些喜欢，将实际的各个路径示意了出来。

● Tc2t表示时钟源到源寄存器reg1所经过的时钟网络延时；

● Tc2r表示时钟源到目的寄存器reg2所经过的时钟网络延时；

● Tco表示数据在被锁存后在寄存器内所经过的延时；

● Tr2r表示数据从上一级寄存器（源寄存器）的输出端到下一级寄存器（目的寄存器）的输入端所经过的延时；

● Tsu表示寄存器的建立时间；

● Th表示寄存器的保持时间。

        在开始这些路径关系公式的分析前，我们还需要了解Setuprelationship和Holdrelationship及其与launchedge和latchedge之间的关系。

如图所示，对于一个寄存器到寄存器的传输来说，正常情况下，各个寄存器都是在时钟的控制下，每个上升沿锁存一次数据，那么也就意味着，两个相邻的寄存器，后一级寄存器每次锁存的数据应该是前一级寄存器上一个时钟周期锁存过的数据。

基于此，我们来讨论建立时间，即setuprelationship时，源寄存器为lauchclock，目的寄存器为latchclock，而lauchedge从时间上看就要比latchedge早一个时钟周期，即他们之间通常是相差一个时钟周期的关系。

反观保持时间则不然，即holdrelationship实际上是同一个edge，也就是说后一级寄存器的保持时间很可能遭到上一级寄存器同一个时钟周期所传输数据的违犯。

我们的holdrelationship就是为了防备这种情况的，因此launchedge和latchedge实际上是同一个时钟沿，那么他们的关系通常只是Tc2t（源时钟传输到源寄存器的时间）和Tc2r（源时钟传输的目的寄存器的时间）的时间差。

        因此，如图所示，理想情况下，抛开什么时钟的抖动以及其他不确定时间，我们可以得到reg2reg传输的建立时间和保持时间余量（slack）计算公式：

        建立时间

Setuptimeslack=DataRequiredTime–DataArrivalTime

DataArrivalTime=LaunchEdge+Tc2t+Tco+Tr2r

DataRequiredTime=LatchEdge+Tc2r-Tsu

        保持时间

Holdtimeslack=DataArrivalTime–DataRequiredTime

DataArrivalTime=LaunchEdge+Tc2t+Tco+Tr2r

DataRequiredTime=LatchEdge+Tc2r+Th

         接着，我们要来实际应用这些理论，看看实际工程中如何对这些错综复杂的关系进行分析和处理。

如图所示，我们这个例程的分频计数实验中使用了一个时钟信号clk，每一次计数都是基于这个时钟的上升沿。

        这个时钟哪里来？

它的时钟频率如何确定？

拍脑袋随便设？

非也，咱做事一定要有依有据。

如图所示，我们的SF-CY3板载了一颗25MHz的有源晶振，通过管脚分配，我们便将这个时钟引入了设计中。

因此，我们这个设计的时钟便要约束为25MHz，即40ns的时钟周期。

好，下面我们就动手为这个实例添加时序约束。

如图所示，我们点击工具栏的一个闹钟模样的图标便可打开QuartusII内嵌的时序设计TimeQuest，我们接下来的时钟约束设置便是在该工具中完成的。

TimeQuest的主界面如图所示，首先需要新建一个sdc文件，然后在该文件中输入时钟约束脚本，或者使用GUI进行约束设置更新到sdc文件中。

        点击菜单栏NetlistàCreateTimingNetlisk，弹出的菜单中使用默认设置，点击OK便可。

接着进行时钟约束，点击菜单栏ConstraintsàCreateClock。

Clockname是我们随便给约束的信号起的名字，没有特别限制；Period为时钟周期，我们的时钟晶振是25MHz的，即40ns；Targets选择实际被约束的时钟管脚，点击改行最后面的按钮可以选择相应的管脚信号；SDCcommand无须设置，自动根据前面的设置生成，Waveformedges也无须设置，我们采用默认设置，即0ns时钟上升，20ns下降。

点击Run完成约束设置。

接下来，我们要依次点击主界面右下方task栏里的UpdateTimingNetlist和WriteSDCFile选项，弹出的WriteSDCFile窗口如图所示，我们更改SDCfilename为ex0.sdc，接着点击OK。

        此时，我们可以在工程目录下找到一个ex0.sdc的文件，并且这个文件里面有一条这样的时钟约束语句：

create_clock-name{SYS_CLK}-period40.000-waveform{0.00020.000}[get_ports{clk}]。

这便是我们前面所添加的约束。

        接着回到QuartusII，重新对工程进行编译。

接着再进入TimeQuest，点击Report下的ReportAllCoreTimings。

        在Report窗口中，出现了ReportTiming（Core）一栏，下拉后，我们便可以看到SYS_CLK时钟的Setup和Hold路径的分析。

先点击Setup一栏，我们看到右侧齐刷刷的把所有的路径都罗列了一通。

这便是SYS_CLK时钟的所有相关Setup路径分析情况，打头第1条是Slack最差的情况，喔……，居然还有36ns多，可谓余量“富得流油”。

        再看Hold路径，如图所示，Slack最差的只有0.464ns，正应了前面所说的，Hold和Setup是一对“鱼和熊掌”，或者更形象一点，那叫做“跷跷板的两端”。

二者平衡当然是最佳状态，可惜很多时候咱说得不算，大趋势咱改变不了，顶多小范围微调。

不过，不用担心，有正余量就OK了，说明设计本身的时序是不存在隐患的。

        好，看完宏观局势，我们再来瞄一眼微观情况。

如图所示，这是一条setup路径的详细分析。

回头可以对照前面给过的公式，把这个路径里面的各个参数对应一代，还真那么回事哦。

不过有一点笔者也深感困惑，就是那个uTsu，公式里明明是“-”，而分析中却变成了“+”。

公式从理论上讲是肯定不会错，所以为了“套”一下公式我们只能吧正分解为“夫妇”（负+负）了。

之说以这么推测，从笔者接触QuartusII开始，大概7到现在的13，这个地方的TimeQuest分析好像一直没有“纠正”过，那么我觉得Altera这么个大厂也不至于老犯这么低级的错误吧，所以，这里面一定“暗藏玄机”。

个人猜想，还未官方求证。

待我发个邮件有回复了再分享给大家。

DataArrivalTime=LaunchEdge+Tc2t+Tco+Tc2r

                            =0+2.733+0.261+（0.858-0.261）

DataRequiredTime=LatchEdge+Tc2r–Tsu

                               =40+2.651–（-0.021）

Setuptimeslack=DataRequiredTime–DataArrivalTime=42.672–3.591=39.081ns

        再看Hold路径的详细分析，也是对照前面的公式，我们可以一一对应。

通过这种实际分析，希望能够加深大家的理解，尤其是时序分析工具和理论之间的对照关系。

DataArrivalTime=LaunchEdge+Tc2t+Tco+Tr2r

                            =0+2.636+0.261+（0.758-0.261）

DataRequiredTime=LatchEdge+Tc2r+Th

                               =0+2.718+0.212

Holdtimeslack=DataArrivalTime–DataRequiredTime=3.394–2.930=0.464ns