由程序调试引发的思考

                                            由程序调试引发的思考

        今天下午开始调试某个项目程序，遇到了2个简单的细节问题，造成时间和精力的浪费。

问题1：  抓取4路应答信号波形，只有其中两路返回了应答信号，对应信号被置为高电平，另外两路始终没有返回应答信号，即对应信号始终为低电平。

原因：  在前期进行程序调试时，我把另外两路应答信号在模块例化时，直接设置为低电平0，故出现上述原因。但是在发现这个原因时，我花费了好半天去查找该2路信号逻辑，因为在潜意识里，上述4路信号逻辑是完全相同的，所以百思不得其解。

 

问题2： 在用chipscope对第4路模块输出的最终结果进行在线观测时，发现输出结果始终为0，且输出使能一直为0，即输出没有被触发，而其他3路均有对应的结果输出，由于4路逻辑控制是完全一样的，故感觉问题出现的很奇怪。

原因：从4路信号时序对齐啊，第4路对应的fpga硬件电路啊等等其他方面查找，均无所获，最后发现是：第4路逻辑模块是复制第1路逻辑模块，有些地方忘了修改，造成第4路的输出信号本质上没有连接到chipscope对应的ILA核上，故始终没有抓到第4路的输出结果。

 

问题3： 今天在调试PCIe板卡（fpga为EP端）与PC端上位机通信时，已确认驱动安装正确，板卡能够识别。出现的问题现象为：每当我把fpga程序烧录完毕后，打开上位机软件，发现软件识别PCIe总线的链路速率和链路位宽均错误。我不烧录程序，单独打开上位机软件，则能够正确识别PCIe总线的链路速率和链路位宽均错误。这个问题也是困扰了我一个晚上。

原因：首先怀疑驱动安装有问题，卸载后重新尝试，发现该现象一直存在，且完全复现。于是怀疑fpga程序有误，造成的这个现象，但是这个程序是厂家的测试例程，经过厂家验证的，故排除该可能性。接着怀疑上位机软件是不是有问题，但是另一个同事则用该软件调试没有问题。最后分析到：程序下载后，是不是fpga端与PCIe端在链路协商握手方面存在什么先后关系，从而造成一下载程序，上位机软件就从能够正确识别链路信息编程识别错误。最后最后，就在fpga程序下载完毕后，首先禁用PCIe板卡设备，然后再次启用，这样相当于设备开启时，fpga此时已经加载程序，可以与上位机软件正确握手了。因为上位机软件是厂家提供的，不知道为什么会需要增加这样一个操作，这个操作也是经过N次不断试错，发现的一种解决方法，坑先留着，等到有一天自己能够解惑吧。

问题4：在进行模块例化时，各端口的互联信号一定要进行声明，尤其是信号位宽＞1。 否则，程序在进行仿真调试和编译时，该管脚会被综合工具默认设置为位宽是1bit，如果在仿真测试没有及时发现该隐藏bug，那么在板级调试时，很容易因为这个BUG造成不必要的调试错误。

例如某模块例化时，包含4bit位宽的端口 .layerindex(layerindex)，需要对该端口进行声明wire [3:0] layerindex，如果忘记声明，则默认layerindex为layerindex[0:0]，当你仿真只覆盖layerindex==1这种情况时，仿真结果没有问题。

但是当你在板级调试时，layerindex覆盖0~15各种情况时，就会造成错误，但是这种隐藏bug很难被发现，因为layerindex==1正确这种情况会给板级测试带来误导，造成问题定位分析困难。我亲自经历了这种错误，造成了3天痛苦的查找问题所在。

经验是：为避免问题4这种低级错误的一种有效方法为：一定要及时查看综合工具和仿真工具的warning提示，工具会及时提醒开发者对于低级错误的定位和尽早解决。

 

总结：  （1） 个人的粗心造成不必要的时间和精力的浪费，或者说粗心造成了更大的时间成本。

               （2）在遇到问题时，首先不要推测是复杂的原因造成的，而是直接从问题最直接相关的那一点开始查找验证。故

                         “遇到问题/事情，先往简单处着手”，不要直接给它复杂化，而是由简到繁，步步为营。  人生处世亦如此。