关于时序报告

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

         – Post-Map Static Timing Report

– Post-Place & Route Static Timing Report

         所谓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寄存器中。

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

*博客内容为网友个人发布，仅代表博主个人观点，如有侵权请联系工作人员删除。