quartus中的signaltapⅡ 的问题

问题描述：在一次调试中发现这样的问题，用signaltapⅡ观察4个信号，结果正确，若再加一路观察信号，则时序中有错误。好像是signaltapⅡ对原来的逻辑造成了影响，又或者是signaltapⅡ采样出来并传上电脑来的数据出错。在网上搜索了一下，这方面的资料。

    另外，通过对这方面内容的了解之后，接触到这样一个词汇：增量编译（incremental compilation）如果能好好利用quartus的这个功能，那么将在一定程度上解决FPGA设计中编译太慢的问题。所以这个问题可以深入研究。在网上收到一篇altera关于这方面的文档《Quartus Ⅱ Incremental compilation for hierarchical and team-based design》好像是Quartus手册中的某一章。因为现在其中大部分我都用不到，并没有做仔细研究，只是看了其中的<Debugging Incrementally With the SignalTap ⅡLogic Analyzer>这一小节。总结一下，使用增量编译SignalTap ⅡLogic Analyzer的步骤，即在加入并编译SignalTap ⅡLogic Analyzer时保持原来综合的布局布线结果不变的方法。这有几个处：1、SignalTap ⅡLogic Analy观察信号进行调试时，和不使用SignalTap ⅡLogic Analyzer时的逻辑是一样的，即你调试的逻辑和最终使用的逻辑的一样的。2、当设计较大时，在需要改变SignalTap ⅡLogic Analyzer的设置时，可只编译SignalTap Ⅱ这样就节约了时间。

    步骤：1、在assign->design partitions window中将当前工程的netlist type 设置为post-fit.

          2、全编译。

          3、在SignalTap Ⅱ的Node Finder中利用post-fitting滤波器添加要观察的信号。

另外也可以使用settings->compilation process settings 中的smart compilation（参考《flat compilation flow with no design partitions》小节）

 

 

 

下面贴出我在网上粘贴过来的文字：

原文地址http://blog.ednchina.com/riple/4065/message.aspx

 

 

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

 

 

    FPGA的资源是有限的。 riple

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

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

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

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

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

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

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

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

 

 

riple

2009/8/2 8:35:33

我对这个问题的看法是：增量编译是建立在Design Partition技术的基础之上的。Design Partition的目标是：源代码和约束没有变化的Partition是不需要重新编译和布局布线的。SignalTapII作为一个 Partition，由于其要观察的信号数量发生了变化，其重新编译和布局布线是不可避免的；但是设计的其他部分，作为被观察对象，是不需要重新编译和布局布线的，这样就有效地缩短了编译时间，并保持了原有设计的时序特性。SignalTapII的观察对象，可以有综合前、综合后、布局布线后三种基本网表，每一种网表由于其优化力度不同，其可被观察的信号数量和信号名称都是不同的。在包含SignalTapII的增量编译过程中，对布局布线后的网表中包含的信号进行观察是不需要对被观察的设计部分进行重新编译的，只有这样才能最大地发挥增量编译的效果；如果对其他两种网表进行观察，由于某些信号在布局布线过程中被优化掉了，要观察它们，势必要对被观察部分的设计重新进行布局布线并在布局布线过程中对这些原本被优化掉的信号加以保留，这样一来，增量编译就退化成了全编译，失去了增量编译的优势。不知道我说明白了没有？

 

codeman

2009/7/31 21:13:41

还有，请教ripple一个问题，为什么打开cremental compilation后，signaltap中增加节点会默认为 post-fitting filter.有关文章是这么说的： Once your design is set up to use full incremental compilation, the SignalTap II Logic Analyzer acts as its own separate design partition. You can begin taking advantage of incremental compilation by using the SignalTap II: post-fitting filter in the Node Finder to add signals for logic analysis. 似乎这么说解释不通阿

 

codeman

2009/7/31 21:08:58

最近也遇到了这个问题摘录一段话： Incremental compilation enables you to preserve the synthesis and fitting results of your original design and add the SignalTap II Logic Analyzer to your design without recompiling your original source code. This feature is also useful when you want to modify the configuration of the .stp file. For example, you can modify the buffer sample depth or memory type without performing a full compilation after the change is made. Only the SignalTap II Logic Analyzer, configured as its own design partition, must be recompiled to reflect the changes. ps，can't find the instance这个错误也遇到过，当时用的方法相当土，直接重新编译。真土

 

 

songchao01

2008/7/30 13:04:33

对于SignalTap的这一点我也深有感触！有时候只是去掉几个观测信号，结果程序工作就不正常了。现在对这种内嵌的调试手段十分怀疑，增加了不确定因素。不知道altera有没有解决这一问题的方法？听说logic lock约束有效果，riple你用过么

 

 

candela

2008/1/13 11:25:16

 

关于“测不准原理”，最近刚好碰到一个bug和其相关，记录在此全当是看了博主文章后的实践心得吧：

写了一个发包模块，因考虑到外用逻辑分析仪的引脚设置起来太麻烦，所以采用signaltapII，调试了5次之后终于发包正确了，自认为没问题了就打了个包存档，还跟老大汇报说OK了。结果集成到他的工程以后发现发的包是错的，我又回头看我的工程发的包明明是没问题的。搞了半天发现，我还是带着signaltapII测的，忽然想起楼主说的“测不准原理”，于是去掉signaltapII编译果然发的包是错的，重新加上signaltapII编译后又是好的，而且看里面的波形也看不到哪里逻辑有问题。

折腾了很久，最后的解决办法是：将编译选项的full ncremental complation给off掉，去掉sigaltapII编译后测发包，是错误的。然后加上signaltapII再编译，这时发包还是错误的了。好，带着signaltapII编译的情况下bug也出现了!接下来的事情就好办了，这时signaltapII抓出来的波形里面已经暴露出明显的逻辑错误了，改代码，编译，发包测试OK。然后再去掉signaltapII，再测，还是OK。于是这才算是真正OK了。

总结起来就是楼主说的几种情况之一：加了signaltapII后bug不出现了。希望其他兄弟引以为鉴，千万不要忘了去掉signaltapII再测试一遍！

至于为什么将编译选项的full ncremental complation给off掉后编译结果就比较真实，原因我还不太清楚，初步猜想可能是：不off掉的话是增量编译，不如完整编译的结果好，在此基础上添加的siganltapII的结果也不完全可信；一旦完整译过一次之后，内部逻辑和节点数据库都是可信的，那么在此基础上添加的siganltapII的可信度也会更高。以后如果找到针对于此的altera文档我在贴上来吧，兄弟们如果实在没办法的话可以用我这个土办法试一试。