论文部分内容阅读
随着深亚微米集成电路技术的发展，系统芯片上将集成越来越多的IP核，这些IP核不仅包括为数众多的存储器模块、控制电路模块、时钟电路模块、I/O模块和A/D、 D/A模块，还包括很多MCU、MPU和DSP，基于IP核的软硬件协同设计技术已经成为系统芯片发展的必然趋势。软硬件协同设计要求系统功能一部分由硬件实现，而其余部分则由软件实现，系统硬件实现的部分通常是由VHDL、Verilog等硬件编程语言描述其模型，然后进行仿真验证，最后利用EDA工具综合成门级网表并进行版图级的布局布线，而系统软件实现的部分则通常由C、C++等高级语言描述，并最终由软件编译器编译通过。由于系统芯片软件、硬件采用不同的设计方法和描述语言，这给验证带来了巨大的挑战，传统的软件、硬件分开验证的策略并不适合软硬件协同设计的要求，这就需要软硬件协同验证来解决上述问题。
系统芯片复杂度的增加使验证所耗费的周期愈来愈长，成本愈来愈高，据统计，验证已经占到整个芯片设计工作的70%甚至更多[1]，为了缓解芯片上市日益紧迫的压力，工业界迫切需要新的验证方法和验证技术，事务级协同验证将是一个很好的选择。基于此，本文将首先介绍一下当前系统芯片验证的主要方法，通过对目前验证方法的分析和评估，提出事务级建模及事务验证策略，文中还将说明事务级设计及验证语言SystemC并在最后简单介绍一下SCV验证库。
当前主要验证方法介绍
系统芯片的验证主要可以分为形式化验证和基于仿真的验证，其中形式化验证方法包括定理证明技术、模型形式检查和等价性形式检查，基于仿真的验证则包括快速原型系统、软硬件协同验证等等。形式化验证与仿真验证的最大区别是形式化验证不需要测试平台（Testbench）和测试向量，虽然形式化验证能够达到较快的验证速度和很高的验证覆盖率，但形式化验证没有考虑设计对象的时序信息，所以该方法只能成为仿真的一种补充，本文后面介绍的事务级验证属于仿真的一种。
目前，系统芯片设计普遍采用IP核复用和基于平台的设计思想，这些复用的IP核包含了相当多的可编程逻辑资源，例如微处理器、数字信号处理器等等，软硬件协同验证能够帮助开发人员在硬件原型生产出来之前就能进行软件的设计和调试，从而大幅度削减芯片的开发周期。软硬件协同验证同时验证系统的软件和硬件，主要分为基于软件的协同模拟技术和基于硬件的协同仿真技术。目前基于FPGA硬件验证平台的协同验证技术正被越来越多的验证工程师采用，笔者所在实验室购买的奥腾公司Nexar2004+NanoBoard开发板正是软硬件协同验证的理想平台，该开发组件中包含了51系列及ARM系列单片机的软核，用户通过将硬件资源和软件资源下载到NanoBoard开发板上的FPGA中，可以实现软硬件的协同验证。
传统的软硬件协同设计中硬件模块是由Verilog等硬件编程语言描述，软件模块则由C、C++等高级语言描述，在基于FPGA的协同验证中，由于FPGA中包含了可编程的软核甚至是硬核，再加上FPGA本身的门电路可以综合成系统所需的硬件，所以利用FPGA开发平台进行协同验证是个不错的选择，但FPGA验证平台通常价格比较昂贵，同时开发人员也不容易观察到MCU，DSP等微处理器内部的状态位和断点信息。将系统芯片硬件模块的RTL描述提升到事务级，并通过SystemC在统一的环境下进行软硬件协同设计与验证能够很好的解决由于系统芯片软件、硬件采用不同设计语言所带来的验证困难。研究表明，在事务级进行验证可以大幅度提高设计生产率总体水平，下文将具体介绍事务级建模及验证方法。
事务级建模及验证方法
事务[2]是指在系统模型中两个组件之间通过接口所做的一次数据的交换或控制的传输，事务可以是读写某个存储单元的简单事务，也可以是数据包传输这样的复杂事务。
图1 基于事务的验证流程
事务级建模（Transaction Level Modeling，TLM）最早出现在系统级语言及建模领域，文献[3]首先定义了通道（Channel）的概念，这里通道将通信和计算分开，下文将会阐述通道和接口是事务级建模的基础。文献[4]具体介绍几种事务级建模方法，其中总线功能模型（Bus Function Model，BFM）应用比较广泛，其它如总线仲裁模型、周期精确的计算模型等则相对受关注程度较小。总线功能模型用来模拟总线的功能，其作用是把底层总线的时序封装起来，向上层提供一个统一的接口，使上层不用关心底层具体的实现细节。在事务级建模中，总线功能模型也可以理解为下文将要阐述的事务器。
事务级模型中的模块可以是硬件模块，也可以是软件模块。事务级模块之间的通信和RTL级模块不一样，在RTL级中，模块之间的通信通过管脚进行，而在事务级中，模块之间通过函数调用的方法进行通信。所以说事务级比RTL级更抽象，层次更高。
基于事务的验证（Transaction-based Verification，TBV）包括测试对象（Design Under Test，DUT）、事务器（Transactor）和测试程序，其验证流程如图1所示。
上述验证流程中，测试对象是基于信号的RTL级硬件模块，事务器则是一系列函数的组合，而测试程序代表用来产生验证所需事务的代码。验证流程中的核心模块事务器可以产生事务所代表的信号变化，并与测试对象的实际管脚相连。一般来说一个设计往往具有不同的接口，因此在一个验证环境中就需要有不同的事务器以产生不同的测试向量。测试程序、事务器一般用HDL语言或者C语言来描述，而测试对象则通常由Verilog HDL或者是VHDL描述，由于SystemC能够描述系统的软件和硬件，这里的3个模块都能用SystemC在统一的环境下进行描述。SystemC本身所具有的通道、接口的概念也正提供了事务级建模的理想平台，下文将具体介绍SystemC以及基于SystemC的事务级验证方法。
基于SystemC的事务级验证方法
SystemC是以Synopsys公司为首的OSCI (Open SystemC Initiative) 组织在1999年提出来的一种基于C++的建模平台。2005年12月12日，IEEE委员会批准SystemC为IEEE1666标准，目前SystemC的最高版本为SystemC2.2，有兴趣的读者可以在文献[5]中查阅关于SystemC最新的研究成果并下载相关的库文件。
SystemC是建立在C++基础上，它保留了C/C++的优点，同时将并发、定时事件、重启机制等概念引入了C++，使其可以描述硬件。简单的说，SystemC是在C++的基础上增加了一个能对硬件不同抽象层次描述和仿真的C++类库和一个不依赖于任何硬件仿真器的仿真内核。对于描述传统硬件的门级、RTL级、系统级等各个抽象层次，SystemC都能进行很好的建模和仿真。SystemC用一种语言就能统一的描述软件和硬件，非常适合系统芯片软硬件协同设计的需求，其优点还体现在理想的行为模型仿真效率、与RTL模型的无缝连接、对接口电路混和模型的支持等等。基于SystemC的设计流程如下图所示：
SystemC中有一些关于事务级建模很重要的概念：接口（interface）、通道（channel）和端口（port）。在SystemC中，接口是一个C++抽象类，抽象类中定义了只有函数声明而没有函数体的纯虚函数。如下所示：
#include
template
class read :virtual public sc_interface
{public
Virtual void read(unsigned int address,T&data)=0;
};
通道是接口类的子类，它可以继承一个或者多个接口，通道具体实现接口中定义的函数方法，通道本身又可分为基本通道和分层通道，其中分层通道允许设计的通道中包括模块、进程和其它通道。端口用来声明使用的接口，然后连接到实现了该类接口的通道上。在实际使用时，端口和接口的区别不大，可以把端口理解为特殊的接口。直观的讲，接口和端口说明了一个模块的输入和输出情况，而通道对输入输出端的功能进行具体实现。这种接口的定义和实现分开的方法称为接口方法调用（Interface Method Call）。SystemC最大的优势在于可以将模块的功能部分和通信部分分开，这也是其进行事务级建模的基础。在利用SystemC设计的模块中，模块之间的通信不是通过管脚信号来进行，而是通过接口里定义的方法来进行，模块间的通信的方式由信号变为函数调用，因此仿真速度得到了大幅度的提高。据统计，同一建模对象的SystemC事务级模型的仿真速度大约是SystemC RTL级模型的100倍[6]。
图2 基于SystemC的设计流程
利用SystemC的事务级验证首先建立在利用SystemC进行事务级建模的基础上，硬件模块和软件模块都可以直接用SystemC编写，软件模块链接处理器的指令集仿真器后与硬件模块在统一的开发平台上即可进行软硬件的协同验证。这里指令集仿真器也采用事务级模型，其可以由用户自行设计或由EDA厂商提供。基于SystemC的系统芯片设计可以在很多开发平台上进行，例如基于Windows平台的VC++环境[7]以及基于Linux平台的GNU C++环境，现在也有越来越多的商业软件开始提供SystemC的开发环境，例如Synopsys的CoCentric System Studioy以及Cadence Incisive平台等等。开发人员利用SystemC的标准库一般也能有效地完成验证工作，而SCV(SystemC Verification Standard)的提出则是为了进一步增强SystemC语言的验证能力，下面简要介绍一下SCV。
SCV是一种基于SystemC类库的C++类库，是对SystemC标准库验证能力的扩展，其目前的最高版本为1.0p2。SystemC验证库在随机验证、数据内查、事务记录等方面进行了有效增强。为了区别SystemC库，SCV标准的类和函数均使用前缀scv_。SCV验证库对随机测试提供了很好的支持，文献[8]中提供了一个利用SCV随机测试的方法验证FIFO结构的实例，结果表明基于SCV的验证大大提高了仿真效率。关于SCV验证库的具体内容有兴趣的读者可以参考文献[5]。
结语与展望
软硬件协同设计要求系统在更高的层次进行仿真和验证，基于SystemC的事务级建模和验证无疑最符合协同设计的需求。本文对SystemC以及事务级建模和协同验证方法进行了介绍，目前，SystemC的普及程度远没有Verilog和VHDL广泛，但相信随着事务级验证相关EDA工具与方法的成熟，越来越多的公司和用户将采用事务级建模和验证方法进行产品开发，SystemC以及SystemC验证库还处于不断的更新中，可以预见的是以SystemC为基础的事务级建模及验证方法将成为电子系统级设计的重要发展方向。
参考文献
[1] Prakash Rashinkar，Peter Paterson，LeenaSingh．System-On-a-Chip verification methodology and techniques[M]．Kluwer Academic Publishers,2001
[2] Sudeep P．Transaction Level Modeling of SoC using SystemC2.0．Synopsys User Group Conference’02.2002，Bangalore．Kluwer Academic Publishers
[3] D.Gajski et al．SpecC:Specification Language and Methodology．Kluwer,Jan 2000
[4] Lukai Cai，Daniel．Transaction level modeling：an overview．CODES+ISSS2003．Newport Beach,CA,USA,2003
[5] www.systemc.org
[6] Pete Haedee．Getting Hardware and Software to Speak the same language．Dedicated Systems Magazine,Vol2,2002
[7] 陈曦，徐宁仪．SystemC片上系统设计．北京：科学出版社，2004
[8] 王锦程等．SCV及其在SOC验证中的应用．武汉大学学报，2004，4：116－119。
系统芯片复杂度的增加使验证所耗费的周期愈来愈长，成本愈来愈高，据统计，验证已经占到整个芯片设计工作的70%甚至更多[1]，为了缓解芯片上市日益紧迫的压力，工业界迫切需要新的验证方法和验证技术，事务级协同验证将是一个很好的选择。基于此，本文将首先介绍一下当前系统芯片验证的主要方法，通过对目前验证方法的分析和评估，提出事务级建模及事务验证策略，文中还将说明事务级设计及验证语言SystemC并在最后简单介绍一下SCV验证库。
当前主要验证方法介绍
系统芯片的验证主要可以分为形式化验证和基于仿真的验证，其中形式化验证方法包括定理证明技术、模型形式检查和等价性形式检查，基于仿真的验证则包括快速原型系统、软硬件协同验证等等。形式化验证与仿真验证的最大区别是形式化验证不需要测试平台（Testbench）和测试向量，虽然形式化验证能够达到较快的验证速度和很高的验证覆盖率，但形式化验证没有考虑设计对象的时序信息，所以该方法只能成为仿真的一种补充，本文后面介绍的事务级验证属于仿真的一种。
目前，系统芯片设计普遍采用IP核复用和基于平台的设计思想，这些复用的IP核包含了相当多的可编程逻辑资源，例如微处理器、数字信号处理器等等，软硬件协同验证能够帮助开发人员在硬件原型生产出来之前就能进行软件的设计和调试，从而大幅度削减芯片的开发周期。软硬件协同验证同时验证系统的软件和硬件，主要分为基于软件的协同模拟技术和基于硬件的协同仿真技术。目前基于FPGA硬件验证平台的协同验证技术正被越来越多的验证工程师采用，笔者所在实验室购买的奥腾公司Nexar2004+NanoBoard开发板正是软硬件协同验证的理想平台，该开发组件中包含了51系列及ARM系列单片机的软核，用户通过将硬件资源和软件资源下载到NanoBoard开发板上的FPGA中，可以实现软硬件的协同验证。
传统的软硬件协同设计中硬件模块是由Verilog等硬件编程语言描述，软件模块则由C、C++等高级语言描述，在基于FPGA的协同验证中，由于FPGA中包含了可编程的软核甚至是硬核，再加上FPGA本身的门电路可以综合成系统所需的硬件，所以利用FPGA开发平台进行协同验证是个不错的选择，但FPGA验证平台通常价格比较昂贵，同时开发人员也不容易观察到MCU，DSP等微处理器内部的状态位和断点信息。将系统芯片硬件模块的RTL描述提升到事务级，并通过SystemC在统一的环境下进行软硬件协同设计与验证能够很好的解决由于系统芯片软件、硬件采用不同设计语言所带来的验证困难。研究表明，在事务级进行验证可以大幅度提高设计生产率总体水平，下文将具体介绍事务级建模及验证方法。
事务级建模及验证方法
事务[2]是指在系统模型中两个组件之间通过接口所做的一次数据的交换或控制的传输，事务可以是读写某个存储单元的简单事务，也可以是数据包传输这样的复杂事务。
图1 基于事务的验证流程
事务级建模（Transaction Level Modeling，TLM）最早出现在系统级语言及建模领域，文献[3]首先定义了通道（Channel）的概念，这里通道将通信和计算分开，下文将会阐述通道和接口是事务级建模的基础。文献[4]具体介绍几种事务级建模方法，其中总线功能模型（Bus Function Model，BFM）应用比较广泛，其它如总线仲裁模型、周期精确的计算模型等则相对受关注程度较小。总线功能模型用来模拟总线的功能，其作用是把底层总线的时序封装起来，向上层提供一个统一的接口，使上层不用关心底层具体的实现细节。在事务级建模中，总线功能模型也可以理解为下文将要阐述的事务器。
事务级模型中的模块可以是硬件模块，也可以是软件模块。事务级模块之间的通信和RTL级模块不一样，在RTL级中，模块之间的通信通过管脚进行，而在事务级中，模块之间通过函数调用的方法进行通信。所以说事务级比RTL级更抽象，层次更高。
基于事务的验证（Transaction-based Verification，TBV）包括测试对象（Design Under Test，DUT）、事务器（Transactor）和测试程序，其验证流程如图1所示。
上述验证流程中，测试对象是基于信号的RTL级硬件模块，事务器则是一系列函数的组合，而测试程序代表用来产生验证所需事务的代码。验证流程中的核心模块事务器可以产生事务所代表的信号变化，并与测试对象的实际管脚相连。一般来说一个设计往往具有不同的接口，因此在一个验证环境中就需要有不同的事务器以产生不同的测试向量。测试程序、事务器一般用HDL语言或者C语言来描述，而测试对象则通常由Verilog HDL或者是VHDL描述，由于SystemC能够描述系统的软件和硬件，这里的3个模块都能用SystemC在统一的环境下进行描述。SystemC本身所具有的通道、接口的概念也正提供了事务级建模的理想平台，下文将具体介绍SystemC以及基于SystemC的事务级验证方法。
基于SystemC的事务级验证方法
SystemC是以Synopsys公司为首的OSCI (Open SystemC Initiative) 组织在1999年提出来的一种基于C++的建模平台。2005年12月12日，IEEE委员会批准SystemC为IEEE1666标准，目前SystemC的最高版本为SystemC2.2，有兴趣的读者可以在文献[5]中查阅关于SystemC最新的研究成果并下载相关的库文件。
SystemC是建立在C++基础上，它保留了C/C++的优点，同时将并发、定时事件、重启机制等概念引入了C++，使其可以描述硬件。简单的说，SystemC是在C++的基础上增加了一个能对硬件不同抽象层次描述和仿真的C++类库和一个不依赖于任何硬件仿真器的仿真内核。对于描述传统硬件的门级、RTL级、系统级等各个抽象层次，SystemC都能进行很好的建模和仿真。SystemC用一种语言就能统一的描述软件和硬件，非常适合系统芯片软硬件协同设计的需求，其优点还体现在理想的行为模型仿真效率、与RTL模型的无缝连接、对接口电路混和模型的支持等等。基于SystemC的设计流程如下图所示：
SystemC中有一些关于事务级建模很重要的概念：接口（interface）、通道（channel）和端口（port）。在SystemC中，接口是一个C++抽象类，抽象类中定义了只有函数声明而没有函数体的纯虚函数。如下所示：
#include
template
class read :virtual public sc_interface
{public
Virtual void read(unsigned int address,T&data)=0;
};
通道是接口类的子类，它可以继承一个或者多个接口，通道具体实现接口中定义的函数方法，通道本身又可分为基本通道和分层通道，其中分层通道允许设计的通道中包括模块、进程和其它通道。端口用来声明使用的接口，然后连接到实现了该类接口的通道上。在实际使用时，端口和接口的区别不大，可以把端口理解为特殊的接口。直观的讲，接口和端口说明了一个模块的输入和输出情况，而通道对输入输出端的功能进行具体实现。这种接口的定义和实现分开的方法称为接口方法调用（Interface Method Call）。SystemC最大的优势在于可以将模块的功能部分和通信部分分开，这也是其进行事务级建模的基础。在利用SystemC设计的模块中，模块之间的通信不是通过管脚信号来进行，而是通过接口里定义的方法来进行，模块间的通信的方式由信号变为函数调用，因此仿真速度得到了大幅度的提高。据统计，同一建模对象的SystemC事务级模型的仿真速度大约是SystemC RTL级模型的100倍[6]。
图2 基于SystemC的设计流程
利用SystemC的事务级验证首先建立在利用SystemC进行事务级建模的基础上，硬件模块和软件模块都可以直接用SystemC编写，软件模块链接处理器的指令集仿真器后与硬件模块在统一的开发平台上即可进行软硬件的协同验证。这里指令集仿真器也采用事务级模型，其可以由用户自行设计或由EDA厂商提供。基于SystemC的系统芯片设计可以在很多开发平台上进行，例如基于Windows平台的VC++环境[7]以及基于Linux平台的GNU C++环境，现在也有越来越多的商业软件开始提供SystemC的开发环境，例如Synopsys的CoCentric System Studioy以及Cadence Incisive平台等等。开发人员利用SystemC的标准库一般也能有效地完成验证工作，而SCV(SystemC Verification Standard)的提出则是为了进一步增强SystemC语言的验证能力，下面简要介绍一下SCV。
SCV是一种基于SystemC类库的C++类库，是对SystemC标准库验证能力的扩展，其目前的最高版本为1.0p2。SystemC验证库在随机验证、数据内查、事务记录等方面进行了有效增强。为了区别SystemC库，SCV标准的类和函数均使用前缀scv_。SCV验证库对随机测试提供了很好的支持，文献[8]中提供了一个利用SCV随机测试的方法验证FIFO结构的实例，结果表明基于SCV的验证大大提高了仿真效率。关于SCV验证库的具体内容有兴趣的读者可以参考文献[5]。
结语与展望
软硬件协同设计要求系统在更高的层次进行仿真和验证，基于SystemC的事务级建模和验证无疑最符合协同设计的需求。本文对SystemC以及事务级建模和协同验证方法进行了介绍，目前，SystemC的普及程度远没有Verilog和VHDL广泛，但相信随着事务级验证相关EDA工具与方法的成熟，越来越多的公司和用户将采用事务级建模和验证方法进行产品开发，SystemC以及SystemC验证库还处于不断的更新中，可以预见的是以SystemC为基础的事务级建模及验证方法将成为电子系统级设计的重要发展方向。
参考文献
[1] Prakash Rashinkar，Peter Paterson，LeenaSingh．System-On-a-Chip verification methodology and techniques[M]．Kluwer Academic Publishers,2001
[2] Sudeep P．Transaction Level Modeling of SoC using SystemC2.0．Synopsys User Group Conference’02.2002，Bangalore．Kluwer Academic Publishers
[3] D.Gajski et al．SpecC:Specification Language and Methodology．Kluwer,Jan 2000
[4] Lukai Cai，Daniel．Transaction level modeling：an overview．CODES+ISSS2003．Newport Beach,CA,USA,2003
[5] www.systemc.org
[6] Pete Haedee．Getting Hardware and Software to Speak the same language．Dedicated Systems Magazine,Vol2,2002
[7] 陈曦，徐宁仪．SystemC片上系统设计．北京：科学出版社，2004
[8] 王锦程等．SCV及其在SOC验证中的应用．武汉大学学报，2004，4：116－119。