BFM的作用是完成TL和RTL之间的数据同步和交互。简单的来说，BFM一方面完成了将RTL级的总线传输信号抽象为事务级的数据包的作用，封装了总线传输中繁琐的具体时序信息，只将其中的地址、数据等有用信息提取出来，形成TL信息，完成了抽象程度的提升；另一方面，BFM根据特定的接口标准，在TL数据的基础上，补充其缺失的RTL时序、信号信息，还原为RTL数据，即完成抽象程度的下降。因此，BFM与模块接口的标准是紧密结合的，一种BFM负责一种接口标准的TL和RTL数据的相互转化。下面以我们验证平台中的BFM为例，说明TL数据访问与RTL数据访问之间的对应关系。验证平台中的BFM以AHB总线为接口。
3．2 BFM的具体实现
    本文中的BFM可以分为两个组成部分：与SCE-MI协议的接口和与AHB总线的接口。与SCE-MI协议的接口部分完成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遵守SCE-MI协议的规定也正是出于通用性的考虑。

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

                                  

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