RTL仿真一直是IC设计生产流程中非常重要的一个环节。但是，随着设计规模的不断增大和功能复杂度的不断提高，较长的仿真时间就成了制约验证工作的主要瓶颈之一，运行数天甚至数周的超长测试用例是非常影响验证效率的。于是就引入了许多用于缩短仿真时间的技术，其中极为有效的一种是使用硬件加速器。硬件加速技术已经存在了近十年，起初用于取代定制的FPGA仿真板，到现在，它已经成为一种必不可少的验证工具。

到现在，硬件加速技术已经发展演进为SA（simulation acceleration）技术了，SA技术不仅继承了硬件加速的的优点，同时还融合了HVL（high level verification languages）testbench的优点。在SA模式下，设计在硬件加速盒里面被编译和运行，而HVL testbench是在连接到硬件加速盒的模拟器里运行的。使用SA模式时，相比testbench的运行速度，设计的运行仿真速度快到可以被忽略。SA模式就像在超高速计算机运行RTL仿真。总体仿真速度不再由RTL仿真速度的限制，这对验证效率的提高无疑是巨大的。PMC公司是最早对SA技术进行探索的公司之一，2011年，在试点项目中，他们采用了复杂的混合的语言(Verilog, VHDL 和SystemVerilog)进行了RTL设计，直到2014年后，SA技术得到较成熟的应用。这篇文章要介绍的将Testbench和多种语言编写的设计应用于仿真加速的方法。

SA模式对Testbench的要求

首先，必须要说明的是，并不是所有测试平台或测试用例都适合在SA模式下运行，这里进行简要介绍。

SA的主要性能影响因素之一是测试平台的执行时间。执行时间主要是用来记录典型的仿真运行时间，确保testbench使用的时间少于总的CPU时间的 2-3%，这样才能说明SA模式的加速是有意义的。较小的设计往往产生较高的测试平台CPU使用率，所以它们一般并不适用于SA模式。有些testbench在搭建时，在testbench与DUT之间有过多的交互作用，例如在每个时钟都要持续监视RTL的信号的情况，这类testbench也不适用于SA模式。

另一种可能影响SA性能的地方出现在测试平台和DUT硬件加速盒之间的同步和数据传输上。不过相比于testbench的执行时间以及软硬件之间环境切换的影响，这个影响实际还是比较小的。

还有一种可能影响SA性能的因素就是把设计文件下载到硬件加速盒以及上传最终仿真波形的时间。如果对于非常小的testcase，上传和下载的时间可能会超过testcase的执行时间，这导致的最终结果不是加速仿真，反而使仿真时间变长了。所以适用于SA模式的理想testcase应该有相对较长的运行时间，太简单的testcase就没必要使用SA模式了。

仿真类型

仿真测试平台在SA模式下运行的移植是一个多步骤的过程。第一次把它引入到硬件加速盒里的时候，任何人都不可能一下子就完成了所需要的testbench的修改升级并且以SA模式正常工作。并且由于硬件加速器的成本高，通常许多验证团队共用一个硬件加速器，使用硬件加速器直接调试显然也不太经济。所以较为可取的方式是，把移植过程拆分成四个部分，每一个部分都用于处理不同的问题。

1. 正常仿真。建议使用相同硬件加速器供应商的的相同模拟器，不同的模拟器在RTL的行为上会有一些细微的差别。首先，选择一个testcase 作为首次引入的目标，这个testcase 不要太长，也不要太短，便于观察RTL行为又不用反复调试就好。执行这个testcase 完成仿真，保存种子和日志文件，这些在接下来的步骤中会用到。

2. SA_SIM仿真。SA_SIM仿真用于调试testbench中的SCEMI管道和DPI集成的错误。DUT仍然在RTL仿真器中运行，testbench开始以SA模式运行。使用之前保存的种子重新运行所选的testcase ，仿真结果应与前一个步骤保存的日志文件相同。如果不同，就要找出原因并修正仿真结果的所有差异。

3. SA_SW仿真。SA_SW仿真使用主机模拟器同时运行testbench和DUT。DUT被综合成二进制文件，在主机模拟器中运行的硬件加速器模型里进行仿真。再次用保存的种子重新运行之前所选择的testcase ，并比对仿真结果。这一步的作用是找到将RTL综合到硬件加速盒里时可能出现的bug。

4. SA_HW仿真。SA_HW仿真里，testbench 在主机仿真器运行，DUT在硬件加速盒中运行。首先，在tbrun 的模式下进行SA_HW仿真。这时硬件加速盒是基于SA_HW仿真的lock step技术运行仿真的，这样在硬件加速盒的软件模型和硬件加速盒的实际硬件实现情况中潜在的问题都可以被标记。最后以SA_HW仿真的标准状态运行实际的SA仿真，查看仿真效果。

编译多种语言编写的RTL代码

经验表明，SA移植过程中最麻烦的一点就在于编译要装载到硬件加速器的设计文件，这些设计文件是由复杂的混合语言编写的，同时包含Verilog、 VHDL以及SystemVerilog。就算是所有的编译工具都来自于一家EDA工具供应商，SA工具链中Verilog、 VHDL和SystemVerilog代码的编译和执行还是会有些许差别，这极可能造成SA仿真和普通仿真的结果不一样。

当用户编译时遇到的工具问题，建议用户首先确认代码无误，然后把问题尽快提交给工具供应商。如果问题得以确认，一般数天后工具供应商会发布SA工具链的补丁包来解决这个问题。如果EDA工具不存在问题，得到了设计，编译SA就是直截了当的了。编译流程可以复用大多数编译脚本和ICE编译流程原件。一般编译用于SA模式的RTL设计文件需要以下几个步骤。

1. 定义SA编译库的路径。建议把SA编译库和仿真编译库设置为相同的路径。

2. 生成可综合的RAM模型，使用的脚本和ICE模式中使用的RAM生成脚本是一样的。

3. 找到设计中的所有非可综合行为组件，比如RAM模型、DesignWare 或者gtech 库，并将它们转化为可综合的版本。

4. 分析仿真编译脚本，用SA编译器指令替换掉仿真编译器指令（比如用vhan替换ncvhdl，用vlan替换ncvlog），另外再添加 +rtlCommentPragma 和 synthesize_on/off 指令来完成编译。

5. 分析完RTL代码之后，就要调用综合器把RTL代码综合成加速器识别的二进制文件。因为设计中的所有内容都要最终被综合成在硬件加速盒可用的电路，所以编译器会报告编译过程中遇到的不可综合模块，工程师一般还需要反复修改代码几次，最终让所有的RTL代码均可综合。

TESTBENCH的完善

为了让testbench 都能更好的支持SA模式，常常需要修改拓展VIP（Verification IP）组件，并且嫁接上可复用的TB_CTRL（testbench controller），TB_CTRL能够使testbench 和硬件加速盒之间更好的相互联系作用。VIP组件和TB_CTRL单元都可以在不同的验证工程中复用，所以一旦将他们创建出来，可以非常有效的减少移植其他的testbenche使之支持SA模式的麻烦。

优化一个第三方的VIP使之支持SA模式可能是移植过程中最大的挑战了，除非VIP和硬件加速器是来自同一个供应商，在市场上是很难找到现成好用的加速器VIP了。关于如何复用内部VIP以及有特定功能的testbench，这是另外一个复杂的问题了，原文所附参考文献中有所提及。下面只是简要介绍testbench和硬件加速盒间的信息交互方法。要注意的是具体使用哪种方法要看具体需求，没有可以满足所有需求的万能方法。

• SCE-MI（标准协同仿真建模接口）。这种方法优先使用于testbench和硬件加速盒之间要进行高速数据流传输的情况。SCE-MI就像是内置到SA工具里用于完成一些辅助功能，如查询队列状态等。

• E/SV DPI接口。这种方法优先使用与testbench或VIP要完成一些控制命令的情况，它就像端口方法一样，可以允许Specman e语言调用SV功能，反之也是。

• MARG （direct memory copy）接口。这种方法优先使用于零时刻testbench和硬件加速盒之间要传输存储器块内容的情况。MARG接口极其适用于一次性的存储和读取的情况。

• Tcl deposit/force/value命令，实际上，testbench 仍可以使用Tcl deposit/force/value命令与DUT进行信息交互。这种方法当然比较慢，但是这是一种非常方便的调试方法。

项目参考说明

下表中列出的是一些可供参考的基准，项目A是我们开始试运行的项目，花了一年时间学习SA的基本原理并处理各种工具问题。此后，项目B把SA方法更精细化了，并且准备将其投入更广阔的应用，在完成项目B的时间内，构建了所有的SA编译脚本、TB_CTRL复用组件、移植了两个相关的VIP使其支持SA方法、还解决了一些偶然的工具问题。直到开始项目C时，EDA工具不存在问题，也没有新的VIP要求支持SA，成熟的SA方法只花了3周就解决了仿真验证问题。

上面的参考结果中，我们可以看到其实加速因子并不是特别高，主要原因在于在上面三个项目里面，我们主要考虑的是尽快将SA模式加以应用，缩短验证时间，而不是怎样去提高加速因子。

结论

实际项目里，我们还是要权衡一下，是否要使用SA模式，因为不管我们再怎么完善testbench，SA模式也不可能像ICE模式运行那么快。SA模式的优势在于保证HVL testbench的灵活性的同时，缩短仿真验证时间，我们做过一些投资回报率的计算，主要分析了硬件加速器的使用费和license费用，发现只要SA的加速因子不低于30-40x，使用SA方法至少不会让你亏本。同时SA模式还有一些无形的收益，比如减少你debug的时间，以及让验证组工作效率提高等。

您可以在手机移动端同步关注订阅号“路科验证”。

如需转载请联系路科验证，并注明出处“路科验证”。