基于ISE时序约束特权Word文档下载推荐.docx
《基于ISE时序约束特权Word文档下载推荐.docx》由会员分享，可在线阅读，更多相关《基于ISE时序约束特权Word文档下载推荐.docx（19页珍藏版）》请在冰点文库上搜索。
1.路径终点生产groups（顾名思义就是进行分组）
2.指定不同groups之间的时序要求
全局约束使用默认的路径终点groups——即所有的触发器、I/Opads等
问题思考
单一的全局约束可以覆盖多延时路径
如果箭头是待约束路径，那么什么是路径终点呢？
所有的寄存器是否有一些共同点呢？
问题解答
什么是路径终点呢？
——FLOP1,FLOP2,FLOP3,FLOP4,FLOP5。
——它们共享一个时钟信号，约束这个网络的时序可以同时覆盖约束这些相关寄存器间的延时路径。
2、周期约束
周期约束覆盖由参考网络钟控的的同步单元之间（触发器等）的路径延时。
周期约束不覆盖的路径有：
1、inputpads到outputpads之间的路径（纯组合逻辑路径）；
2、inputpads到同步单元之间的路径；
3、同步单元到outputpads之间的路径。
周期约束特性
周期约束使用最准确的时序信息，使其能够自动的计算：
1.源寄存器和目的寄存器之间的时钟偏斜（ClockSkew）
2.负沿钟控的同步单元
3.不等同占空比的时钟
4.时钟的输入抖动（jitter）
假设：
1.CLK信号占空比为50%
2.周期约束为10ns
3.由于FF2将在CLK的下降沿触发，两个触发器之间的路径实际上将被约束为10ns的50%即5ns
3、时钟输入抖动（ClockInputJitter）
时钟输入抖动是源时钟的不确定性（clockuncertainty）之一
时钟的不确定时间必须从以下路径扣除：
——周期约束建立时间路径
——OFFSETIN约束的建立时间路径
时钟的不确定时间必须添加到以下路径中：
——周期约束保持时间路径
——OFFSETIN约束保持时间路径
——OFFSETOUT约束路径
4、Pad-to-Pad约束（管脚到管脚）
——不包含任何同步单元的纯组合逻辑电路
——纯组合逻辑延时路径开始并结束于I/Opads，所以通常会被我们遗漏而未约束
哪些路径是由CLK1进行周期约束？
哪些路径是由pad-to-pad进行约束？
点击看原图
5、OFFSET约束
OFFSET约束覆盖以下路径：
——从inputpads到同步单元（OFFSETIN）
——从同步单元到outputpads（OFFSETOUT）
OFFSET约束特性
OFFSET约束自动计算时钟分布延时
1.提供最准确的时序信息
2.大量增加输入信号到达同步单元的时间（时钟和数据路径并行）
3.大量减少输出信号到达输出管脚的时间（时钟和数据路径先后）
4.约束也可以解释时钟输入抖动——使用抖动确定关联的周期约束
6、时钟延时
数据路径延时和时钟分布延时都需要在OFFSET计算中使用到
——OFFSETIN=T_data_in–T_clk_in
——OFFSETOUT=T_data_out+T_clk_out
在这个电路中哪些路径是由OFFSETIN和OFFSETOUT来约束的？
问题解答：
——OFFSETIN：
PADAtoFLOPandPADBtoRAM
——OFFSETOUT：
LATCHtoOUT1,LATCHtoOUT2,andRAMtoOUT1
下面给出的系统框图里，你将给出什么样的约束值以使系统能够跑到100MHz？
（假设在下面的器件之间没有时钟偏斜）
1、PERIOD=10ns
2、OFFSETIN（BEFORE）=7ns
5、OFFSETOUT（AFTER）=8ns
小结
1.
性能期望和时序约束相关联
2.
周期约束覆盖同步单元之间的延时路径
3.
OFFSET约束覆盖从输入管脚到同步单元和从同步单元到输出管脚之间的延时路径
二、分组与OFFSET约束
特定路径时序约束
使用全局时序约束（PERIOD,OFFSET,PAD-TO-PDA）将约束整个设计
仅仅使用全局约束通常会导致过约束
——约束过紧
——编译时间延长并且可能阻止实现时序目标
——通过综合工具或者映射后时序报告重新审视性能评估
特定路径约束能够覆盖全局时序约束在特定路径上的约束
——这就允许设计者放宽特定路径的时序要求
更多关于特定路径约束
你的设计器件的内部面积将会从特定路径约束收益。
特定路径约束包括：
1.多周期路径Multi-cyclepaths
2.跨时钟域路径
3.双向总线
4.I/O时序
特定路径约束应该由你的性能目标来界定，不能够不加限制的随意放置
1、全局约束回顾
使用全局PERIOD,OFFSETIN和OFFSETOUT约束将约束所有以下的路径
这使得控制设计的总体性能更加容易
2、特定路径约束实例
一条特定路径约束对于路径本身的优化微乎其微
这有助于你更好的控制设计性能，并带给执行工具更大的灵活性以达到你的性能和使用要求
生成特定路径约束需要两个步骤：
1.多个有共同时序要求的特定路径终点生成一个groups
2.关联两个groups，指定它们的特定路径的时序要求
3、路径端点生成Groups
特定路径时序约束在终点路径较好的分组后会更加高效——否则，约束一个大的工程将极其耗时耗力。
约束编辑有助于你更容易的进行路径终点（pads,flip-flops,latches,andRAMs）进行Groups分组。
使用约束编辑器，终点路径的分组有以下选项：
–Groupbynets
–Groupbyinstancename
–Groupbyhierarchy
–Groupbyoutputnetname
–TimingTHRUPointsoption
–Groupbyclockedge
Nets分组与outputnetname分组对比
由net分组的“NET_A”将生成一个只包含FLOP2的group
——Group包含选择网络所驱动的寄存器
由outputnetname分组的“NET_A”将生成一个只包含FLOP1的group
——Group包含选择网络的源寄存器
4、回顾全局OFFSET约束
在时钟行中使用Pad-to-Setup和Clock-to-Pad列为所有出于该时钟域的I/O路径指定OFFSETs。
为大多数I/O路径进行约束的最简单方法——然而，这将会导致一个过约束的设计。
5、指定管脚的OFFSET约束
使用Pad-to-Setup和Clock-to-Pad列为每个I/O路径指定OFFSETs。
这种约束方法适用于只有少数管脚需要不同的时序约束。
更常用的方法是：
1.为Pads生成Groups
2.对生成的指定Groups进行OFFSETIN/OUT约束
6、双沿时钟的OFFSET约束
OFFSET约束指明了FPGA管脚的输入数据和初始时钟之间的关系。
初始时钟沿在周期约束定义中出现关键词“高”和“低”。
——高：
初始时钟上升沿（默认），即上升沿锁存数据
——低：
初始时钟下降沿
如果所有的I/O都由时钟的一个沿控制，那么你可以使用这个关键字高或低进行周期约束。
如果两个沿都用到，你就必须进行两个OFFSET的约束。
——每个OFFSET对应一个时钟沿
——DDR寄存器也是这样使用的一个例子
双沿时钟的OFFSETIN约束
输入数据在上升沿或者下降沿之前3ns有效——周期约束为10ns，初始上升沿，占空比为50%。
为每个时钟沿生成一个时钟Groups
——输入时钟的上升沿，OFFSET=IN3nsBEFORECLK;
——输入时钟的下降沿，OFFSET=IN-2nsBEFORECLK;
（在初始时钟的上升沿后2ns=时钟下降沿前3ns）
双沿时钟的OFFSETOUT约束
输出数据必须在时钟的上升沿或者下降沿后3ns内有效——周期约束为10ns，初始上升沿，占空比为50%。
——输入时钟的上升沿，OFFSET=OUT3nsAFTERCLK;
——输入时钟的下降沿，OFFSET=OUT8nsAFTERCLK;
（在初始时钟的上升沿后8ns=时钟下降沿后3ns）
特定路径时序约束如何改善了设计性能？
你如何约束这个设计使其内部时钟频率达到100MHz？
输入（数据）将在时钟CLK的上升沿到达前3ns内有效。
输出数据必须在时钟CLK的下降沿后4ns内稳定下来。
写出合适的OFFSET约束？
——它使得执行工具更加灵活的达到你的时序要求。
——给时钟信号CLK施加一个10ns的全局周期约束。
——OFFSET=IN3nsBEFORECLK;
OFFSET=OUT
4nsAFTERCLK;
三、特定路径约束
1、时钟上升沿和下降沿之间的时序约束
周期约束可以自动计算两个沿的的约束——包括调整非50%占空比的时钟。
例：
一个CLK时钟周期约束为10ns，能够应用5ns的约束到两个寄存器之间。
不需要特定路径应用到这个例子中。
2、相关时钟域的约束
为一个时钟进行周期约束——以这个周期约束确定相关的时钟。
执行工具将根据它们的关系来决定如何处理跨时钟域。
DCM有多个输出：
——确定DCM输入时钟的周期约束
——执行工具将会从这个周期约束推导出其输出的约束
——所有的约束将会和原始的周期约束相关
3、不相关时钟域的约束
在这个例子中，周期约束不覆盖到处于两个时钟域之间的任何延时路径。
——这是默认的处理方式。
你必须添加一个约束覆盖到相关时钟域之间的路径中。
——例如，频率相同，但是CLK_B有一些相位偏移。
在两个不相关的时钟域你就必须添加一些同步电路。
约束两个时钟域之间的路径。
——使用GroupsbyNETs选项为CLK_A和CLK_B定义groups，如果你为每个时钟添加完周期约束，这个步骤将自动完成。
——在这个寄存器的groups之间指定快速/慢速例外约束。
4、多周期路径约束
多周期约束应用在连续几个时钟周期内寄存器不需要更新的情况。
——总是至少需要一个时钟周期才更新。
——通常的，这样的寄存器由时钟使能信号控制。
一个分段计数器就是这样的一个例子。
——COUT14每隔4个时钟周期才更新一次。
——这些寄存器间的路径就算是多周期路径。
5、False路径
False路径选项将用于防止约束覆盖到特定路径
6、时序约束优先级
从高到低为：
1.False路径——将会覆盖任何其它的约束路径
2.FROMTHRUTO
3.FROMTO
4.管脚指定OFFSETs
5.GroupsOFFSETs（由寄存器或者PADS生产的groups）
6.全局PERIOD和OFFSETs——最低优先级约束
这里特权同学提醒大家注意的是，通常类似下面这样的计数器绝对不可以归为多周期约束：
reg[15:
0]counter;
always@（posedgeclkornegedgerst_n）
begin
if（!
rst_n）counter<
=16’d0;
elsecounter<
=counter+1’b1;
end
虽然我们想想似乎counter[1]也是2个clk变化一次，counter[2]也是4个clk变化一次……但是，我们想想看，如果从counter=1到counter=2没有在一个clk完成，那么肯定就会影响到counter=2到counter=3的变化，对吧？
所以，这样的计数器不能算做多周期约束例外。
提纲里描述的多周期例外的计数器应该是这样一个模型：
rst_n）counter[1:
0]<
=2’d0;
elsecounter[1:
=counter[1:
0]+1’b1;
rst_n）counter[15:
2]<
=14’d0;
elseif（counter[1:
0]==2’b11）counter[15:
=counter[15:
2]+1’b1;
上面两个always块里的数据互不干扰，并且都正常工作，只有下一个always块检测到前一个always块里的counter[1:
0]==2’b11时才进位加1。
写到这里，特权发现单从功能上来说，这两个例子是没有差别的，说白了，任何一个计数器都可以建模成后面的形式。
或者说，我的问题其实没有说明白，反而被自己的例子给驳倒了。
呵呵，换个角度思考这个问题，到底什么时候是多周期例外，什么时候不是？
这个其实还是要看情况的，如果你的系统实时性较高，可能会在某一特定的时钟周期用到16位计数器的计数值（如a=（counter=16’hffff）?
1b’1:
1’b0;
），那么这个计数器的高位就不能算作多周期例外。
而如果比如在我的一个工程里，有这样的计数器用法：
cuonter[2:
0]没16个clk的后8个clk需要自增加（从0到15），而高位counter[18:
3]当然只有在16个clk变化一次，因为这里counter是用于作为一个地址产生器，也就是说，我的地址是每16个clk的后8个clk用到，那么这里的counter[18:
3]就是一个8clk的多周期例外实例。
说白了，还是要具体问题具体分析。
四、达到时序收敛
题记：
achievingtimingclosure即达到时序收敛，这是一个很具有挑战性的任务。
因为实际的工程项目往往不会像我们用一个资源超大（相对于你的设计来说）的FPGA来做几个数码管串口实验那么简单。
设计者往往需要达到成本、速度、资源等各个方面的平衡，即使是一个小设计，有时候也是很费神的。
特权同学前几周在饱经ISE4里才有的老器件的折磨后，感慨良多。
1、关于时序报告
ISE中的时序报告分为两种：
–Post-MapStaticTimingReport映射后
–Post-Place&
RouteStaticTimingReport布局布线后
所谓Post-Map是布局后（没有布线）的静态时序报告，主要用于估计设计的性能，然后提前对设计做一些必要的修改。
因为设计的实现（布局布线）是很消耗时间的。
Post-Place&
Route就是布局布线后的一个比较接近实际板级的一个静态时序报告了，这算是设计者进行时序分析的最终依据。
2、关于性能估计
综合报告
准确的逻辑延时；
基于扇出的布线延时估计
报告的性能是实际的20%误差内
Post-Map静态时序报告
准确的逻辑延时
基于最快的可能的布线资源的布线延时估计
使用了60/40规则来计算更趋近于实际的性能估计
60/40法则：
这是一个时序约束合理性的经验法则；
打开Post-Map静态时序报告，查看时序报告中关于逻辑延时的百分比
——低于60%，时序很有机会到达时序约束要求
——60%到80%，如果使用了高级选项，时序也很有机会达到时序要求
——80%以上，基本上很难（回到综合部分，或者重新优化你的代码）
Route时序分析
找出时序违规的因素有很多：
设计的综合不当或者代码风格太烂；
糟糕的综合结果（路径中的逻辑太繁杂）
不准确或者不完整的时序约束
4.
糟糕的逻辑映射和布局
每个问题都用不同的解决方案：
重写代码
添加时序约束（注意应该是一些时序例外）
使用不同的软件选项重新综合或者实现
准确的定位时序报告能够解决大多数问题。
一些可能的问题和解决
布线延时太长——似乎有些路径扇出很低，但是延时却很大，那么很可能这个地方的布线比较拥堵。
解决办法：
如果是不相关的逻辑布局到一块，可以到Floorplanner中查看。
（这个问题特权同学还没有完全领会也是比较头疼的，希望看到更多更好的资料或者自己在工程中有更多体会时再和大家分享）
高扇出问题——解决办法是复制高扇出的网络。
如果是组合逻辑，那么就比较难了。
逻辑级数太高——这个问题综合工具无法做太多优化。
首先查看是否该路径为多周期路径，如果是，添加多周期例外；
使用retiming选项更加均匀的分配触发器之间的逻辑；
确定一个比较好的代码技巧被运用到了你的设计代码中；
使用流水线设计。
I/O时序问题——使用DCM移除时钟分布延时；
将输入输出相关的寄存器放入IOB寄存器中。
另外在实际应用中，其实很是有很多可以应用的技巧的，比如实现属性选项里其实是可以设置布局布线的努力程度，还有布局布线的次数等待，对于大多数设计而言这些工具都是有用的。
升级会员 