利用Ｇｅｍｉｎｉ平台实现仿真加速

摘要：目前硬件加速技术已经逐步应用于实际的设计验证。文章通过介绍SpringSoft公司的Gemini硬件验证平台的基本功能和应用，结合Co-Simulation方式在实际项目中的应用，给出使用该套验证系统对项目的实际效果和意义。

关键词：硬件加速器 混合仿真 仿真加速

随着FPGA技术的发展，将设计提前实现于FPGA上，使得设计更早有效且高速的测试。从客观上看，我们需要这样一个平台，首先它能够以比较高的仿真加速比进行运行，其次它的debug方法应该是能够易于硬件设计和验证工程师的使用，能够通过波形和信号分析的方法使设计中的潜在bug趋于收敛。

Gemini平台的功能简介

验证加速技术是利用FPGA阵列或处理器阵列将SoC设计的全部或者部分验证工作交由硬件完成，其余部分由软件仿真器完成，从而摆脱仅仅依靠软件仿真器进行仿真的方法以达到加快验证速度的目的。Gemini是SpringSoft开发研制的硬件验证系统。在硬件上，Gemini具有适合SoC设计应用的可扩展体系结构。在软件上，层次化分割算法，时钟处理引擎，可扩展的软件架构包装了FPGA配置的专业知识。在侦错阶段，Gemini结合了SpringSoft广为人知的Debussy/Verdi界面，具有100%的可视能力。目前Gemini系统能够支持高达10M ASIC gate的设计。在ICE模式时钟速度可以达到10-100Mhz，混合验证（Co-Sim）速度比RTL软件仿真提高10-100倍。

Gemini进行验证设计

利用Gemini平台进行验证加速的平台设计不仅可以帮助硬件工程师更方便的从信号的全侦测性上快速分析和定位bug所在点，也能比较快的把设计应用于FPGA以帮助提高验证的效率。如果是有关图形或者图像的算法模块能够应用于Gemini平台上，将更有利于提高它的仿真加速比。

Gemini平台目前主要的工作模式有Co-Sim和ICE。Co-Sim工作模式主要是相对单纯依靠HDL仿真器来讲的，基本思路是把设计的一部分或全部模块放到Gemini平台上（前提是这部分代码可综合），把TB（TestBench）或者包括一部分的设计模块（这取决于验证分块的方法和代码是否可综合）仍然交给仿真器完成。Co-Sim的TB信息和激励来源于simulator的实际的仿真过程，尽管实现在FPGA上的设计可以执行得比较快（时钟频率可以是MHz级的速度），但是由于他们之间存在信息交互，仿真器速度明显慢于Gemini上FPGA实际run的速度，所以Gemini要等TB。但是这已经比把TB和设计的全部使用HDL simulator执行要快很多。对于硬件验证工程师来讲，把TB经过比较小的改动就应用于Gemini，在换取比较高的仿真加速比的同时又能通过波形debug将是一件非常乐于接受的事情。对于验证工程师来说，最容易上手的就是Co-Sim模式了。本文重点介绍在项目中是如何使用Gemini Co-Sim模式进行验证的。

（一）Preparation Stage

对于Cosim模式最重要也就是首先要明晰哪些是需要用仿真器去执行的，哪些是需要移植到Gemini硬件平台上执行的。首先分析笔者当前项目的TB和设计的图1（Figure1左边框图部分）。在当前的SoC设计中，在内部算法模块处理中最消耗仿真时间的就是JPEG模块和MP4模块了。如果使用Gemini平台，就会比较方便于验证工程师比较快的发现和定位问题，为了能够达到让算法模块加速验证的目的，需要对上面这个TB的结构进行一些划分以Co-Sim的形式实现在Gemini平台上。

因为主要验证的是这两个相对独立的算法模块，所以首先把整个验证系统做一个简化，笔者把TB和设计的顶层实现在simulator上，因为pad部分是FPGA无法兼容和实现的，RST和CLK部分是相对比较复杂的，外设的仿真模型又是不能综合的也必须放在仿真器这一端，把实现在simulator上的这一部分划分称之为的WS（WorkStation），把MP4和JPEG这两个大的设计模块和其他相关功能模块放到Gemini平台上。

那么这两个模块都会用到一些memory模块。这些memory最初在TB里是以一些仿真模型的形式存在的。我们是把这些memory以仿真模型的方式放在WS一侧，还是以FPGA block memory的形式把它放在Gemini这一侧？

通过对Gemini Co-Sim工作特性的了解，我们知道WS和Gemini之间如果信息交换越多，就越会影响Co-Sim的仿真加速性能，特别是使用dump波形的方式进行debug时。所以较好的办法就是把这些memory实现在Gemini这一侧。由于FPGA的memory拼装形式和ASIC或者我们所使用的仿真模型不一样，所以我们首先要对原始TB中的memory模型做一些修改，这些修改的目的就是为了适合Gemini以比较规范的方式把它们进行再实现。对于这一部分，Gemini工作手册中也做了比较详细的描述。做好了memory的再实现之后，基本上有了实现在Gemini平台上的TB的雏形，但是还是要再仔细核查实现之后的WS和Gemini之间有多少根clock source穿进Gemini，按照规范，这些clock source不能超过16根。完成这些为了Co-Sim的准备工作之后，我们需要在simulation平台上以这个修改好的环境执行一下simulation，当然只是简单的执行而不是大批或完整的simulation，目的是要确认clock工作正常或初始指令运行正常（虽然TB没有做过大的改动，但是对于验证来讲，任何的改动都要进行重新确认）。修改之后的为Gemini setup的验证环境就如图1右边所示。

（二）Setup Stage

完成Co-Sim之前的准备工作之后，我们开始进入setup阶段。这一步我们只需按照最新版本的Gemini setup流程使用一键式操作就能完成整个setup flow了。但是在做一键式操作之前需要设定一个RCF文件。RCF文件有这样几个主要功能：划分WS和Gemini，即告诉工具哪些设计是要放在Gemini上的，哪些设计是要放在WS上的；clock源的指定，即刚才前文所说的需要指定哪些clock是main clock从WS送给FLB的；probe信号，Co-Sim的波形上（默认情形下，Co-Sim dump的波形只有WS的全部信号和WS与Gemini之间的接口信号）。

（三）Runtime Stage

当Setup的工作完成之后，就可以开始执行验证了。需要注意的是：首先，run的这个project是Gemini setup flow重新生成的库系统，要想在Gemini平台上执行仿真验证，软件执行时是后台直接把做好setup后的二进制文件下载到Gemini硬件平台上，并通过PLI建立起simulator和硬件加速器之间的联系；其次，以前的TB的文件列表需要做一下更新，前边我们指出，把MP4和JPEG的设计完全实现在Gemini上，那么以前TB文件列表中的这一部分文件列表就相应的要去掉，取而代之的是Gemini帮我们综合好的文件，这个文件是Gemini做好setup flow之后的实现在Gemini上的FPGA网表；再次，需要注意如果memory也实现在Gemini上，那么文件列表中的这一部分内容也要向应的注释掉；最后，我们需要在Gemini执行仿真，还需要添加一些在simulator平台上没有的Gemini的环境变量，以确保正确的资源被调用。

效果评估和分析

表1是通过实际记录linux server仿真时间得到的仿真速度的比较。从记录的结果上看，Co-Sim明显比单纯使用simulator快很多。

第一，Co-Sim的WS和Gemini之间的划分，这中间的接口信号越多，他们之间造成的信息交互就越多，信息交互越多，由于WS远远慢于Gemini，FLB的高速度就越容易被WS拖累下来，这样也就影响了整体的仿真加速比。JPEG测试用例由于还用到了外部的senor model，因为这是做JPEG编码的输入源，由于这个仿真模型是不可综合的，所以在最初划分时只能把它放在WS一侧，所以WS和FLB之间的数据交换量就陡然上升，这导致了加速比的迅速降低，当然这也是进行Co-Sim的一个瓶颈，如果我们使用可综合的sensor model把它放到Gemini上，那么相信这个加速比将会有显著的提升；第二，测试用例的复杂度，越简单的验证测例，系统调用越少，执行得越快，也就越容易获得比较高的仿真加速比；另外影响仿真加速比的原因还会有一些，比如是否需要分析波形，波形中所需要观测的信号的多少，这会对仿真加速比造成比较明显的影响，这一点的原因和在仿真器上单独执行的原因是一样的；此外上面列表中所示的CPU rate，CPU服务器的占用率也对加速比有影响，如果CPU不能100%的保证给当前simulation使用，那么势必会造成任务的分时分流，也会使得加速比有不同程度的影响。

结论

SpringSoft的Gemini硬件仿真加速器，使得它对整个项目的验证周期上有了一个比较明显的改善，这虽然在验证的初期开发上并不能感受明显，但是当一个项目的验证进入中后期，及时引入验证加速系统，会比较明显的改善纯粹使用仿真器进行仿真所耗用的时间，特别是对于那些比较复杂的算法模块时特别有帮助。

（作者单位：上海交通大学微电子学院）

参考文献

李嘉辉.新一代验证加速技术[J].中国集成电路,2007(1).