功能验证已经成为开发SoC的主要问题。随着一些复杂SoC的规模超过两千万门，以及对开发和集成嵌入式软件的需求持续增加，软件模拟器已经力所不及。在设计过程需要几百万个时钟周期来充分测试和验证软件功能的情况下，软件仿真器的性能下降到1-5Hz。按照这种速率，软件调试需要几年的时间。如果设计项目组不能够投入这么多的时间，则意味着SoC芯片制造出来之后，在加电后的几秒内就会出现错误。
基于事务的验证允许代表单个或者多个时钟周期的大量数据不经多次调用而直接进入模拟器，极大地提高了模拟性能。到目前为止，验证环境都是基于事件的，也就是说必须在每个时钟周期甚至子周期提供验证数据。大多数硬件验证语言，如Synopsys的Vera或Verisity的e语言都是这样工作的。而事务则可以处理结构化可视数据类型。例如，一个以太网事务可以处理一个完整的以太网数据包；一个PCI DMA总线事务可以处理一个完整的突发传输。
仿真器外部接口的增强提高了验证通信接口的性能。例如，仿真器的DirectC调用使验证性能提高了大约一个数量级。然而这种仿真性能和验证完整性的提高，仅仅把软件调试周期减少到一年以内，仍然存在难以容忍的芯片设计质量和上市时间的矛盾。低成本的服务器集群也不是理想的解决方案，因为它们只能解决多个小型测试的回归问题，而不能加速像软件集成这样的线性过程。因此，对于大多数设计团队，真正的应用开发和调试过程只有在拿到硅芯片之后才能开始。
仿真
多年来，仿真和模拟加速硬件系统已经增强了模拟性能。这些硬件系统提供的性能加速从模拟加速器的几十kHz到Aptix系统的几十MHz。例如，运行在Aptix System Explore上的设计能够以实时或者接近于实时的速度运行，与实际操作环境相互作用。
过去几年开发的基于事务的系统级验证技术能够极大地影响SoC验证的效率。例如，Zaiq的方法包含一个事务处理器(transactor)结构，可以无缝地重新定位仿真和模拟。现在Aptix的最新产品是Aptix SoC Validation Lab。
Zaiq基于事务的验证技术将处理器定义为HDL总线功能模型(BFM)和C语言间的接口部件。C语言一侧包括测试控制、数据产生与检查，以及C/C++抽象层，后者执行数据操作，如分段与重组、打包和协议相关的功能。(见图1)。
这种面向事务的定位，加上平台库所提供的数据打包能力具有多个优点。首先，它为测试者提供了一个结构化的视角和简单的应用程序接口(API)。这可以把测试者从底层总线协议的细节中解放出来，只关注于产生完成测试目标所需要的条件，从而产生更有效率的测试代码编写和更高的测试质量。其次，它提供可重用性，即通过改变底层的BFM模型，为一个接口所写的测试可以运行在另外一个不同的接口上。最后，它可以提高性能。基于事务的传输层把C语言一侧的事务请求映射到HDL寄存器，控制BFM中的状态机。相对于发送周期性的信号请求，或者单个信号的编程语言接口(PLI)请求，使用事务传输层具有巨大的速度优势。在很多情况下，性能的提升超过几个数量级。
传输层的TestBenchPlus (TBP)软件支持线程，这样可以启动多个并发任务。这一特性加强了对被测试器件(DUT)的控制，更接近于仿真真实的系统级性能。
另外，Zaiq提供了一个应用型平台库和环境工具，以方便串行协议数据的产生与检查、回归配置管理、性能监控和控制功能、以及图形和命令行用户界面的使用。
基于事务的仿真
目前已有两项技术，基于事务的仿真和系统级仿真，问题是如何无缝地提供基于事务的仿真系统。在Aptix SoC Validation Lab以及其他与协同仿真相关产品的基础上，Zaiq和Aptix已达成技术和市场合作关系来组合这两项关键技术，新产品称为PREP Messenger。对PREP Messenger的要求如下：
?在系统级验证方面提供已被Zaiq证明是成功的丰富测试激励方式，包括复杂数据类型和协议的产生，自检查测试和随机激励。
?利用Aptix在硬件仿真方面的专业经验，达到相对于软件仿真器的几个数量级的性能提高。
?在不需要修改、转换步骤，或者维持多组代码的基础上，允许相同的测试和BFM模型无缝地应用于模拟和仿真。
Zaiq和Aptix认识到让PREP Messenger使用Accelera标准协同仿真API：建模接口(SCE-MI)的优势，该标准对基于事务的协同仿真提供了标准定义。SCE-MI标准定义了与硬件信息端口通信的软件代理，结构上与Zaiq的PREP环境相匹配。SCE-MI允许在软件代理和HDL信息端口之间有多个虚拟通信通道。在事务架构的硬件和软件两方面都符合工业标准接口，再加上相对于专用接口的性能优势，PREP Messenger可以保护开发者在验证IP上的努力。Aptix/Zaiq的SCI-MI基础结构可由SCE-MI Tranporte独立提供，并包含在PREP Messenger标准协同仿真传输层中。
提供与SCE-MI兼容的基于事务的仿真涉及如下开发内容：
1. 利用Aptix Expeditor高速物理接口实现SCE-MI通信基础结构。
2. 支持通过SCE-MI基础结构与Aptix System Explore平台的通信，或者通过工业标准接口与软件仿真器通信，同时对测试编写者保持相同的系统验证API。
3. 开发一个可综合的BFM结构，包括与SCE-MI信息端口的标准接口，在不需要改变BFM的情况下，按照HDL进行软件模拟，然后综合成硬件仿真。
目的是既不改变高层基础结构，也不改变测试代码，从而当HDL和测试平台的HDL部分(SCE-MI BFM)被映射进仿真器时，测试环境的其它部分保持不变。这种可重定位的概念意味着测试环境可以透明、无缝地从纯软件模拟转换到高速硬件仿真。用这种方法，运行在最新PC平台的Linux系统下，可以实现超过软件模拟器20000倍的性能提高。
对于每个可综合的BFM模型都有一个对应的C/C++侧的函数。这个C语言侧的处理器负责对高层协议建模和验证，从而为测试编写者提供了一个简单的类似于加载/存储的API。C语言侧的多个处理器都作为一个单独的插入执行，在模拟和仿真中插入控制和切换都同样由传输层处理，从而提供了硬件系统测试中所需要的并行操作。
SoC实例
为了展示PREP Messenger的强大能力，看一下假设的网络SoC(NSoC)，该实例实现了一个简单的SOHO完整路由芯片。图2所示的网络SoC包含两个主要部分。第一部分包含ARM 926EJ-S内核，用于芯片的初始化、配置路由表和数据类型，并且实现USB2.0的用户接口。该芯片中的ARM系统是ARM PrimeXsys平台的一个子集。芯片的另一部分实现网络路由引擎，通过一个双端口的数据包存储器分别与嵌入式微处理器和ARM AMBA-AHB总线相连。芯片的输入侧能够把4个支持多协议的输入端口与2个支持多协议的输出端口相连。
NSoC的系统级测试集中在两个方面：首先是网络子系统的数据处理和协议检查；其次是网络子系统与用来配置和监视系统的ARM代码的兼容性。
在NSoC的验证环境中，C语言测试组产生网络子系统的测试条件。该测试条件详细说明应用于NSoC的分组数据格式和协议：长度、载荷、报头、数据包的间隔时间，以及错误情况。该条件即包括用来满足特定事件覆盖的直接测试用例，以及基于直接测试用来覆盖测试编写者没有详细描述情况的随机激励。
当今的数据、计算机和通信系统包含迅速增加的协议、格式和复杂层次。PREP平台库提供这种功能的可重用性，并且把这种复杂性跟测试编写者、BFM模型编写者以及SoC芯片设计者隔离开。数据产生库提供大多数标准数据类型和协议，如以太网、Utopia接口、ATM、AMBA-AHB、AXI和PCIX。软件计分板系统跟踪加到系统上的激励，并且自动检查结果。测试编写者可以完全描述数据类型来实现直接测试用例，或者允许平台库随机产生数据类型的部分或者所有域对系统进行实验。
BFM模型对每个接口或者协议产生适当的信号和周期。它们产生总线周期，发送和接收数据，监视错误。它们可以连接到一个标准接口或者专用接口。
传输层通过一个事务API进行访问，把适当的事务请求发送给BFM模型。传输层使用标准的Verilog PLI或VHDL FLI接口作软件模拟，使用SCE-MI传输器API作协同仿真。
每个事务处理器含一个带有与SCE-MI硬件侧信息端口接口的可综合BFM核；与之相对应的C语言侧函数来作协议检查、错误处理、排队和SCE-MI功能测试有关的处理，并且具有和SCE-MI软件侧信息端口代理的接口，以及一个可选的平台库的API。
Zaiq提供SYSTEMware验证元件库(SVC)。SVC是由Zaiq支持和验证过的成熟的事务处理器，用来支持行业标准接口。SVC由可综合的HDL编写的BFM组成，与SCE-MI API兼容。它们有一个对应运行在自己线程内的C函数，来实现高层抽象，并且能够无缝地重定位于模拟或