引言

伴随着微电子产业的发展和摩尔定律的不断应验，IC设计的规模越来越大，集成度也越来越高，已经足以将整个系统集成到一个芯片中，这种技术就是SoC（System on Chip,片上系统）技术。相对于PCB（Printed Circuit Board，印刷电路板）级的系统，SoC的优点是显而易见的。SoC意味着更好的电路时序和更高的可靠性，但同时SoC也意味着更复杂的逻辑。为了解决SoC的众多设计难题，SoC设计方法学中最显著的一个特征就是IP（Intellectual Property，知识产权）的复用技术；然而系统的复杂度决定了不可能简单地将各个IP模块集成起来就完成了SoC的设计，SoC验证成为了一个新的问题。

在验证问题成为SoC设计的新的挑战之后，人们逐渐提出各种应对方法。其中，SoC软硬件协同验证的思想，切实反应了SoC验证中的问题和解决方法，越来越多地受到关注。本文以SoC软硬件协同验证思想为基础，提出一种验证平台的实现；同时考虑到SoC的不同设计层次，建立起统一的高速的系统级验证环境，有效的缓解了SoC验证中的关键难题。

1SoC软硬件协同验证

SoC设计中，系统的功能是需要SoC的软件硬件相互配合共同实现的，这就出现了软硬件接口的验证问题。在以往的系统设计流程中，由于软件的实际运行需要一个完整的可用的硬件平台，软件与硬件的接口的验证过程是在硬件全部开发完毕，至少获得了硬件原型之后。这样的开发流程最严重的问题就是，软硬件之间的接口可能出现设计上的错误。而要纠正这样的错误，要么修改软件来适应硬件（这一般都会导致系统整体性能的损失），要么修改硬件来适应软件（这又要导致硬件的设计、制造的更改，造成成本上升，设计周期延长）[1]。无论哪一种方法都是设计者所不希望看到但是又不能保证避免的。所以，在SoC的设计方法学中，必须在软硬件的开发过程中，就完成硬件原型的建立，并开始软硬件的联合验证，即SoC软硬件协同验证[23]。

2混合建模实现SoC软硬件协同验证

本文在一般的SoC软硬件协同验证的基础上，提出混合建模方法（CoModeling），使用各种不同抽象层次的模型共同组成SoC硬件系统，直接为SoC的软件提供可运行的载体，来实现SoC软硬件协同验证。不同抽象层次的模型包括事务级模型、功能性模型的高抽象层次的模型和RTL模型。

2.1验证平台架构说明

如图1所示，整个验证平台的架构可以分为两个部分：软件建模部分，以PC机上软件的形式建模；硬件建模部分，以FPGA的形式建模。全部的硬件部分和除“ARM软件集成开发环境”之外的软件部分都用来建模SoC硬件系统，SoC软件可以直接在这个SoC硬件系统模型上运行、调试，如图中“ARM软件集成开发环境”所示。验证平台建模的SoC硬件系统，是针对ARM架构的SoC，以AHB总线为基础。AHB总线上的各模块为建模的基本单元。

图1验证平台架构

验证平台软件部分中最重要的模型是CPU的ISS（Instruction Set Simulator，指令集仿真器），用来模拟SoC系统中的CPU，可以提供软件代码执行时周期准确的仿真结果。平台中使用的是ARM系列CPU的ISS，称为ARMulator。ARMulator也是ARM CPU软件集成开发环境的直接载体，SoC的软件开发人员可以在基于ARMulator的集成开发环境中运行、调试源代码，与其在真实的CPU上的运行调试完全相同。其他的总线模型，如图中所示的IP3、IP4，用来描述SoC硬件系统中除CPU之外的一些模块，最好都是SystemC语言描述的事务级模型。事务级模型是RTL级硬件模型的抽象，省略了RTL级的实现细节，但是仍然以周期数精确等方式反映了RTL级模型的特点，是设计初期系统建模的常用选择。不过考虑到验证环境的通用性，再加上ARMulator本身也并不是SystemC语言的模型，而是基于C的功能性模型，验证环境自然需要同时支持事务级模型与功能性模型，因此，验证平台也支持其他总线模块以C/C++等语言描述的功能级模型。这些模型与ARMulator都连接到AHB总线的模型上，如图1中IP3、IP4所示，AHB总线模型负责完成ARMulator与软件方各总线模型间，以及与硬件方之间的连接。

验证平台硬件部分的物理载体是以FPGA为主的PCB板卡，以PCI总线为物理通道连接到PC机。SoC硬件系统中RTL模型形式的总线模块全部下载到FPGA内部，如图1中的IP1、IP2。由于FPGA内模块的RTL模型与CPU之间的总线通信数据可以在软件方得到良好的可观测性，对于以验证总线模块间通信正确性为目的的系统级验证来说，模块间通信数据的可观测性是足够的，这也就部分避免了硬件建模方法观测性不足的缺点。

因为软件方的模型抽象层次比硬件方RTL模型的抽象层次高，所以要想把软件方模型和硬件方模型组合起来形成可用的SoC硬件系统，就必须完成这两种抽象层次之间的数据同步和交换，这个任务是BFM完成的。BFM的具体实现将在后面详细阐述。总体的效果是，在软件方模型看来，BFM代表了硬件上的RTL模型，对软件方隐藏了RTL模型的实现细节，软件方只需要访问BFM，就得到了相应模块的数据；而在硬件方模型看来，BFM代表了软件方的所有总线模块，BFM驱动的RTL级总线信号就是由软件方中各总线模块的总线访问转化而来的。

硬件方与软件方接口的实现，以PCI总线为基础，遵守SCEMI（Standard CEmulation Modeling Interface）协议[4]。SCEMI是Accellera组织提出的用于规范协同仿效平台[5]中软件方与硬件方之间的接口的协议，是业界实际的标准，目前已被多个商业化验证平台支持。本验证平台的BFM遵守SCEMI协议接口，也是为了验证平台以及BFM本身的通用性。

如上所述，通过BFM的层次转接作用，软件方模型和硬件方模型得以完成连接，不同抽象层次的模型共同构成了SoC的硬件系统；而SoC的软件则可以以此硬件系统为基础，得到实际的运行和调试，最终建立起了混合建模的软硬件协同验证环境。

2.2以平台为基础的验证流程

基于上述验证平台，混合建模方法的流程如图2所示。在系统级仿真和软硬件划分之后，开始软件和硬件的并行设计，同时开始软硬件协同验证。协同验证过程可以分为三个阶段。在最初的验证阶段中，SoC硬件系统全部由软件方的模型建模。随后的阶段，开始完成硬件系统中高层模型中IP模块的逐个细化，此时，完成了RTL模块开发的IP可从软件建模部分移到硬件建模部分的FPGA中，还未开发出的模块，或是未完成配置的IP仍然由软件方的模型建模。这样，设计人员完成一个模块的细化，验证人员就可以开始系统级验证工作，而不必等到系统的全部模块全部完成细化后才开始验证。这样，一方面避免了验证等待设计的情况；另一方面，模块的逐个细化，可以使新出现的仿真错误的bug被定位到最后细化的模块中，有效降低了验证的难度。最后的阶段，除CPU之外，SoC硬件的所有模块都被逐步移到了验证平台的硬件方FPGA中，即基本完成了RTL级模型的SoC软硬件协同验证，之后向快速原型验证的迁移是也非常方便的，大部分的验证环境都可以复用。

图2混合建模方法验证流程

总的来说，混合建模方法的好处就在于：建立支持不同抽象层次模型的验证环境，从而在不同层次的验证中实现验证环境的复用，也使得在不同层次的设计过程中始终都可以进行系统级验证；同时糅合了软件和硬件建模方法的特点来解决RTL模型仿真速度慢的问题[6]，并且避免了硬件建模的低可观测性增加系统验证难度的问题。

3总线功能模型BFM

在上述的验证平台中，BFM模块起着混合建模方法中高层次模型与RTL模型间的转接作用，是验证平台中最为关键的组成部分。下面详细阐述BFM模块的概念和具体实现。

3.1BFM及事务级的概念

BFM是与TL（Transaction Level，事务级）的概念分不开的。TL模型是高于RTL模型的一个抽象层次，忽略了RTL模型中具体的信号和时序信息，但是保持RTL模型中模块的框架和模块间数据通信的信息和周期数。TL模型最典型的例子就是符合总线接口协议的模块，例如符合AHB总线接口的一个模块A，模块A的TL模型保持与其RTL模型相同的模块接口、模块边界以及内部功能，但是其内部功能只是功能性描述，不涉及硬件具体实现；模块的接口则是忽略了AHB总线接口协议的具体信号和相关时序，只关心其总线访问的关键信息，如访问的地址、数据、完成访问所花的周期数等。模型的优点是忽略了硬件具体实现细节，使得模型大大简化，模型的建立和仿真都不复杂，同时又保留了部分RTL模型的特征，使得仿真结果的精确度有一定保证，满足了系统级仿真的需求。

BFM的作用是完成TL和RTL之间的数据同步和交互。简单的来说，BFM一方面完成了将RTL级的总线传输信号抽象为事务级的数据包的作用，封装了总线传输中繁琐的具体时序信息，只将其中的地址、数据等有用信息提取出来，形成TL信息，完成了抽象程度的提升；另一方面，BFM根据特定的接口标准，在TL数据的基础上，补充其缺失的RTL时序、信号信息，还原为RTL数据，即完成抽象程度的下降。因此，BFM与模块接口的标准是紧密结合的，一种BFM负责一种接口标准的TL和RTL数据的相互转化。下面以我们验证平台中的BFM为例，说明TL数据访问与RTL数据访问之间的对应关系。验证平台中的BFM以AHB总线为接口。

3.2BFM的具体实现

本文中的BFM可以分为两个组成部分：与SCEMI协议的接口和与AHB总线的接口。与SCEMI协议的接口部分完成TL数据的接收和发送。与AHB总线的接口部分完成总线RTL信号的驱动，其实现的关键在于AHB总线协议的信号识别，这里采用有限状态机来检测、控制AHB总线RTL信号，下面给出状态机中控制AHB单周期总线传输的状态机状态转移图。如图3所示，状态HTRANS对应AHB时序图中address phase周期；状态WAIT对应Data Phase；状态SUSPEND对应AHB时钟停止，接收/发送TL数据的状态；状态ERROR对应总线传输出错的情况。

BFM是为了验证的目的而引入的一个额外模块。BFM本身的设计和验证虽然会增加工作量，但是由于BFM作为一个VIP（Verification IP），可以在不同的验证流程中得到复用。例如，本验证平台中AHB总线接口的BFM，就可以在不同的使用AHB总线的SoC验证中得到复用，相当于降低了BFM的开发复杂度。BFM遵守SCEMI协议的规定也正是出于通用性的考虑。

图3AHB单周期总线传输的时序图和状态机状态转移图

4实验与结论

为了说明验证平台的可行性和验证的高效性，以一个AC3音频格式解码系统为例，使用混合建模的方法构建其系统级模型并完成了验证。AC3音频解码系统的硬件架构如图4所示，系统采用ARM架构，主要由ARM处理器核、存储器以及解码硬件加速器IP、DAC（Digital to Analog Converter，数模转换器）构成。采用混合建模的方法，ARM处理器核以及存储器部分在软件方建模，解码加速器IP、DAC则使用RTL模型，在硬件方建模。实验证明，混合建模的验证平台是可行的，验证速度也在可以接受的范围内。

图4AC3音频解码系统硬件架构

总的来说，本文介绍的基于混合建模的SoC软硬件协同验证的方法，针对SoC验证挑战中最突出的问题，提出在SoC的设计过程中以混合建模的方式完成SoC整个系统的建模并开始验证，使系统各层次之间的验证平滑过渡，缩短了设计周期；同时也减少了软硬件之间不协调的可能性，避免了大跨度的设计流程的迭代，并且满足了系统级仿真的速度要求，没有影响验证的效率。因此，这种方法对于SoC的验证方法的不断完善有着一定的积极意义。