第二折。上周的某一天，在我们这边，类似的现象“终于”也发生了。由于时差的关系，我们没能得到美国软
件工程师的及时支持。眼瞅着手上仅有的两个系统陷入瘫痪，工作不能继续，没办法，只能自己硬着头皮调试
一下看看。系统崩溃后，嵌入式Linux操作系统的响应异常缓慢，通过网络登陆无法进行调试和控制。幸好还
有串口调试台，通过串口可以看到系统反复打印出对总线上特定地址范围的数据写入失败。由于该现象发生在
FPGA文件下载完成后，我通过在系统启动后FPGA下载前杀掉相关进程的方法阻止了系统的崩溃：只要不下载
FPGA文件，或者替换为旧文件，系统就不会崩溃。

接下来，我试图找出FPGA引发系统崩溃的原因。中断信号引发系统崩溃的说法首先被排除了，原因是FPGA的
中断产生逻辑电路相当标准，不可能产生随机的错误行为。问题缩小到FPGA连接到CPU的双向数据总线上，
这里是除中断外唯一一个由FPGA驱动到CPU的逻辑电路。我的推论是，由于该FPGA工程没有对CPU相关的输
入输出引脚进行时序约束，两次编译会导致双向数据总线的输出使能信号的响应差异，这一差异进一步影响了
FPGA驱动双向数据总线的速度差异，在某些情况下，FPGA或早或晚地驱动了总线，引发了总线驱动冲突，导
致CPU对总线上其它设备的访问失败。经过对所有CPU相关的信号进行时序约束后，编译的二进制文件没有引
发系统崩溃。

通过RTL视图，我逐个定位了CPU相关引脚在RTL视图中的位置。修改特定LE的对外连接和内部逻辑关系，我把
所有可能驱动CPU的相关逻辑都关闭了：中断信号被禁止了，双向数据总线的使能被禁止了。我在不影响所有其
他逻辑的功能和时序特性的情况下，得到了一个完全不会驱动CPU总线相关信号的FPGA二进制文件。出乎意料的
是，该二进制文件下载后，系统依然崩溃。

本帖最后由 GoldSunMonkey 于 2011-11-28 15:13 编辑

到了这一步，我找遍了“路灯下所有能找的地方”，只能向其他方向“胡乱”摸索了。我尝试了给来自
CPU的控制输入信号，包括所有的地址线，增加上拉电阻的方法，也没有成功。

    经过了类似的一系列摸索，最终我在PlanAhead视图中发现了蹊跷：在该工程中竟然存在没有分配布局位
置的输出引脚，而这些输出引脚在该项目中并没有被实际的输入逻辑驱动，这些引脚被工具缺省地连接
到了逻辑“0”上。通过比较成功和失败两次编译结果中给出的最终引脚分配报告，我发现，这些没有得到
位置约束的引脚竟然可能随机出现在任意的空闲引脚上。
    通过进一步分析，在导致系统崩溃的编译结果中我最终找到了答案：一个没有逻辑驱动，也忘了分配布局
位置的输出引脚被工具随机分配到了FPGA没有用到（也没有位置约束）的一根CPU地址输入线上，这根地
址线就被短路到了“0”电平上，进而导致CPU外部总线上特定地址范围不能被CPU访问到，最终引发了系统崩溃。

通过这一问题的解决，我获得了以下几点认识：  
1. 没有约束位置的引脚是很危险的，尤其是输出引脚。随机分配的结果很可能是灾难性的。所以，PCB原理图
上的所有引脚，即使在FPGA内部没有被用到，也最好如实地加以约束。
2. PlanAhead工具可以为大家提供相应的内部链接的检查
3. FPGA EDITOR也能为大家找出内部逻辑的走线的检查和分析。
4. 为什么会存在未分配的输出和输入引脚？这是因为该工程还存在尚未实现的后期功能。这些引脚就是给以后
开发留下的，由于我们太专注于眼前要实现的功能而被忽视了。
5. 为什么会存在未用到，却实际连接了的地址线？这是PCB设计上的“冗余设计”。这样的冗余设计在该项目
中还有很多，有一些还真在关键时刻给了我们FPGA开发上的便利。
6. 既然上述两个问题都有合理的解释，为什么还会出现这么不合理的错误？原因之一是在PCB和FPGA设计上
缺乏完善的设计文档，PCB设计者的意图没有有效传达给FPGA设计者，而FPGA设计者之间也没能充分交流
原因之二是FPGA开发流程上缺乏被称之为“Peer Review”的设计评审和设计质量保证措施，一个显而易见
的
错误就被这样忽略并遗留了下来。