FPGA 工程师的核心竞争力

不管是RTL design还是做simulation的、上板测试的都算FPGA工程师，并且往往一个工程师者随着项目进度会从头做到尾，项目的输出就是FPGA bitfile作为产品的一部分正常工作，所以导向就是最终上板的结果。从项目时间来看，前面coding和simulation占据一部分时间，很多代码还是复用之前项目的，而debug就分单独模块验证、整块FPGA验证、软硬件跨部门验证、整体系统验证等，调试占用的比重越来越大。而FPGA的特点决定了调试不太容易，相比simulation来说困难多了，出现一个issue先定位是软件的问题、硬件的问题，还是FPGA的问题？如果是FPGA的问题，容易复现不？如何判断是哪一部分模块的问题？大致的问题在哪里？如何设置debug点，使用identify/chipscope/逻辑分析仪去抓？出一个版本往往按小时算，一次设置trigger信号可能还找不到想找的点，需要多次去抓信号和出版本。这过程中，没经验的工程师是赶急赶忙地去出调试版本，或不知从何下手，忙很久却劳而无功；有经验的先分析推测问题可能出现的地方，分步骤去验证问题的原因，能较快地定位在issue所在。这就是核心竞争力！当然要做到这步需要很多的积累，比如对产品架构有整体了解，对具体模块、FPGA技能很熟悉，对常见协议如AMBA、DDR有一定经验，要不然你又不是跳大神靠掐指一算就算出问题所在了。IC原型验证工程师，如另一答案所说，有的公司就是工程师兼一下把活干了就行，有的则是正规的team专门做原型验证，尤其是涉及到多块大容量FPGA分割方案的。这里FPGA与simulation相比优点就是在真实的物理环境中运行、运行速度快、能run大量的case进行回归测试，缺点也很明显，介入时间晚，移植到FPGA平台花的时间很长、需要处理大量的硬件相关问题如时钟外围器件管脚连接、debug困难等。随着芯片规模扩大，二者各自的优缺点越来越明显，越来越多公司开始使用Emulator，Emulator更偏向simulator的硬件化，离simulator更近，离FPGA远多了（本人现在emulator AE）。同样，做原型验证的工程师有什么核心价值？别人搞不定的问题你能搞定，这就是价值所在，比如需要实际接硬件作为激励源发某个特殊case才能复现的issue，重要性还很高，simulation搞不定，你在FPGA上搞定了，谁敢小瞧你？要是仅仅跑个流程，能用就行，随便找个人都能玩通的活，公司又不是傻子给你那么多钱干啥？综上，你的工资是公司付给你不可替代性的成本，你越不可替代，你的价码越高，如果太低你会跳槽走人，太高公司也会找机会把你换掉。这其中有普遍性分工的因素（比如普遍性而言design给的钱比原型要高些），也有具体个人的因素（你牛就该拿高价），不宜过分强调哪个极端。---------------------------------------------如何提高debug的能力？来个可执行性高的方法：给上司和相关人员发邮件汇报工作，整理思路并记录过程，同时展示你的工作成果。比如在系统联调中出了个bug，先给上司口头汇报下这个情况，然后去定位，到一个阶段或下班前发邮件，先描述下环境配置和现象，让别人知道是怎么回事（有些人开头就说具体现象，听的人不知所云），然后你定位到这个现象发生了，稍微描写下发生的问题；接下来分析可能性，出现这个问题可能的原因，怎样去确认是哪个环节发生的事情，并且你因此做了哪些操作去确认来进一步缩小范围；如果是哪个小范围的问题，可以做哪些操作去进一步确认问题，比如打印中间变量结果、出测试版本加chipscope信号去抓取数据、bypass某些旁路等；如果一次性没找到问题的根源，那之前的操作排除了哪些可能，接下来还有哪些操作可以去做去确认，需要做的工作和工作量、时间评估、需要的资源支持评估等；如果通过debug找到了issue所在，分析下产生的原因在哪里，是低级错误、test case没覆盖掉、健壮性不够、软硬件配合、还是架构上有问题？如果是简单地修改该怎么做，要多少工作量，影响有多少？如果是完全解决这个issue，涉及的范围有多广，收益和风险在哪里，该不该做？提出建议，让上司等决定。如果问题一直找不到，那可以采用什么样的手段规避掉，收益和风险又在哪里？如果问题不复现了，可能产生的风险有多大？需要记录下来，下一次可能又会出现。如果把一次次的邮件内容同时整理下来，放在word文档里，适当编辑下格式，加上日期、环境配置等信息加在邮件附件里，更往上点，有专门的issue track平台在上面记录，那就更好了。

感谢楼主辛勤分享