FPGA设计之“甩锅大法”

本文主要是介绍FPGA设计之“甩锅大法” | 凌云时刻，希望对大家解决编程问题提供一定的参考价值，需要的开发者们随着小编来一起学习吧！

凌云时刻 · 技术

导读：FPGA设计如何自证清白？

作者 | 隐达

来源 | 凌云时刻（微信号：linuxpk）

写在前面

这篇文章并不是教唆读者老爷们真的学习如何甩锅，否则，那谁谁很生气，后果很严重。本文说不定会成为我老人家在阿里的“遗作”：入职还没满月就早夭了，何其惨也。

因此本文的主旨是跟大家探讨如何“自证清白”，当然即使这么说仍是显得消极，正确的说法应该是：如何快速排除是否是FPGA本身的问题，从而提升问题的定位和解决效率。

如果我用论文的笔触来写这篇文章，读者老爷们肯定会勃然大怒：干活已经很辛苦了好吧，生活已经很艰难了好吧，房价已经很高了好吧，谁还愿意看你这味同嚼蜡的破文章？X之拂衣去，深藏功与名，徒留我一人，狂饮忘情水。

所以呢，必须有点趣味才能吸引读者老爷们宝贵的注意力，还有啥能比一个colorful的故事更吸睛的涅？所以，还得从N年前我老人家那次漂亮的“甩锅”说起…

插播一段声明：我的文章里的故事，出于各种考虑（不能泄露前雇主的商业机密，不能泄露前同事们的隐私，等等，等等，等等），不见得100%完全吻合当年的实际情况，但是保证95%的真实度。故事如果非本人亲自经历，我会醒目的进行说明，咱不干“抄袭琼瑶阿姨还死不承认”那么low的事儿。

故事

话说大约在夏季，应该是2005年五一前后（可能有误差，但是妹子们的穿着很清凉我是记得很清楚滴），我所在的产品正在如火如荼的开发之中，市场对于XX特性的单板需求之旺盛，使得产品上上下下如同打满了鸡血，员工在办公室、实验室通宵达旦司空见惯。产品一直处在一边不断发货，一边不断增加新特性的状态。

那时候火到什么程度呢，运营商的大货车天天在XX中心排长队，以至于每到饭点，公司得专门派两个保安，组织货车司机们去食堂吃饭。而各地运营商的各个老总纷纷给自己认识的X司的各级老总打电话：哈尼！亲！蜜糖！萨瓦迪卡！崩猪！务必先保证我的发货！我请你大宝剑滴干活，地方你挑（其实大宝剑这句是我加的，因为没人给我打电话，我也不知道有没有提及大宝剑）。

我当时带一个包括我在内一共15人的团队，开发ALTERA公司最高端、容量最大的一款FPGA，整块单板的XX特性基本全部通过这片FPGA来实现（开发这款FPGA的血泪史另文呈现）。经过单元测试、集成测试和系统测试，都顺利过关，我的团队也已经接受了新的开发任务，进入需求分析阶段了。

相对而言我和我的团队都比较轻松，完全可以一边高唱“我得意的笑，我得意的笑”，一边跳起不输广场大妈们的婀娜舞姿。但是人家软件、硬件的兄弟都在不眠不休，好比别人在饿肚子，我这边不但有肉包子吃，还边吃边吧唧嘴巴，何止是不厚道，简直就是不厚道嘛，所以我们也不好意思早点下班。

Well，老子说了：“祸兮福所伏，福兮祸所依”；古人说了：“人无远虑，必有近忧”；哲人说了：“生活总是在你嘚瑟的时候，狠狠地收拾你一回”。嗯，这个哲人就是我。

Suddenly吧，有一天吃过晚饭，一个同事跑到我的办公位说：老大找你。我虽然愚钝，还是从那个同事的表情中读出了一丝“小样儿，这下你要糗大了”的意思。我边走边琢磨：出问题了？不能够啊，虽然问题一直很多，但咱的FPGA一直很Solid啊，都证明了不是其他硬件就是软件的问题啊…

忐忑滴我走进了实验室，机架周围全是人，产品老大黑着脸，嗯，比李逵和张飞加起来都黑。

“你过来”。

我小碎步上前：“Yes Sir？”

“之前呢，大家也怀疑过FPGA的问题，当然后来也都定位清楚了不是，但是这次不一样。过去三天，软硬件的团队用了各种方式进行定位和确认，大家一致认为这次肯定是FPGA的问题，所以才把你叫过来看看怎么解决。”

老大不愧是老大，绝不拖泥带水：“出问题的是XX客户，对我们构建当地市场格局至关重要，因此必须以最快的速度彻底解决问题！”

我听着听着汗就下来了，因为一般情况下，出了问题大家肯定要吵吵一番，软件怪硬件，硬件怪逻辑，逻辑怪网管，网管怪天气…这次人家做了如此充分的准备，又是如此的同仇敌忾，看来此番凶多吉少、在劫难逃啊…

众目睽睽之下，我努力让自己镇定下来，当然脑袋没闲着，诸如“是福不是祸，是祸躲不过”、“脑袋掉了碗大个疤”等等豪言壮语，还有黄继光江姐等伟岸形象在脑海中来回闪现。“既然大家都认为是FPGA的问题，那我们马上进行定位和解决”。

围观的群众脸上都露出了蒙娜丽莎般的微笑：小样儿，挺住哈，我们终于也可以喘口气了。我开始挨个给几个主要团队成员打电话，让他们马上到公司来。有人明显不情愿，显然嘛，人家正吃着火锅唱着歌，跟女朋友卿卿我我，享受着女友的秋菠，我这不是给人添堵么？

尽管如此，一个小时之内，人还是到齐了。我把情况简单说了一下，大家分头行动。问题确实比较让人头痛：因为要重现并不容易，我们也没有发现重现的规律，跟进了原始森林之后迷了路差不多。一天过去了，nothing changed；又一天过去了，same as yesterday；第三天也快过去了，same old same old。

团队的士气明显低落且有些抵触了：凭啥就认定是我们的问题呢？

这三天，我在旁边看着他们忙活，一直在琢磨：怎么才能证明问题没有出在FPGA呢？How？大概后半夜吧，我开始安排团队成员各自去睡觉（实验室里有垫子），忽然灵光一闪：你送给我啥，我不做任何处理，原封不动给你返回去，如果还是有问题，不就说明不是FPGA的问题了么？

这跟现在收快递是一样一样滴：当你的面我没拆封，东西却坏了，这肯定不是我的责任嘛。

实现其实很简单，就是做一个环回（术语叫Loop Back）：把FPGA接收到的数据，不做任何处理，直接拉到输出的管脚上去。布局布线遇到了一些问题：因为逻辑资源的使用率已经很高（超过了80%，布线资源尤其紧张，因为时钟频率很高），增加的逻辑虽然不多，但总是要耗费资源。长话短说，这个问题最终解决了。上电测试，果然OK，保险起见，跑上24小时，若没有误码，就说明问题不在FPGA之前的数据链路中。

24小时过去，OK。我有些沮丧：因为问题不在FPGA之前的数据链路，那问题出在FPGA的概率反而增大了。

怎么进一步验证呢？很简单，再增加第二个环回：FPGA处理后的数据不送给后续芯片，而是直接返回上游。如果24小时测试能pass，那么可以证明不是FPGA的问题；反过来，如果测试fail了，可以100%确定就是FPGA本身的问题。

又一个24小时过去，没问题。为了保险起见，我又去协调了几块单板，全部加载带第二环回的逻辑，所有单板再跑上24小时。结果大家也猜到了，测试通过。

我去找老大，把定位、验证的过程汇报了，老大眉头紧蹙：Are you sure？我点点头。老大拍了一下脑袋：shit！

我也理解老大的举动：我只是证明了FPGA的清白，但是问题依然在那里，仍然没有定位啊。为了表示对老大的理解和支持，我还问候了老大一句雷布斯版的“Are U OK”？其他各个团队的扛把子陈浩南们和各自手下的山鸡们都被召回到公司，个个都瞪着我，原因就不用说了。我耐心的把整个验证过程解释给他们听，再说不耐心也不行，他们人多，打不过啊。话说理工男的可贵品质之一就是讲道理、讲逻辑。在我说的口干舌燥，几次导致局部有雨之后，大家终于认可了我的结论。

我跟我的团队自此始终跟攻关的其他团队一起定位问题（实际上，在定位和解决各种问题的过程中，FPGA和软件同样灵活的可编程特性，起到了很大的作用，这是题外话了）。大概又过了两周之后，问题终于被定位：公司自研的一款ASIC，在特定情况下，会非法改写某块内存。定位是定位了，一时半会儿却无法解决：ASIC做一次EC要不少银子不说，关键是时间至少也要半年啊。最终还是FPGA对问题进行了规避，同时马上启动ASIC的EC。

经过这次折腾，我意识到环回是个好东西，应该大力推广，广而告之：毕竟，一花独放不是春，万紫千红才是春对吧；大家好才是真的好，对吧。征求了部门老大的意见后，我花了几天的时间，写了“大规模FPGA环回功能设计指导书”，把部门的高手都召集起来进行了几轮评审，就作为强制性规范发布了。其核心内容就是在常规功能之外增加数据刚进入FPGA和FPGA刚处理完之后的两个环回功能，用于精确定位是否是FPGA的问题。环回功能用一个简单的开关控制，缺省是关闭的。

效果还是灰常立竿见影的，真正的做到了“用过的都知道”：问题定位周期缩短了至少30%。有的资源比较富裕的设计还会在FPGA内部再增加一到两个环回，帮助定位问题出在具体哪个模块。一年时间内，我加了三次薪，可谓春风得意马蹄疾，而且年底又无耻的拿了一次最高荣誉奖。

后记

2005年过去了，我很怀念它：轻轻的一个奖，叫我思念到如今。从那之后，每当我在KTV深情唱起“当我想你的时候，我的心在颤抖；当我想你的时候，泪水已悄悄的滑落”的时候，不明就里的吃瓜群众都认为我在追忆某个未曾到手的妹子，其实，我只是在怀念我的2005。

END