时序收敛十大准则

准则一：合适的代码风格

准则二：精准的时序约束

准则三：高理高扇出网格

准则四：层次化设计结构

准则五：处理跨时钟域设计

准则六：少而精的物理约束

准则七：选择实现策略

准则八：共享控制信号

准则九：读懂日志和报告

准则十：发挥Tcl的作用

少而精的物理约束

不同于对时序约束尤其是时钟约束之全面而精准的要求，Vivado 对物理约束的要求只有一个字：少。这里的物理约束更多强调的是除了I/O 引脚位置这些必要项之外的约束，例如对RAMB 和DSP48 的位置约束，还有局部的floorplan 计划。

很多资深工程师非常喜欢画floorplan，因为其对设计的数据流和资源使用情况了如指掌，根据自己理解画出的floorplan通常也算合理。但是，floorplan 在Vivado 中的重要性远低于以往在ISE 上的作用。根据客户的实际经验反馈，绝大多数的设计中都无需任何floorplan（某些时序要求较高的SSI 芯片设计上可能需要），因为算法的改进，Vivado 在布局上比上一代ISE 更聪明，没有任何物理约束（除了IO 引脚位置约束）的设计反而能在更短的时间内更好地满足时序要求。

在确实需要锁定某些宏单元以及进行floorplan 的设计中，一般我们会推荐先不加任何物理约束来跑设计，在其他诸如改进源代码，设置约束和选项，改变策略等办法都试过后，再尝试物理约束。而且，最好只在少量关键的设计区域进行floorplan，切忌过度约束，不要创建资源利用率过高的pblocks，同时避免重叠的pblocks 区域。

顺便提一下，Vivado IDE 中的Device 视图可以通过设置不同颜色来高亮显示不同模块，用户可以根据当前设计的布局结果配合时序报告和关键和调整floorplan，操作非常便捷。

选择实现策略

从ISE 升级到Vivado 后，很多用户发现SmartXplorer 功能不见了，当设计进行到后期，假如不能遍历种子，常让人感到无所适从，甚至怀疑到了这一步Vivado 便无计可施。那么事实到底如何呢？

严格来讲，Cost Table 其实是一种无奈之举，说明工具只能通过随机种子的改变来“撞大运”般筛选出一个最佳结果，这也解释了为何改变Cost Table 的结果是随机的，一次满足时序，并不代表一直可以满足。

因为更高级算法的引入，Vivado 中的设计实现变得更加可靠，而且是真正意义上的可预计的结果。但这并不代表在Vivado 中对同一个设计进行布局布线只能有一种结果。我们可以通过“策略”来控制实现过程中的算法侧重，从而可以产生更优化的结果。

策略（Strategy）是一组工具选项和各个阶段指示（Directive）的组合，Vivado IDE 中内置了几十种可供用户直接选用，但如果穷尽各种组合，整个实现过程大约有上千种策略。当然，我们没必要遍历每种策略。而且因为策略是一种可预计可重现的实现方法，所以对同一个设计，可以在选择几种有侧重点的策略后挑选出效果最好的那个，只要设计后期没有大的改动，便可一直延用同样的策略。

具体策略的特性，请参考UG949 和UG904 等文档，也可以在Vivado 中通过help 菜单了解。更多时候，选择怎样的策略是一种经验的体现，另外，即使找到了最佳实现策略，也仍旧有可能不满足时序要求，这时候我们还可以参考《用Tcl 定制Vivado 设计实现流程》中所述，对设计实现的流程进行进一步的个性化定制。

另外要强调一点，修改策略来提升性能必须放在调整代码、约束和选项等更直接高效的优化方法之后进行，其能带来的性能提升比起前述优化方法来说也更加局限。

共享控制信号

共享控制信号这一点充分体现了设计必须考虑到用于底层实现的芯片结构的重要性，在Xilinx 的芯片上，时钟、置位/复位和时钟使能等信号通称为Control Set，进入同一个SLICE 的Control Set 必须统一。换句话说，不同Control Set 控制下的FFs 不能被Vivado 放进同一个SLICE。

为了提升SLICE 的利用率，获得更高效的布局方案，提升时序性能，我们必须控制一个设计中ControlSet 的总数，尽量共享控制信号。具体做法包括：

尽量整合频率相同的时钟和时钟使能信号；
在生成IP 时选择“共享逻辑”功能，则可以在不同IP 间尽可能的共享时钟资源；
遵循Xilinx 建议的复位准则：

尽量少使用复位
必须复位时采用同步复位
确保使用高电平有效的复位
避免异步复位（RAMB 和DSP48 模块中不支持异步复位）

Xilinx 的复位准则必须严格遵守，根据现场支持的经验来看，很多设计性能的瓶颈就在于设计源代码时没有考虑底层实现器件的硬件结构特点，尤其以复位信号的实现问题最为突出。

读懂日志和报告

任何一个工具的日志和报告都是衡量其性能最重要的一环，正因为有了完备的日志与报告，用户才可以通过其中显示的信息，定位设计中可能的问题，决定优化方向。

Vivado 日志中将信息显示为三大类，分别为Error、Critical Warning 和一般Warning/Note 等。Error 会导致工具直接中断，其他警告不会中断工具运行，但所有的Critical Warning 都需要用户逐一检查并通过修改设计、增加约束或设置选项之类的办法来修复。

Vivado 的报告功能很强大，除了《读懂用好Timing Report》中描述的时序分析报告，还有很多重要的报告，小到检查设计中的特定时序元件和链路，大到各种预置和自定义的DRC 检查，不仅提供给了用户多样的选择，也进一步保证了设计的可靠性。

Vivado 也一直在增强和更新报告的种类，比如2014.3 之后还增加了一个设计分析报告report_design_analysis，用来报告关键路径上的潜在问题以及设计的拥塞程度。完整的report 命令和功能可以在UG835 中查询。

发挥Tcl的作用

Tcl 在Vivado 中的作用不容小觑，不仅设计流程和报告全面支持Tcl 脚本，就连XDC 约束根本上也来自于Tcl，用户甚至可以直接把包含有循环等功能的高级约束以Tcl 的形式读入Vivado 中用来指引整个实现流程。

《Vivado 使用误区与进阶》系列中有三篇关于Tcl 在Vivado 中的应用文章，详细描述了如何使用Tcl 创建和应用约束，查找目标和定位问题；如何用Tcl 来定制Vivado 的设计实现流程，为图形化界面提供更多扩展支持；以及如何用Tcl 实现ECO 流程。Tcl 所带来的强大的可扩展性决定了其在版本控制、设计自动化流程等方面具有图形化界面不能比拟的优势，也解释了为何高端FPGA 用户和熟练的Vivado 用户都更偏爱Tcl 脚本。

另外，随着Xilinx Tcl Store 的推出，用户可以像在App Store 中下载使用app 一样下载使用Tcl 脚本，简化了Tcl 在Vivado 上应用的同时，进一步扩展了Tcl 的深入、精细化使用。最重要的是，Tcl Store 是一个基于GitHub 的完全开源的环境，当然也欢迎大家上传自己手中有用的Tcl 脚本，对其进行补充。

小结

关于UltraFast 的要点总结基本可以概括在上述十点，这也可以看作是对《Vivado 使用误区与进阶》系列短文的一个串烧。说实话，八九页的篇幅要将整个UltraFast 讲透基本没有可能，对于正在使用Vivado 做设计或是有兴趣试用的读者们，强烈建议各位在Xilinx 官网下载完整的UltraFast 指南并通读