ISE时序约束笔记Word下载.docx

ISE时序约束笔记Word下载.docx

《ISE时序约束笔记Word下载.docx》由会员分享，可在线阅读，更多相关《ISE时序约束笔记Word下载.docx（18页珍藏版）》请在冰豆网上搜索。

所有的寄存器是否有一些共同点呢？

问题解答

什么是路径终点呢？

——FLOP1,FLOP2,FLOP3,FLOP4,FLQP5

――它们共享一个时钟信号，约束这个网络的时序可以同时覆盖约束这些相关寄存器间的延时路径。

周期约束

周期约束覆盖由参考网络钟控的的同步单元之间的路径延时。

周期约束不覆盖的路径有：

inputpads到outputpads之间的路径（纯组合逻辑路径），inputpads到

同步单元之间的路径，同步单元到outputpads之间的路径。

周期约束特性

周期约束使用最准确的时序信息，使其能够自动的计算：

1.源寄存器和目的寄存器之间的时钟偏斜（ClockSkew）

2.负沿钟控的同步单元

3.不等同占空比的时钟

4.时钟的输入抖动（jitter）

假设：

1.CLK信号占空比为50%

2.周期约束为10ns

3.由于FF2将在CLK的下降沿触发，两个触发器之间的路径实际上将被约束为10ns的50%即5ns

时钟输入抖动（ClockInputJitte）

时钟输入抖动是源时钟的不确定性（clockuncertainty）之一

时钟的不确定时间必须从以下路径扣除：

周期约束建立时间路径

——OFFSETIN勺束的建立时间路径

时钟的不确定时间必须添加到以下路径中:

周期约束保持时间路径

——OFFSETIN勺束保持时间路径

――OFFSET0U■约束路径

non

Pad-to-Pad约束

――不包含任何同步单元的纯组合逻辑电路

――纯组合逻辑延时路径开始并结束于I/Opads，所以通常会被我们遗漏而未约束

ISE时序约束笔记3GlobalTimingConstraints

问题思考哪些路径是由CLK1进行周期约束？

哪些路径是由pad-to-pad进行约束？

OFFSET约束

OFFSET勺束覆盖以下路径：

从inputpads到同步单元（OFFSETIN

——从同步单元到outputpads（OFFSETOU）

OFFSET约束特性

OFFSET勺束自动计算时钟分布延时

1.提供最准确的时序信息

2.大量增加输入信号到达同步单元的时间（时钟和数据路径并行）

3.大量减少输出信号到达输出管脚的时间（时钟和数据路径先后）OFFSET勺束也可以解释时钟输入抖动一一使用抖动确定关联的周期约束

时钟延时

数据路径延时和时钟分布延时都需要在OFFSET计算中使用到

——OFFSETIN=T_data_i-T_clk_in

OFFSETOUT=T_data_out+T_clk_out

ISE时序约束笔记4GlobalTimingConstraints

在这个电路中哪些路径是由OFFSETIN和OFFSETOU■来约束的？

问题解答：

——OFFSETINPADAtoFLOPandPADBtoRAM

——OFFSETOUTLATCHtoOUT1,LATCHtoOUT2,andRAMtoOUT1

下面给岀的系统框图里，你将给岀什么样的约束值以使系统能够跑到100MHz?

――假设在下面的器件之间没有时钟偏斜

PERIOD=10ns,OFFSETIN（BEFORE）=7nsandOFFSETOUT（AFTER）=8ns

小结

1.性能期望和时序约束相关联

2.周期约束覆盖同步单元之间的延时路径

3.OFFSET勺束覆盖从输入管脚到同步单元和从同步单元到输出管脚之间的延时路径

ISE时序约束笔记5TimingGroupsandOFFSETConstraints

特定路径时序约束

使用全局时序约束（PERIOD,OFFSET,PAD-TO-PDA各约束整个设计

仅仅使用全局约束通常会导致过约束

――约束过紧

――编译时间延长并且可能阻止实现时序目标

——通过综合工具或者映射后时序报告重新审视性能评估

特定路径约束能够覆盖全局时序约束在特定路径上的约束

这就允许设计者放宽特定路径的时序要求

更多关于特定路径约束

你的设计器件的内部面积将会从特定路径约束收益

1.多周期路径Multi-cyclepaths

2.跨时钟域路径

3.双向总线

4.I/O时序

特定路径约束应该由你的性能目标来界定，不能够不加限制的随意放置全局约束回顾

使用全局PERIOD,OFFSETI和OFFSETOUT勺束将约束所有以下的路径

这使得控制设计的总体性能更加容易

習一［

CDATA

特定路径约束实例

一条特定路径约束对于路径本身的优化微乎其微

这有助于你更好的控制设计性能，并带给执行工具更大的灵活性以达到你的性能和使用要求

生成特定路径约束需要两个步骤：

1.多个有共同时序要求的特定路径终点生成一个groups

2.关联两个groups，指定它们的特定路径的时序要求生成终点路径的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包含选择网络的源寄存器

DQ

NET_A

>

FLOP1

ISE时序约束笔记6TimingGroupsandOFFSETConstraints

回顾全局OFFSET约束

在时钟行中使用Pad-to-Setup和Clock-to-Pad列为所有出于该时钟域的I/O路径指定OFFSET。

为大多数I/O路径进行约束的最简单方法一一然而，这将会导致一个过约束的设计。

指定管脚的OFFSET约束

使用Pad-to-Setup和Clock-to-Pad列为每个I/O路径指定OFFSET。

这种约束方法适用于只有少数管脚需要不同的时序约束。

更常用的方法是：

1.为Pads生成Groups

2.对生成的指定Groups进行OFFSETIN/OUT勺束

双沿时钟的OFFSET约束

OFFSET勺束指明了FPGA管脚的输入数据和初始时钟之间的关系。

初始时钟沿在周期约束定义中岀现关键词“高”和“低”。

――高：

初始时钟上升沿（默认），即上升沿锁存数据

――低：

初始时钟下降沿

如果所有的I/O都由时钟的一个沿控制，那么你可以使用这个关键字高或低进行周期约束。

如果两个沿都用到，你就必须进行两个OFFSET勺约束。

――每个OFFSET寸应一个时钟沿

――DDR寄存器也是这样使用的一个例子

双沿时钟的OFFSETIN约束

50%

输入数据在上升沿或者下降沿之前3ns有效周期约束为10ns，初始上升沿，占空比为

为每个时钟沿生成一个时钟Groups

——输入时钟的上升沿，OFFSET=IN3nsBEFORECLK;

时钟下降

――输入时钟的下降沿，OFFSET=IN-2nsBEFORECLK在初始时钟的上升沿后2ns=

沿前3ns）

双沿时钟的OFFSETOUT勺束

占空比为

输出数据必须在时钟的上升沿或者下降沿后3ns内有效周期约束为10ns，初始上升沿，

50%。

——输入时钟的上升沿，OFFSET=OUT3nsAFTERCLK;

――输入时钟的下降沿，OFFSET=OUT8nsAFTERCLK在初始时钟的上升沿后8ns=

沿后3ns）

特定路径时序约束如何改善了设计性能？

你如何约束这个设计使其内部时钟频率达到100MHz?

输入（数据）将在时钟CLK的上升沿到达前3ns内有效。

输出数据必须在时钟CLK的下降沿后4ns内稳定下来。

写出合适的OFFSET约束？

――它使得执行工具更加灵活的达到你的时序要求。

你如何约束这个设计使其内部时钟频率达到100MHz？

――给时钟信号CLK施加一个10ns的全局周期约束。

写出合适的OFFSETS束？

——OFFSET=IN3nsBEFORECLK;

OFFSET=OUT4nsAFTERCLK;

ISE时序约束笔记7Path-SpecificTimingConstraints

时钟上升沿和下降沿之间的时序约束

周期约束可以自动计算两个沿的的约束一一包括调整非50%占空比的时钟。

例：

一个CLK时钟周期约束为10ns，能够应用5ns的约束到两个寄存器之间不需要特定路径应用到这个例子中。

相关时钟域的约束

为一个时钟进行周期约束一一以这个周期约束确定相关的时钟。

执行工具将根据它们的关系来决定如何处理跨时钟域。

DCM有多个输出：

――确定DCM输入时钟的周期约束

――执行工具将会从这个周期约束推导岀其输岀的约束

――所有的约束将会和原始的周期约束相关

不相关时钟域的约束

在这个例子中，周期约束不覆盖到处于两个时钟域之间的任何延时路径。

一一这是默认的处理方式。

TC

COUTU

PRE2

偏移。

在两个不相关的时钟域你就必须添加一些同步电路。

False路径

False路径选项将用于防止约束覆盖到特定路径

多周期路径约束

QUT1

Q2Q304Q14Q15

PERIODCLKAPERIODCLKB

CLK^A

CLKB

映。

—二问。

口心

时序约束优先级

从高到低为:

1.False路径一一将会覆盖任何其它的约束路径

2.FROMTHRUTO

3.FROMTO

4.管脚指定OFFSETS

5.GroupsOFFSETs（由寄存器或者PADS生产的groups）

6.全局PERIOD和OFFSET——最低优先级约束

这里特权同学提醒大家注意的是，通常类似下面这样的计数器绝对不可以归为多周期约束：

reg[15:

0]counter;

always@（posedgeelkornegedgerst_n）

begin

if（!

rst_n）counter<

=16'

d0;

elsecounter<

=eounter+1'

b1;

end

虽然我们想想似乎counter[1]也是2个elk变化一次，counter[2]也是4个elk变化一次”但是，我们想想看，如果从counter=1至Ucounter=2没有在一个clk完成，那么肯定就会影响到counter=2至Ucounter=3的变化，对吧？

所以，这样的计数器不能算做多周期约束例外。

提纲里描述的多周期例外的计数器应该是这样一个模型：

always@（posedgeclkornegedgerst_n）

beginif（!

rst_n）counter*1:

0+<

=2'

elsecounter*1:

=counter*1:

0++1'

rst_n）counter*15:

2+<

=14'

elseif（counter*1:

0+==2'

b11）counter*15:

=counter*15:

2++1'

上面两个always块里的数据互不干扰，并且都正常工作，只有下一个always块检测到前一个always

块里的counter*1:

0+==2'

b时才进位加1。

写到这里，特权发现单从功能上来说，这两个例子是没有差别的，说白了，任何一个计数器都可以建模成后面的形式。

或者说，我的问题其实没有说明白，反而被自己的例子给驳倒了。

呵呵，换个角度思考这个问题，到底什么时候是多周期例外，什么时候不是？

这个其实还是要看情况的，如果你的系统实时性较高，可能会在某一特定的时钟周期用到16位计数器的计数值（如a=（counter==

16'

hffff）?

1b'

1:

1；

那么这个计数器的高位就不能算作多周期例外。

而如果比如在我的一个工程里，有这样的计数器用法：

cuonter[2:

0]没16个clk的后8个clk需要自增加（从0到15），而高位counter[18:

3]当然只有在16个clk变化一次，因为这里counter是用于作为一个地址产生器，也就是说，我的地址是每16个clk的后8个clk用到，那么这里的counter[18:

3]就是一个8clk的多周期例外实例。

说白了，还是要具体问题具体分析。

ISE时序约束笔记8AchievingTimingClosure

题记：

achievingtimingclosure即达到时序收敛，这是一个很具有挑战性的任务。

因为实际的工程项目往往不会像我们用一个资源超大（相对于你的设计来说）的FPGA来做几个数码管串口实验那么简单。

设

计者往往需要达到成本、速度、资源等各个方面的平衡，即使是一个小设计，有时候也是很费神的。

特权同学前几周在饱经ISE4里才有的老器件的折磨后，感慨良多。

关于时序报告

ISE中的时序报告分为两种：

-Post-MapStaticTimingReport

-Post-Place&

RouteStaticTimingReport

所谓Post-Map是布局后（没有布线）的静态时序报告，主要用于估计设计的性能，然后提前对设计做一些必要的修改。

因为设计的实现（布局布线）是很消耗时间的。

Post-Place&

Route就是布局布线后的

一个比较接近实际板级的一个静态时序报告了，这算是设计者进行时序分析的最终依据。

关于性能估计

综合报告

1.准确的逻辑延时；

2.基于扇岀的布线延时估计

3.报告的性能是实际的20%误差内

Post-Map静态时序报告

1.准确的逻辑延时

2.基于最快的可能的布线资源的布线延时估计

3.使用了60/40规则来计算更趋近于实际的性能估计

60/40法则：

1.这是一个时序约束合理性的经验法则；

2.打开Post-Map静态时序报告，查看时序报告中关于逻辑延时的百分比

――低于60%，时序很有机会到达时序约束要求

――60%到80%,如果使用了高级选项，时序也很有机会达到时序要求

――80%以上，基本上很难（回到综合部分，或者重新优化你的代码）

Post-Place&

Route时序分析

找出时序违规的因素有很多：

1.设计的综合不当或者代码风格太烂；

2.糟糕的综合结果（路径中的逻辑太繁杂）

3.不准确或者不完整的时序约束

4.糟糕的逻辑映射和布局

每个问题都用不同的解决方案：

1.重写代码

2.添加时序约束（注意应该是一些时序例外）

3.使用不同的软件选项重新综合或者实现

准确的定位时序报告能够解决大多数问题。

一些可能的问题和解决

布线延时太长一一似乎有些路径扇岀很低，但是延时却很大，那么很可能这个地方的布线比较拥堵。

解决办法：

如果是不相关的逻辑布局到一块，可以到Floorplanner中查看。

（这个问题特权同学还没有完全领会也是比较头疼的，希望看到更多更好的资料或者自己在工程中有更多体会时再和大家分享）

高扇岀问题一一解决办法是复制高扇岀的网络。

如果是组合逻辑，那么就比较难了。

逻辑级数太高一一这个问题综合工具无法做太多优化。

首先查看是否该路径为多周期路径，如果是，添加多周期例外；

使用retiming选项更加均匀的分配触发器之间的逻辑；

确定一个比较好的代码技巧被运用到了你的设计代码中；

使用流水线设计。

I/O时序问题一一使用DCM移除时钟分布延时；

将输入输出相关的寄存器放入IOB寄存器中。

另外在实际应用中，其实很是有很多可以应用的技巧的，比如实现属性选项里其实是可以设置布局布线的努力程度，还有布局布线的次数等待，对于大多数设计而言这些工具都是有用的。