日志

验证的方法篇之五：硬件加速

热度 1已有 4799 次阅读| 2016-9-11 15:51 |个人分类:验证系统思想

我们之前介绍过的动态仿真和静态检查方法各自具有优势，然而它们都不具备的一个优势在于速度。尤其是在SoC的设计体量越来越大的时候，仿真速度成为制约验证进度的重要障碍。同时，由于仿真速度的限制，一些真实的用例也无法在RTL级仿真很快地呈现结果，这种困难在硅后软件测试发现问题反馈给硅前硬件团队时更加明显，因为通常这意味着硬件团队需要将耗时很长（相对硬件仿真的承受能力）的软件进行分析，找到可能的问题点，拆分软件场景，进而在硬件仿真上尝试重现问题。仿真速度的限制使得在硬件仿真方法上面无法很好地早期测试软件，而这一任务一般交给了另外两种方法：

虚拟模型平台（virtual prototype platform）
硬件加速（haradware acceleration）

上一篇已经讨论过虚拟模型平台，它的一项优势在于可以在硬件设计之前就用来建立硬件模型，并通过集成来生成虚拟模型平台，当然这也意味着新的工作量和技能学习需要引入进来。那么，对于硬件加速而言，它通常的流程是如何呢？一般需要等到硬件设计初步稳定，进而将其映射到可配置的平台上面，因此设计的数字电路部分可以通过更高的时钟频率（受限的，无法达到真实芯片频率）来仿真。这种方式相比于RTL仿真速度已经有了质的提升，稍后我们会比较速度的提升优势。

目前业界主要的硬件加速方式分为两种，即FPGA和专用的模拟器（emulator）。实际上，专用模拟器仍然是基于FPGA的定制产品，只不过比起商用的FGPA（Xilinx、Altera），它在硬件加速方面还有其它显著的特点：

内部可编程单元的连接网络方式不同于商用FPGA，这使得它在综合布线效率上面显著优于FPGA，而且对于内部可编程单元的利用率也高于FPGA。
外部连接网络的方式也不同于FPGA，这使得它可以通过多路复用技术实现片上存储共享而不再像FPGA一样需要定制的存储器，同时通过扩大I/O管脚数目来扩展器件之间通信带宽，以此来确保模拟器之间的通信速度不会成为瓶颈。
通过智能的内部数据采集和内置追踪存储器的帮助，这使得被映射到模拟器平台的所有逻辑单元在理论上都是可见的。这种采集方式在一开始建立平台时就可以通过定义采集信号列表来修改内部走线，同时也不会降低模拟速度。

模拟器的这些特点与FPGA可以很好地区分开来，而在实际工作中，FPGA和模拟器使用的场景也有所不同。FPGA原型验证主要是针对于小型设计或者单独的IP，而模拟器则是用来面向更大更复杂的SoC设计。FPGA主要是为软件开发提供平台，而模拟器则是为了硬件和软件协同验证和整个系统的测试。随着最近10年，模拟平台技术日趋完善和容易使用的情况下，与FPGA相比，越来越多的公司开始考虑使用模拟器，这主要是基于如下的因素：

更快的平台建立时间
更快的编译综合时间（从RTL到仿真运行）
良好的调试条件，例如信号可追踪，波形可保存，设置断点等等
模拟器的高存储量、可裁剪同时支持多个任务供多个用户使用
通过云端来购买使用流量使用远程服务，而不再像FPGA需要一次性购买，减低前期投入成本
容易操作

以下是FPGA同模拟技术的比较：目前业界的硬件加速标准并未达成一致，主流的三家公司实现硬件加速的具体技术也各有特点。我们在上面提到的模拟器（emulator），通过将设计逻辑映射到可编程单元的方式，主要有Veloce（Mentor）和ZeBu（Synopsys）。

Veloce采用的技术正是我们上面提到的，通过定制的可编程单元（非常类似于FPGA），不同的内部连接网络结构，以及透明的可调式电路实现在该模拟器平台上。平台上的每一块模拟器芯片都可用来模拟一小块的设计逻辑，而整个芯片的功能则是通过集成各个模拟器芯片实现片间快速通信来实现的。

而ZeBu不一样的地方在于它直接采用FPGA，而且通过技术也将透明的可调式电路技术和其它特性实现到FPGA中，多个FPGA进一步来组成完整的芯片功能，这种方式对于用户来看，与Veloce的区别并不大。

在此之外，Cadence公司的仿真加速器（simulation accelerator）Palladium也显得与众不同。它作为独立的加速器平台，内部包括有数量巨大的简单处理器，而每一块处理器又可以来仿真一小块设计的逻辑部分，并且将运算结果在它们之间传递。看起来，这些处理器每一个的运算速度都要低于我们的桌面处理器，但是由于我们通过成千上万个小的处理器并行工作，这使得实际的运算结果要大大高于独立处理器的表现， 同时，这些独立的小型处理器也支持透明化的调试方式。

通过这些模拟器，我们可以主机的验证平台到模拟器的激励场景，同时，假如我们需要设计一个USB器件，我们可能会将物理层的USB与模拟器相连，进而同电脑或者其它器件相连。这时候，我们将模拟器与真实世界的应用器件连接的方式（不同于与主机上的验证平台连接）称作是在线模拟（in-circuit emulation）。随之而来的问题是，一般真实世界的频率要高于模拟平台的频率，这时候我们需要为它们之间频率的差异搭建降速同步的桥接，我们称之为速度桥接（speed bridge）。它主要的功能是通过缓存快速端的数据，进而主动降低快速端的速度，来适配两端的数据率。

如果我们要将RTL的验证平台移植到模拟平台上，我们可以通过可配置平台来仿真待验设计，同时将验证平台运行在加速平台以外的主机上，这种方式被称为联合仿真（co-simulation）。这些激励可以由软件的验证环境从主机给入到可配置平台上面，或者由真实世界的接口给入到可配置平台。另外一方面，硬件加速的方法受到的限制是它们没有办法像RTL仿真一样透明地去观察硬件信号和内部逻辑，也无法很好地去调试硬件程序（例如设置断点）。

在实际联合仿真平台中，加速因子最大的受限因素在于平台外主机的验证平台运行速度，以及它与加速平台之间通信的速度。因此，在构建一个联合加速平台环境时，我们需要考虑的是：
尽可能地将验证平台实现为可综合的，这样有助于它们也可以被移植到加速平台上，从而减少对平台外主机的依赖性。
如果仍然有一些验证平台组件无法被移植到加速平台上，那么我们需要考虑主机与加速平台之间的通信速度如何可以变得更快，或者通信次数更少（少即是“快”）。这里，通过TLM通信方式，提高每次通信的信息量而减少它们之间需要同步的次数，也是值得采用的加速方法。

我们下篇将为大家带来关于功耗的《效能验证》。