特别需要指出的是 Flow Navigator 只有在 Vivado IDE 中打开.xpr 工程文件才会显示，如果打开的是设计检查点.dcp 文件（不论是工程模式或是非工程模式产生的 dcp）都不会显示这个侧栏。
非工程模式
非工程模式下，由于不会创建工程，用户就需要自己管理设计源文件和设计过程。源文件只能从当前位置访问，在设计实现过程中的每一步，数据和运行结果都存在于 Vivado 分配到的机器内存中，在用户不主动输 出的情况下，不会存储到硬盘中。
简单来讲，非工程模式提供了一种类似 ASIC 设计的流程，用户拥有绝对的自由，可以完全掌控设计实现流程，但也需要用户对设计实现的过程和数据，尤其对文件输出和管理全权负责，包括何时、何地、输出怎样的文件等等。
使用非工程模式管理输入输出文件、进行设计实现都需要使用 Tcl 脚本，但这并不代表非工程模式不支持图形化界面。非工程模式下产生的.dcp 文件一样可以在 Vivdao IDE 中打开，继而产生各种报告，进行交互式调试等各种在图形化下更便捷直观的操作。这是一个常见误区，就像很多人误 认为工程模式下不支持 Tcl 脚本运行是一个道理。但两种模式支持的 Tcl 命令确实是完全不同的，使用起来也不能混淆。
下图所示是同一个设计（Vivado 自带的 Example Design）采用两种模式实现所需使用的不同脚本，更详细的内容可以在 UG975 和 UG835 中找到。需要注意的是，工程模式下的 Tcl 脚本更简洁，但并不是最底层的 Tcl 命令，实际执行一条相当于执行非工程模式下的数条 Tcl 命令。
Tcl对图形化的补充
相信对大部分 FPGA 工程设计人员来说，图形化界面仍旧是最熟悉的操作环境，也是设计实现的首选。在 Xilinx 推出全面支持 Tcl 的 Vivado 后，这一点依然没有改变，但我们要指出的是，即使是在图形化界面上跑设 计，仍然可以充分利用 Tcl 的优势。在 Vivado IDE 上运行 Tcl 脚本主要有以下几个渠道。
Tcl Console
Vivado IDE 的最下方有一个 Tcl Console，在运行过程中允许用户输入 Tcl/XDC 命令或是 source 预先写 好的 Tcl 脚本，返回值会即时显示在这个对话框。
举例来说，设计调试过程中，需要将一些约束应用在某些网表目标上（具体可参照《Tcl 在 Vivado 中的应 用》所示），推荐的做法就是在 IDE 中打开.dcp 然后在 Tcl Console 中输入相应的 Tcl/XDC 命令，验证返回值，碰到问题可以直接修改，直到找到正确合适的命令。然后可以记录这些命令，并存入 XDC 文件中以备下次实现时使用。
还有一种情况是，预先读入的 XDC 中有些约束需要修改，或是缺失了某些重要约束。不同于 ISE 中必须修改 UCF 重跑设计的做法，在 Vivado 中，我们可以充分利用 Tcl/XDC 的优势， 在 Tcl Console 中输入新的 Tcl/XDC，无需重跑设计，只要运行时序报告来验证。当然，如果能重跑设计，效果会更好，但是这种方法在早期设计阶段提供了一种快速进行交互式验证的可能，保证了更快地设计迭代，大大提升了效率。
另外，通过某些 Tcl 命令（例如 show_objects、select_objects 等等）的帮助，我们还可以利用 Tcl Console 与时序报告、RTL 和门级网表以及布局布线后的网表之间进行交互调试，极大发挥 Vivado IDE 的优势。
Hook Scripts
Vivado IDE 中内置了 tcl.pre 和 tcl.post，用户可 以在 Synthesis 和 Implementation 的设置窗 口中找到。设计实现的每 一步都有这样两个位置可供用户加入自己的 Tcl 脚本。
tcl.pre 表示当前这步 之前 Vivado 会主动 source 的 Tcl 脚本，tcl.post 表示这步之后会 source 的脚本。
Tcl 脚本必须事先写好，然后在上图所示的设置界面由用户使用弹出窗口指定到脚本所在位置。
这些就是所谓的“钩子”脚本，正是有了这样的脚本，我们才得以在图形化界面上既享有一键式执行的便利，又充分利用 Tcl 带来的扩展性。比较常见的使用场景是，在某个步骤后多产生几个特别的报告，或是在布线前再跑几次物理优化等。
Customer Commands
Vivado IDE 中还有一个扩展功能，允许用户把事先创建好的 Tcl 脚本以定制化命令的方式加入图形化界面，成为一个按钮，方便快速执行。这个功能常常用来报告特定的时序信息、修改网表内容、实现 ECO 等等。
用 Tcl定制实现流程
综上所述，标准的 FPGA 设计实现流程完全可以通过 Vivado IDE 一键式执行，如果仅需要少量扩展，通 过前述钩子脚本等几种方法也完全可以做到。若是这些方法都不能满足需求，还可以使用 Tcl 脚本来跑设计，从而实现设计流程的全定制。
注：以下讨论的几种实现方案中仅包含后端实现具体步骤的区别，而且只列出非工程模式下对应的Tcl 命令。
右图所示是 Vivado 中设计实现的基本流程，蓝色部分表示实现的基本 步骤（尽管opt_design 这一步理论上不是必选项，但仍强烈建议用户执行），对应 Implementation 的 Default 策略。黄色部分表示可选择执行的部分，不同的实现策略中配置不同。
这里不会讨论那些图形化界面中可选的策略，不同策略有何侧重，具体如何配置我们将在另外一篇关于 Vivado 策略选择的文章中详细描述。
我们要展示的是如何对设计流程进行改动来更好的满足设计需求，这些动作往往只能通过 Tcl 脚本来实现。
充分利用物理优化
物理优化即 phys_opt_design 是在后端通过复制、移动寄存器来降扇出和 retiming，从而进行时序优化的 重要手段，一般在布局和布线之间运行，从 Vivado 2014.1 开始，还支持布局后的物理优化。
很多用户会在 Vivado 中选中 phys_opt_design，但往往不知道这一步其实可以运行多次，并且可以选择不同的 directive 来有侧重的优化时序。
比如，我们可以写这样一个 Tcl 脚本，在布局后，使用不同的 directive 或选项来跑多次物理优化，甚至可 以再多运行一次物理优化，专门针对那些事先通过 get_nets 命令找到并定义为 highfanout_nets 的高扇出网络具体 directive 的含义可以通过 UG835、UG904 或 phys_opt_design -help 命令查询。
布局布线之间的多次物理优化不会恶化时序，但会增加额外的运行时间，也有可能出现时序完全没有得到优化的结果。布线后的物理优化有时候会恶化 THS，所以请一定记得每一步后都运行 report_timing_summary，并且通过 write_checkpoint 写出一个.dcp 文件来保留阶段性结果。这一步的结果不理想就可以及时退回到上一步的.dcp 继续进行。
楼主
标题置顶
标题高亮
