捉鬼记

当工程师的都知道“debug”这个词，意思是“排除故障”。英文的字面意思是“抓臭虫”。但我觉得这不太贴切。臭虫虽然讨厌，但大不了就是咬一口，叮个包，总归还要不了命。而且有时就在面，抓起来并不困难。可在工程设计中要是留下个隐患，有时可要出大乱子。从这个意义上讲，说是“捉鬼”可能更恰当。鬼不但吓人，还可能要命啊。   从事硬件设计多年，捉的鬼不少了。本来嘛，硬件工程师的工作无非是俩部分：前期的工程设计，以及实验室里或现场的故障排除。而每个故障的表现尽管千奇百怪，但原因无外乎：设计错误，元器件失效，使用不当。对新产品设计而言，则主要在前两种。硬件工程师排除的自然是硬件故障，然而事情有时并非如此简单。在今天这样高度集成的电子设备中，这个界限越来越模糊。做个工程师，必须拳打脚踢，那样都不能含糊。要不然，麻烦就要上身。   说说我的一次捉鬼的经历吧。   · 遇见鬼 在C公司工作期间，一直做大型路由器接口模块的硬件设计。大约是在04年开始的一个项目用到了QDR静态存储器。当时这款存储器还属新品，生产厂家不多。开始时只有CYPRESS一家的可用。但C公司的产品设计要求是：除非功能特殊的器件，一般器件必须要有俩个以上的供应商，以防止因供应商的原因造成器件短缺影响生产。对存储器这种常规器件更要如此。于是一边设计一边要找这种存储器的替代厂家。最后，在设计基本完成时，又从K公司找到了同样的器件。至此全部器件的选型都满足了设计要求。公司器件数据库将这两家的器件列入同一器件编号下，表示可以相互通用。因当时K公司还不能提供器件样品，所以产品的测试只用了CYPRESS的器件。完成设计，样机制作，实验室调机，通过测试，为软件团队的软件开发提供支持，指导试生产，。。。，一系列的辛苦不必再说。最终，产品顺利投产。公司的产品目录上又多了一个，每年公司巨额的收入账上，又加入了新的一笔。。。。而我又转入了下一个轮回，开始了新项目的设计，命啊。。。   大约两年后，就在我已经渐渐淡忘了这个项目时，某一天，一个负责新品生产的工程师突然找到我，通报了一个严重情况：两年前投产的那个产品在近期的生产中突然发现大批的成品不能通过测试。问全部集中在QDR存储器上。开始时工厂试图通过更换器件来解决问题但是无效。更可怕的是：这一故障情况不稳定，同一块板子，这次测试通过了，下次重复再测可能就通不过。这是最让搞硬件的肝儿颤的“软故障”。 听完情况介绍，哥们的冷汗就下来了。通常情况下，我们在投产前已经对工厂的技术人员进行了培训，常见的问题都有处理的措施。只有在无法解决的情况下才会联系我们。现在因为这个故障已经造成停产，大批的成品堆在那无法出厂。更为严重的是几年来已有上千件成品交付用户使用，很多现在处于运行状态。如果这些已经交付的产品中也存在同样问题，在使用中发生故障，造成用户数据流中断，停机，用户要求返修，退货，这麻烦可就大了去了。别说我这个小小的工程师，上面几级的头头脑脑都要有好看的。而事实也证明了我的猜想, 很快部门经理和高一级的主管就打电话或发来电邮询问情况，同时再三强调：这是目前压倒一切的中心任务，必须尽快破案！（呵呵，当然不是原话，但意思是对的，听着有点儿像这两天公安部急着抓杀人犯的口气，这中外当头儿都差不多）。   当时的感觉就是：遇见鬼了！   · 抓鬼   等一惊一炸的功夫儿过去后，我冷静下来，开始思考各种可能性。产品已经投产两年，一直没听说有质量问题。突然暴出这个问题，肯定哪有了变化。于是我找到新品工程师仔细的询问了情况，果然发现了线索：该产品在投产后一直使用CYPRESS的QDR存储器，一切正常。前不久K公司的存储器开始供货，所以近期的生产使用的是K公司的器件。而问题就是在换器件后爆发的。很明显，问题与K公司器件的使用有直接关系。 想到这儿我心里有了底：有目标就好办！于是我要求马上从工厂的测试通不过的板子中给我发5个过来，用来查找问题。与此同时，我还得恢复所需的测试设备。时间已经过去了两年，原来的测试平台或是已经拆除，或是转做它用，现在再恢复起来又是一番辛苦，自然是不在话下。   很快工厂发来的板子到了。放到系统上一测，果然，存储器的测试不断出错，而且出错的地址和数据不固定，完全是随机状态。按照存储器的技术指标反复核对了板子上的器件时间参数状态，没有发现问题。这说明问题不是由于时间关系计算错误引起的。这让我松了一口气。如果是这种问题，要解决就只能重新做板子了。那我基本上就死定了。这种随机状态的错误让我感觉，这并不是由于器件的物理故障所引起，而更像工作状态混乱造成的。我从厂家网站上下载了最新版本的技术文件，查找其中任何可能导致器件工作不稳定的原因。终于在有关数字锁相环（DLL）的内容中，发现了一段描述：   1. 必须在控制线DOFF为低电平情况下加电。 2. 器件核心部分必须先于接口部分加电。 3. 待电源电压及时钟稳定后再恢复DOFF为高电平。 4. 如果做不到上面三条，则必须将输入时钟中断30NS后再恢复。所有这些都是为了保证DLL的正常工作。   看了这段内容让我很兴奋，因为我清楚地记得以前的技术文件没有这些要求。我有个习惯，每开始一个项目设计，便将有关的技术文件放在一个独立的文件夹里。有问题抓过来一翻很方便。找到那个项目的文件夹，翻到原来保存的老版本的K公司存储器技术文件，果然找不到这部分内容，这就对了。在初始设计时，电源时序是个重要内容。所有的器件都核对过是否对此有要求。以便分配相应的供电线路。 不过即使如此，恐怕也很难按此要求办，该存储器的两路电源同为1.8V， 总不能为了两个存储器再多加一路电源和时序控制吧，那也太不经济了。 如果是这样，很有可能就不选它的器件了，因为同样的产品，CYPRESS并没有这些要求。文件中的这段描述，更像是在器件出来后发现了DLL的初始稳定性的问题而采取的一种补救措施。DLL是其内部工作的时钟源，如果它工作不稳定，其余电路的工作无从谈起。现在虽然还不能最后肯定，但直觉告诉我：它就是那个鬼！   · 打鬼   现在的问题是知道了原因，未必就有办法。   这是个两年前完成的设计，板子上的电源及控制状态都已经固定，不可能再动，要动就成了修改设计了。所以前面所说的1，2，3条都办不到。但是第4条却是可以动动手脚。在这个板子上，是由一个大型ASIC直接驱动这两个QDR存储器。其时钟在ASIC的直接控制下。如果通过软件控制ASIC内部的相关寄存器在加电后先切断时钟输出一段时间，然后再开通，不就符合第4条的要求了吗。为了证实此方法的可行，我又去查那个ASIC的技术文件。那是个有数百个管脚的芯片，几千页的文件浩如烟海。好在我的目标明确，直奔主题，很快查清，确有一个寄存器可以用来控制这个时钟的输出。此计可行！剩下的就是具体实施。但这却是不在我的掌控之中了。   这部分软件修改涉及到ASIC的驱动程序，而这个驱动程序又被测试和应用两大系统使用，相关的软件开发团队有几百人，遍布全球。每个新版本的含盖内容及要处理的问题早已排好了，容不得我一个搞硬件的插手。我只能找相关的软件工程师帮忙了。负责这部分的人远在西部的SAN JOSE, 不能面谈，还有三个小时的时差。只能通过电邮联系了。 急忙写好邮件，说清原委，指出要修改的地方和方法，，，当然也少不了一番好话和感谢。   剩下的就是等着了。   这段时间我原来的部门经理休长假不上班，由另一个组的头儿麦克带管我们组，人也远在波士顿。麦克没有介入这个项目的开发过程，对情况一无所知。现在出了这样的事，平添了一股压力，颇有些紧张。因为都知道停产（LINE STOP）意味着什么。虽然说问题原因可能各种各样，但搞硬件的人肯定是首当其冲站在第一排挨*子儿的。万一问题解决不了，炒掉个把工程师是小事，他这个当经理的肯定也脱不了干系。 代管代出个这样的结果不是倒霉吗！所以他的电话和电邮就不断，又要开会，又要找人，也不知道到底要干什么，其实是有点儿麻爪儿了。我这里已经有了方案，但在未证实之前，又不想张扬，怕万一不成，没有了退路。只好先含含糊糊的应付他，最后干脆不接电话了。   挨到了快下班的时候，SAN JOSE有消息了。负责软件的那个哥们挺帮忙，按要求改好程序后给我发来过来。马上，开机，启动测试：   一遍，通过。 两遍，通过！ 有门儿！   但这还不算。别忘了前面说过，有的板子是可以通过测试的，但并不能保证多次重复后还不出错。按要求必须要长时间反复测试才行。测试程序跑一遍要十几分钟，于是就写了个控制自动测试的SCRIPT，让这几块板子，加电，测试，关机，再加电，，，总之得把它们往死里折腾。。。   回到家，吃完饭，心里还是不踏实。就把笔记本电脑通过VPN接到了公司里测试用的路由器上，，，这也是典型的C公司文化。C公司为充分展示其网络设备公司的技术，和利用其自有网络的资源，早在十几年前就给每个工程师都配发了一部笔记本电脑。 在今天这个笔记本电脑都已经臭了街当白菜卖的时代，这实在不算个什么事儿。可是在当时每部还是要两三千美元的时候，就显得很奢侈了（因为办公室都还有台式机和工作站用）。而且员工在家中的上网费用由公司报销。当然这一切不是为了摆阔，目的是让你在任何时间任何地点，只要有网络存在，就能让你连到公司的任何一台服务器或者路由器上。公司的理由是：作为一个网络设备供应商，如果我们自己都不能用好自己的网络，如何能说服用户买我们的设备？这样你就没理由说“我不在实验室，不能。。。”的话。所以公司的一道风景就是，一到开会时，就见人手一机，这边说着会上的事，那边屏幕上还跑着终端上的数据。当然，也免不了时不时 的看点儿闲白儿，查查股票。当经理的也都知道，睁一只眼，闭一只眼。只有一条，你得出活儿，不能误事，，哦， 扯远了。   简短截说，由测试路由器终端返回的结果整齐而稳定：   测试完成，零错误。。。 测试完成，零错误。。。 ：：： 测试完成， 零错误。。。   这一行行的字符看着比美女照片都养眼啊！   基本上可以肯定，问题解决了。为了保险起见，我强按住发电邮通知的冲动，决定再等一个晚上。待明天看完结果再说。那晚上，睡得好香。。。（哦，不过说实话，我平时觉也不错，躺下就跟死狗似的）   第二天一上班，就迫不及待地检查结果，不出我所料：全部测试通过，没有任何错误。大功告成！   不过，事儿还不算完。。。 · 哪来的鬼？   剩下的事情就是按部就班了。把新的测试程序转给专门的测试组，由他们按规定对工厂发回来的五块板子再进行全面测试。他们要比我折腾得狠，全部测试完成要几天的时间。但我已经不担心了。   还有当然是要向有关人员通报，头一个就是麦克。这家伙听到结果后没有表现出很高兴的意思，似乎对问题的原因不太相信。不过，按照经验来说，他是对的。   一款新器件用于生产，不是拿来就用的。取得了公司器件库的编号，只意味着允许装机使用，但不意味就可以用于生产。必须要经过全面的测试验证。公司并没有专门的测试平台，哪个新产品设计选用新器件，哪个产品就要当作测试平台。选用这款器件的工程师也就同时还担负有验证的责任。测试要由独立的测试组进行（就是前面提到过的）。测试过程中要给设备加载１００％的数据流量，同时升高或降低各路电源电压，时钟频率，以及环境温度。依据设计不同，这些组合有可能达到几十个，所以又称为“corner test”.，如果是因为这个器件哪一项测试通不过，那就得摘牌儿。经历了这一番历练，在所有的犄角旮旯里都能正常工作，才算通过，允许用于生产。以后如果其他设计使用时，最后也还要重复同样的测试。所以，一般情况下，设计师都愿意使用数据库中现成的器件，因为风险要小得多。   作为替代品，在这款Ｋ公司的存储器提供样品后，也经历了同样的过程：将几块已经通过测试的板子上的CYPRESS片子拆下来，再换上K公司的片子去测试。这个过程虽然是由新品工程师负责，我没经手，但通过测试的结果我是知道的。   如果器件厂家因为各种原因需要修改器件性能，变更技术文件，应该在第一时间通知用户。公司在收到通知后也会对数据库进行更新，加入新的内容。搜索器件数据库，你可以发现每个器件下都列有所有时期的技术文件，甚至有的还有扫描上去的手写的。   K公司的关键问题是后期批量生产的器件较之用于测试的样品有了变化（厂家技术文件的修改说明了这一点），可是却没有通知用户！这种情况很少见。   我向麦克说明了这些情况，并且给他发去了两个内容不同的技术文件，以及目前测试的结果。事实俱在，他终于认同了。然后马上他就表示出了一种愤怒：K公司怎么能这样！不想玩儿了吗？我要找他们！   也是，平白无故受了这么大的惊吓，搁谁也不干。再者说，想在C公司的这桶饭里挖一勺子是那么容易的吗？这就要多说两句关于C公司的元器件供应商认定过程。 因为是大型网络设备制造商，C 公司的元器件采购对各个供应商而言是块大肥肉。因为这类器件的利润要远高于用于消费类产品的器件，所以谁都希望能插上一脚。但问题是C公司并不是来者不拒，而是要对各个供应商逐一审查，包括器件性能，供货条件，甚至公司的财务状况，都要考虑。即使器件不错，可是如果不能保证供应，甚至不知哪天关门了，要东西没有了，那不坑人吗。我就知道有过为了保证器件供应，C公司甚至要给某个供应商提供财政资助的情况。由此可见，能让C公司认可不是件容易的事。而一旦被认可上了名单，不但可以应用于现有产品，在有新项目开始时，设计师也会优先考虑使用。这对供应商而言就意味着可观 的出货量和利润，任谁都不会对此掉以轻心。   说一件我亲身经历过的事做例子。就是在开始设计上面提到的这个项目时，需要一个带电切换电路（HOT SWAP）。以前的设计都是用分立器件，设计复杂，所需的空间大。我希望简化设计，到处寻找替代品。后来发现ONSEMI有个芯片接近我的要求，但还要修改才能使用。于是就和它的销售代表联系，说明了我的要求。他们满口答应同意修改。很快，新芯片出来了，完全符合我们的要求。设计简单，所需空间大大缩小。于是不但用在我的设计中，随后其他人的设计也纷纷使用。但是过了一两年后有消息说ONSEMI要停产这个产品，原因是其成品率太低，实在不赚钱。可C公司有几个产品都使用了这款器件，已经投产。这时ONSEMI如果停产不就把我们给晾这儿了吗。于是有关部门就找ONSEMI的人讨论此事。具体过程不清楚，但最后的结果是：ONSEMI继续生产这款器件，但只供C公司一家使用，以维持现有产品的生产。而新设计则建议使用其下一代产品。显然ONSEMI宁可吃点儿亏少赚点儿，也不愿意冒开罪C公司从而失去供应商的资格的风险。   像K公司这种做法，显然C公司是无法容忍的。   · 没让鬼吓着   麦克如何去和K公司交涉我就不关心了。那不是我的事。但我后来听他说，开了好几次电话会议，把出现这个问题的原因查了个底儿掉。K公司反复地解释了原因和解决的措施，并一再的道歉，确保不会再有此类事发生才算罢了。   几天后，全部测试完成，没有再发现任何存储器测试错误。后面的事就简单了。因为这个问题并不真正是器件的物理故障，是初始化的问题。而且目前只是在工厂测试中发现，没有出现在用户的系统中。所以不需要召回那些用户手中的设备，只要通过更新测试软件即可解决。当然，用户的应用软件也要升级以避免同样的问题，这些通过计划中的软件更新就可以了。   结果可以说皆大欢喜。麦克给我发来 一份电邮通知说，给我发了一笔奖金。通知中说：感谢你在这次处理XX产品停产事件中所作出的努力，使问题在这么短的时间内就得到了解决，。。。云云。钱不多，几百块而已。不过想起刚开始时所承受的压力，也算是个安慰吧。在这个过程中，我基本上没走弯路，对这一点我还是挺满意的。   “这么短的时间。。。你到底用了多长时间”？   不算后来测试组正式测试所用的时间，我一共用了两天，一天复现问题，一天查原因，找解决方法和测试  。   还行吗？   还行吧！   不久，我的部门经理克丝蒂回来上班了，很快也听说了这件事，但她并没有任何表示。 过了一段时间，她给我看了一份公司关于该系列产品的报表。在产品销量一栏， 我的这个产品名列榜首。而在返修率（RMA）一栏，则是孤孤零零的一个“0”。   “You should be proud of this!" 她对我说。   我可以“proud“ 吗？   路由器这玩意儿不同于时装， 也不像手机，它的销量完全取决于用户对此类产品的需求。我一个设计师是左右不了的。所以我不能把这顶高帽带在自己头上。   至于返修率的问题吗。。。呵呵，咱还要说是整个团队努力的结果，是吧？不过，既然她都让我”proud“的了，那我就先接着吧？ 您说呢？ 这次抓鬼的过程应该说是成功的。说起来，可以有几条经验可以总结：   1. 要注意保存好原始资料   现在的设计复杂程度越来越高，周期也拉的较长。短的几个月，长的可能就得以年记。这么长的时间，中间还要穿插许多不同的内容，任谁都很难保证记住设计过程中的每个细节。这样一来，随时注意留下记录，保存好所用技术文件及关键的数据就显得极为重要。你的工作笔记本的作用不是教科书，不一定非要清清爽爽，横平竖直。它应更像一块黑板，不但记下你的计算过程和结果，还可以包括你的问题，困惑和疑问。文字，数字，图形，甚至情绪化的标记都可以是内容。这样作的目的只有一个：帮你记住尽可能多的信息。你在设计过程中随手写下的几个字，文件中标注的几个数据，日后都有可能对你有所帮助，帮你回忆起当时的设计依据和条件.   以这次的事情为例，如果我没有保留Ｋ公司原来的技术文件，就很难在事发后的分析中发现新老文件的差异，以判断出可能的故障原因。即使后来排除了故障，也很难让人相信，这是器件厂商的原因，而不是我设计的问题。麦克很可能会问：为什么在开始设计时没有注意这个问题, 而导致现在造成这么大的恐慌？那就真是有嘴说不清了。   1. 你不止是个硬件设计工程师   你的头衔是个“硬件工程师”, 但你不止是一个“硬件”工程师。现在电子工程设计的集成度越来越高，硬件与软件的界限也越来越模糊。现在一个硬件工程师所从事的工作，几乎等同于若干年前一个系统设计师。我总喜欢将现在硬件工程师的工作比喻成“搭台”的，软件工程师的工作是“唱戏”的。观众看到的是演员在台上五花八门的演出，可没了舞台，灯光和布景，那就啥也不是。   系统的功能要靠软件实现，但它必须要在硬件环境的支持下。在现在的产品开发过程中，多数情况下硬件设计要先于软件开始，软件的工作要在硬件已经形成的环境里进行（我这里指的是那些直接与硬件打交道的底层驱动程序和管理程序，而不是指上层的应用程序和操作系统）。这就决定了硬件设计在整个流程中起着一定的引领作用。从某种程度上说硬件设计者是整个设计阶段的带路人并不为过。因此你不能把自己仅仅局限在硬件的领域内. 　在设计过程中必须要考虑：这样作，对软件会有什么要求？有没有实现的可能？如何能使相应软件设计工作变得简单？ 你可能不需要去写程序，但你必须要了解与你的硬件相关的软件部分如何工作。   还以上面的事为例：当我认为可以通过软件修改来解决这个问题时，不搞清具体的相关寄存器的功能和操作方式，而只是简单地推给软件组让他们去修改，以应对存储器的初始化的问题，那结果很可能就是被置之不理，因为他们很可能不理解存储器的上电过程与他们有什么关系。至于存储器的错误那更是与他们无关：你们搞硬件的难道不应该先把硬件故障排除后再找我们吗？   1. 给你的设计多留些余地   这里说的余地，并不单指在选择器件时，其参数相对于应用环境要留有一定的余量。更指 的是，应该充分利用你的设计中的可用资源，为其功能或工作特征的改变或拓展留下空间。   比如说：按照现在的硬件结构，有没有可能应对不同的使用环境？这个产品将来有没有升级的要求？ 如果要升级硬件要做哪些变动？能否让你的设计用很少的修改，甚至不修改，只通过改动软件来实现？你选用的器件将来会有变动吗？如果有，你能做到不修改电路板就实现吗？   举个例子：一个器件管脚的设置会导致不同的功能状态，那么有可能的话，在电路中就不妨将上拉和下拉电阻都放上，在装配时根据需要只安装其中之一即可。再比如，如果你的设计中有FPGA，那么通常情况下它的管脚和内部逻辑单元的使用量最好控制在８０％以下。一方面这样FPGA的编译／合成速度会很快，内部的定时关系也容易保证，同时剩余的管脚和逻辑单元也可能成为你的备用资源。分析一下你的设计，把那些将来有可能用来改变电路功能或特征的的某些信号（主要是控制类信号），接到FPGA上，而不是简单地固定在一个逻辑电平上。这样一旦有需要，只要修改你的FPGA设计即可。这都远比你将来再修改电路板要容易的多。   只所以这样做，是因为就现在硬件的复杂程度而言，翻新一版硬件所需时间和费用远非软件的修改所能比。单说修改过程，一旦方案确定，软件的修改只是敲敲键盘以及系统编译的时间，几乎没有其他成本。而硬件的改动，即便你只是要增加一个电阻，电路图－布线－元器件表－制板－装配－调试这一系列过程少那个也不成。这种耗费往往是惊人的。更不要说碰到前面提到的紧急情况。如果我在前面提到的设计中，不是简单的将QDR存储器上的DOFF控制线固定死，而是连到FPGA上，那么我就有可能在FPGA中加一个简单的控制即可达到目的，而无需兴师动众去麻烦千里之外的软件组的人，所需的时间还要少得多。在板子上增加几个电阻，多布几条线，不是很困难的事，但可能带来的收益却是不可低估的。　 　　　　 当然，所有这些都要在不影响主体设计性能的前提下，不能喧宾夺主。说句玩笑的话，这多少有点儿像谍战剧中那些深藏不露的间谍卧底，武侠小说中密不示人的行侠剑客。这些人从受领任务的那一天起，就大隐于世，从不张扬。只是冷眼旁观他们的同伴建功立业，争奇斗艳。他们也许永远不会被启用，只能默默一生，直到终老。而如果有一天他们被召唤，那多半是形势已经到了关键时刻，生死关头. 他们的出手一击，有可能成为扭转乾坤的胜负手，一决生死的杀手锏。到了那时，你可能会由衷地感叹，自己当初是多么“英明”。   如果这样的比喻可以接受，就这样来概括吧：   各位将军，当驱动你的大军攻城略地之时，别忘了埋下一支伏兵，留下几个卧底。他们可能使你在关键时刻反败为胜。   列位庄主， 在差遣你的镖局出发上路之前，要记得派出几个潜行的剑客，布放几个隐身的保镖。他们也许会让你在生死关头转危为安。