本文转载自： FPGA的现今未微信公众号
在FPGA项目中，相信很多人都遇到过一种情况：项目经理为了赶进度，会让开发人员在写完代码后，尽快的上板测试，有的是为了提前了解项目的情况，有的纯粹是为了赶进度，所谓的小步快跑、快速迭代。结果是解不完的上板bug，开发人员疲于应付，究竟是出了什么问题呢？本文就这个问题做一个简单的总结。
背景
在说明这个问题前，还是要先说一个老生常谈的话题，FPGA的开发流程，如下图所示，从理论上讲，他本应该是一个串行的过程。
那如果为了加快进度，将上板测试提前，那开发流程可能就是这个样子了，如下图所示，在单元仿真完成一部分后，就开始进度系统仿真（有的公司可能系统仿真都没有），系统仿真进行一点后，就开始上板测试。整个开发过程变成了一个半并行的过程。
引发的问题
先说结论，这样做会引发2个主要的问题：1、解决问题的代价大大提升了；2、流程被打乱，开发人员无法主动发现问题。
大家都知道，FPGA问题解决的代价，在不同的阶段是不一样的，以前有人做过研究，如果单元仿真阶段解决一个问题的代价为1，那么系统仿真阶段解决这个问题的代价就是10，上板测试阶段解决这个问题的代价就是100或者1000了。仿真（后面把单元仿真和系统仿真统称为仿真）没有做完的情况下，就开始上板测试，必然会发现不少问题，上板测试发现的问题到底现在要不要解决？有人会说当然要解决，解决的话势必会消耗开发者的时间，甚至被这些问题牵着走，没有精力来做好仿真，因为解决这些上板问题的代价已经成倍的增加了。那如果不解决呢？如果不解决，那测试还有什么意义。
根据作者以前的项目经验，大部分项目只要把上板测试提前，打乱仿真阶段的计划，开发人员都没有精力做好仿真，同样，我们的验证人员可能要复现上板问题，原有的仿真计划无法顺利进行，没有办法主动的去发现问题，导致本应该在仿真阶段发现的问题遗留到上板测试阶段，所有人都被这种提前上板测试的活动打乱计划，最终得不偿失。
如何解决
先讲一个故事，作者13年的时候曾参与一个项目，当时我们有充分的时间做单元仿真和系统仿真，最终的结果就是版本交给测试人员，测试一轮后他们有点“慌”了，因为没有发现一个功能性问题，这在以前的版本中是绝无仅有的。这个事情也再一次印证了仿真的重要性。
言归正传，如果为了赶进度，上述的问题是否就无法解决呢？也不全是，要想加快进度，提前进行上板测试，前提是应该满足如下几个要求：
1、首先从流程上来讲，上板测试可以提前，但是只能和系统仿真重合，如下图所示，单元仿真阶段，开发人员可以以很低的代价发现一些基本的问题，甚至一些低级问题，而这些问题上板阶段却是很难定位的。
2、系统仿真和上板测试重合的时候，要做到上板测试不超前，仿真一个特性，测试一个特性。比如系统仿真的第一步一般都做一些简单的基本功能的仿真，寄存器的读写、单个报文的冒烟测试等，这些基本功能仿真通过后，再上板测试效果会好很多。再比如仿真阶段先完成接口的环回验证后，再用环回的方式上板测试接口的稳定性。
3、做好计划，不越界，及时停止。哪些特性通过仿真来验证，哪些特性通过上板来验证，需要提前做好计划，保证上板测试的特性，都是被仿真过的（除非无法仿真），其次上板测试人员和主要的开发人员最好不要是同一个人，要让代码开发人员有精力充分的验证好自己的代码。最后当上板测试发现版本质量不符合预期的时候，要及时停止，重新审视仿真是否做到位。
小结
为了加快进度，上板测试和仿真阶段可以重合，要做好特性的仿真计划和上板测试计划，特性和特性之间可以并行进行仿真和上板测试，就某个特性，还是要遵循先仿真，后上板。