FPGA测试环境转型篇之一：为什么需要转型？

​

距离红宝书的出版已经过去12个月了，距离书中18章的最后更新 SV及UVM高级话题篇之五（终）：OVM与UVM的混合仿真 也已经过去18个月了，除了平时在思考和开发一些方法学原型，路桑也积累了一些案例，可以继续做成新的章节，或者独立成章，或者添加到有的章节上面。至于将来是否要出新的一版，或者独立成册，暂时还没想好。我能够还有勇气继续写的原因来自于我两个女儿现在能玩儿到一起了，于是晚上回家又能够偶尔解放双手，哄她们睡着以后，继续在深夜写点总结的东西，一来为了给职业时间打戳，一来为了让思路更清晰一些。

 

只有足够的闲(jiu)暇(jing)，才能有新的创造力。

 

如果你也能够饶有兴致地觉得路桑又有新的章节，那你依旧可以把它们集结成册，或者等我的下一版书（对日期暂不做任何承诺..）。

 

好了，正文要开始了..

---

 

在《芯片验证漫游指南》（简称红宝书，以红色封皮得名）出版以后，路桑开始接触到越来越多的团队，以及作为技术顾问为他们提供一些咨询方案。这些咨询案例为我提供了更多国内IC验证的生态样本，也能够让我接下来的提到的解决方案鲜活起来。如果你已经阅读了红宝书最后的几个章节，你会发现其实每一小节都是为了解决验证环节中实际的问题。这么多的小节，不一定你都会遇到，但它们确实可以在你没有成熟方案可以参考的时候，做你的“锦囊”。

 

于是，我们本篇关于FPGA测试环境转型的内容，也将着眼于帮你理清为什么FPGA测试需要转型？什么样的FPGA测试急需转型？转型的方案有哪些？如何做到最小疼痛的转型？以及在转型的过程中如何考虑工具、环境、人力、项目开发流程等的更新？

 

首先，在分析你现有的环境需要需要转型功能验证之前，我们需要承认一个事实，那就是目前没有任何一种验证方法学可以统一“江湖”，帮助我们呈现一个无缺陷的设计。这句话的意思是说，每一种验证方法学和工具都有它们适用的场景，我们应该考虑的是就已有的环境，在做新的投入时，是否能够获得比以往更高的验证收益，即是否可以提高验证效率、发现更多的漏洞、提供更好的复用和更多的量化指标。

 

那么，对于已有的FPGA测试环境，作为verifier，你可以试着回答以下10个问题：

1. 模块级的验证是否做过仿真？

2. 每个模块在测试时是否有测试功能点？

3. 测试用例之间的代码是否可以复用？

4. 项目之间的测试环境和用例是否可以复用？

5. 系统级的集成测试是否做过仿真？

6. 无论仿真还是FPGA测试，是否具备回归测试表？

7. 验证过程中的输入激励如何产生？数据比较如何完成？

8. 数据比较失败时的调试在仿真环境和FPGA环境如何调试？

9. 如何对测试过程做量化评估，有什么指标？

10. 仿真环境与FPGA测试之间是否有边界？如何确定在哪个环境完成验证？

 

提出上述的问题，基本围绕着验证环境的构建要素进行考量，即：

• 验证环境如何构建？

• 激励如何产生？

• 数据如何监测？

• 结果如何比较？

• 调试如何进行？

• 过程如何量化？

• 环境和测试是否可以复用？

 

上面这些问题以及它们背后的验证环境考量因素，无论在动态仿真还是FPGA测试，都是必须思考的问题。如果在回答FPGA测试环境的10个问题中，有一半以上问题的答案是否定的，或者让你犹豫无法明确回答，那么，你目前的FPGA测试环境就很有必要思考为什么要转型了。从实际经验来看，FPGA模拟电路的速度要远远高于仿真环境，但是为什么我们依然需要引入仿真环境？请注意，这里的“转型”为的是优化验证效率，而不是单纯地转向某个其它的环境。

 

之所以需要引入仿真环境，那就是现有FPGA测试环境所不具备的仿真验证环境构建的要素，而这些要素在可以提高我们验证效率的前提下，还能够完善更多验证的质量。

 

为什么这样讲呢？

 

典型的FPGA测试方法基本都是在模块经过简单的仿真以后，就在FPGA上做系统的集成测试。这种快速的原型验证方法在以前确实是个利器，因为它简单而有效，能够让系统层的用户更早地进行软件开发。但最近这些年，IC行业的验证思路都在进行缓慢温和的整合。一个值得注意的趋势是，典型的ASIC/SoC验证方案都在引入FPGA/Emulator加速器来做立体的验证方案，以此来弥补动态仿真性能的不足；同时，基于FPGA开发设计的公司也在引入动态仿真来提高模块的完备性。

 

为什么是这样呢？

 

这显然是一个融合的过程，谁都离不开谁了。在20年前，PC性能腾飞而ASIC功能没那么复杂的情况下，仿真工具可以动态地利用服务器阵列的资源来满足快速的功能验证需求；而现在，无论单核的性能相比于爆炸性的SoC系统复杂度，还是迟迟才推出应用的多核并行仿真，在大型SoC系统仿真面前都已经非常吃力，于是FPGA/Emulator又迎来了它们的市场。有趣的是，虽然此消彼长，但提供完整解决方案的玩家名单依然没什么变化，可谓是左手倒右手吧。

 

 

再回到FPGA测试，它们也同样面临着设计变得复杂的问题。比如，在以前10个模块做完简单测试以后就可以进行系统集成和FPGA测试，但现在这个系统的模块数目至少得再加个0。那么如上图所示的FPGA倒梯形的结构随着系统的复杂，它的底层模块在没有经过充分验证就直接做系统测试所带来的系统性风险将越来越大，同时由于系统层的缺陷数目增长也将越来越难以控制和调试，这都将危及到系统集成的整座大厦都有坍塌的风险，所以以往的快速而有效的手段在日趋复杂的系统面前也需要与仿真进行融合，使得底层集成的模块功能可以得到更全面的验证。

 

于是，FPGA测试需要转型，需要融合成熟的动态仿真方法（UVM），这不是简单的孰优孰劣的问题，而是基于提高验证完备性的考虑，我们需要在融合的过程中考虑如何解决以下问题。

 

如何改造升级已有的FPGA测试环境？

这需要认识已有的资源（激励、监测和检查如何实现），再考虑如何整合。例如，原有环境的哪些组件可以复用到新的环境中，原有环境的比较方法是否需要更新。

 

如何融合仿真环境和FPGA环境？

融合的方案不止一种，根据实际来选择方案。一种相对经济的方案是将仿真环境同FPGA环境剥离开，各自独立维护。前者提供模块验证环境和系统验证环境，后者只提供系统验证环境；另外一种更为长远的方案（也需要更多的前期投入），即是考虑类似于emulator建议的双顶层验证结构，即验证环境在仿真器，而DUT在FPGA或者仿真器（与验证环境同一个或者另外一个）。这种方案带来的直观收益就是，在能够承受FPGA与仿真器做协同仿真、速度降低的同时（仍然远高于仿真速度），能够有统一的验证环境来做软件开发（FPGA+仿真器）以及设计调试（单纯的仿真环境）。

 

如何复用仿真环境和FPGA环境的测试代码？

环境复用和融合需要实现，同时，也要考虑如何复用测试代码。如果你之前阅读过

SV及UVM接口应用篇之一：DPI接口和C测试（上）

SV及UVM接口应用篇之二：DPI接口和C测试（下）
那么你需要明白FPGA的功能模块不一定具备处理器单元，这就需要我们提供外部的虚拟处理器，在系统层面上实现C/C++软件开发。这个时候，如果在上一个问题中能够提供（FPGA+仿真器）的协同仿真结构，那么在仿真环境一侧例化虚拟处理器单元，提供C接口与FPGA中的设计模块交互，将有利于接下来FPGA在更高系统中的软件层面的联调。这一经验同样来自于，FPGA设计的开发团队往往非常紧凑，即设计、验证、软件的人员沟通较ASIC/SoC的人员要频繁和顺畅，这种高效的团队沟通也将为软件测试用例的早期开发和调试打下良好的基础。

 

在FPGA环境测试遇到问题时如何在仿真环境中重现和调试？

在完成两者环境和测试用例的融合以后，我们还应当考虑，如何在FPGA测试环境遇到问题以后，可以将问题重现到UVM环境。如果FPGA环境和仿真环境是独立的，那么应该考虑的是首先如何重现激励，继而将在两个独立环境中暴露同样的设计问题，并且均能在环境中检查出来；如果采用的是FPGA+仿真器的协同仿真结构，那么就需要考虑如何确保在协同仿真环境中发生数据错误的随机种子在接下来的单纯仿真环境调试中可以重现数据错误，继而展开调试。

 

以上的每一个问题都将在接下来的章节中一一得到详细的讨论。有一些话题，将在结构层面展开讨论，有一些话题我们将给出一些参考代码或者实现建议，便于读者在FPGA测试环境转型过程中参考。