dsp死掉重启后还是不行

可能是堆栈溢出、数组溢出、访问指向空地址的指针未声明的函数调用跑飞等原因。

1、堆栈溢出：以TI CCS3.3为例，程序运行的堆与栈的空间大小都是由软件设计师自己定义分配大小的。一般出现问题就是为DSP软件运行设置的堆或栈的空间太小，而导致程序不能正常运行。堆或栈空间太小编译生成out文件时，是不会报错的。TI ccs3.3中Stack Size是0x400(即默认的配置)，Heap Size是0x200（即默认配置）。如果程序出现莫名的跑飞情况可以试试改改这两个参数值。

2、数组溢出：数组溢出就是定义数组的空间大小，而通过数组下表访问时，下标超过了数组的边界，这样可能改写其他地址的数据，造成程序跑飞。有可能是使用未初始化的变量作为下标方位数组（这种情况编译器通常会有warning提示）；还有可能是通过计算关系计算下标，而在异常的情况下下标会越界（应用下标前对下标的范围进行判定，正常后再使用）。

3、访问指向空地址的指针：访问未初始化的空指针也可能出现DSP跑飞的情况；或者将指针作为函数参数传递时，指针未指向具体的地址，而在函数中使用，可能出现死机的情况（也可能不会，在ccs3.3下）。这些“指针未初始化”或“指针未指向具体变量”的问题编译器不会提示错误，最多提示警告。而“指针未指向具体变量”作为函数参数传递，在VC2005中，编译时不会报错，但有警告，但是在debug状态下运行时直接就跑死了，也算是暴露问题了。

4、未声明的函数调用跑飞：在TI ccs3.3中一些函数没有显式声明，而直接调用可能达不到函数预期的效果或者就是跑飞。以前写过一个CCS环境下因printf函数跑飞的问题。其实未声明函数调用，在zynq的开发平台vivado的SDK中也出现过，编译不报错，运行就是达不到预期的效果。

自从去年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完全不具备的。

---