如果说那次捉鬼是一次过关斩将的胜利,那这次电阻的事可算得上败走麦城了。前者是在毫无准备遭受突然袭击的情况下所取得的胜利,而后者,却是在有着充分准备的情况下的“惨胜”,虽胜犹败。
关云长败走麦城,最后丢掉了性命。一个工程师失败一次却未必是坏事,它有可能成为下一个成功的开始。都说人不能“记吃不记打”,就是说要懂得接受教训。那这次的教训是什么呢?
1. 别被现象牵着鼻子走
一个工程设计可能会出现各种问题。我们在试图解决问题时总是从它的表面现象开始,希望由现象分析出原因。正是这个过程,容易让人进入一个误区,就是往往从现象的复杂程度来断定原因的复杂程度。在这种意识的引导下,常常会作出相反的判断。比如说,看到系统的状态不稳定,就会本能地想到是不是哪部分的参数不稳定造成的。而由此引发的处理方法,很可能就是想:是不是应该把什么地方“调一调”? 虽然说有的故障的确是这种问题,但在目前很多情况下,并非如此。
当今电子工业中的元器件水平已经远非二三十年前可比。无论是有源还是无源器件性能都已相当稳定。只要你的设计不是错的太离谱,基本的工作性能都是可以保证的。而如果出现了不正常的状态,很多情况下都是由于器件使用不当造成的。换句话说,那些看似“忽好忽坏”的“软故障”,很多时候只是由那些“少装了个电阻”,“设置错了电平”之类的“硬性错误”所导致的。这在数字系统中尤其典型。别忘了,数字系统只认‘1’和‘0’,黑白分明。可你要把它置于一个‘1’‘0’不分的灰色区域,那可就不能怪它六亲不认了。
由此而言, 那就是:一个复杂的故障现象的背后,很可能是只是一个简单的原因。同样,一个看似简单的故障现象,其故障机理却可能非常复杂。不要被表面现象所迷惑,因为这很可能是个错觉。不要被初始的判断牵着鼻子走,因为这有可能背道而驰。
在这次上拉电阻的事情过程中,ACK信号的表现就是一个例子。按一般规律,ACK的存在,就意味着读写正常。以此为依据,我发现手动读写操作都正常,自然也就得出ACK处于正常状态的判断。而这一推论恰恰跳过了上拉电阻是处于一个“灰色”区域的事实。当然,这次的故障也有偶然因素。如果ACK的电平恢复时间再长些,以至于造成超时报警,那么FPGA频频出现的中断就必然会引起我的注意,从而引导我去检查相应的地方。也是该我倒霉,它偏偏就处在这个似是而非的状态,害的我绕了一个大圈子。
有人可能要问:我要是遇到类似的问题该怎么办呢?很遗憾,我只能说:我不知道。就像世界上没有两棵一模一样的树这样的事实一样,工程设计中的问题也不可能一模一样。在这行儿里,不存在什么“秘籍宝典”能让你包打天下。唯一的办法就是要一点一滴的丰富知识,积累经验。那些所谓“专家”“大师”的“金玉良言”充其量也就是作为你的参考。它不能代替你自己的思考。学别人的经验,应该注意的是分析的过程,而不是最终的结果。
干这一行,学历,经验都不是障碍,因为这些都可以弥补。真正不受待见的是那些只会“纸上谈兵”的人。
其实,那些挂着“牛人”“大鸟”招牌的人们,那个没有过被撞的鼻青脸肿,头破血流的经历?所谓“经验”其实就是“失败的经历”。因为胜利往往会让人忘记很多事情,而失败才会帮助你记住一些东西,记得死死的。
如果你是新入此行,经验不多,而又碰到了设计或实验中的难题,千万别发愁,而应该高兴才对。因为这意味着给你的经验宝库添材加料的机会来了。拾掇好家伙什儿,准备上货吧!
2. 你的敌人往往就是你自己
随着设计工具的完备,一个工程师现在所承担的工作量及范围与以前比已经增加了许多。因此出错的可能性也大大地增加了。原因很简单:是人就会犯错误。区别只是多少和大小的问题。我们能做的一个是如何少犯错,另一个就是如何发现错误。对于前者,在很大程度上取决于设计者的知识水平和工作经验。而后者则往往受到很多心理因素的影响。
一个工程师在完成一个设计后,最长见的心理表现就是很自信,认为我已经花了很多心血,做了很多工作,该想到的都想到了,不会再有什么问题。在这种心理作用下,常常对由别人来复核自己的设计表现的很抗拒。甚至有的人自持资格老,水平高,觉得由别人来审核他的设计是对他的侮辱,不尊重。其实,这恰恰说明他不懂设计复核的意义所在。
一个设计在调试中出现问题,一般有两个原因:一是由于已知或未知的技术风险,二则仅仅是因为设计中的疏忽和大意。对技术风险的应对措施进行评估的意义我就不必絮叨了。仅就第二个原因而言,它的适用范围包括了所有的人,几乎和设计者的经验和水平无关。这类问题如果摆在面前,几乎每个人都能指出错在什么地方。但问题恰恰在于不是每个人都能注意到它,或者干脆就是忘了。
想想我们在设计的过程中,有没有过这样的情形:
- 对一个元件的数值大小拿不准主意,但又得把它加上才能进行下面的事,于是就随意放了一个相同尺寸或管脚的元器件在那,准备回头有时间再修改,但后来事情一多,给忘了。
- 一个新设计的开始为了保险和快,重复使用了老设计的部分内容。由于把注意力都集中在新设计的特殊部分,而忘了对所沿用的老设计进行必要的修改以应对新的使用环境,到调试时才意识到。
这些错误听起来似乎都有些荒唐,但却是真实常见的问题。
你有过在调试中发现了一个问题都不好意思告诉别人,一边改一边骂自己:怎么犯这种低级错误的时候吗?别人不敢说,反正我是有过。
在这种情况下,设计者所要面对的挑战,不是他的水平高低,不是他经验多少,与他的资格地位更是不搭界。他所要面对的只是他自己,要承认这样一个事实:他会犯错误。换句话说:他的敌人这时就是他自己。
俗话说“旁观者清”。就工程设计过程而言,设计者本人由于注意力高度集中在他认为的重要问题上,视野难免变窄。而旁人因为没有心理负担,更为超脱,看问题的角度会完全不同,因而很容易发现那些被忽略的问题。
我喜欢把这些浮在表面,很容易解决,却又比比皆是的问题比作“浮土”。一套高档家具被一层厚厚的尘土覆盖,自然不至于让家具报废,但你不清理干净,还真没法用。搬进新居之前,清理一下,不过举手之劳。为什么非要等到什么都就位了再忙个鸡飞狗跳呢?
其实这种由多方进行设计复核的过程是基于我们都已经很熟悉的利用“多样性”来改善最终结果的概念:在接收解码过程中,我们会使用“大数判决”的方法来对付误码。在WIFI的射频系统中我们用了MIMO的多天线体制来抵抗信号的衰落和反射。对待我们自己的设计为什么不能利用这个“多样性”的好处呢。
具体就我的这个设计而言,虽然有设计复核的过程,但参加复核的人多偏重于板子一级的设计。如果考虑到这是一个新设计的芯片,而设计团队又近在眼前,的确是应该让他们的人更多地参与。这个电阻的特征就不至于等到最后才搞清。
说了这么多,可能还会有人质疑:花时间就解决这些“鸡毛蒜皮”的问题值得吗?在后期实验室里不也同样可以解决吗?
回答还是那句老话:时间和成本。
一个是花点儿时间,让你带着一个干干净净的样机进实验室,把精力集中在那些真正关键的问题上。另一个则是在实验室里昏天黑地的忙上几天,却只是为了清理这些“浮土”。再回去修改设计,重新做板子,等上十天半个月拿到新样机后,才能处理后面的问题。那个更合算?
当然,如果你的老板有大把的资金大把的时间,容许你由着性子,今天为了加个电阻改一版硬件,明天为了改两条线再重新做一部样机,那我也就无话可说了。只能送一句祝福的话:祝你走运。
3. 细节决定成败
这个项目的设计使用了大量模拟仿真的技术。这些技术的使用使得许多问题被发现在硬件完成之前,从而大大加速了整个开发过程,效率提高了不少。但是后来的结果也证明:模拟仿真不能代替一切。在认定结果时,必须考虑到各种可能的情况。盲目的仅以模拟的结果作为依据,有时要出乱子的。
现代电子工程领域中的模拟仿真技术已经非常发达,几乎已经涵盖了模拟信号和数字信号所有范围。大到系统功能,小到一条信号线的信号特征都可以各种工具软件分析。但是这些都要基于一个前提,就是你所使用的条件和模型是准确的。否则,得到的结果就要打折扣,或者甚至会南辕北辙。而提供精确的条件和模型在实际过程中恰恰是非常困难的事。有时因为条件所限不得已只能估计,或者只能考虑极端的情况。这样一来,通过模拟得到的结果,有时就只能作为参考,作为验证的手段之一,而不是全部。同时还要辅以其他的手段。示波器和万用表对硬件工程师来说,是看家的本事,至少现在是没有过时的。
从这种意义上说,现代的模拟仿真技术和传统的调试手段是相辅相成的两方面。使用模拟仿真技术可以高效率地对系统功能进行验证,但在处理一些细节和边界的问题上,有时却会力不从心。系统中的细节问题往往在开始时不被重视,慢慢留到最后就有可能成为绊脚石,使得成功与失败只一步之隔。既然搬开了最后的绊脚石就是成功,那也就可以说:细节决定了成败。
通俗的说法就是:模拟仿真决定了方针路线,却管不了生活小节。
推广一些可以这么说:靠这个可以助你取得大势,但要彻底天下太平,睡个安稳觉,还少不得要做些保境安民的具体琐事才行。
再扯远点儿:美国人为了打塔.利.班,动用了导.弹,卫星,全球鹰,可最后解决本.拉.登,还是要靠几个特种兵手里的自动*。
“大.炮不能上刺.刀”,这句话在这儿还仍然适用。当工程师,应该有统领全局的视野,可也得有能像“蓝博”那样靠一刀一*解决问题的能力。
工程设计中的问题各种各样,表现方式不同。有的作用明显,有的深藏不露。但不论看似严重的故障,还是不起眼的细节问题,都是设计中的隐患。它们只有形式的区别,没有重要不重要之分。
从大里说,几个恐.怖分.子,可以搅得一个国家人心惶惶,鸡犬不宁。一片防热泡沫可以毁掉一架航天飞机,要了七个宇航员的性命。由小处讲,一个上拉电阻也可以让我灰头土脸,一个多礼拜不得安生。
步入这一行的人,或许是因兴趣所在,被不断出现的新技术所吸引,或者是为养家糊口,不得已为安身立命而忙碌,有一点恐怕是共同的,就是都希望能做出点儿成绩,干出些名堂。既然是这样,“细心和认真”就应该是对我们所有人的一个共同和基本的要求。
莫因事小而不为,别把细节当儿戏。愿以此与同行们共勉。
用户1553703 2012-10-31 13:09
用户1659534 2012-7-26 16:12
用户1661292 2012-7-24 19:45
用户1468416 2012-6-22 13:07
受教了,写的不错
用户1130179 2012-6-19 17:05
用户1372461 2012-5-24 12:46
用户1642009 2012-5-14 08:27
叔森 2012-5-12 17:25
用户1614730 2012-5-9 14:27
用户1366145 2012-5-7 10:44