|
- UID
- 824598
|
在板子上，FPGA与ASIC之间的是以“异步”方式工作。双方一问一答。前面问的事有了答复，才接着问下一件事。过期不答，就要中断报警。对FPGA发来的每一个读写要求，ASIC都应该发回一个应答信号（ACK）。正常的ACK应该是一个负脉冲，宽度为一个时钟周期。可是我现在看到的却是另一番奇怪的情景：ACK脉冲迅速降到低电平，一个时钟周期后，却没有跳回到高电平，而是循着一条漫长的RC充电曲线返回，远远看去成了一个锯齿波。
难怪FPGA读出的数据要慢几拍！
FPGA在检测到ACK信号的负跳变后，就进入等待状态。一旦ACK回到高电平，就开始按规定的时序发送或读取数据。现在ACK产生了负跳变，却迟迟没有返回。FPGA则就像苏文茂的相声里说的那个老头儿，痴痴地等着楼上掉下的第二只靴子，却一直没有动静。老头儿没听到靴子响不敢睡觉，FPGA没看到期待中的高电平，也不敢造次，不能进行下一步的操作，被“干”在这儿了！
严格地说，FPGA楼上的第二只靴子还是掉下来了，只是晚了些。因为ACK电平的恢复虽然慢，但毕竟还是回来了。鬼使神差的是这个恢复时间并没有超过规定的时间间隔，所以FPGA也没把它按“超时”处理，产生中断。
“哥们儿不就是晚来了一会儿吗，你还动真格的？真要打９１１报警呀！”
“但你可是把我坑苦了！你不是有上拉电阻吗？怎么还这么磨磨蹭蹭的！”
这个ACK信号线上是应该有一个上拉电阻的。在ASIC一旦放弃对它的低电平驱动后，电源会经过这个上拉电阻对其快速充电，使之回到高电平。如果没有它，这个充电过程就要经过其它回路，其时间常数要远大于正常情况。所看到的结果就是这个德行。由于ACK的恢复周期拉长，返回的数据也就姗姗来迟。而测试平台只是进行功能检查，读写的速度要远低于实际系统的情况，对这种延迟不敏感。在系统中进行手动读写时，因为是手敲命令，更慢，当然也发现不了。
莫非我记错了？再翻ASIC的技术文件，没错呀！上面明明白白写着ACK输出端内部有上拉电阻啊！难道是做ASIC的那帮小子偷工减料？我得找他们！
ASIC的总体负责人叫戴维。他也是当年S公司留下来的几只大鸟之一。戴维和电影里的那个骑着扫帚乱飞的小男孩是一个地方的人。却没有印象中那儿的人的刻板。为人很热情幽默。据他说，当初离开那儿来这儿，就是因为受不了那里的沉闷和拘束。尤其痛恨的就是动不动就要西装革履打领带。现在除了说话还是舌头根儿发硬的哈利波特味儿，与其他人别无两样。
我风风火火地找到他：
“您老人家在那个ACK管脚上到底放没放上拉电阻啊？”
“哦，我得查查。。。” 他倒是不着急。
过了一会他来到我这儿，靠着墙不紧不慢地说：
“我们的确有一个上拉电阻在那。。。”
“噢。。。”
“不过。。。”
“什么？”
“。。。那个电阻有效时间只有一个时钟周期。。。”
“嘛玩意儿？一个时钟周期？！您老这是嘛路子？”
。。。
费了好大的劲，我才从戴维的解释中明白点儿意思。
这个ASIC是由C公司自己设计的，但生产却要由IBM代工。就是现在那些“Fabless”公司常见的做法。要由别家公司代工，芯片的设计在一定程度上就要迁就代工公司的工艺要求，还要在性能和成本之间折中。在芯片内部，电阻实际上都是由处于各种状态的CMOS单元构成。ACK这个信号所处位置，要构成一个完全意义上的上拉电阻有些困难。于是就因陋就简用了一个逻辑代替，而且只在ACK处于低电平的状态下开通，以确保能出现一个负跳变。剩下的他们觉得无关紧要，不影响其他性能，因为很容易在板子上弥补。
所以说，技术文件上说有上拉电阻并没错，不过嘛。。。
听了这些，我不禁仰天长叹：这可真是IBM做的片子，真有大爷的风范！只管一个时钟周期，到点儿拍屁股走人。留下一个烂摊子要我来收拾。
到现在，原因已经彻底清楚了：区区一个电阻的事！因为它只有效一个时钟周期，驱动过后，ASIC的ACK端子就成了开路状态，只能靠FPGA一头的输入端一点儿微小的漏电流充电。等它再回到高电平，黄花菜都凉了！
想我半世“英名“，在这行儿里混迹多年，也算个吃过见过的主儿。没想到今天栽在一个不起眼的上拉电阻手里！天理何在？！
现在，楼上的那只靴子倒是掉下来了，可我还能睡吗？ |
|
