SoC软硬件协同验证方法及平台设计

SoC软硬件协同验证方法及平台设计

韩正飞

(南京大学微电子设计所MG0922083)

【摘要】软硬件协同验证是SoC设计的核心技术。本文先介绍了基于SoC设计的软硬件协同验证方法学原理及其验证流程。然后分析了SoC开发中采用的3种软硬件协同验证方案，对其各方面性能做出比较并提出应用建议。接着基于指令集仿真器(Instruction Set Simulation,ISS)仿真方法的基础上，设计了一种基于SystemC和ISS的软硬件协同验证平台。并对该平台的架构和功能做了简单的介绍。

【关键字】SoC 软硬件协同验证验证方法验证平台

一、引言

随着以IP(Intellectual Property)核复用为核心的设计技术的出现，集成电路(Integrated Circuit,IC)应用设计已经进入SoC(System on a Chip)时代，SoC是一种高度集成的嵌入式片上系统。芯片设计中的任何缺陷都会导致整个芯片的设计失败，因此，在流片之前，必须对芯片的系统功能实行验证。软硬件协同验证技术的概念很早就被提出来，但直到集成电路工业进入超大规模(ULSI)时代，以IP设计重用为核心的系统集成芯片(SoC)技术成为研究热点，软硬件协同验证技术才得到更多的关注和重视。

所谓软硬件协同验证(hardware/software co-verification)是指在硬件的物理原型(电路板或芯片)生产出来之前，通过一个系统模型来运行软件，以此来检查硬件设计中的bug、软件中的缺陷及软/硬件接口中的错误。

软硬件协同验证的主要目的是验证系统级芯片软硬件接口的功能和时序，验证系统级芯片软硬件设计的正确性，以及在芯片流片回来前开发应用软件。其优点是使软件/硬件并行开发成为可能，缩短了设计周期，减少设计投入。对于软件工程师来说，可以较早地在硬件模型上调试软件；对于硬件工程师来说，软件也可看作是对硬件验证的一个额外的激励。

二、软硬件协同验证

2.1传统的协同验证系统

传统的协同验证系统由一个硬件执行环境和一个软件验证环境组成，通过事件和命令在2个环境中进行控制和信息交互，如图1所示。硬件仿真通过运行在工作站上的软件程序模拟，通过设定的通信接口与软件执行模块交互。软件执行模块用于产生总线周期的序列，序

列被转换成信号事件或命令集后用于驱动对应的硬件执行命令；同时，对硬件的总线周期响应进行采样。软/硬件仿真使用的是独立的进程，一般采用进程间通信(Inter Process Communication,IPC)技术和总线封装器来实现软硬件仿真器之间的通信、同步和信息交互。

2.2 传统的协同验证步骤

在软件方面，软件验证主要建立系统中处理器的虚拟原型(virtual prototype)，通过编译器、调试器和仿真器来实现。在硬件方面，将软件调试验证正确的应用程序作为测试向量加入到硬件测试平台(testbench)中，进行硬件仿真，仿真正确说明硬件的RTL描述功能正确，然后依次进行综合，布局布线，检查布局布线后时序和逻辑是否正确，最终采用硬件加速器来完成整个验证过程。协同验证过程的基本框架如图2所示。

如图2所示，软硬件协同验证流程主要分为3个步骤：

（1）算法级设计和硬件系统结构的系统仿真验证：主要利用软件算法，验证在硬件结构上实现的可行性。利用高层次语言，如C，C++或System C，进行算法级的仿真。同时进行软件和硬件部分的划分，明确软件和硬件完成的工作。

（2）代码和硬件HDL语言的协同仿真验证：主要是对SoC当中CPU的软件虚拟原型（virtual prototype）和利用HDL语言或网表模拟出来的硬件系统进行协同仿真验证。这个阶段主要应用C语言和HDL语言进行交互，进行仿真。

（3）软件代码和实时硬件模拟系统的协同仿真验证：在系统设计原型的FPGA硬件模拟系统进行验证，这主要是对芯片的功能、硬件实时性和系统的可测试性设计（Design for Test）进行仿真验证。

三、软硬件协同验证技术的实际应用方案

在实际应用中，常用的有3种软硬件协同验证方案：ISS、CVE、FPGA/EMULATOR。

3.1 ISS方案

图3是ISS方案的系统结构图。ISS方案采用ISS(例如ARMulator)代替CPU执行软件，并通过接口与外设及内存通信。该方案中的外设模型一般用C语言建立，其中ISS可以是指令级精确的，也可以是指令周期级精确的，还可以是具有硬件系统的时钟级精确，又称为总线功能模型（BFM)。但是，如果所有的外设模块都是C模块，则整个系统不能达到时钟级精确度。通常ISS都带有调试程序，用于控制ISS执行指令。

3.2 CVE方案

图4是CVE方案的系统结构图[2]。CVE方案以seamless的CVE软件为基础，是一种使用两个仿真器进行仿真的方案。CVE通过自身的一个内核将软件仿真与硬件仿真结合。它支持多CPU的模型，具有高效的软件调试能力，可以单步执行CPU指令，随时查看寄存器和内存的情况，同时，它提供了强大的信号观测能力，调试者可以通过设置断点、触发条件等进行有效调试。

3.3 FPGA/EMULATOR

图5为FPGA/EMULATOR方案结构图，FPGA/EMUALTOR方案是将外设、内存等部件综合后用FPGA实现，而CPU则用真实的CPU或FPGA本身集成的CPU实现。这些系统一般可以加一个专门的硬件仿真器进行调试，控制CPU的执行，并读取系统状态。FPGA 是最典型的原型技术。EMULATOR与FPGA相比的最大特点是集成了多个CPU及多个FPGA，其功能更强，但造价更高。

3.4 三种方案的比较

以上3种方案各有优缺点，本文从以下6个方面进行比较。

（1）验证速度在仿真速度方面，FPGA/EMUALTOR采用硬件实现，其速度最快，ISS方案速度中等，CVE方案则最慢。

（2）时间精度在时间精度方面，FPGA/EMUALTOR、CVE都可以达到时钟级精确，而ISS 方案在一般情况下精确度不是很高，大部分为指令级精确。

（3）调试性能：ISS方案一般用来验证系统在算法级上的正确性，对硬件的调试帮助不大，CVE方案具有最强大的调试性能，支持软件的单步执行，随时查看寄存器、内存状态，还可以用硬件仿真器生成波形来调试硬件。因此无论硬件还是软件，CVE的可调试性能都非常高，FPGA/EMULATO的调试性能比较差，它一般是在经过仿真器仿真后再做原型验证，调试时需要通过增加JTAG之类的工具才能看到内部状态;

（4）准备工作：ISS方案需要外设的C模型，一般通过工程师做大量前期积累或者其他途径得到，CVE方案只需做好软硬件配置即可，相对工作量最少，FPGA/EMULATOR需将硬件下载到FPGA中，只有少量的准备工作。

（5）价格成本：ISS方案成本不高，需要一个ISS和一些外设模型，CVE方案需要购买SeamlessCVE软件，比ISS成本高;成本最高的是FPGA/EMULATOR，硬件购买费用很高; （6）适用范围：ISS方案比较适合算法验证和具有一定程度的硬件系统调试，CVE方案适合软硬件的联合调试，尤其在系统未经过充分验证时，需要较好的性能调试。FPGA/EMULATOR适合在经过仿真器验证无误之后，用于原型验证。

将上述比较结果整理如下表所示。

四、软硬件协同验证平台组成结构

传统验证系统一个较为显著的局限是IPC通信会和主机系统的其他通信发生冲突，造成仿真性能的瓶颈。其次，总线封装器和ISS之间的接口是私有的，当新的内核被集成到协同验证系统中时需要修改ISS以支持验证系统的IPC原语，从而增加了复杂度。另外，验证的抽象层次低，存在精度高但速度慢和效率低的问题。

4.1软硬件协同验证平台组成

这里提出的一种软硬件协同验证平台架构在传统验证系统的基础上引入SystemC实现建模，并利用网络传输软件和硬件执行环境之间的数据，实现信息交互，如图6所示。

软硬件协同验证平台按照功能可以分为4个部分：(1)基于硬件描述语言编写的执行程序，应用VMM方法产生软件模型，即ISS需要的测试汇编文件集(TestCase)；(2)利用硬件描述语言编写的RTL级模型，在加载软件模型部分发送过来的内存映像文件后生成RTL级仿真结果；(3)利用SystemC语言编写的仿真模型，在加载内存映像文件后生成SystemC仿真结果；(4)ISS仿真模型，加载测试汇编文件集(TestCase)后生成ISS仿真结果。

软硬件模型与汇编文件集生成程序分别在不同的机器上运行，软/硬件之间通过网络以Socket接口方式实现数据传输和信息交互。按照网络通信可将平台分为客户端和服务端，客户端实现测试向量(TestCase)文件的产生，服务端对接收到的测试向量进行编译，产生验证