① vivado 的cpu利用率不高怎么破
设置里打开性能模式就行了
② 如何加快xcode编译速度
1. 增加XCode执行的线程数
可以根据自己Mac的性能，更改线程数设置5：defaults write com.apple.Xcode 5
另外也有一个设置可以开启：defaults write com.apple.dt.Xcode ShowBuildOperationDuration YES
XCode默认使用与CPU核数相同的线程来进行编译，但由于编译过程中的IO操作往往比CPU运算要多，因此适当的提升线程数可以在一定程度上加快编译速度。
2.将Debug Information Format改为DWARF
在工程对应Target的Build Settings中，找到Debug Information Format这一项，将Debug时的DWARF with dSYM file改为DWARF。
这一项设置的是是否将调试信息加入到可执行文件中，改为DWARF后，如果程序崩溃，将无法输出崩溃位置对应的函数堆栈，但由于Debug模式下可以在XCode中查看调试信息，所以改为DWARF影响并不大。这一项更改完之后，可以大幅提升编译速度。
比如在目前本人负责的项目中，由于依赖了多个Target，所以需要在每个Target的Debug Information Format设置为DWARF。顺便提一下，如果通过Cocoapod引入第三方则Debug Information Format默认就是设置为DWARF的。
SDWebImage通过Cocoapod``Debug Information Format的默认设置
注意：将Debug Information Format改为DWARF之后，会导致在Debug窗口无法查看相关类类型的成员变量的值。当需要查看这些值时，可以将Debug Information Format改回DWARF with dSYM file，clean（必须）之后重新编译即可。
3.将Build Active Architecture Only改为Yes
在工程对应Target的Build Settings中，找到Build Active Architecture Only这一项，将Debug时的NO改为Yes。
664334-fa1eb995c140ce0f.png
这一项设置的是是否仅编译当前架构的版本，如果为NO，会编译所有架构的版本。需要注意的是，此选项在Release模式下必须为NO`，否则发布的ipa在部分设备上将不能运行。这一项更改完之后，可以显着提高编译速度。
4.设计编译优化等级
不要再项目中或者静态库中使用-O4，因为这会让Clang链接Link Time Optimizations (LTO)使得编译更慢，通常使用-O3。
注意：在设置编译优化之后，XCode断点和调试信息会不正常，所以一般静态库或者其他Target这样设置。
4.资源整合
4.1 将常用的代码及文件打包成静态库
4.2 添加预编译文件，把常用的头文件放到预编译文件里面
4.3 能用@class就用@class
③ vivado怎么看设计最小周期
很高兴告诉你！
自从去年10月Xilinx发布ISE147之后，ISE套件便暂时没有了更新计划，相当于进入了软件生命中的“中年”；而当初在2012x版本还作为ISE套件中的一个组件的Vivado，此时已经如早上8、9点钟的太阳一样冉冉升起：因为随着FPGA/SOC制造工艺、硬件单规模和设计方法的不断改进，传统的基于ISE的设计方法已经逐渐不能满足我们的要求了。所以针对新的Artix-7/Kintex-7/Virtex-7芯片，Xilinx都建议我们使用全新设计的Vivado套件来进行开发（使用Spartan-6的筒子可以在新设计中考虑向Artix-7过渡了）。此外，因为ISE套件已经没有升级计划表，所以对新的作系统也无法支持了，例如在Win8/81上面，ISE147几乎无法完美运行，而从Vivado20141版本就开始全面支持了。
直观的来看，我理解的Vivado套件，相当于把ISE、ISim、XPS、PlanAhead、ChipScope和iMPACT等多个独立的套件集合在一个Vivado设计环境中，在这个集合的设计流程下，不同的设计阶段我们采用不同的工具来完成，此时Vivado可以自动变化菜单、工具栏，可以显着提高效率：因为不需要在多个软件间来回切换、调用，白白浪大量的时间。基于Vivado IP集成器（IPI），则把我们对硬件的配置更好地集成到我们的设计中，既极大地提高了对IP的使用和管理，也帮助我们减小了软件和硬件（例如ZYNQ器件的PS）之间的隔阂。Vivado HLS则可以把现有的C代码，在一些特定的规范下直接转换为可综合的逻辑，这也将极大地提高我们实现和移植现有算法的速度。
因为Vivado套件较为复杂，所以先用一个对比测试，来检验一下它们之间的性能差别。采用的测试环境是：
作系统：win7 sp1x64
CPU：I7-4770k，开启超线程，全部超频至43GHz
ISE： 147
Vivado：20141
使用的芯片：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 generalmaxThreads 8
这样就可以分发挥最大的CPU潜力了（例如DRC检查可以使用全部的线程进行并行作）。然后运行产生比特流的作，开始时间是8：15：20，生成bit文件的时间是8：17：12，共花了112秒。
对比ISE的231秒，可以看出Vivado使用的时间只有ISE的485%。俗话说，“时间就是金”，“效率就是生命”，Vivado只用了不到ISE一半的时间就完成了这个复杂工程的全部实现过程，数据非常有说服力。当然Vivado使用的内存貌似比ISE多了几百MB，但是对于现在配置中等的机器都可以达到8GB内存的情况下，这点内存的差距还是可以忽略的。（好马配好鞍，电脑的这点投资和高端的芯片带来的性能提升和time-to-market减小相
④ 如何提高ISE的编译速度
如果你的cpu够强你应该学会如何利用好它来加速你的代码编译速度，那么你怎么才能够最大限度让你的cpu发烧呢？
下面是一个对比：
比如我的cpu是i7 3770k，
编译cocos2d-x的libcocos2d工程：
不优化：
1>Time Elapsed 00:01:35.25
优化后：
1>Time Elapsed 00:00:21.66
效果显着！！！
参考网页：
Visual Studio 2010中C++并行构建调优(1)
http://developer.51cto.com/art/201003/189235.htm
1>cl : Command line warning D9030: '/Gm' is incompatible with multiprocessing; ignoring /MP switch
解决办法是：
Properties -> Configuration Properties -> C/C++ -> Code Generation -> Enable Minimal Rebuild -> No(/Gm-)
Properties -> Configuration Properties -> C/C++ -> Geneal -> Multi-processor Compilation -> Yes(/MP)
一些含义和拓展资料：
Enable minimal rebuild
通过保存关联信息到.IDB文件，使编译器只对最新类定义改动过的源文件进行重编译，提高编译速度
Enable Incremental Compilation
同样通过.IDB文件保存的信息，只重编译最新改动过的函数
/MP (Build with Multiple Processes)
http://msdn.microsoft.com/en-us/library/bb385193.aspx
/Gm (Enable Minimal Rebuild)
http://msdn.microsoft.com/en-us/library/kfz8ad09.aspx
⑤ xilinx ise 编译的过程支持多线程么
是下载线是USB的还是并口的？ 若是USB的，如果开发板和下载线都没问题，下载配置也没问题，则可能是USB驱动的问题，如果刚装过其他版本的ISE则可能导致上述问题，最简单的方法就是卸载后重装ISE。 还有可能是开发板上的跳线没搞对，下载模式的问题
⑥ 如何在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的效率提高到底有多少
自从去年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完全不具备的。