工作以来,学到的最有用的调试方法就是:锲而不舍,一条路走到底。(马老师) riple
学到的最有用的调试格言就是:“三心:细心、耐心和责任心”。(库哥) riple
我采用signaltap的通常步骤是: riple
1. 勘查现场。bug通常不是系统停顿的直接原因;bug发生时,系统按照正常的协议运行,直到走入死胡同,表现为停顿或异常。虽然此时的系统状态不是bug本身,但是这是我们查找bug的唯一可靠线索。当然,如果能通过分析代码确定bug的位置会更省力。我在分析不了众多的并行事件时才会求助于signaltap。 riple
需要观察的系统状态包括:与故障相关的FPGA IO引脚,与故障相关的状态机状态(在这一步不建议引入状态机的输入信号,即使你怀疑哪些输入信号有问题,也最好假装不知道)。 riple
这一步一定要沉住气,一次就可以把所有的异常状态确定下来。 riple
2. 顺藤摸瓜。查到了系统的停顿状态(状态机的状态值)或异常的表现(IO取值异常),就要按照状态机的跳转顺序或IO输出的驱动逻辑,逆向设置触发条件,确认在哪个状态、什么样的输入条件导致状态跳转错误或怎样的逻辑组合导致输出异常。 riple
这一步需要综合捕获的波形和对应的HDL代码才能有效地设置触发条件。这时引入状态机的输入信号和组合逻辑的驱动信号才更有效。 riple
在这个顺藤摸瓜的过程中,会逐步发现某些异常现象。由于FPGA的资源有限,不能设置过大的存储深度,想要同时看到异常的原因和结果是很困难的。举个例子,用50MHz的时钟作为采样时钟,相邻两个采样点的时间间隔是20ns,如果存储深度设为256点的话,一次循环采样可以观察到的时间间隔是5us,对于FPGA本身来说是够了,如果系统中还有其他反应较慢的器件(比如较慢的CPU),这样的观察时间是不够的。这时就需要利用各种触发方式和综合各种触发条件(比如多设一级触发深度)。(以后我会给出signaltap设置选项的用法和用处) riple
这一步是发挥调试人员聪明才智的一步。 riple
3. 设置陷阱,守株待兔。随着离bug作案的时间越来越近,幸运的话,可能已经看到bug在手舞足蹈了。在这一步,一定要通过设置触发条件把bug每次作案的照片(波形)都拍下来。合理的触发条件可以保证每一次抓到的波形都是bug作案的真实写照。 riple
这一步很关键,如果不能抓到bug作案的快照,就不能定位bug。没有证据就下结论是很危险的,可能前功尽弃。 riple
每到这个时候,我就把自己想象成一个戴着皮帽,穿着翻毛皮袄,腰插烟袋杆儿的猎人,在雪地里蹲了三天三夜,正眼看着猎物一步一步走进自己设置的陷阱。 riple
4. 亡羊补牢。捉到了bug,就该处理它了。是自己模块的问题,就要闭门思过了;是外部的问题,就可以兴师问罪了。 riple
用户377235 2013-5-14 21:52
用户1265970 2013-3-27 23:57
ash_riple_768180695 2008-10-6 21:05
用户186686 2008-10-5 21:48
ash_riple_768180695 2008-7-13 18:49
用户131284 2008-7-11 11:15
用户131284 2008-7-11 11:07
用户1124019 2008-4-3 10:08
ash_riple_768180695 2007-12-14 09:31
使用signaltapII需要有硬件电路板和下载电缆,还要PLD器件支持,所以有机会使用的人少了许多。我也是工作后才有机会用起来的,这是我们最常用的调试工具。
用户119502 2007-12-14 08:58