第五章 实战演练之时序收敛.docx
《第五章 实战演练之时序收敛.docx》由会员分享，可在线阅读，更多相关《第五章 实战演练之时序收敛.docx（49页珍藏版）》请在冰豆网上搜索。
第五章实战演练之时序收敛
时序设计四部曲part12
一部曲——时序分析part25
系统内部时钟时序分析6
SDRAM接口时序分析7
二部曲——时序约束part313
全局时钟约束14
IO接口约束之virtualclock生成与约束part416
IO接口约束之理论推导part518
IO接口约束之outputdelay约束part622
特权和你一起学NIOS2第五章实战演练之时序收敛part728
SDRAM时钟频率与相移更改part832
特权和你一起学NIOS2第五章实战演练之时序收敛part934
特权和你一起学NIOS2第五章实战演练之时序收敛part1042
特权和你一起学NIOS2第五章实战演练之时序收敛part1155
特权和你一起学NIOS2第五章实战演练之时序收敛part12完58
写在前面的话：
特权同学花了很多时间在这一章上，甚至当初写《深入浅出玩转FPGA》的时候都没有这样投入过。
因为觉得这个时序分析不仅重要，不仅对初学者来说有难度有深度，而且其中还有很多技巧和方法是非常值得总结和归纳的。
特权同学虽然以往对这些知识点有过学习，有过实践，也有过总结，但是又一次对这些知识点的重新梳理才发觉其实还可以更深入。
学无止境，站在前人（或者说是自己过往认知的基础上）的肩膀上我们可以看得更远，探得更深，摸得更透……
为了不让大家等得太久，这一章分成多部分以博文形式发表，谢谢大家的支持！
也很希望听到反馈的声音，你的问题也许就是我的疏忽。
特权同学在《深入浅出玩转FPGA》一书中也专门有章节和大家探讨时序相关概念，并且有数篇针对TimeQuest的分析案例。
但其实很多人还是对这个熟悉而又陌生的知识点望而生畏，觉得无从下手。
在初学时，特权同学也有过同样的困惑。
但是今天回头看看过去走过的路，发现其实会与不会、懂与不懂之间只是隔了一层薄薄的窗纸而已，只要鼓起勇气花点时间费点精力再用点方法就足以捅破它，迎接你的将会是“柳暗花明又一村”式的豁朗开朗。
咱先在正式入题之前再说些乱七八糟的话题，因为我想，当你的注意力被吸引过来了，我们就可以专心的学习了。
昨晚在几位刚毕业（有的还在待业）的年轻人住处聚会（不要误会，是基督徒的聚会，我们在一起读圣经），会后小洪还有特权同学留下和这些“小朋友”们私下谈论了一些话题。
因为小洪是比较能耐的过来人，所以话题涉及了工作、创业、公司管理经营的一些想法和理念。
讲到创业，一个公司的第一个亿销售额可能需要三年五年甚至更长时间；然而第二个亿往往就不需要这么久了，会大大的缩短，可能只需要一年两年甚至更快。
中文有一个成语很恰当的形容这种现象，叫“厚积薄发”。
学习的过程也是这样，学FPGA我们不用拿年来算，我们只要用心去学，我们所花的每一分每一秒，我们所掌握的每一个知识点，有一天都可能成为我们理解下一个知识点的“跳板”。
当这些“跳板”越来越多的时候，我们前进的步伐也就顺理成章的越来越快。
世上本没有免费的午餐（当然，如果你成为基督徒，那么免费的午餐不仅有，而且会越来越多，我们称之为“爱宴”。
因为在基督徒中间所传递的是真爱，无条件的爱，当你被这种爱包围的时候，你也会愿意用这种爱去体贴顾惜他人。
），要得到一些东西总是要付出一些东西（马经称之为“等价交换”）。
你付出的越多得到的自然也会越多，但是事物的发展也是需要遵循一些规律的，学习这种付出得到的常常不会是45度斜线式的等比回报，更多的时候它就好像（对不起，特权同学想说的这种波形太抽象了，都不知道该如何形容了）……用马克思的话来描述就是：
前途是光明的，道路是曲折的，在曲折中前进。
最后，用圣经节来结束这个话题吧，路加福音6章38节说：
你们要给人，就必有给你们的，用十足的量器，连摇带按，上尖下流的倒在你们怀里；因为你们用什么量器量给人，也必用什么量器量给你们。
时序设计四部曲part1
说时序，这回要真刀真枪的细细的来讲，那么我们还是应该先掌握一些必须的背景知识。
解决几个问题，我想这些问题很可能是大多数初学者没有搞明白的。
如何做时序分析？
在整个设计的哪个环节需要进行时序约束？
如何给设计添加时序约束？
如何查看时序报告？
如何达到时序收敛？
这些疑问其实已经包含了我们接下来要谈的四部曲，即时序分析、时序约束、时序报告、时序收敛。
这里事先申明，所谓四部曲不是任何官方提出来的概念，是特权同学对时序设计在FPGA流程中的理解总结出来的。
如图5.1所示，在整个FPGA流程中，时序约束是在设计输入完成（这个“完成”包含了代码编写好、系统集成好、并且通过综合和功能仿真验证后）并进行了一次编译后进行的。
如果不进行编译，那么设计者很可能无法找到需要约束的路径，甚至摸不清楚有哪些路径是需要约束的，因此，时序约束前的编译必不可少。
时序约束后还需要执行一次编译，这次编译是让开发工具按照设计者的期望（体现到和工具交互的手段就是“时序约束”）去综合与实现，最后用户通过观察时序报告来验证时序是否达到要求。
图5.1
上面是从整个FPGA开发流程的角度来理解时序设计。
下面要从时序设计本身来理解，即四部曲之间到底有怎样的关系。
如图5.2所示，时序约束也逃不了FPGA固有的迭代特性（我们以迭代的生产方式来理解迭代，我们开发一个产品，如果不太复杂，会采用瀑布模型，简单的说就是先需求定义，然后构建框架，然后写代码，然后测试，最后发布一个产品。
这样，几个月过去了，直到最后一天发布时，大家才能见到一个产品。
迭代的方式就有所不同，假如这个产品要求6个月交货，我在第一个月就会拿出一个产品来，当然，这个产品会很不完善，会有很多功能还没有添加进去，bug很多，还不稳定，但客户看了以后，会提出更详细的修改意见，这样，你就知道自己距离客户的需求有多远，我回家以后，再花一个月，在上个月所作的需求分析、框架设计、代码、测试等等的基础上，进一步改进，又拿出一个更完善的产品来，给客户看，让他们提意见。
）。
在整个系统的功能定型后，设计者需要做的一项工作就是时序分析，这个分析在时序设计的初期可能只是系统的时钟频率考虑以及与FPGA接口的外围器件时序要求考虑。
系统时钟考虑是最简单的，FPGA的时钟源通常是外部晶振，但也许这个晶振频率只是作为FPGA内部时钟管理单元的一个基准输入时钟，而FPGA内部跑的时钟频率也通常不完全一致，时钟管理单元可以产生多个不同频率的时钟。
无论如何，这些作为FPGA系统内部的时钟频率是确定的，至少应该是设计者心中有数的。
那么，在时序约束时，按照它们需要跑到的频率去约束它们。
而与FPGA接口的外围器件通常也都有时序要求，尤其是一些高频传输接口，如果不做好时序分析与约束，甚至会导致系统无法正常工作。
这时候需要去翻看对应器件的datasheet，通常直接去找图图和表表就行，图即时序图，表即对应时序图的时间表。
这两样东西分析透了，才能够做出正确的约束，而不是错误的过约束或欠约束。
图5.2
做好第一步的时序分析，那么就能够进行恰当的时序约束。
时序约束是需要通过开发工具来协助的，QuartusII内嵌的TimeQuest就是我们的利器，它能够帮助我们完成整个时序设计。
时序报告也是在TimeQuest内产生的，前面提到了在时序约束后的一次编译过程中工具会尽可能的来满足设计者的要求，最终却是通过时序报告来体现工具的“劳动成果”。
在时序报告中，我们可以查看已经约束的路径是否达到既定要求，没达到要求的在TimeQuest中会用红色字体警示。
当然了，TimeQuest还提供了一些叫做“时序例外”的约束方法，所谓“时序例外”，就是当我们查看时序报告确定时序不收敛（所谓收敛，就是时序完全达到要求）的时候，我们如果找到一些时序要求本来并不高，但是我们的约束却比较紧，并且很多时候这些路径也达到了要求，这时候我们就有必要放宽对这些路径的要求，让原本花费在它们身上的努力转嫁到其它还没有达到时序要求的关键路径上。
此时，我们所做的工作就叫做时序例外约束，它主要是指false路径约束（即不约束这个路径，通常能够用这种约束的路径是系统运行过程中从始至终不曾变化或完全无关紧要的路径）和多周期路径约束（能够使用该约束的比较典型的是多个时钟周期数据才会变化一次的路径）。
时序设计的第一轮是验证原始约束是否达到要求，一般很难一次性成功（不排除系统性能要求不高的情况下一次性成功）。
那么第二轮就需要结合时序报告中的各种路径（包括失败路径和一些可能的过约束路径），并重新考量第一轮的时序分析是否有偏差。
最后可能需要对原来的路径约束做一些更改，或者添加一些时序例外约束。
然后重新编译，重新分析时序报告并验证时序是否收敛，如此往复恩轮，直到最后时序完全收敛。
忘了看过哪位“大虾”的文章，说时序收敛的过程是“打鼹鼠”，特权同学非常赞同，时序报告中体现出来的结果往往是各个区域路径“此起彼伏”式的失败与成功的交错。
总之，时序设计师一项费时费力费脑子的活。
当然了，其实时序设计并不是独立于FPGA开发流程的其他环节的。
在很多极端的情况下，光靠上面的一些反复更改约束并不一定能够解决时序问题。
这时候也许需要对工具的Systhesis选项或者Fitter选项做一些设置，再或者回到源代码进行优化，其实这时候的工作就成了整个流程迭代性的一部分。
一部曲——时序分析part2
系统整合完毕，所有的设计输入、初步的功能仿真等工作就绪后，设计者应该对整个系统所涉及到的各种时序模型做到心中有数。
如图5.3所示，当我们回顾第二个系统的整个架构时，在时序设计的初期，我们首先应该考虑的是这个系统要达到怎样的速度性能才算符合要求。
那么，这个速度性能考虑包括：
系统时钟频率（可能会有好几个系统工作时钟）、外设接口的频率（与FPGA相关的考虑就是FPGA与这些外设间连接的管脚的时序要求）。
从本质上来讲，好像就这两方面。
图5.3第二个系统框图
第二个系统中与系统时钟频率有关的组件是哪些？
与外设接口频率有关的组件又是哪些呢？
其实图5.3中已经很明显的为大家划分出来了。
NIOS2处理器以及时钟单元、SystemID、定时器这几个组件没有和外围器件直接连接的管脚，那么可以认为它们的时序路径只和系统内部的时钟有关。
而GPIO、JTAGUart、SDRAM控制器和EPCS控制器这几个组件都有与FPGA外部器件连接的管脚，那么它们的时序路径就涉及到外围器件的时钟频率（严格来讲可能一般不说是外围器件的时钟频率，总之，你可以理解为这里要说的是外围器件要正常通信需要满足的时序要求）。
但是由于JTAGUart、EPCS控制器使用了FPGA的一些专用管脚，并且无需用户在集成这些组件后再手动分配管脚号，并且在FPGA底层的布局布线上工具已经默认能够保证它们的时序收敛了。
所以，本实例中需要考虑的外围器件时序路径分析只有GPIO外设和SDRAM控制器了。
而GPIO连接的外围设备只不过是LED灯而已，它们的闪烁大都是second级别的，相对于FPGA内部快慢延时最多也只有几十ns的情况，大可以不必理会。
因此，可以这么认为，GPIO与外围的时序基本没有要求，要不要做管脚的时序约束无关紧要，对我们的设计照成不了任何影响。
用前面说过的情况来处理它，就把它归入false路径。
因此，重点就落在了SDRAM的时序分析上。
好的，从上面我们的讨论中分析得出第二个系统需要分析两方面时序：
系统内部时钟的时序和SDRAM接口的时序。
系统内部时钟时序分析
在我们的第二个系统中，依然只有一个外部输入的25MHz时钟。
而仅仅一个时钟对于整个系统运行来说是不够的，因此我们需要借助于CycloneII器件内部的PLL来对这个外部时钟进行倍频或分频处理。
如图5.4所示，这是PLL的简单接口示意图。
Inclk0是输入的外部25MHz外部时钟，由这个时钟通过PLL内部的处理产生了c0/c1/c2三个输出时钟。
这三个输出时钟的频率都是用户可以配置的，通过图中的Ratio列的值可以看出该设计中他们的输出值分别是c0=25MHz，c1=50MHz，c2=50MHz。
而在相位上c0/c1是0dg（一个时钟周期正好是360dg），c2的相位是108dg（即（108/360）*20ns=6ns）。
图5.4
又由于c2是作为驱动外部SDRAM同步的输出时钟信号，因此该系统中真正需要我们关注的内部系统时钟只有c0和c1。
另外，inclk虽然是外部输入的时钟信号，但由于它是连接在了FPGA的专用时钟引脚上，因此也要纳入我们的内部系统时钟考虑的范围内。
对于他们的分析很简单，因为inclk/c0/c1的频率分别应该是25MHz/25MHz/50MHz，所以后面的时序约束中只要对它们做如此约束就可以了。
对于PLL的输出时钟约束，有一个非常“偷懒”的办法，后面会提到，甚至于我们无需关注这个PLL的输出频率到底是多大，只要使用一条语句就可以让时序分析工具自动识别我们对PLL的配置并进行约束。
SDRAM接口时序分析
在《深入浅出玩转FPGA》一书的笔记15里提到了很多IO接口约束的实例，也提到了源同步接口的分析与约束，在开始这部分知识点前也建议大家不妨好好再消化一下那些内容。
当然，我们这里还是会考虑到知识的系统性，所以也会带大家重新回顾一下比较重要的知识点。
如图5.5所示，是一个简单的源同步接口（FPGA与外部芯片）模型。
FPGA内部的时序逻辑基本是寄存器到寄存器的，通常是用相同的时钟分别去驱动源寄存器和目的寄存器，而这个源同步接口的目的寄存器（驱动外部芯片）时钟虽然与源寄存器时钟不同，但仍然是FPGA内部产生的，一般两个时钟是同频不同相的关系。
因此，我们要做的就是对时钟延时路径以及对数据传输路径延时的分析。
图5.5
而对于外部器件，从本质上讲，它和FPGA之间的时序也是寄存器到寄存器的传输，只不过通常源寄存器和目的寄存器是分别处于FPGA内和外部芯片内，并且驱动他们的时钟也常常不是一个时钟。
但是既然它们在本质上是类似的，那么我们就可以在寄存器到寄存器传输的基础上，对它们的不同点做额外的考虑后进行分析。
下面我们就通过FPGA内部路径分析和IO口时路径分析的对比中来摸透IO时序路径分析的脾性。
其实若是一个FPGA内部的路径，如图5.6所示，若约束FPGA的时钟，那么简单的来看，公式+（-）<就必须得到满足。
当然了，往深入的探讨，寄存器的建立时间和保持时间要求也都是需要得到满足的。
图5.6
而同样利用这样的思维去考虑FPGA与外部芯片的时序路径关系的时候，其实也还是完全一样的。
只不过的整个路径原本都在FPGA内部，但现在却要一分为三了，有一部分在FPGA内部，有一部分在芯片内部，还有一部分在哪里？
没错，就是他们在电路板上连线的那部分（图5.5中间粗体路径）。
而时钟路径的分析会稍微复杂一些，有可能和源时钟同频也可能不同频，有可能同相位也可能不同相位，只能具体问题具体分析了。
对于我们这个设计，也可以理解为是一个比较典型的源同步接口的模型。
所谓源同步接口，简单的理解就是输出的数据和输出的时钟路径都是由同一器件（这里是FPGA器件内部）产生的，并且数据传输和时钟的上升沿（或下降沿）通常是中央对齐的或是边沿对齐的。
我们的这个时序是中央对齐的，所谓中央对齐，就是指在数据的采样端（目的寄存器），时钟的上升沿和数据传输的有效窗口（即两次数据变化的中央）是对齐的。
对于SDRAM的数据路径的分析，因为前面说到的三部分里，PCB板的走线延时对于特定的目标应用板是固定的，在芯片内部的路径时间等延时参数也相对固定，可以从芯片的datasheet查到。
那么，只有在FPGA内部的那部分路径延时在时序设计前还是个未知数，而我们要做的就是算出在整个数据路径延时中留给FPGA内部走线延时的时间范围是什么，这个时间范围就是我们要分析的对象，也是我们要添加的约束内容。
我们再来看一个波形，如图5.7所示，这是一个理想的中央对齐的源同步传输。
如果结合图5.5来理解，Dataclock即FPGA内部源寄存器的时钟（图5.5的Sys_clk），Outputclock即FPGA产生的作为外部芯片的时钟（图5.5的Ext_clk），Databus即FPGA与外部芯片的数据传输总线（图5.5的Dataout）。
图5.7
在FPGA内部，Dataclock的每个上升沿Databus会产生跳变。
而Databus需要在芯片端口被Outputclock的上升沿锁存，因此Databus的数据有效窗口（数据保持稳定的两次跳变的中央）必须对准Outputclock的上升沿。
那么Outputclock和Dataclock就会有一定的相位差（Phaseshift），理想状态下这个相位差为180dg。
说完理想的状态，我们再来看图5.8，这是一个和实际情况比较接近的波形（很多时候实际波形要比这复杂得多）。
时钟Dataclock后的若干延时时间（Outputdelay）后输出数据（Databus）才会发生变化，而相应的外部时钟（Outputclock）也必须做出调整（Phaseshift比理想状态下要大一些）。
图5.8
此为，特权同学发现用这个图来理解时序分析工具将要进行的建立保持时间检查再合适不过了。
看那两条虚线，左侧向右打箭头的是建立时间检查，即检查数据输出在最慢情况下，数据是否能够在输出时钟上升沿前的某一个既定时间内（目的寄存器的建立时间）到达。
右侧向左打箭头的是保持时间检查，即检查下一个（当然也可以换到前一个时钟周期来考虑，效果是相同的）数据输出在最快情况下，是否能够在上一级时钟上升沿的某一既定时间（保持时间）之后到达。
好的，在理解了数据和时钟路径传输的基本概念之后，下一部分内容会配合约束方法更详细的来讨论。
前文提到了，这里的SDRSDRAM的数据信号、地址信号以及相关的控制信号传输到SDRAM端口时，它们的信号有效窗口（所谓有效窗口，就是在一个时钟传输周期内，信号总线上所有数据保持稳定不发生变化的时间范围）必须和SDRAM时钟的上升沿对齐，而如何能满足这个要求呢？
通常的做法也就是利用PLL的相位调整来达到输出时钟的可控性。
下面我们就要研究一下SDRAM的时钟信号相位到底该如何取值。
《QuartusIIHandbookVersion9.1Volume5:
EmbeddedPeripherals》中SectionI的1.SDRAMControllerCore部分提出了如何估计SDRAM数据有效信号窗口，并且给出了SDRAM时钟相对于FPGA时钟相移估计的公式。
从机理上来说，下面的估算无非就是通过第一轮的基本时序约束，查看FPGA内部管脚的一些延时值，然后再结合SDRAM的芯片资料提供的一些基本时序参数，从而计算出读和写数据时的滞后值和超前值，然后在这四个值之间取一个比较合适的中间值就是估计的相位值了。
注意了，这里只是估计的，在这个估计值中，还有两个因素是没有考虑进去的，PCB板的线延时时间和SDRAM从PLL输出到外部管脚之间的延时时间。
这两个参数虽然对最后的输出相位影响不是非常大，但是也是需要在后期分析中加以考虑的。
我们首先需要理解读周期最大滞后时间、读周期最大超前时间、写周期最大滞后时间、写周期最大超前时间四个参数的估算公式。
原文的四个公式如图5.9和图5.10所示。
所谓超前时间，是指SDRAM时钟的相移相对于FPGA时钟沿为负的偏移值；而滞后时间则是指SDRAM时钟的相移相对于FPGA时钟沿为正的偏移值。
图5.9
图5.10
对上述四个公式的推导如下：
过去特权同学对这个相移估算也没有太多办法，只能凭感觉找，或者说是主要根据时序分析的结果来一次次的定位最佳的相移值，工作量比较大，也有撞运气的成分在里面，而Altera官方提出的这个方法还是很有效的，至少可以将用户的相移值定位到一个比较小的范围内再进行调整。
在这个基础上还需要考虑一些PLL输出延时或者说是板级延时之类的影响，一般也只需要微调就可以搞定。
由于这个值的估算还涉及一次初步的时序约束以及查看时序报告，并提取相关参数进行计算，所以把实例的分析将放到后文阐述。
初步时序约束的时候也只是先取个大概值。
二部曲——时序约束part3
其实具体进行时序约束的数值通常应该算在时序分析这一步中，之所以特权同学要放到这一步骤来谈，是因为不同的时序约束工具尤其对于IO口的约束方式稍微有些区别，甚至相同的工具也可以有不同的约束方法。
因此，约束值的计算也通常视特定约束方法而定。
换个角度看，一种方式分析通了，其实其它方式也都是换汤不换药的。
在QuartusII工程中，默认的时序分析工具可能不是TimeQuest，因此需要在菜单栏中点击进入AssignmentsàSetting…，然后如图5.11所示，勾选UseTimeQuestTimingAnalyzerduringcompilation。
图5.11
此为，最好如图5.12指定以.sdc为后缀名的约束文件。
在SOPC系统生成后，通常也会自动产生一个cpu.sdc的系统约束文件，它主要对SOPC架构的处理器以及外设进行约束。
因为这些组件都是使用官方提供的或者第三方的IP核，它们一般也都能够集成时序约束文件。
图5.12
下面我们开始大家期待已久的TimeQuest之旅。
点击任务栏上闹钟模样的按钮即可进入TimeQuest。
图5.13
因为我们已经有了一个名为cpu.sdc的约束文件，所以可以在TimeQuest主界面的右下方的Tasks面板直接点击ReadSDCFile即可。
若是还没有任何的约束文件产生，需要用户点击FileàNewSDCFile自己新建一个新的.sdc文件。
图5.14
全局时钟约束
对于系统产生的cpu.sdc文件里本身有一些约束语句，我们不用理会，可以在此基础上添加必要的约束语句。
首先要做的是全局约束，主要是指系统时钟的约束。
FPGA器件外部输入时钟的clk是25MHz，并且它也作为PLL的输入时钟，由PLL产生了多个时钟作为FPGA内部工作的时钟。
因此，我们首先约束clk，然后约束PLL输出时钟。
一种简单的方法是点击菜单栏上的ConstrainsàCreatClock…选项，弹出了傻瓜式的GUI界面，我们对系统输入时钟做如图5.15的约束即可。
图5.15
点击Run后对话框消失，此时我们可以观察工具视窗下方的Console窗口中出现了create_clock-period40-nameEXTIN_CLK[get_ports{clk}]的语句，这就是最终写入.sdc文件中的约束脚本。
用户也可以在Console中直接输入该语句然后回车，或者干脆打开.sdc文件，找个空白处输入该语句然后保存。
总之，手段是多样的，就看用户习惯。
约束完这个时钟，我们使用最直接的方法在.sdc文件中输入derive_pll_clocks-use_tan_name语句，即可让系统自动产生clk作
升级会员 