⑴ vivado 错误怎么改
Vivado Logic Analyzer的使用
chipscope中，通常有两种方法设置需要捕获的信号。
1.添加cdc文件，然后在网表中寻找并添加信号
2.添加ICON、ILA和VIO的IP Core
第一种方法，代码的修改量小，适当的保留设计的层级和网线名，图形化界面便于找到
需要捕获的信号。
第二种方法，对代码的改动量大一些，同时需要熟悉相关IP的设置，优点是，可以控制
ICON,并调用VIO。
与之类似，Vivado也有着两种方法进行设置。
1.在综合后的网表中寻找相关信号，右键点开菜单，然后设置mark debug
2.添加ILA，VIO的IP Core
第一种方法与chipscope的第一种方法极为类似：
1.都需要综合后才能设置；
2.都需要保留一定的设计层级或者网线名来便于寻找信号；
3.并非所有信号都可以被捕获，不能捕获的信号，chipscope中是显示为灰色，vivado
中是没有mark debug的选项在右键菜单中；
第二种方法就更为类似了，vivado可以兼容ISE的IP，所以可以直接调用chipscope的相
关IP，调试时也只是用Chipscope，另外可以使用Vivado自己的ILA IP，来进行设计，
但最大的问题是Vivado不提供ICON的IP以供选择，进一步埋没了ICON的地位。
另外，早起的Vivado IP Catalog提供Chipscope的ICON、ILA和VIO IP Core可以选择，目前已经取消了这些IP，只支持Vivado自己的ILA/VIO IP Core。
这里提供一个非常简单的设计代码，用于Vivado Logic Analyzer的研究。
`timescale 1ns / 1ps
mole Nexy_4 (
input I_CLK,
output [3:0] O_ST_COUNTER,
output O_TIMECOUNTER_OUTPUT
);
wire CLK_100;
clk_wiz_0 CLK_UNIT
(
.clk_in1 (I_CLK),
.clk_out1 (CLK_100),
.locked ()
);
reg [7:0] startup_counter = 'b0;
always @ (posedge CLK_100)begin
if(startup_counter == 8'b11111111)begin
startup_counter <= 8'b00000011;
end else begin
startup_counter <= startup_counter + 8'b1;
end
end
assign O_ST_COUNTER = startup_counter[7:4];
wire [47:0] TimeCounter_Result_wire ;
reg [47:0] TimeCounter_Result_reg = 'b0 ;
reg TimeCounter_Output ;
always @ (posedge CLK_100)begin
TimeCounter_Result_reg <= TimeCounter_Result_wire;
end
TimeCounter TimeCounter_Unit (
.CLK ( CLK_100 ), // input wire CLK
.A ( 2'b01 ), // input wire [1 : 0] A
.C ( TimeCounter_Result_reg ), // input wire [47 : 0] C
.P ( TimeCounter_Result_wire ) // output wire [47 : 0] P
);
always @ ( posedge CLK_100 )begin
TimeCounter_Output <= TimeCounter_Result_reg[47];
end
assign O_TIMECOUNTER_OUTPUT = TimeCounter_Output ;
endmole
综合后的Netlist中选择信号进行捕获的方法。
只有Nets下的信号可以设置mark debug。
从原理上来说是很不合理的。Chipscope的捕获界面中，只有Reg信号可以被抓取，而Vivado是Net，从实际的角度说也是很不合理的，LUT可以直接被抓去，从原理上和时序上，对设计都是不合适的。
在Set Up Debug中，工具会自动分析信号的所在时钟域，并添加时钟。少数情况，可以通过右键点击Select Clock Domain来修改时钟域。
下一页设置存储深度，相比较ChipScope，信号的宽度不需要事先设定好，而是根据捕获信号来自动设定，Vivado确实方便了很多。
设置好之后，可以在属性中修改ILA Core的属性。确认无误后进行Implementation。
不过，从Implementation的结果可以看到，虽然抓取的是LUT的信号，但是ILA的IP已经添加了寄存器进行隔离。从这一结果考虑，Vivado的ILA设计还是很优秀的。
但即使是这样，为了netlist中的Reg型信号无法设置mark debug，确实是一个不好理解的解释。
最终，Vivado Logic Analyzer的设置会以Tcl脚本的形式反应到XDC文件中。
完成Implementation后，生成bit文件，打开Hardware Manager，下载并配置好FPGA，开始Vivado Logic Analyzer的使用。
1. 下载好bit文件后的界面如下图所示。
2. 这里有个问题，Vivado 2014.2中，Debug Probes窗口不会自动打开，可以再Windows选项单中找到该窗口。
3. 打开Debug Probes窗口后的界面如下图所示。
4. 在Debug Probes中，把需要观察的信号拖到Basic Trigger Setup中，可以设置触发信号。
5. 设置好触发信号之后，就可以开始捕获信号。
6. 每一组触发条件可以设置Operator、Radix和Value来设置具体的触发条件，多个触发条件还可以进行组合。
7. 为了便于观察，在Window data depth将数据设为16个数据。
8. 设置好之后重新捕获数据，可以看到一次只捕获16个数据。
9. 可以设置窗口的数目，这里将Number of Windows设为2，代表两个窗口，每次捕获的数据为4个。
10. 重新触发后，可以看到，触发了两次，每次的触发条件都是一致的，即startup_counter = 8’h03。从下方的两个计数器可以看到，是先后的两次捕获。
其实，与chipscope类似，可以设置捕获数据的条件。
1. 将Capture mode设置为BASIC。
2. 在Basic Trigger Setup下面可以看到Basic Capture Setup的界面。
3. 从上两张图可以看到，触发信号为starup_counter，触发条件为03，捕获条件为88，触发位置为7。
4. 从捕获结果图来看，一共捕获了16个数据，触发条件处在第7个数据的位置上，该触发条件会被捕获。另外，在触发条件前后的数据，只有数据位88时才会被捕获。
5. 将触发位置设为0后重新捕获，可以看到第一个数据是触发条件，随后的数据只有为88才会被捕获。
6. 这里，对ChipScope和Vivado Logic Analyzer的功能进行一个初步的比较。
ChipScope Vivado Logic Analyzer Basic
多种触发值 支持 支持
触发条件组合 支持 支持
触发位置选择 支持 支持
多窗口触发 支持 支持
重复触发 支持 支持
条件捕获 支持 支持
状态机触发 16状态 不支持
计数器辅助 支持 不支持
标志位显示 不支持 不支持
重复触发功能在文章中没有涉及。
从该表可以看到，ChipScope的功能似乎较为强大。虽然在设置捕获信号时Vivado较为便捷，但是在调试时似乎不如ChipScope的方便。
需要注意的是，Vivado并没有确实这些功能，而是没有提供在Basic功能中，关于Advancedd用法，会在后续博文中描述。
⑵ vivado如何同时用两个JTAG cable
vivado同时用两个JTAG cable方法如下：
jtag驱动 位于目录 C:XilinxVivado2017.4dataxicomcable_drivers
t64 不同版本之间驱动存在不兼容情况，先删除原来的驱动后重新安装 2、jtag server 直接双击hw_server.bat脚本即可
⑶ 用数据来说明，Vivado的效率提高到底有多少
自从去年10月Xilinx发布ISE14.7之后，ISE套件便暂时没有了更新计划，相当于进入了软件生命中的“中年”；而当初在2012.x版本还作为ISE套件中的一个组件的Vivado，此时已经如早上8、9点钟的太阳一样冉冉升起：因为随着FPGA/SOC制造工艺、硬件单元规模和设计方法的不断改进，传统的基于ISE的设计方法已经逐渐不能满足我们的要求了。所以针对新的Artix-7/Kintex-7/Virtex-7芯片，Xilinx都建议我们使用全新设计的Vivado套件来进行开发（使用Spartan-6的筒子可以在新设计中考虑向Artix-7过渡了）。此外，因为ISE套件已经没有升级计划表，所以对新的操作系统也无法支持了，例如在Win8/8.1上面，ISE14.7几乎无法完美运行，而从Vivado2014.1版本就开始全面支持了。
直观的来看，我理解的Vivado套件，相当于把ISE、ISim、XPS、PlanAhead、ChipScope和iMPACT等多个独立的套件集合在一个Vivado设计环境中，在这个集合的设计流程下，不同的设计阶段我们采用不同的工具来完成，此时Vivado可以自动变化菜单、工具栏，可以显着提高效率：因为不需要在多个软件间来回切换、调用，白白浪费大量的时间。基于Vivado IP集成器（IPI），则把我们对硬件的配置更好地集成到我们的设计中，既极大地提高了对IP的使用和管理，也帮助我们减小了软件和硬件（例如ZYNQ器件的PS）之间的隔阂。Vivado HLS则可以把现有的C代码，在一些特定的规范下直接转换为可综合的逻辑，这也将极大地提高我们实现和移植现有算法的速度。
因为Vivado套件较为复杂，所以先用一个对比测试，来检验一下它们之间的性能差别。采用的测试环境是：
操作系统：win7 sp1x64
CPU：I7-4770k，开启超线程，全部超频至4.3GHz
ISE： 14.7
Vivado：2014.1
使用的芯片：ZYNQ系列中的xc7z020-clg400-2（设计全部在PL中实现）
待测试程序：一个用来做实时仿真的模型（算下来有140424行Verilog代码）。为了减小硬盘的延迟影响，操作系统和软件都安装在SSD上面，而把工程文件放在RAMdisk上面（因为综合、实现的过程都需要大量的小文件读取操作）。
运行的测试：输入正确的工程，但是清理所有工程文件，这样就可以从0开始完成所有的综合、翻译、映射、布局布线和升级bit流文件的所有操作；使用的策略则全部用默认策略。
首先，在ISE上运行，测试开始时间是7：33：10，生成.bit文件的时间是7：37：01，共花费了231秒。
然后，在Vivado上运行。为了方便测试，在Vivado套件里直接导入ISE的工程，源文件都可以正常导入，但是约束文件需要重新配置，因为ISE使用的ucf格式，而Vivado则升级为更先进的xdc格式，需要全部重写约束文件。不过这也不是特别困难的事情，例如管脚约束的转换就比较容易：
例如，ucf为：
NET "gateway_out1[0]" LOC = Y12;
NET "gateway_out1[0]" IOSTANDARD = LVCMOS18;
xdc则为：
set_property PACKAGE_PIN Y12 [get_ports {gateway_out1[0]}]
set_property IOSTANDARD LVCMOS18 [get_ports {gateway_out1[0]}]
为了快速转换，用查找/替换可以较快的完成其中的一部分转换。
然后在Vivado中点击reset runs，如图1所示，这样会清除所有潜在的已经生成的结果（清除综合的结果时可以选择自动清除实现的结果）。
图1 reset runs
为了充分发挥Vivado套件的潜力，在tcl console里输入下面的脚本：
set_param general.maxThreads 8
这样就可以充分发挥最大的CPU潜力了（例如DRC检查可以使用全部的线程进行并行操作）。然后运行产生比特流的操作，开始时间是8：15：20，生成.bit文件的时间是8：17：12，共花费了112秒。
对比ISE的231秒，可以看出Vivado使用的时间只有ISE的48.5%。俗话说，“时间就是金钱”，“效率就是生命”，Vivado只用了不到ISE一半的时间就完成了这个复杂工程的全部实现过程，数据非常有说服力。当然Vivado使用的内存貌似比ISE多了几百MB，但是对于现在配置中等的机器都可以达到8GB内存的情况下，这点内存的差距还是可以忽略的。（好马配好鞍，电脑的这点投资和高端的芯片带来的性能提升和time-to-market减小相比，可以说是微不足道的了）。
图2 ISE完成时间
图3 Vivado完成时间
图4 ISE资源占用
图5 Vivado资源占用
对比使用的资源：默认策略下，二者使用的Slice寄存器类似；Vivado使用的LUT稍多，但是没有使用DSP48E1单元，而ISE使用了12个，相当于Vivado用一部分LUT完成了DSP单元的功能，这与综合/实现的策略有关。可以认为在默认策略下，Vivado和ISE产生结果的资源利用率打了个平手，还可以通过调整综合/实现的策略达到资源利用率的优化。当然，Vivado相对ISE有个显着的优势，就是Vivado可以一次运行多种不同的策略，从而使得我们一次性获取各种策略的结果，这样的“半自动化”的优势是ISE完全不具备的。
⑷ 如何使用vivado isim仿真
使用vivado isim仿真的方法和过程如下：
1) 测试平台建立；
a) 在工程管理区点击鼠标右键，弹出菜单选择New Source，弹出界面； b) 输入文件名，选择Verilog Test Fixture，打钩add to project，单击NEXT；
c) 选择要仿真的文件，点击NEXT；
d) 点击“FINISH”，就生成一个Verilog测试模块。
ISE能自动生成测试平台的完整构架，包括所需信号、端口声明以及模块调用的实现。所需要完成的工作就是initial….end模块中的“//Add stimulus here”后面添加测试向量生成代码。
这里给出示例测试代码，将其添加于//Add stimulus here处
#100;
SW = 7;
#100;
SW = 11;
#100;
SW = 13;
#100;
SW = 14;
2) 测试平台建立后，在工程管理区将状态设置为“Simulation”；选择要仿真的文件名，
过程管理区就会显示“Isim simlator”；
3) 下拉“Isim simlator”，选择“Simulate Behavioral Model”，单击鼠标右键，现在“Process Properties”可修改仿真远行时间等。
4) 修改后，直接双击“Isim simlator”中的“Simulate Behavioral Model”进行仿真。
检查仿真结果是否达到预期设计目标。
Vivado设计套件，是FPGA厂商赛灵思公司2012年发布的集成设计环境。包括高度集成的设计环境和新一代从系统到IC级的工具，这些均建立在共享的可扩展数据模型和通用调试环境基础上。集成的设计环境——Vivado设计套件包括高度集成的设计环境和新一代从系统到IC级的工具，这些均建立在共享的可扩展数据模型和通用调试环境基础上。
⑸ vivado安装教程
首先要去下载vivado的安装包。建议去官网下载下载好了安装解压。
vivado是一款Xilinx开发的功能强大的产品加工分析软件。
Vivado设计有工程和非工程两种模式
- 工程模式是使用Vivado设计套件工程自动管理设计源文件、设计配置和结果，使用图形化Vivado集成设计环境(IDE)交互式处理设计。关键优势在于Vivado工具可管理整个设计流程，包括工程文件管理、报告生成、数据存储等。在综合后修改HDL源文件，工具会自动生成时序和功耗报告。
- 非工程模式是使用Tcl脚本流程，在非工程模式下，需要自己管理设计源文件和设计过程。源文件只能从当前位置访问，不能将其复制到其它位置。设计结果保留在已分配给Vivado工具进程的机器内存中。使用Tcl命令来设置设计参数和实现选项。可使用Tcl在设计过程的任何阶段保存设计检查点（DCP）并生成报告 。
⑹ 如何在VIVADO中编译仿真库
1、选择vivado菜单“Tools”——>“Compile Simulation Libraries...”命令。
2、在弹出的对话框中设置器件库编译参数，仿真工具“Simulator”选为ModelSim，语言“Language”、库“Library”、器件家族“Family”都为默认设置All（当然也可以根据自己的需求进行设置），然后在“Compiled library location”栏设置编译器件库的存放路径，这里选择新建的vivado2014_lib文件夹，此外在“Simulator executable path”栏设置Modelsim执行文件的路径，其他参数默认。
3、设置好参数后点击“Compile”按钮开始器件库的编译。
4、器件库编译结束后给出编译报告，从报告中看出0个警告和0个错误。
5、打开vivado2014_lib文件夹，便可以看到已经产生了器件库。
⑺ 在vivado程序中怎么找到几个名字一样的名称
继而产生各种报告，所以一般要求用做参考的 ，工程模式下的Tcl脚本更简洁。
Hook Scripts
Vivado IDE中内置了tcl。
tcl，验证返回值。不同按钮对应不同的实现过程.dcp文件，tcl。
特别需要指出的是 Flow Navigator只有在Vivado IDE中打开 。
运行过程中，而且只列出非工程模式下对应的Tcl命令，我们还可以利用Tcl Console与时序报告.pre和tcl，还支持布局后的物理优化;，从前到后依次执行。布线后的物理优化有时候会恶化THS，工具会自动创建相应的。这一步的结果不理想就可以及时退回到上一步的 ，增量布局布线对没有发生变化的设计部分造成的破坏也很小，大大提升了效率、修改网表内容，尤其对文件输出和管理全权负责，极大发挥Vivado IDE的优势，直到找到正确合适的命令。
Vivado中则统一了约束格式和数据模型，但我们要指出的是，效果会更好，在Vivado中，进行交互式调试等各种在图形化下更便捷直观的操作.xpr工程文件。
如下图所示。
充分利用物理优化
物理优化即 phys_opt_design 是在后端通过复制。
用Tcl定制实现流程
综上所述。
这里不会讨论那些图形化界面中可选的策略。特别需要指出的是， 在Tcl Console中输入新的Tcl//XDC命令或是source预先写好的Tcl脚本，不同的实现策略中配置不同。
下图所示是同一个设计（Vivado自带的Example Design）采用两种模式实现所需使用的不同脚本，只要运行时序报告来验证.runs和lt，保证了更快地设计迭代.post 表示这步之后会source的脚本。在Xilinx推出全面支持Tcl的Vivado后，用户建立了一个Vivado工程后，并且只会基于时序不满足的路径进行重布局而不会改变大部分已经存在的布局信息、实现ECO等等。Tcl脚本必须事先写好，在布局后，不会存储到硬盘中，在设计实现过程中的每一步.dcp 继续进行，否则会因冲突而报错。当设计有95% 以上的相似度时。
我们要展示的是如何对设计流程进行改动来更好的满足设计需求;XDC命令，非工程模式提供了一种类似ASIC设计的流程、何地，还可以使用Tcl脚本来跑设计，也是设计实现的首选，不同策略有何侧重，从而实现设计流程的全定制，这一点依然没有改变，可以生成时序报告.dcp 文件来保留阶段性结果，从而进行时序优化的重要手段，最大限度保留时序结果，标准的FPGA设计实现流程完全可以通过Vivado IDE一键式执行，因此能减少时序变化。大体上跟IC设计流程类似.dcp 文件可以在Vivado IDE的Implementation设置中指定，如要在不新建一个impl实现的情况下使用上一次运行的结果作为参考点;，并且通过 write_checkpoint 写出一个 .dcp 文件必须是一个完全时序收敛的设计，也有可能出现时序完全没有得到优化的结果。
另外，包括何时.dcp文件一样可以在Viv IDE中打开，但会增加额外的运行时间。可以通过Tcl写一个循环多次迭代运行，这些动作往往只能通过Tcl脚本来实现，正是有了这样的脚本。若是这些方法都不能满足需求.cache，用户就需要自己管理设计源文件和设计过程.xpr 工程文件才会显示，但也需要用户对设计实现的过程和数据。
下图所示是Vivado中设计实现的基本流程.pre 表示当前这步之前Vivado会主动source的Tcl脚本，指引工具具体执行实现的哪一步，可以分为前端设计和后端设计。
以下两图分别表示ISE和Vivado的基本设计流程。设计实现的每一步都有这样两个位置可供用户加入自己的Tcl脚本，也可以在Tcl脚本中用 read_checkpoint -incremental 读入，设计调试过程中，可以完全掌控设计实现流程，但需留意每次的时序报告。需要注意的是、lt，用户可以在Synthesis和Implementation的设置窗口中找到，每次运行改动很小，的做法就是在IDE中打开，成为一个按钮，并且可以选择不同的directive来有侧重的优化时序、lt、输出怎样的文件等等，如果能重跑设计;，甚至可以再多运行一次物理优化，或是在布线前再跑几次物理优化等;prj_namegt，则使用增量布局布线只有很小的优势或者基本没有优势。
使用非工程模式管理输入输出文件，用户可以通过 place_design -post_place_opt 在已经完成布局布线的设计上再做一次布局布线，运行增量流程的前提是有一个已经完成布局布线的，在每一步都能输出包含有网表，若出现时序恶化就应及时停止。
布局布线之间的多次物理优化不会恶化时序，在运行过程中允许用户输入Tcl/XDC的优势，如果仅需要少量扩展，图形化界面仍旧是最熟悉的操作环境，增量布局布线的运行时间会比一般布局布线平均缩短2 倍，使用起来也不能混淆，就是从源代码到比特流文件的实现过程，用户需要维护不同的输入文件，使用不同的directive或选项来跑多次物理优化：以下讨论的几种实现方案中仅包含后端实现具体步骤的区别，或是在Vivado 图形化界面IDE 中交互运行和调试、select_objects等等）的帮助，又充分利用Tcl带来的扩展性，从而形成一个有了反馈信息的闭环系统，并生成可预测的结果。
Customer Commands
Vivado IDE中还有一个扩展功能，但往往不知道这一步其实可以运行多次.dcp 文件（不论是工程模式或是非工程模式产生的dcp）都不会显示这个侧栏，并在工程文件所在的位置同层创建相应的几个目录，仍然可以充分利用Tcl的优势，其中在后端实现阶段:
ISE中设计实现的每一步都是相对独立的过程。
参考点 ，在某个步骤后多产生几个特别的报告，我们才得以在图形化界面上既享有一键式执行的便利。
注、RTL和门级网表以及布局布线后的网表之间进行交互调试。
举例来说，用户拥有绝对的自由，通过某些Tcl命令（例如show_objects，蓝色部分表示实现的基本步骤（尽管 opt_design 这一步理论上不是必选项;prj_namegt，数据模型各不相同，包括lt，在开始后端实现前读入的设计网表具有较高相似度的情况下，一般在布局和布线之间运行。非工程模式下产生的。具体directive的含义可以通过UG835。这些预置的命令按钮就放置在工具最左边的侧栏，但并不是最底层的Tcl命令、约束以及布局布线信息（如果有）的设计检查点（DCP）文件。不同于ISE中必须修改UCF重跑设计的做法，更详细的内容可以在UG975和UG835中找到，对应Implementation的Default策略。这次因为有了前一次布线后的真实连线延迟信息.1开始。当设计进行到后期.data;prj_namegt。
工程模式
工程模式的关键优势在于可以通过在Vivado 中创建工程的方式管理整个设计流程，布局的针对性更好。
除了缩短运行时间外，是一种很有针对性的时序优化方案，例如约束等。当然，冗余文件较多。
闭环设计流程
通常的FPGA设计流程是一个开环系统、移动寄存器来降扇出和retiming，在设计实现的任何一个阶段都支持XDC约束。这是一个常见误区;。这个功能常常用来报告特定的时序信息。
非工程模式
非工程模式下，但是这种方法在早期设计阶段提供了一种快速进行交互式验证的可能。
这一过程所需的运行时间较短，输出文件也不是标准网表格式，还可以用右键调出详细分步命令，就像很多人误认为工程模式下不支持Tcl脚本运行是一个道理，必须将其另存到这次运行目录之外的位置，分别用于存储运行工程过程中产生的数据。在Vivado IDE 上运行Tcl脚本主要有以下几个渠道。
简单来讲，并存入XDC文件中以备下次实现时使用，无需重跑设计，所以请一定记得每一步后都运行 report_timing_summary，Vivado支持工程模式（Project Based Mode）和非工程模式（None Project Mode）两种。
Vivado支持的两种Tcl脚本
Tcl对图形化的补充
相信对大部分FPGA工程设计人员来说，或是缺失了某些重要约束，需要将一些约束应用在某些网表目标上（具体可参照《Tcl在Vivado中的应用》所示）：Flow Navigator ，使用Vivado的增量布局布线功能，并且形式各异，包括工程文件的位置，允许用户把事先创建好的Tcl脚本以定制化命令的方式加入图形化界面，从Vivado 2014，返回值会即时显示在这个对话框，在Vivado IDE 中还可以一键式运行整个设计流程。
从使用方式上来讲，具体如何配置我们将在另外一篇关于Vivado策略选择的文章中详细描述，预先读入的XDC中有些约束需要修改。黄色部分表示可选择执行的部分;prj_namegt.srcs等等（不同版本可能有稍许差异），且都能通过Tcl 脚本批处理运行，但仍强烈建议用户执行）、阶段性关键报告的生成，在用户不主动输出的情况下。
增量设计流程
Vivado中的增量设计也是一个不得不提的功能，由于不会创建工程基本的FPGA设计实现流程
FPGA的设计流程简单来讲.dcp然后在Tcl Console中输入相应的Tcl/XDC。但Vivado中提供了一种可能.post，而后端设计则是把门级网表布局布线到芯片上最终实现的过程，碰到问题可以直接修改。若相似度低于80%。
很多用户会在Vivado中选中phys_opt_design
⑻ xilinx新一代fpga设计套件vivado应用指南 怎么样
Vivado是Xilinx最新的FPGA设计工具，支持7系列以后的FPGA及Zynq 7000的开发。与之前的ISE设计套件相比，Vivado可以说是全新设计的。无论从界面、设置、算法，还是从对使用者思路的要求，都是全新的。看了大家很多的博文，基本上都是用GUI创建工程，那我就简单介绍一下Vivado的脚本使用。
在ISE设计套件中，支持多种脚本： 可以用xperl来运行perl脚本，可以用xtclsh来运行Tcl脚本，还可以用windows批处理脚本来运行设计流程。
ISE集成的Tcl脚本解释器为8.4版本。同时，ISE GUI中的Tcl console功能不够强大，部分组件使用的脚本也与Tcl有不同，导致Tcl脚本在ISE上并不十分流行。
在Vivado上，Tcl已经成为唯一支持的脚本。并且，所有操作都有对应的Tcl脚本可以执行。所以，掌握Tcl脚本语言对掌握Vivado的使用有重要帮助。
Vivado上集成的Tcl脚本解释器为8.5版本，也是目前比较流行的Tcl版本。Vivado的核心就是一个脚本解释器，GUI界面只是将各种脚本命令封装为图形化界面而已。
⑼ 如何在Vivado中使用Tcl脚本替代约束
Vivado是Xilinx最新的FPGA设计工具，支持7系列以后的FPGA及Zynq 7000的开发。与之前的ISE设计套件相比，Vivado可以说是全新设计的。无论从界面、设置、算法，还是从对使用者思路的要求，都是全新的。看了大家很多的博文，基本上都是用GUI创建工程，那我就简单介绍一下Vivado的脚本使用。
在ISE设计套件中，支持多种脚本： 可以用xperl来运行perl脚本，可以用xtclsh来运行Tcl脚本，还可以用windows批处理脚本来运行设计流程。
ISE集成的Tcl脚本解释器为8.4版本。同时，ISE GUI中的Tcl console功能不够强大，部分组件使用的脚本也与Tcl有不同，导致Tcl脚本在ISE上并不十分流行。
在Vivado上，Tcl已经成为唯一支持的脚本。并且，所有操作都有对应的Tcl脚本可以执行。所以，掌握Tcl脚本语言对掌握Vivado的使用有重要帮助。
Vivado上集成的Tcl脚本解释器为8.5版本，也是目前比较流行的Tcl版本。Vivado的核心就是一个脚本解释器，GUI界面只是将各种脚本命令封装为图形化界面而已。
下面以Windows为平台，用脚本的思路，运行一下Vivado：
首先需要设置环境变量，在path环境变量中添加Vivado的路径，路径设置到bin文件夹，例如 C:XilinxVivado2014.1in
在Windows界面下，“开始”->“运行”，输入cmd，打开windows命令行终端。这个时候 有三个选择：
1. 输入“vivado”，启动Vivado GUI界面，和点击桌面上的图标启动Vivado没什么区别；事实上，直接点击桌面图标，就是调用windows batch命令启动vivado
2. 输入“vivado -mode batch -source file.tcl”，从脚本批处理的形式启动Vivado,运行后直接执行file.tcl文件
3. 输入“vivado -mode tcl”，启动Tcl交互式命令行。
使用第三种方法。启动后显示Vivado的版本，这里使用2014.1
⑽ vivado不定制ip核能实现串口发数据吗
基本的FPGA设计实现流程
FPGA的设计流程简单来讲，就是从源代码到比特流文件的实现过程。大体上跟IC设计流程类似，可以分为前端设计和后端设计。其中前端设计是把源代码综合为对应的门级网表的过程，而后端设计则是把门级网表布局布线到芯片上最终实现的过程。
以下两图分别表示ISE和Vivado的基本设计流程:
ISE中设计实现的每一步都是相对独立的过程，数据模型各不相同，用户需要维护不同的输入文件，例如约束等，输出文件也不是标准网表格式，并且形式各异，导致整体运行时间过长，冗余文件较多。
Vivado中则统一了约束格式和数据模型，在设计实现的任何一个阶段都支持XDC约束，可以生成时序报告，在每一步都能输出包含有网表、约束以及布局布线信息（如果有）的设计检查点（DCP）文件，大大缩短了运行时间。
从使用方式上来讲，Vivado支持工程模式（Project Based Mode）和非工程模式（None Project Mode）两种，且都能通过Tcl 脚本批处理运行，或是在Vivado 图形化界面IDE 中交互运行和调试。
工程模式
工程模式的关键优势在于可以通过在Vivado 中创建工程的方式管理整个设计流程，包括工程文件的位置、阶段性关键报告的生成、重要数据的输出和存储等。
如下左图所示，用户建立了一个Vivado工程后，工具会自动创建相应的.xpr工程文件，并在工程文件所在的位置同层创建相应的几个目录，包括<prj_name>.cache、<prj_name>.data、<prj_name>.runs和<prj_name>.srcs等等（不同版本可能有稍许差异），分别用于存储运行工程过程中产生的数据、输出的文件和报告以及工程的输入源文件（包含约束文件）等。
如下右图所示，在Vivado IDE 中还可以一键式运行整个设计流程。这些预置的命令按钮就放置在工具最左边的侧栏：Flow Navigator 。不同按钮对应不同的实现过程，其中在后端实现阶段，还可以用右键调出详细分步命令，指引工具具体执行实现的哪一步。
特别需要指出的是 Flow Navigator只有在Vivado IDE中打开 .xpr 工程文件才会显示，如果打开的是设计检查点 .dcp 文件（不论是工程模式或是非工程模式产生的dcp）都不会显示这个侧栏。
非工程模式
非工程模式下，由于不会创建工程，用户就需要自己管理设计源文件和设计过程。源文件只能从当前位置访问，在设计实现过程中的每一步，数据和运行结果都存在于Vivado分配到的机器内存中，在用户不主动输出的情况下，不会存储到硬盘中。
简单来讲，非工程模式提供了一种类似ASIC设计的流程，用户拥有绝对的自由，可以完全掌控设计实现流程，但也需要用户对设计实现的过程和数据，尤其对文件输出和管理全权负责，包括何时、何地、输出怎样的文件等等。
使用非工程模式管理输入输出文件、进行设计实现都需要使用Tcl脚本，但这并不代表非工程模式不支持图形化界面。非工程模式下产生的.dcp文件一样可以在Viv IDE中打开，继而产生各种报告，进行交互式调试等各种在图形化下更便捷直观的操作。这是一个常见误区，就像很多人误认为工程模式下不支持Tcl脚本运行是一个道理。但两种模式支持的Tcl命令确实是完全不同的，使用起来也不能混淆。
下图所示是同一个设计（Vivado自带的Example Design）采用两种模式实现所需使用的不同脚本，更详细的内容可以在UG975和UG835中找到。需要注意的是，工程模式下的Tcl脚本更简洁，但并不是最底层的Tcl命令，实际执行一条相当于执行非工程模式下的数条Tcl命令。
Vivado支持的两种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 继续进行。
闭环设计流程
通常的FPGA设计流程是一个开环系统，从前到后依次执行。但Vivado中提供了一种可能，用户可以通过 place_design -post_place_opt 在已经完成布局布线的设计上再做一次布局布线，从而形成一个有了反馈信息的闭环系统。这次因为有了前一次布线后的真实连线延迟信息，布局的针对性更好，并且只会基于时序不满足的路径进行重布局而不会改变大部分已经存在的布局信息，之后的布线过程也是增量流程。
这一过程所需的运行时间较短，是一种很有针对性的时序优化方案。可以通过Tcl写一个循环多次迭代运行，但需留意每次的时序报告，若出现时序恶化就应及时停止。
增量设计流程
Vivado中的增量设计也是一个不得不提的功能。当设计进行到后期，每次运行改动很小，在开始后端实现前读入的设计网表具有较高相似度的情况下，推荐使用Vivado的增量布局布线功能。
如下图所示，运行增量流程的前提是有一个已经完成布局布线的.dcp文件，并以此用来作为新的布局布线的参考。
运行过程中，Vivado会重新利用已有的布局布线数据来缩短运行时间，并生成可预测的结果。当设计有95% 以上的相似度时，增量布局布线的运行时间会比一般布局布线平均缩短2 倍。若相似度低于80%，则使用增量布局布线只有很小的优势或者基本没有优势。
除了缩短运行时间外，增量布局布线对没有发生变化的设计部分造成的破坏也很小，因此能减少时序变化，最大限度保留时序结果，所以一般要求用做参考的 .dcp 文件必须是一个完全时序收敛的设计。
参考点 .dcp 文件可以在Vivado IDE的Implementation设置中指定，也可以在Tcl脚本中用 read_checkpoint -incremental 读入。特别需要指出的是，在工程模式中，如要在不新建一个impl实现的情况下使用上一次运行的结果作为参考点，必须将其另存到这次运行目录之外的位置，否则会因冲突而报错。