原创 一个上拉电阻的故事－２.　胶着的巷战

将样机交给软件组后，我已经松了口气。按照已经测试的状态，我估计最多三五天就会有结果。我已经把注意力转移到手边的另一个项目上去了。

部门经理克丝蒂对这个项目并未多问。我过去的每个项目她都参与过。对我的情况很了解。所以她显得很放心。

两三天过去，软件那边没有什么消息。我觉得有些奇怪，去打听也被告知有进展，但还有问题。

又过去几天，没等我问，负责软件的哥们儿找我来了，带来的却不是好消息。

据他讲，一个奇怪的现象让他困惑：系统现在已经可以对ASIC进行读写。手动单步操作时结果也都正常。但是一旦以批量处理的方式读出数据，虽然数据可以出来，结果也都正确，但却总是慢两拍：第一个读命令的结果，要到发第三个读命令时才返回来。

换句话说：早上我在公司打电话订的早餐，到了晚饭时才给送来。我是吃还是不吃？　晚到的早餐还可以放冰箱里，赶明儿再吃。晚来的数据可没地儿交代，我这儿没冰箱，过时不候啊！那能把一顿饭耽误两个饭点儿得不少活儿那，我这FPGA没这么大的道行啊！

开始我以为是他用的板子有毛病。可是换了几个板子情况都一样。又在模拟的环境下反复核对了结果，仍然没有发现任何问题。

这事儿进入了一个怪圈：当你试图去检查测试这个故障时，不论你怎么折腾，结果都是正确的。可当你把它置于正常运行状态时，不论你用什么办法，问题总是在那。

邪了门儿了！

软件的那个哥们也没辙了：“这送餐的说不定在路上哪儿堵车给耽误了。要不，咱晚点儿下班，多等会儿？”

他的意思是，在他的读操作里，加上两个周期的延迟，以便能和返回的数据对上。但是，问题是我们现在根本不清楚造成这种现象的原因。你现在加上两个周期，哪天它想不开又给你变成三个了，你怎么办？总不能追着屁股后面跟着改吧！

再说，那也不叫个活儿呀。

我坚持认为，是软件里有问题。如果硬件有问题，在测试平台上怎么都正常？在系统中手动操作怎么也正常？

然而，试着用了几种方法，还是不能发现软件哪有什么不对。

。。。

时间已经过去了好几天，还是毫无头绪。我开始有些不耐烦，和软件的哥们儿商量时也不太客气了:

“这个寄存器要先写后读，你是这么做的吗？“

“这组寄存器的地址边界被设在xxxx, 不会弄错吧？“

“返回的数据是按照协议的规定重新组合的吗？会不会哪反了？“

，，，

搞软件的那个哥们儿脾气好，对我这些有理没理的质问都没有辩解，只是一遍又一遍地检查，反复试各种方法验证。。。

仍是不见一丝曙光！

我的感觉好像是走夜路的人迎面碰上了一簇鬼火，在我面前晃来晃去躲不开。可要是伸手去打，却死活够不着。

克丝蒂有点儿沉不住气了。按照以往经验，早该有戏了。即使不成，也应该知道问题在哪，着手解决了。她开始一次又一次地询问情况。虽然没有催促，但显然不像开始时那样沉着了．

“I just got a call from San Jose,… xxx asked about this …”　她说。上一级的主管在San Jose. 他打电话来问，肯定也知道了事情进行的不顺利。

头上的压力越来越大，我开始有些乱了章法了。

原本信心满满，想速战速决，没想到是今天这个局面。

，，，

期望中痛快淋漓的歼灭战没有出现。闪击不成，却进入了残酷无比，胶着的巷战，一步步的顶牛。在我面前横着的，好像是格罗尼兹血染的街道，四平街那座撒满黄豆的天桥。。。更可怕是此时的攻击已经失去了明确的目标。四面都是敌人，却无从下手，举步维艰。

时间一分一秒的过去，局势却不见丝毫的改观。。。

打僵了！