原创 资源受限--使用signaltapII调试FPGA设计中的bug

    FPGA的资源是有限的。 riple

    设计已经占用了可观的资源（%的LE，%的MB），signaltap还要和设计抢占资源。“抢占”在这里是很贴切的，既包括抢占LE、MB，还包括布局资源和布线资源。我把“抢占”造成的影响叫做“测不准原理”。这一原理是贯穿signaltap调试始终的一条基本原理。一句话来说，就是“对信号的观察会引入对信号的影响”。 riple

    这些影响绝大部分表现不出来，或者是我没有刻意去观察；但是表现出来的影响是原有的设计功能发生了变化。有的变化是原有的bug不出现了（这应该看作是坏的变化），有的变化是新的bug出现了。 riple

    据我分析，造成这些影响的可能原因有以下几个： riple

1. 
   
2. signaltap工具本身存在bug。这一点我无法证实，只是猜想。signaltap的原理是在设计的网表中插入触发逻辑和存储逻辑以及用于和PC机通讯的虚拟JTAG链路实现嵌入式逻辑分析仪功能的。这一插入过程是由QUARTUS软件完成的，对用户是不可见的。由于用户无法控制和约束这一过程，加入signaltap后的电路功能与用户设计初衷相违背也是可能的。  riple
   
3. 被观察的信号扇出变大，造成设计的时序余量发生变化。实现触发逻辑需要在信号路径上加入触发器和组合逻辑，这样一来必然造成被观察信号的扇出变大，信号的输出延时增大。如果被观察信号的时序很紧张的话，加大信号的延时可能使时序关系变好（原有的bug不出现了），也可能恶化其时序（bug出现得频繁了或新的bug出现了）。  riple
   
4. 由于“抢占”的存在，造成设计的时序余量发生变化。由于触发逻辑和存储逻辑的加入，FPGA的资源要重新分配。原设计在FPGA内的布局位置和布线资源会发生变化，时序也会受到影响。往往加入signaltap后，布局布线后的时序分析结果会比原来差。 riple

    我解决上述矛盾的方法是尽可能少地添加被观察信号。我常用的几个方法是： riple

1. 
   
2. 在每次重新编译之前，对信号的保留做一个评估，如果被观察信号被证明与要查找的问题无关，就删除这个信号。  riple
   
3. 在每次编译成功之后，要查看编译报告，如果系统的逻辑资源利用比例在95%以上，就要考虑去除一些被观察信号或去除几个触发级别，或者减小采样深度。 riple 
   
4. 如果有必要的话，把仅需要作为触发条件的信号的采样使能关闭也能显著减少逻辑资源的占用。  riple
   
5. 系统存储资源的占用比例也要考虑在内，不可占用太多。与此相关的选项是采样深度、信号个数、信号的采样使能是否关闭。  riple
   
6. 编译成功后，要查看时序分析报告。如果系统时序下降很大或者被观察信号的时序不能满足，要考虑采用上面的方法减少对逻辑资源的占用。 riple

    另外，采样时钟的选择对系统的整体时序影响也很大。选取的原则是： riple

1. 
   
2. 尽可能从设计的顶层选择信号作为采样时钟，而不是随便把哪个module的输入时钟作为采样时钟，以利于QUARTUS优化全局时钟资源的利用。 riple 
   
3. 在保证观察精度的前提下，选择较低频率的时钟。  riple
   
4. 采样时钟本质上是触发条件之一（最基本的触发条件），如果恰当的选取非时钟信号（没有确定频率的信号）作为采样时钟，可以起到事半功倍的效果。 riple