哈哈。你一定不知道debug的最高境界是什么，是猜。对于总工程超过五十万行，内部代码上万行的模块，丢到FPGA上跑是不可能有波形看的，只能抓debug信号，通常要看的信号太多，debug接口太少会耗费大量时间进行迭代，逻辑分析仪的操作也很耗时，而且很多信号不在debug接口上，没法看。有时候想用chipscope看，需要编多版bit，每编一版大半天就过去了。所以对于极难调试的问题，一般就靠猜，猜准了再抓。一般来讲，拿FPGA跑，上来20秒内挂掉的都是比较明显的bug，成因不会很复杂，容易解决，真正怕的是那种跑几十分钟或者几小时没事，然后挂掉的。我昨天刚经经历这个过程。我们在用FPGA测SSD读写的heavy loading，开十个线程同时对flash进行读写，然后比较读出来的结果和写进去的结果，结果发现跑半个小时没事，但是此后大约几分钟，传到1KB对齐的末尾地址的时候，有可能会错几个byte，我当时由这个现象，根据对design的了解，开始有了某些怀疑方向，然后就开始想象，各个模块访问我的模块之间是如何交互，在何种情况下可能出现这种错误，想了半天想到在某种极其巧合的情况下可能会存在访问冲突，导致出错，这种冲突只有几个周期的时钟窗口，必须周边的模块恰巧都在那时候按照一定的顺序动作才会出现，于是让firmware临时修改了一个寄存器的配置，果然再跑就没有问题了，接着开始修改design。前几天还是调FPGA，测试power mode，每两秒钟就会进一次睡眠然后再恢复传数据，跑二十多分钟会出现进低功耗出不来，当时我用逻辑分析仪抓了几个状态机，看完之后大概明白了现象，然后就开始看 code，发现一个复位信号可能导致出错，然后一跟踪，发展这个复位居然有七八个源，而且每个源又有五六层逻辑。当时就根据code一点点推断，由于没有波形，所以很多信号是0是1就靠猜和推断，最后我们锁定了一个信号，这个信号没有引出到debug接口，所以编了版bit，用chipscope抓，一看果然是它。hack了一下之后，跑了一晚上没有出错，而且还抓到了一个华硕主机板的bug。这种方法，说起来还是受到我们team leader的启发，他负责的code有八万行以上，因为design太大，所以没有定位之前就抓基本无益，再加上这些design经过的验证不少，相对简单的bug早就修干净了，所以一出问题他就会先猜，好几回都让他直接命中。
