用Palladium加快多媒体芯片的系统级验证

引言

目前，多媒体芯片的开发面临着集成度高、产品上市时间紧迫、市场变化迅速等诸多挑战。不同于传统的ASIC，多媒体芯片通常是复杂的SoC，在芯片中除了核心的音视频处理电路以外，一般都有MCU、DSP或CPU来协助音视频处理电路完成系统级的控制功能，或者由DSP、CPU完成某些音视频算法。有的多媒体芯片内部甚至集成了多个MCU、DSP或CPU内核。另外，大部分多媒体芯片都需要与外部CPU协同工作，如PC摄像头多媒体芯片需要和PC一起工作，移动终端多媒体芯片需要和基带处理器一起工作。

中星微电子公司致力于多媒体芯片的开发，并可提供完整的软件和系统解决方案。根据功能的不同，软件可分为驱动程序、固件和应用程序。对多媒体芯片进行系统级验证要同时验证驱动程序、固件等软件部分。基于NC-SystemC，中星微开发出系统级的验证平台，该平台用SystemC集成芯片的驱动程序和应用程序，用Perl来解析测试命令，用NC仿真器进行SystemC和Verilog的联合仿真，较好地解决了软硬件联合仿真的问题，大大提高了验证效率。但由于多媒体芯片规模比较大，依据一个系统级的仿真向量对芯片进行仿真时往往需要几个小时，比如仿真一秒钟的声音需要7～10个小时，仿真一幅1.3M或3M的图像需要1～2个小时。在验证初期，系统的硬件和软件都不稳定，往往需要花费大量时间来验证一个很小的问题，这严重影响了芯片的开发进度。在验证后期，迫于流片时间的压力，又没有时间对芯片进行充分验证。因此，工程师迫切需要一种新的验证方法来加快仿真速度，这就是硬件加速器。

目前，EDA市场上有许多硬件加速器的解决方案，Cadence的Palladium是基于定制CPU的解决方案，其它都是基于FPGA的。本文采用Palladium作为硬件加速解决方案。

基于ARM的STB

STB的硬件结构

基于ARM的STB(可综合测试平台)的硬件结构如图1所示。

传统的硬件加速器大多工作在ICE(电路内仿真)模式下，这种模式的测试激励由外部硬件设备提供。但是，由于硬件加速器的工作速度有限，无法实现与外部高速设备的直接连接，因此，需要采用Cadence的速率适配器(Speedbridge)来进行速率转换，这样又会增加整个验证系统的复杂程度。STB的基本思想是用可综合的RTL来实现SoC验证中用到的所有仿真模型。由于不同的SoC芯片对各个仿真模型的要求不完全相同，所以，仿真模型必须是可配置的。STB中利用ARM来配置各个仿真模型，并控制各个仿真模型对芯片进行操作，比如读／写芯片的寄存器、为芯片提供音视频输入数据等。同时，ARM也可以运行芯片的驱动程序和应用程序(实际上许多手机基带处理器都是ARM内核)。STB可以对中星微的所有多媒体芯片进行系统级的软硬件联合验证，能够降低验证环境的复杂度，实现更灵活的配置，同时不会降低性能。

STB的ARM子系统

ARM子系统包括ARM内核、多层AHB总线、连接到AHB总线上的SRAM控制器、SDRAM控制器、DMA控制器、外部异步接口CPU_BFM、AHB-APB接口电路，以及连接到APB总线上的中断控制器、定时器等。

多层AHB总线可以连接8个AHB主设备和8个AHB从设备。不同的AHB主设备可以同时访问不同的AHB从设备，从而提高了系统的数据吞吐能力。为了简化设计，多层AHB总线不支持Burst、Split、Retry和Error传输。为了适应不同仿真模型的需求，多层AHB总线对AHB总线的传输类型没有限制，支持SINGLE和所有INCR及WRAP传输类型。

DMA控制器协助ARM完成数据搬运工作。DMA控制器提供了4个硬件通道和4个软件通道，每个通道可以独立设置源地址、目的地址、传输长度和控制字。DMA控制器支持嵌套操作，即高优先级的数据传输可以暂时打断低优先级的数据传输，高优先级的数据传输结束后再继续进行低优先级的数据传输。为了提高数据传输的速率并尽量减少对多层AHB总线的占用，DMA控制器使用了两个AHB主设备：一个AHB主设备负责从源地址读取数据，然后把数据存人FIFO中；另一个AHB主设备则从FIFO中读取数据，并写到目的地址中。

CPU_BFM模拟了手机基带处理器的异步接口，用来访问其它异步接口。CPU_BFM是STB控制DUV的主要途径，ARM通过CPU_BFM可以读写DUV的寄存器，DMA控制器可以通过CPU_BFM把需要解码的音视频数据快速写到DUV中，或者把解码后的数据读入到STB中。ARM可以配置CPU_BFM的读写宽度，从而具有更大的灵活性。

AHB-APB接口电路提供了ARM控制大多数仿真模型的通路。ARM子系统中的中断控制器和定时器都连接到APB总线上。

STB的其它仿真模型

除了ARM子系统外，STB还集成了其它仿真模型，如USB OTG、UTMI PHY、图像传感器、ADC、SCI、SPI、IIC、NOR闪存、NAND闪存、SD卡等。这些仿真模型都连接到APB总线上，ARM通过AHB-APB来配置和控制这些仿真模型。

STB的软件架构

eCos(嵌入式可配置操作系统)是一种针对16位、32位和64位处理器的可移植嵌入式实时操作系统。eCos的源代码是公开的，其最大的特点是模块化，内核可配置。它的另一个优点是使用多任务抢占机制，具有最小的中断延迟，支持嵌入式系统所需的所有同步原语，并拥有灵活的调度策略和中断处理机制，因而具有良好的实时性。

STB的软件基于eCos构建，如图2所示。HAL、eCos内核、eCos内核API、硬件驱动程序构成了eCos的基本架构。DUV驱动程序可以调用STB硬件驱动程序、eCos内核API和HAL硬件抽象层。DUV应用程序调用DUV驱动程序和文件系统对DUV进行系统级验证。如果对相对比较简单的DUV进行验证，可以不使用文件系统和eCos。

Palladium的使用流程

Palladium是基于定制CPU的硬件加速解决方案。和传统的基于FPGA的硬件加速器相比，Palladium的编译速度快、调试能力强，并支持多用户。

Palladium支持SA(模拟加速)和ICE两种模式，后者的运行速度更快，但要求测试平台完全可综合。本文选用ICE模式，其流程顺序为模型替换、代码综合、编译硬件、编译软件、运行和测试。

模型替换

由于ICE模式只能处理可综合的RTL代码，所以需要把测试平台和DUV中所有不可综合的仿真模型(如存储器的仿真模型)都替换为可综合的仿真模型，把所有不可综合的语句如initial、PLI调用等放入∥synopsys translate_off／on语句块中。Palladium可以支持Pullup和Pulldown。

代码综合

对验证的测试平台和DUV进行综合，把RTL代码转化为门级网表。典型的综合脚本如下：

综合结束后可以检查报告文件hdlIce.log，如果有错误提示，就需要修改RTL代码并重新综合；如果有警告提示，则需要确认是否有问题。

编译硬件

对综合后的门级网表进行编译，把门级网表转化为可以在Palladium上运行的数据库。编译过程分为如下步骤：输入门级网表、设置设计、设置仿真器配置、设置时钟、设置编译、选项、预编译、ICE准备、编译。

编译软件

编译STB中在ARM上运行的软件，把编译后的软件代码存为数据文件。同时准备其它的数据文件，如音视频输入数据等。

运行

在Palladium上运行编译好的数据库，运行过程分为如下步骤：下载设计的数据库和各个存储器的初始化文件、设置内置逻辑分析仪的触发条件、设置波形信息、复位芯片、运行芯片、上载存储器内容和仿真波形。

调试

检查上载的存储器内容和仿真波形，如果不符合设计的要求，则查找相应原因。如果是测试平台和DUV的错误，则需要修改相应的RTL代码并重新进行综合、编译硬件和运行；如果是ARM软件的错误，则需要修改ARM软件、编译软件并运行。

Palladium的测试结果

对Palladium的使用可分为三个阶段：第一阶段主要测试Palladium的基本流程，重点是STB的硬件和基本软件；第二阶段用已经流片的设计进行测试，测试重点是STB的软件和Palladium的功能、运行性能以及测试能力；第三阶段用Palladium对正待开发的芯片进行验证。

Palladium可以正确仿真数字逻辑，并且能够处理多时钟和异步时钟。Palladium的运行速度大约是200 kHz～500kHz，比RTL仿真快了100倍～500倍。

使用Palladium时的限制在于，Palladium只能做数字逻辑的功能验证，不能做模拟电路的验证，也不能验证建立时间和保持时间等时序问题。为了达到更好的运行性能，需要对DUV中相关的时钟电路进行优化，所以该部分电路不能通过Palladium进行验证。另外，由于替换了存储器仿真模型和其它不可综合的仿真模型，所以该部分也不能通过Palladium进行验证。所有Palladium不能验证的部分必须采用传统的逻辑仿真器进行充分验证。

可以看出，Palladium不可能取代传统的逻辑仿真和FPGA原型验证，Palladium只是这些验证手段的补充。

结语

基于Cadence提供的Palladium硬件加速解决方案，本文构建了一个全新的验证平台。该平台加速了多媒体的系统级验证，使得工程师可以在流片之前对芯片进行更充分的软硬件验证。