软硬件协同（共7篇）
软硬件协同 篇1
0 引言
现代系统设计许多都是由C/C++, Python等高级语言来完成, 而且这些系统越来越复杂, 涉及到的算法的运算量也越来越大, 许多算法需要用硬件实现来满足算法的实时性要求。FPGA是一种可编程的逻辑器件, 它具有便于修改, 调试, 并能并行地完成大量的运算, 从而提高算法的实时性, 并且随着硬件制造水平不断地提高, FPGA的资源越来越大, 工作频率也越来越高, 使得能在其上面完成的算法也越来越复杂。但是传统的软硬件分开设计的方法由于软硬件设计者采用不同的设计语言, 存在软硬件设计者之间难以沟通导致设计周期长等问题, 这种设计方法已不能满足快速地增长的市场要求, 如何将这些系统设计中的算法快速转换为相应的硬件来实现, 需要新的软硬件协同设计方法。当前基于C/C++的软硬件协同设计, 有一个System C标准化组织一直致力于这个工作[1], 也有少量商业化工具例如Synopsys公司Synphony C Compiler和Calypto Design Systems公司的Catapult SL Synthesis可以将C/C++算法转换为相应的硬件[2,3]。Python是一种简单易学并且功能强大的编程语言, 有许多算法是由Python来实现, 而且这些算法很多是免费、开源的, 和C/C++类似需要如何完成基于Python的软硬件协同设计[4]。
1 基于Python的软硬件协同设计发展
由于Python的强大的软硬件描述能力, 近年来许多研究者在Python的软硬件协同设计方面进行了许多研究, 其中Logaras E提出了一种称为Sys Py (System Python) 可以使用Python来描述硬件并将其自动转换为VHDL[5], Zhang mi采用PDSDL (Dynamic System Description Language) 来进行系统建模和校验并可将系统转换为Verilog的硬件描述[6], 特别是Decaluwe J提出一种称为My HDL的Python扩展包来进行软硬件协同设计[7], Villar J I采用My HDL完成了一个接口设计实例[8]。这些开发工具各自具有自己的一些特点, 但是他们有一点是相同, 就是采用Python来进行软硬件协同设计。下面以My HDL为例介绍基于Python的软硬件协同设计。
2 基于Python的My HDL包简介
My HDL采用Python扩展包的形式使其能支持硬件设计和仿真并在仿真结果符合要求后可将软件算法自动转换为相应的采用Verilog或VHDL硬件描述, 由于My HDL包是基于Python的硬件扩展, 下面主要对My H-DL硬件方面的一些主要特点做简要介绍[9]。
2.1 数据类型
标准Python的int类型已经具有许多硬件设计所需要特征, 但是在硬件设计中由于包含许多位操作和处理, My HDL设计了intbv类, 提供索引和切片操作来支持位的操作和处理。
2.2 模块, 端口和信号
在My HDL采用函数来对硬件的模块进行建模, MyHDL也有信号对象, 类似于VHDL语言的信号, 采用信号作为函数的参数来定义模块的端口。
2.3 发生器
发生器是My HDL的一个关键概念, 用来建立并发性模型, 对应于Verilog的always块或者VHDL的进程。
2.4 自动转换
在一定限制条件下, My HDL使用to Verilog () 或者to VHDL () 函数将My HDL设计自动转换为相应的Verilog或者VHDL代码, 如果符合My HDL可综合子集的要求, 就可使用My HDL完成可硬件综和的代码并在FPGA上实现。
2.5 仿真
My HDL通过Cosimulation对象使其能支持仿真, 对于自动转换的Verilog代码或者VHDL代码, My HDL还可作为硬件校验语言来对转换后的Verilog或VHDL进行协同仿真和校验。
3 采用My HDL的硬件设计优点
Verilog和VHDL是当前的主流硬件设计语言, 但是使用基于Python的My HDL作为硬件设计也具有许多优点[10]使得其可以作为设计者特别是硬件设计的初学者另外一种较好的选择。
3.1 My HDL使用成本低
My HDL是免费的并且开源, 在使用My HDL设计的工具链中同样可以使用大量的免费工具比如ICArus, IVERILOG仿真工具, GTKWAVE查看仿真波形, 从而可以减少设计成本。
3.2 在硬件设计中使用先进的软件开发技术
由于Python本身是一种软件开发语言, 现代软件开发的先进方法比如快速应用开发, 测试驱动开发都在Python上得以体现, 由于硬件描述语言的硬件设计和软件开发具有一定的相似性, 采用My HDL可以使用最新的软件开发技术。
3.3 软硬件设计可以采用同样的开发环境
Python是算法实现的一种理想的语言, 很多算法都由Python实现, 通常算法的软硬件实现由不同工程师来实现, 软件工程师使用Python, 硬件工程师使用通用的硬件描述语言, 例如Verilog或VHDL, 硬件工程师和软件工程师之间存在一条鸿沟, 而采用My HDL, 就可以在同一个Python环境实现算法设计, 仿真和校验。
3.4 其他优点
对于没有一定硬件设计经验的设计者, 通常采用Verilog设计会混淆阻塞和非阻塞赋值, 不清楚Verilog的符号运算, 采用VHDL进行设计又不理解VHDL的信号概念, 会觉得VHDL的类型和位宽转换很繁琐, 但是如果采用基于Python的My HDL包作为设计语言, 这些都将不成为问题。
4 基于Python的软硬件设计流程
在现代系统设计中, 软件工程师采用Python等高级语言, 而硬件系统设计多采用Verilog, VHDL硬件描述语言, 在如何将Python描述的软件映射为相应的硬件上, 软硬件开发者之间的交流存在一道天然的鸿沟, 而采用Python来进行软硬件协同设计就可以解决这一个问题, 基于Python的软硬件协同设计的流程如图1所示。
首先采用Python进行系统设计, 然后根据系统性能要求进行软硬件划分, 对于系统性能要求比较高的部分采用Python的My HDL扩展包的形式来由硬件实现, 同时采用Python来编写硬件测试平台。测试仿真如果不符合系统设计要求可以重新进行软硬件划分, 如果测试仿真结果不正确, 可重新修改。仿真通过后可以用My HDL扩展包自动将Python转换为Verilog代码, 这时的Python测试平台无需修改还可以与转换后的Verilog代码一起进行混合仿真, 如果仿真通过就可以进行硬件的综合, 下载, 测试阶段, 这与传统的硬件设计过程相同。
5 结语
从上面分析可以看出基于Python的My HDL既是一种软硬件协同设计方法, 同时其也是Python的扩展包, 使得整个开发过程仅使用一种Python语言, 并可以很方便地将一个软件算法快速地转换为其相应的硬件实现, 从而完成一个软硬件系统设计。由于Python目前的可综合子集的限制和其本身还处在发展阶段, 基于Python的软硬件设计还主要用于系统的建模方面, 将其用于芯片设计的应用还不是很多, 有研究者比较过My HDL与传统硬件设计语言的实现, 对于小规模的应用优势不是很明显。但是随着现代系统的算法越来越复杂性, 系统规模也不断增大, 相对于传统的软硬件设计方法采用Python来进行软硬件协同设计的优势就会体现出来, 系统设计、仿真、校验的速度会大大提高, 采用Python进行系统设计的产品能更快地进入市场。随着基于Python系统设计方法和工具的发展, 基于Python的软硬件协同设计方法将会有广泛的应用前景。
摘要：针对当前系统设计中软硬件设计者分别采用不同的设计语言存在的天然鸿沟和如何将基于Python的大量软件算法快速地转换为硬件设计的问题, 研究了一种新的基于Python的软硬件协同设计方法。并以基于Python的MyHDL扩展包为例, 重点研究了以Python作为软硬件协同设计、仿真和校验的系统设计流程, 得出基于Python的软硬件协同设计方法能大幅度提高系统设计及算法硬件实现的效率的结论。
关键词：Python,FPGA,软硬件协同设计,硬件加速
参考文献
[1]Intel IT Center.SystemC Version 2.3 user guide[EB/OL].[2012-07-25].http://www.accellera.org/downloads/standards/systemc.
[2]Synopsys.High level synthesis with Synphony C compiler[EB/OL].[2012-08-20].http://www.synopsys.com/Systems/BlockDe sign/HLS/Pages/default.aspx.
[3]Calypto Design Systems.Catapult product family overview[EB/OL].[2012-10-20].http://calypto.com/products/catapult/cata pult_overview.
[4]Python Software Foundation.Python documentation (Python2.7) [EB/OL].[2012-06-10].http://www.python.org.
[5]LOGARAS E, MANOLAKOS E S.SysPy:using Python for pro cessor-centric SoC design[C]//2010 17th IEEE InternationalConference on Electronics, Circuits, and Systems (ICECS) .Athens, Greece:IEEE, 2010:762-765.
[6]ZHANG Mi, TU Shi-liang, CHAI Zhi-lei.PDSDL:a dynamicsystem description language[C]//ISOCC'08.International SoCDesign Conference.Busan, Korea:ISOCC, 2008:204-209.
[7]DECALUWE J.MyHDL:a Python-based hardware descriptionlanguage[J].Linux Journal, 2004, 127 (10) :5-10.
[8]VILLAR J I, JUAN J, BELLIDO M J, et al.Python as a hard ware description language:a case study[C]//2011 VII SouthernConference on Programmable Logic (SPL) .Cordoba, Argenti na:[s.n.], 2011:117-122.
[9]Anon.The MyHDL manual[EB/OL].[2012-06-02].http://www.myhdl.org.
[10]Anon.From Python to silicon[EB/OL].[2012-07-10].http://www.myhdl.org/doku.php.
软硬件协同 篇2
随着电子技术的发展，IC设计的规模越来越大，复杂度越来越高。利用IP核复用技术和用户开发的专用IP核可以设计组成一个完整的系统级芯片。研究实践表明，在目前芯片的研发流程中，仿真验证的实践已经占到整个设计周期的70%以上。现有的仿真平台多是基于模块级的仿真，对在系统级的仿真缺乏手段，由于芯片产生缺陷的地方多在系统级环境下，模块与模块之间的冲突。因此将软件代码融入硬件仿真作为RTL的激励，可以提高验证的覆盖率。软件还可以很好的模拟实际的工作环境，可以充分控制所需验证的硬件功能，也避免了编写测试代码验证设计的典型应用。在此基础上，衍生出软硬件协同仿真这一需求。软硬件协同仿真指系统设计过程中同时验证软件和硬件，在系统硬件还未可用之前，在硬件模型上运行系统软件，检查调试软硬件设计中的缺陷及接口的错误等。而在使用软件验证过程中，还需要进行软件的调试，本文主要介绍了软硬件协同验证中软件仿真调试内容。
1 软件仿真调试模型
本文Soc芯片选择ARM，利用ARM汇编编译器ARMASM,C/C++编译工具ARMCC、ARMCPP以及连接器工具ARMLINK，将由C语言和汇编编写的源文件编译连接成带调试信息的可执行ELF文件格式并生成bin文件。将bin文件加载到硬件模型的存储器中，由硬件模型仿真产生出波形文件。
软硬件系统仿真中分析elf可执行文件和产生的波形文件，进行软件仿真调试，系统流程如图1所示。
在软件仿真调试模型中，主要包括以下的内容:
(1)软件的Firmware code经过编译器编译链接生成elf格式的可执行文件和二进制bin文件。硬件的仿真是基于二进制可执行文件，为了实现源码级的调试，需要解析elf文件中的调试信息。
(2)软件代码作为硬件仿真RTL的激励产生出波形文件，其中包含了程序仿真阶段的所有信息，进行软件调试需要对波形文件解析。
(3)利用解析得到的elf文件调试信息和波形文件的信息，将源代码和波形文件连接起来，并进行软件调试。
2 DWARF调试规范
在本文模型中采用DWARF(Debugging With Attributed Record Formats)调试规范[1],DWARF是一种非常优秀的调试规范，遵从GNU FDL授权，规定了编译器生成源码级别的调试信息的格式。调试信息被包含在ELF文件某几个节中，对于这些包含调试信息的节，在ELF文件规范[2]中并没有定义这些节，这些节中的调试信息的含义由编译时指定的调试信息格式来解释。
DWARF中的基本描述实体是调试信息条目DIE(Debugging Information Entries)。DIE中包含一个指定DIE所描述内容的标签(tag)，以及许多用来填充细节并进一步描述实体的属性(attribute)。DWARF调试信息项之间的所有关系被表示成一棵树，树的节点就是调试信息表项自身。节点的子节点实际上就是该表项所有的子表项，这颗树通过先序进行了线性化，每个调试信息表项可以有，也可以没有子表项。
DWARF的调试信息条目自身不包含调试信息表项标签或每个属性的属性名和形式编码。相反地，每个调试信息表项以一个代码开头，该代码描述了在一个单独的缩写表(abbreviation table)中的表项，缩写表中的表项才包含了调试信息项的标签或各个属性的属性名和形式编码。这个代码后面直接跟着一系列属性值。缩写表中相应的表项将引导对直接包含在.debug_info节中的信息的解释。每个编译单元与一个特殊的缩写表相联系，但是多个编译单元可以共享同一个表。实验表明用缩写表可以将DWARF文件的大小缩减一半。源程序经过编译器的编译后，主要的调试信息包含在以下四个节中，节关系如图2所示。
(1).debug_info包含调试信息的调试信息表项(DIE)，描述了代码内所有可供调试的模块的信息，包括函数、局部变量、全局变量等。
(2).debug_abrev包含对调试信息入口的标签和属性的格式说明，所有的编译单元的缩写表(abbreviation table)包含在这个单独的对象文件的节.debug_abbrev中。
(3).debug_line包含目标文件中机器码地址和源文件语句对应信息，对于源码级调试而言，需要解析.debug_line信息。例如当在某一行上设定断点时，调试器将利用行信息找到实际应该断点的地址。当某个指令引起段错误时，调试器会利用行信息反过来找出源代码中的行号，并告诉用户。
(4).debug_pubname保存源程序中的全局对象名、函数名及在.debus_info中的偏移。
Dwarf还有一些段，如.debug_frame段描述了调用栈的使用情况用于调试回溯;.debug_aranges段描述了各个CU的地址范围;.debug_loc信息来获取栈指针等[3]。通过对ELF文件中dwarf段的解析可以对软件代码进行调试。
3 软件仿真调试模型实现
本文模型将软件和硬件波形连接起来按指令同步，可以快速了解软硬件协同仿真过程中问题发生时，执行的是哪条指令，对应的是哪个函数，函数的调用关系，有效解决了软件的调试问题。
3.1 文件连接与断点操作
本文利用ELF文件调试信息，将波形文件和源文件连接起来。现代的计算机原理为程序存储原理，程序输入到计算机中，存储在内存储器中(存储原理)，在运行时，控制器按地址顺序取出存放在内存储器中的指令(按地址顺序访问指令)。在处理器中一般有一个寄存器PC存放当前指令的地址，在波形文件中对应PC信号的值。根据波形文件中PC的值确定当前代码执行的位置，按照调试信息.debug_line节中机器码地址和源文件语句的对应信息，可以将波形的位置和源文件代码连接起来，按指令同步。
断点设置是调试器调试程序的基本操作，给定源文件的行进行断点操作(包括设置，取消等)，首先需要找到源文件代码行对应的可执行代码的位置。根据.debug_line节调试信息调试控制程序可以得到可执行二进制代码的位置，在波形文件中查找PC信号的值，在对应位置设置断点[4]。区别于一般的软件指令集仿真，在软硬件协同仿真中，可以根据硬件的波形设置断点对应到软件的代码中。在波形中在指定PC信号位置处设置断点，直接对应到源文件的行位置。
3.2 调用堆栈
函数的层次调用中，可以解析得到调用它们的函数的调用结构，这些函数调用结构表现出一种“堆栈”的特征，最后被调用的函数出现在最上方。因此称这种关系为调用堆栈(call stack)。在程序发生故障的时候，程序被终止，一般可以得到最后出错的函数。利用调用堆栈可以知道出错的函数在被哪些函数调用的过程中出错，依此可以检查出错的原因。
在调试器中获得当前函数的调用情况，需要解析.debug_frame节中保存的堆栈状况，对指令解析，获得返回该函数调用函数的地址，从而获得函数所有的调用路径直到main函数。
本文根据波形文件中的信息采用了一种新的方法实现函数的调用堆栈。调试信息.debug_pubnames节中记录了全局对象名、函数名及在.debus_info中的偏移，根据.debug_info、.debug_abbrev节内容，可以得到当前工程中所有函数的地址范围，然后保存在一个数据结构中。在波形文件包含了程序运行过程中PC的所有路径，当程序被中断时，通过中断处的PC，查找函数的范围可以确定当前所在的函数。函数在执行过程中会调用其他函数，所以通过PC向前查找，直到本函数的开始位置，继续向前查找可以得到调用本函数的函数。依次查找可以获得当前函数的调用堆栈直到main函数。整个流程如图3所示。
3.3 数据操作
数据基本操作包括程序中全局变量和局部变量的操作。数据操作的关键在于确定操作变量地址。在DWARF中变量使用DW_TAG_variable调试信息条目DIE描述，变量的属性数据存放在.debug_info节中，属性名和形式编码存放在.debug_abbrev节中。.debug_abbrev节包含了对.debug_info节内容的解析。变量的地址由变量属性DW_AT_location描述。
全局变量的地址固定，一般分配在目标文件的数据段中。对于全局变量，DW_AT_location属性描述了变量的绝对地址。
局部变量相对复杂，因为局部变量可以在全局数据区，可以在栈上，甚至是在寄存器中。全局数据区局部变量与全局变量类似，寄存器中的局部变量，记录变量的寄存器可以得到变量的值，下面对于在栈上的局部变量进行讨论。在堆栈中分配的局部变量，其地址随着函数的调用位置和深度而变化，以其所在函数的调用帧栈基地值进行偏移。局部变量所在函数使用DW_TAG_subprogram调试信息条目DIE描述。函数的调用帧栈基地值存储的寄存器由属性DW_AT_frame_base指定(如:x86使用ebp寄存器，arm体系结构使用r13寄存器)。变量的DW_AT_location属性描述了变量的偏移地址。将函数调用帧栈基址寄存器于变量偏移地址相加可以得到当前局部变量的地址。
根据波形文件中的读写时序，搜索对变量地址最近的写操作。首先在地址总线上查找变量的地址，然后分析写选通信号是否有效。写选通信号送到所有的存储器，但只选通地址有效的存储单元，使之能写入数据。最后读取数据总线上的数据，得到当前变量的值。读写时序如图4所示。
4 软硬件协调仿真调试
将源文件编译产生的二进制代码加载到芯片存储器中，由硬件模型仿真产生VCD波形文件，其中VCD文件包含了整个仿真时间内的信号变化信息，如图5所示。VCD是一个通用的波形文件格式，是IEEE1364标准(Verilog HDL语言标准)[5]中定义的一种ASCII文件。
图中左边为VCD文件的信号值列表，右边为仿真时间内的信号值。在VCD波形文件中仅列出了地址总线，写选通信号线，数据总线和PC寄存器信号。其中波形文件中PC信号记录了程序运行过程中的所有路径。选择源文件中指定行可以对应到VCD波形仿真的位置。反之，选择VCD波形仿真位置，根据PC寄存器值，定位到源文件，如图6所示。
根据VCD波形中的PC路径可以确定PC当前位置函数中的函数调用堆栈的层次结构。当前PC信号为0x1B20,main函数地址范围为0x1AE0到0x1BE4，可以得到当前函数为main函数。在解析二进制可执行文件得到全局变量和局部变量的地址，如全局变量g_flag，解析获得地址为数据段的0x000d0000处。在波形中可以看到，在432.0μs左右，写选通信号线为高电平，对地址0x000d0000写操作，数据总线的值为0，得到当前全局变量g_flag为0。(下转第147页)波形中对全局变量g_flag写操作对应于源文件中对全局变量g_flag赋值操作。在VCD波形文件中根据读写时序，查找依据PC寄存器最近对该地址单元的写操作，可以确定变量值，进行软件调试。另外根据波形文件和调试信息可以实现单步调试、变量值查找等功能。
5 结束语
本文介绍了软硬件协同仿真的原理和流程，利用经编译得到的带调试信息的二进制可执行文件和硬件仿真的波形文件，设计了软硬件协同仿真环境。该环境可以实现硬件波形和软件代码之间的对应连接，并且实现一定的软件调试功能，可以更好地验证软硬件的功能和时序。一般软件仿真基于指令集的仿真，本文设计了一种新的基于硬件波形的仿真环境仅依赖于编译产生的可执行文件和仿真波形文件，不需要指令仿真，可以为各种项目调试验证使用。
参考文献
[1]UNIX International Programming LanguagesSIG.DWARF Debugging Inofmration Format[Z].Revision:2.0.0(Jul.27,1993).
[2]Tool Interface Standard(TIS).Exeeutable and Linkable Format(ELF)Speeifieation(Versionl.2)1998[Z].
[3]李宝丹.嵌入式系统辅助调试环境的开发北京邮电大学[D].2009.
[4]张和君,张跃.基于DWARF的Bootloader远程交叉调试模型[J].计算机工程,2006(24):60-62.
软硬件协同 篇3
软硬件协同验证技术的概念很早就被提出来[3], 但直到集成电路工业进入超大规模 (ULSI) 时代, 以IP设计重用为核心的系统集成芯片 (SoC) 技术成为研究热点, 软硬件协同验证技术才得到更多的关注和重视。
所谓软硬件协同验证 (hardware/software coverification) 是指在硬件的物理原型 (电路板或芯片) 生产出来之前[3], 通过一个系统模型来运行软件, 以此来检查硬件设计中的bug、软件中的缺陷及软/硬件接口中的错误。
软硬件协同验证的主要目的是验证系统级芯片软硬件接口的功能和时序[1], 验证系统级芯片软硬件设计的正确性, 以及在芯片流片回来前开发应用软件。
其优点是使软件/硬件并行开发成为可能, 缩短了设计周期, 减少设计投入。对于软件工程师来说, 可以较早地在硬件模型上调试软件;对于硬件工程师来说, 软件也可看作是对硬件验证的一个额外的激励。
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) 进行仿真验证。
软硬件协同验证系统由一个硬件执行环境和一个软件执行环境组成, 通过事件和命令, 使用一些机制, 在这两个环境间进行控制。当前, 软硬件协同验证方法有如下几种[5]:带有逻辑仿真器的主机代码模式 (hostcode mode with logic simulator) 、带有逻辑仿真器的指令集仿真 (ISS with logic simulator) 、C/C++仿真 (C/C++simulation) 、CPU的RTL模型仿真、CPU的硬件模型仿真、带有逻辑仿真器的评估板在板验证、在电路仿真 (circuit emulation) 、FPGA原型 (FPGA prototype) 等。每种协同验证方法各自有其长处与缺陷, 如何在设计中具体应用这些验证方法要看具体的设计规范、验证工具与环境以及协同验证关注的性能 (速度) 、准确性、适用性等。
3 软硬件协同验证技术的实际应用方案
在实际应用中, 有3种软硬件协同验证方案:ISS、CVE、FPGA/EMULATOR。
3.1 ISS方案 (如图3所示)
图3是ISS方案的系统结构图。ISS方案采用ISS (例如ARMulator) 代替CPU执行软件, 并通过接口与外设及内存通信。该方案中的外设模型一般用C语言建立, 其中ISS可以是指令级精确的, 也可以是指令周期级精确的, 还可以是具有硬件系统的时钟级精确, 又称为总线功能模型 (BFM) 。但是, 如果所有的外设模块都是C模块, 则整个系统不能达到时钟级精确度。通常ISS都带有调试程序, 用于控制ISS执行指令。
3.2 CVE方案
图4是C V E方案的系统结构图[2]。C V E方案以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, 其功能更强, 但造价更高。
4 几种方案的比较
以上3种方案各有优缺点, 本文从以下6个方面进行比较。
(1) 验证速度
在仿真速度方面, FPGA/EMUALTOR采用硬件实现, 其速度最快, ISS方案速度中等, CVE方案则最慢。
(2) 时间精度
在时间精度方面, FPGA/EMUALTOR、CVE都可以达到时钟级精确[2], 而ISS方案在一般情况下精确度不是很高, 大部分为指令级精确。
(3) 调试性能
ISS方案一般用来验证系统在算法级上的正确性, 对硬件的调试帮助不大, CVE方案具有最强大的调试性能, 支持软件的单步执行, 随时查看寄存器、内存状态, 还可以用硬件仿真器生成波形来调试硬件。因此无论硬件还是软件, CVE的可调试性能都非常高[2], FPGA/EMULATOR的调试性能比较差, 它一般是在经过仿真器仿真后再做原型验证, 调试时需要通过增加JTAG之类的工具才能看到内部状态;
(4) 准备工作
ISS方案需要外设的C模型, 一般通过工程师做大量前期积累或者其他途径得到[6], CVE方案只需做好软硬件配置即可, 相对工作量最少, FPGA/EMULATOR需将硬件下载到FPGA中, 只有少量的准备工作。
而可以极大的改善硬件验证的准确性。软硬件协同仿真采用模拟技术[7], 在模拟的硬件模型上运行软件。它可以在尚未生产出硬件之前对虚拟模型进行早期调试, 并为软件调试提供虚拟平台, 从而对包含硬件在内的整个系统进行功能验证, 节约了准备硬件平台的时间。由于考虑了软件实际运行的情况, 所以该验证能够更接近实际应用环境, 更容易发现设计中的问题, 避免早期设计错误, 降低设计风险以及设计对交货期的影响。在实际项目中, 要根据项目的需要, 考虑速度、性能、成本、消耗资源等诸多因素, 选择一种或者多种方案来进行验证, 加快验证速度, 节约验证成本。
(5) 价格成本
ISS方案成本不高, 需要一个ISS和一些外设模型, CVE方案需要购买SeamlessCVE软件, 比ISS成本高;成本最高的是FPGA/EMULATOR, 硬件购买费用很高;
(6) 适用范围
ISS方案比较适合算法验证和具有一定程度的硬件系统调试, CVE方案适合软硬件的联合调试, 尤其在系统未经过充分验证时, 需要较好的性能调试。FPGA EMULATOR适合在经过仿真器验证无误之后, 用于原型验证。
将上述比较结果整理如表1所示。
表1 3种软硬件协同验证方案的比较
5 结论
软硬件协同验证可以使软件工程师尽早的接触到硬件设计, 从而使软件的开发测试和硬件设计可以并发进行。与传统的先设计硬件后开发软件的串行开发模式相比, 软硬件协同验证可以大大缩短整个项目的开发周期。同时, 软硬件协同仿真提供了在真实系统中出现的激励信号, 和人工加入的测试信号相比, 具有更高的真实性, 从
参考文献
[1]Janick Bergeron, Eduard Cerny, Alan Hunter, Andrew Nightingale.Verification Methodology Manual for SystemVerilog11055174P325-385
[2]Seamless CVE.Hardware/software co-verification technology.http://mentor.com
[3]ANDREWS J R.Co-verification of hardware and software for ARM SoC design[M].America Eisevier Inc, 2005
[4]WANG P, LIN J S, ZHNG L G.hardware/software co-verification platform for EOS design[J].高技术通信 (英文版) , 2005 (3) :195-198.
[5]HAB[B]A, TAHAR S.Design for verification of System C transaction level models[C]//IEEE Proc of the Design, Automation and Test in Europe.Germany, 2005:560-565
[6]张奇, 曹阳, 李栋娜.基于System C的SoC行为级软硬件协同设计[J].计算机工程, 2005, 31 (19) :217-219
[7]BRUCE A, GOODENOUGH J.Re-useable, hardware/software co-verification of IP blocks[C]//Proc of14th Annual IEEE Int ASIC/SoC Conf.Arligton, VA, USA, 2001:413-417.
软硬件协同 篇4
2010年HE K M等人提出了引导滤波(Guided Filter)[1]算法。该算法与双边滤波最大的相似之处就是同样具有保持边缘的特性,不同之处在于它还克服了去伪影的影响。该算法被大量用于图像处理领域中,在去雨雪[2]、去雾[3]、前景提取[4]、图像去噪、图像增强、级联采样等方面有很好的处理效果。
但是,随着处理图像的尺寸不断扩大,基于CPU处理的引导滤波算法越来越不能满足人们的需求,因此,王新磊等[5]用CUDA实现了引导滤波GPU加速。为使引导滤波能在嵌入式领域达到实时处理,本文提出了基于FPGA对引导滤波实现加速的方法。
1 引导滤波算法介绍
引导滤波理论的基础是局部线性模型。该模型认为:任意函数上的任意一点与该点邻近部分的点可以看成是线性关系,一个复杂的函数可以用很多局部线性函数来表示。若需要求出该函数上某一点的值,只需求出所有包含该点的线性函数的值,并求出这些线性函数值的平均值,这个平均值就是该函数上所求点的值。
2 引导滤波加速器设计
2.1 实验环境介绍
本文采用Zynq-7000系列的Zedboard开发板[6]作为硬件开发环境,其PS端提供了ARM Cortex-A9处理器、512 MB DDR3内存空间和外部存储接口。其PL端的XC7Z020 CLG481-1 EEP芯片提供了可编程逻辑阵列单元,为硬件加速提供了丰富的逻辑资源。本文采用SD-So C[7]作为软件开发环境,它是基于Zynq-7000全可编程芯片在嵌入式系统中的IDE(Integrated Development Environment)。
2.2 算法结构设计
本文将单通道的图像数据存储在PS端的外部存储中,之后读取数据到内存中。为了获取最大的运算性能,在引导滤波函数调用前分配好算法需要的图像缓冲空间,将内存空间指针以参数形式传递给引导滤波函数,供其使用,之后PS端调用引导滤波函数。本文将引导滤波算法分为两部分,其中一部分是将对算法有较大影响的函数用硬件加速,硬件加速部分将数据传到PL端,PL端将其用硬件逻辑电路实现,对实现的硬件再通过流水线、并行处理和算法重构等优化方法对算法进行优化。处理完数据后,再将数据写回到PS端。最终PS端将处理好的图像存储在外部存储中。算法结构设计如图1所示。
2.3 优化方法
2.3.1 流数据传输
为了获取PS端和PL端的最大传输性能,本文使用SDSo C开发环境中的sds_alloc函数[8]在PS端申请连续的物理地址作为图像缓冲区,并在硬件函数声明前插入指导编译器的参数#pragma SDS dada zero_copy(img In[0:rows*cols])和#pragma SDS data access_pattern(img In[0:rows*cols])命令来将图像数据转化为流数据[8]进行传输。
2.3.2 流水线优化
为了增加程序的并发性,流水线优化可以使当前操作没有完成之前就开始执行下一个操作。环境SDSo C的PIPELINE[8,10]优化指令可以对函数及循环进行优化。下面分别对函数的流水线和循环的流水线优化进行说明。
(1)函数的流水线操作
从图2可以看出,func函数需要3个时钟完成一组操作。若进行两组操作,在没有进行流水线优化的情况下,每次操作顺序执行,最后一次输出需要6个时钟;而经过流水线优化的func函数,每经过1个时钟就可以读取下一组数据,两组操作完成后只需要4个时钟周期就能够输出结果。由此可见,流水线优化可以提高函数的并发性,增加算法的效率。
(2)循环的流水线优化
从图3可看出,用循环来对图像像素进行处理,假设每个像素处理时间为30个时钟周期,若处理图像大小为512×512,则未流水线优化前,需要的总时钟个数为7 864 320个时钟周期;流水线优化后,需要的总时钟个数为262 174个时钟周期,性能有了近30倍的提升。
2.3.3 并行处理
SDSo C环境提供了async和wait指令,使得程序员能够对硬件函数的同步方式进行控制。硬件开始工作后,PS端的async指令会交还CPU的控制权,继续执行PS端的任务,实现软硬件函数并行处理。通过这种方法,可以增加系统的并行性,提高算法的效率。wait命令用来同步数据,使得下一个函数能够成功应用上一个硬件函数的输出结果,防止程序死锁。
3 实验结果分析
本文输入单通道的.bmp格式文件为待处理图像,模板大小选择3×3,引导图像和待处理图像为同一张图像,实验效果如图4所示。
其中,图4(a)为待处理图像和引导图像,图4(b)为经过软硬件协同加速器实现的引导滤波效果图,图4(c)为在PC上用Open CV库纯软件实现的引导滤波效果图。通过对比可看出,经过软硬件协同加速器实现的引导滤波和在PC上纯软件实现的引导滤波在效果上基本相同。
为了比较本文提出的软硬件协同加速器的加速效果,分别测出了在PS端对不同大小图像实现引导滤波算法的帧率值和软硬件协同加速器对不同大小图像实现引导滤波算法的频率值。实验数据如表1所示。
4 结束语
本文实现了引导滤波的软硬件协同加速器,并利用开发环境SDSo C所提供的优化指令对硬件进行了性能优化。与CUDA实现的引导滤波相比,性能虽有所不及,但加速效果明显,并在低功耗及开发周期上优势大于CUDA。本文提出的软硬件协同加速器可直接用于内置CPU和FPGA的嵌入式系统中,缩短了嵌入式工程师开发周期,提高了系统整体性能。
参考文献
[1]HE K M,SUN J,TANG X O.Guided image filtering[C].Proceddings of the 11th European Conference on Computer Vision.Heraklion,Crete,Greece:Lecture Notes in computer Science,2010:1-14.
[2]郑贤辉.单幅图像去雨雪的算法研究[D].厦门:厦门大学,2014.
[3]杨燕,白海平,王帆.基于引导滤波的单幅图像自适应去雾算法[J].计算机工程,2016,42(1):265-271.
[4]漆琳智,张超,吴向阳.引导滤波的单幅图像前景精确提取[J].杭州电子科技大学学报,2013,33(5).
[5]王新磊,何凯,王晓文.引导滤波算法的CUDA加速实现[J].吉林大学学报,2016,34(1).
[6]Xilinx.Zynq architecture[Z].2016.
[7]Xilinx.SDSo C development environment[Z].2016.
[8]Xilinx.SDSo C environment user guide[Z].2016.
[9]CHATI H D,MUHLBAUER F,BRAUN T,et al.Hardward/software co-design of a key point detector on FPGA[C].IEEE Computer Society,2007:355-356.
软硬件协同 篇5
本文采用软硬件协同的设计思想,设计了AFDX协议处理芯片片上系统,研究了AFDX协议处理芯片的软硬件分区结构及功能,详细地研究了调度器和虚拟链传输控制等关键技术的实现。
1 软硬件协同设计
软硬件协同设计是软件和硬件的折中过程,将软件功能移植到硬件实现以加速软件执行,将硬件功能用软件实现以降低硬件实现的代价。因此,软硬件协同设计应充分考虑软件在处理控制方面的操作优势及硬件处理并行操作优势的特点[5,6]。下面从4个方面对基于软硬件协同的AFDX协议片上系统的设计过程进行详细说明。
1.1 分区结构
针对AFDX协议处理芯片的特点,本文提出了一种软硬件协同设计的分区结构,如图1所示。对于实时性要求很高的处理由单独的硬件模块完成,这些硬件模块在有数据需要处理的时候才工作,而不知道这些数据最终如何以及何时被其他模块使用,它们之间的协同工作在软件控制下完成。软件部分运行在NIOSⅡ处理器上,主要实现系统级的控制,如配置系统参数、协调各硬件模块的通信、发送帧的调度及接收帧的多路分解。
1.2 硬件功能
硬件分区结构由媒体访问控制器(MAC)、终端系统传输模块、发送/接收冗余管理模块、NIOSⅡ处理器、虚拟链数据存储器及相关辅助电路组成[4]。
(1)媒体访问控制器:发送数据时,通过NIOSⅡ处理器的调度程序和调度器的控制,负责从发送虚拟链数据缓存中读取数据,并按照AFDX协议的数据格式发送给物理层接口;接收数据时,通过物理层接口从物理层获取数据,然后按照AFDX协议进行数据解析,并通过接收冗余管理模块的处理,最终存入接收虚拟链数据缓存中。
(2)终端系统传输模块:由调度器、抖动时间、各虚拟链时间和虚拟链指针等模块,各个模块通过NIOSⅡ处理器的调度程序完成AFDX传输过程中的流量整形。按照定义好的配置表将数据流整形成各个虚拟链路中定义的最小带宽分配间隙和最大帧长参数。在满足虚拟链最大抖动范围的前提下,经过调度器叠合后发送到交换机中。
(3)冗余管理模块:冗余管理包括发送冗余管理和接收冗余管理。发送冗余管理对逐个虚拟链进行配置,经过调度器整形的虚拟链可选择从媒体访问控制器A或B发送帧数据,或同时发送。接收冗余管理对接收到的帧数据进行完整性检查,并判断是否有效,以及删除冗余通道中重复收到的有效帧。
(4)NIOSⅡ处理器:是系统的核心控制模块,负责协调各个模块之间的工作。主要功能包括:启动时配置系统、调度传输帧以及接收帧的多路分解。当开机或重启时,CPU读取配置存储器,确定虚拟链的数目、各个虚拟链所需的带宽和终端系统的媒体访问控制。
1.3 软件功能
软件结构包括主控模块、初始化模块、AFDX协议控制模块、中断管理模块、存储管理模块和错误管理模块。
(1)初始化模块:负责初始控制信息,对主控模块进行初始化,并通过AFDX协议控制模块对各个硬件模块进行初始化。
(2)主控模块:是软件运行的核心模块,是程序运行的主线程序,负责对系统其他软件模块进行管理。通过AFDX协议控制模块实现对硬件部分的管理,以此控制AFDX数据帧编解码速度及各硬件模块之间的交互;通过存储管理模块实现对片上系统各个存储器的访问与控制;通过调用中断管理模块实现系统软硬件中断的处理;通过错误管理模块监视系统的错误信息,并据此对主控模块进行相应的调整及处理。
(3)AFDX协议控制模块:是软件控制硬件模块的接口,按照软硬件接口规范将信息以命令的方式发送给相关硬件模块。为了使软件与硬件模块之间能够正常工作,它与每个硬件模块之间通过1个命令缓冲区队列(FIFO)进行信息交互,并把命令FIFO的状态传递给主控模块,主控模块据此判断AFDX协议的帧数据传输是否可以继续下去,若命令FIFO不可用(已满),则暂停数据传输,一直等待到可用为止。
(4)存储管理模块:负责对系统各个存储器进行管理,包括发送/接收虚拟链数据存储器、NIOSⅡ软件运行时的SDRAM、SRAM及掉电时用于保存程序的Flash。
1.4 软硬件接口及交互方式
软硬件接口及交互的方式是软硬件之间通信必须要考虑的问题,设计时主要考虑降低接口的复杂度及提高通信的速度。NIOSⅡ处理器的Avalon总线提供主模式和从模式2种接口,通过定制Avalon总线的时钟、地址、片选及读写控制信号,实现与具体硬件模块匹配的时序,从而实现与不同硬件模块的通信交互。软硬件之间的交互方式主要有2种:(1)单命令方式:软件和硬件直接交互,完成基本语法元素的解析,如对各硬件模块发送控制命令、1次性数据读写等;(2)DMA方式:主要用于软硬件之间或硬件与硬件之间进行频繁的数据存取操作,如发送/接收数据帧的读写等。
2 关键技术
2.1 调度器的设计
调度器是终端系统多个虚拟链进行流量整形的关键。每个虚拟链的带宽分配需要考虑到最小带宽分配间隙(BAG)、虚拟链能够传输的最大帧长度(Lmax)及最大抖动边界(Max.Jitter)3个条件的限制。BAG是以两个相继帧的起始位之间的间隔来确定的,范围为BAG=2k ms(0≤k≤7)。抖动是指从开始的BAG到第1个虚拟链分配的最大分配带宽传输的帧之间的间隔[1],两者关系如图2所示。
其中最大抖动边界必须符合以下公式:
式中,NWB为网络带宽,单位100 MB/s。
基于上述分析,本文给出两种调度器的实现方案。
(1)同步调度方案。为了简化控制逻辑和定时时间,该方案要求各虚拟链同步且传输在最小周期为T(T叟1 ms的范围内发生,具体设计如下:(1)每个虚拟链拥有独立的BAG定时器,即使2个虚拟链的BAG值相同,也不能使用同1个BAG定时器;(2)不同虚拟链的数据应该在不同的传输周期给媒体访问控制器;(3)拥有1个抖动定时器,各BAG定时器仅在抖动定时器溢出时才复位,最大抖动边界计算由式(1)确定;(4)每个虚拟链传输控制逻辑应设定1个可传输标志(FTT)来通知调度器传输该虚拟链的帧数据。下面以虚拟链A(BAGA=2 ms)和虚拟链B(BAGB=3 ms)传输过程为例对本方案进行说明。该调度器运行的结果如图3所示。
在图3中,将时间t ms到(t+1)ms定义为周期t,具体调度过程如下:
周期0:调度器启动,检测到虚拟链A有数据,且FTTA为1,经过一定抖动延时后调度帧A0,并复位FTTA。
周期1:检测到虚拟链B有数据,不经过抖动延时调度帧B0,并复位FTTB。
周期2:BAGA时间到,设置FTTA,检测到虚拟链A有数据,经过一定抖动延时后调度帧A1,并复位FTTA。
周期3:没有数据传输操作,保持原状态。
周期4:BAGA和BAGB时间都到,设置FTTA和FTTB,检测到虚拟链B有数据,经过一定抖动延时后调度帧B1,并复位FTTB;虚拟链A在超过最大抖动延时后没有帧数据传输,设置Reset BAGA,重新开始新的BAGA定时。
周期5:在新的BAGA周期检测到虚拟链A有数据,且FTTA为1,经过一定抖动延时后调度帧A0,并复位FTTA。
周期6:没有数据传输操作,保持原状态。
(2)异步调度方案。根据AFDX协议规定,1个AFDX的最长数据帧长为1518 B,假设以100 Mb/s速度传输,可以算出1个数据帧传输的最大时间为1 518×8/100=122μs,即使虚拟链以最小BAG时间(即1 ms)传输,也会留出大量空闲时间。因此,本调度方案就是考虑在1个最小BAG时间内同时传输多个虚拟链数据。具体设计如下:(1)每个虚拟链拥有独立的BAG定时器;(2)不同虚拟链的数据可以在同一个传输周期内被调度器调度,但是一旦某虚拟链开始传输,则只有等该虚拟链完全传输完后,才释放空闲时间;(3)每个BAG定时器是独立运行的,且拥有独立的抖动定时器,每个虚拟链的最大抖动边界由式(2)确定;(4)每个虚拟链传输控制逻辑应设定1个可传输标志(FTT)来通知调度器传输该虚拟链的帧数据。下面以虚拟链A(BAGA=1 ms)和虚拟链B(BAGB=1 ms)传输过程为例对本方案进行说明,该调度器运行的结果如图4所示。
从图4可以看出,虚拟链A和B各自定义了独立的最大抖动边界Amj和Bmj,并且将1 ms时间周期划分为n个小周期(每个小周期Tn=1 000/nμs)。调度时,每个帧传输应该在1个小周期内完成,当某个小周期被某帧占用后,只有等到下个小周期,才能用于传输其他帧。采用该调度方式,当传送帧的长度过长时,帧传输时间加上允许抖动有可能超过容许的Tn时间空档。在这种情况下,要使每个小周期传输正确可靠,就需要缩短最大抖动边界,或者限制每个虚拟链数据帧实际传输的长度,尽量不使用最大帧长度。
2.2 虚拟链传输控制
虚拟链的传输控制包括帧数据发送和接收2个独立的过程,发送和接收过程都存在3种操作模式:运行、终止和暂停状态。本文采用有限状态机来实现3种模式之间的转换与控制。下面以发送状态机的设计为例进行详细说明,发送状态机如图5所示。
(1)终止状态:当软硬件复位或接收到终止传输指令时,发送过程处于终止状态;当接收到开始发送指令后才能脱离停止状态;当处于停止状态时,传输进程停止。
(2)运行状态:该状态下执行发送数据帧的调度与传输。发送过程在以下情况下停止运行状态。
(1)软硬件被复位,则进入终止状态。
(2)NIOSⅡCPU发出停止传输指令,则进入终止状态。
(3)检测到发送FIFO下限溢位错误,即在帧传输过程中,当发送FIFO为空时,会形成1个下限溢位错误。一旦发生这种情况传输进程就会切换到暂停状态。
(4)发送过程描述符不可用时进入终止状态。
(3)暂停状态:该状态下暂停执行发送数据帧的调度与传输,但是系统保留发送过程的配置信息。发送过程在以下情况下跳出暂停状态:
(1)接收到发送轮询请求指令。当接收到该指令且发送FIFO没有下限溢位错误时,发送自动轮询会被激活,进入运行状态。
(2)NIOSⅡCPU发出停止发送指令,则进入终止状态。
3 仿真与实现
基于本文提出的设计方案,媒体访问控制器采用Actel公司的Core10/100IP核,其他硬件部分采用Verilog HDL语言在RTL级进行描述,NIOSⅡ软件采用C语言进行编程,最终集成在Altera公司的EP1S40芯片上进行了相关的仿真与验证。表1给出了采用不同调度方案、在处理不同个数虚拟链和不同缓存大小时,AFDX协议芯片处理单个虚拟链传输的平均用时。
从表1可以看出,异步调度方案的平均用时明显小于同步调度方案;同步调度方案的平均用时主要与最小传输周期T有关;异步调度方案情况下,随着小周期Tn变小,虚拟链和单个字节的平均传输用时也变小,但是当Tn小于200μs时,单个字节的平均用时没有明显地改变。由式(2)可知,当Tn变小时,虚拟链对固定抖动的影响就会变大,要使帧数据能正常完成,就必须减少虚拟链最大帧长Lmax的大小。所以当Tn小于200μs时,对提高帧数据的传输没有意义。
基于软硬件协同的思想设计了AFDX协议处理芯片片上系统,并在Altera公司的EP1S40芯片上进行了相关的仿真与验证。结果表明,该方案能很好地实现AFDX协议,可以实时地对虚拟链进行调度,完成数据帧的编解码,具有双冗余通道的功能。该设计方案兼备了硬件的强大并行处理能力及软件的灵活性和可编程性,具有方便、快捷、高效的优点,为片上系统的设计提供了一个很好的参考示例。
参考文献
[1]AEEC.ARINC664Aircraft data networks,Part7:avionics full duplex switched ethernet(AFDX)Network[S].Airlines Electronic Engineering Committee,2005.
[2]MCHALE J.AFDX technology to improve communications on boeing-787[J].Military&Aerospace Electronics Mag-azine,2005,16(4):22-23.
[3]LI Qiao,GE Peng,XIONG Hua Gang.Effective band-width over AFDX[C].25th IEEE Digital Avionics Systems Conference,2006.
[4]Actel Corporation.Developing AFDX solutions(application note AC221)[DB/OL].http://www.actel.com.2005.
[5]熊志辉,李思昆,陈吉华.支持平台设计方法的系统芯片协同设计环境[J].计算机辅助设计与图形学学报,2005,17(7):1401-1406.
软硬件协同 篇6
传统使用FPGA的数字信号处理系统的设计,首先需要用仿真软件进行建模仿真,得到预想中的仿真结果后,再根据仿真过程和结果,使用硬件描述语言创建硬件工程,最后完成硬件仿真。整个过程漫长而繁杂,尤其困难的是仿真过程不够直观,一旦遇到问题无法及时准确地确定问题所在。随着业界引入Simulink仿真开发工具,虽然可以对数字系统进行直观的仿真,但由于软件仿真仍与硬件实现有着相当大的距离,最初只被用于软件仿真阶段。而Altera DSP Builder将MathWorks Matlab和Simulink系统级设计工具的算法开发、仿真和验证功能与Altera开发工具整合在一起,缩短了软件仿真与硬件实现间的鸿沟。DSP Builder在算法友好的开发环境中可以帮助设计人员快速生成DSP设计硬件表征,从而缩短了DSP设计周期。已有的Matlab函数和Simulink模块可以和Altera DSP Builder模块以及Altera知识产权(IP)MegaCoreR功能相结合,将系统级设计实现和DSP算法开发相链接。DSP Builder支持系统、算法和硬件设计共享一个公共开发平台[1]。它还引入回路硬件(HIL)的思想,可以将硬件平台接入仿真链路,在不具备测试条件和环境的情况下,进行软硬件协同仿真,具有很强的实用性。
2 基于DSP Builder的DSP系统开发流程
首先使用DSP Builder模块搭建完成特定功能的系统,然后使用Simulink构建软件测试环境以及测试向量。软件仿真完成后使用Signal Compiler编译DSP Builder模块生成HDL工程[2]。但由于现阶段自动生成的代码可读性不够强,效率上不够高,所以需要对代码进行优化。即使这样,相对于传统开发方式还是极大地减少了开发者的劳动强度。完成之后就可以结合Altera其他开发工具进行综合、布局、布线。在不存在硬件测试环境的情况下,还可以使用HIL模块,将硬件平台链接入DSP Builder进行软硬件协同仿真。DSP Builder开发流程如图1所示。
3 基于DDS的多功能调制器设计
直接数字合成器(Direct Digital Synthesizer,DDS)是采用数字技术的一种新型频率合成技术,其通过控制频率、相位增量的步长,产生各种不同频率的信号,进而达到调制的目的[3]。它的优点有:较高的频率分辨率;可以实现快速的频率切换;在频率改变时能够保持相位的连续;容易实现频率、相位和幅度的数控调制。
3.1 基于DDS的调制器原理
DDS系统的核心是相位累加器,它由一个累加器和一个N位相位寄存器组成。每到一个时钟脉冲,相位寄存器以步长M增加。相位寄存器的输出与相位控制字相加,其结果作为正(余)弦查找表的地址。正(余)弦查找表由ROM构成,内部存有一个完整周期正弦波的数字幅度信息,每个查找表的地址对应正弦波中0~360°范围内的一个相位点。查找表把输入的地址信号映射成正(余)弦波的数字幅度信号,同时输出到乘法器输入端[4],与幅度控制字相乘后产生输出波形。图2是基于DDS技术调制器的基本原理图。
3.2 利用DSP Builder设计基于DDS的调制器
由于篇幅所限,只列举出基于DDS的频率调制器。其调制原理是:使用输入的数字信号控制电子开关在两个不同的频率控制字间进行切换,从而达到输出不同频率信号的目的。具体实现如图3所示。幅度与相位调制器的原理与调频类似,也是通过调制信息选择不同的幅度控制字和相位控制字来实现。
本设计中累加器由带缓存功能的加法器模块实现,在生成的HDL工程,可以看出,软件调用的是Altera的LPM加法器模块来实现硬件电路。用于储存波形数据的ROM是由Altera的IP核LPM_ROM实现的。
3.3 仿真结果及分析
本仿真通过引入HIL模块来进行软硬件协同仿真。首先在Simulink平台下进行软件仿真,当结果满足设计要求时,使用Signal Compiler将Input,Output模块之间DSP Builder模块生成HDL工程,经代码优化后搭建顶层含HIL模块的仿真平台,如图4所示。设置两个不同的频率控制字分别为500000和900000,由输入数字信号对这两个频率控制字进行选择,进而影响载波频率,达到调频的目的。设置相位控制字为90,幅度控制字为5,由脉冲发生器产生随机脉冲数字信号作为调制信息。
通过设置HIL模块,在其中添加FPGA工程。硬件平台选用Altera DE1board,置有CycloneII EP2C20F484C7芯片。仿真链路创建好后,进行仿真。图5为引入HIL模块的软硬件协同仿真结果,与单独使用Simulink进行仿真的结果相同。可以看出由于调制信号的存在,当输入比特1的时候输出高频载波信号,反之输出低频载波信号,且两种频率切换时,相位连续。软件仿真与软硬件协同仿真结果相吻合,实验结果表明,该基于DDS技术的调制系统频率和相位灵活可调,具有较高的频率分辨率,性能良好。理论上,只要构成正弦信号的查找表样本足够大,输出信号的位宽足够长,输出波形的分辨率可以无穷小。但出于节省资源的角度考虑,通常不会将样本点数选得过大。
4 DMB-TH系统的交织解交织器设计
由于大多数编码是基于信道差错满足统计独立的特性而设计的,但由于实际信道往往是突发错误与随机错误并存的组合信道,所以需要利用交织技术将信道错误的相关度减小。在交织深度足够大的时候,就可以把突发错误离散为随机错误,为正确译码创造更好的条件。交织又可以分为分组交织和卷积交织。DMB-TH标准中使用的是卷积交织。
4.1 卷积交织、解交织器原理
时域符号交织编码是在多个信号帧的基本数据块之间进行的,其原理如图6所示。数据信号(即星座映射输出的符号)基本数据块间的交织采用基于星座符号的卷积交织编码,变量B表示交织宽度(支路数目),变量M表示交织深度(延迟缓存器尺寸)。
进行符号交织的基本数据块的第一个符号与支路0同步。交织、解交织对的总时延为M×(B-1)×B个符号[5]。
4.2 DMB-TH标准下交织解交织器的设计与实现
本文以国标中的一种交织模式为例进行设计,即B=52,M=240个符号[6]。顶层模块如图7所示。Conv_interlever是交织器模块,Con_Deinterlever是解交织器模块。交织器子模块的核心是基于Memory Delay的延迟模块,用来实现数据的定量延时。在FPGA内部实现中是通过调用LPM_RAM模块来实现的。
4.3 仿真结果及分析
图8是基于HIL模块的软硬件联合仿真波形图,上面是输入的待交织信号,中间是经过交织后的信号,下面是解交织后的数据信号。因国标中的交织与解交织器交织深度较大,故解交织器的输出信号会有一个明显的延迟。
构造仿真模块与搭建仿真环境完成后,运行Signal Compiler生成HDL工程,由于本设计使用的片上存储单元众多,所以需要注意一下资源的使用情况。硬件实现后发现本交织、解交织器共使用了5×106 byte的存储单元,消耗十分巨大,有待进一步改进。
5 结论
本文通过对基于DDS的多功能调制器以及DMB-TH标准下的交织、解交织器进行了设计实现。本方法可以快速构建DSP系统,并在外部硬件测试平台不够完备的情况下,引入HIL模块进行软硬件联合仿真。相对于传统开发方式,具有更大的优势。
摘要：传统DSP系统开发过程中从理论分析到软件仿真再到硬件实现,周期长效率低。而采用基于DSP Builder的快速DSP系统开发方法,可以快速完成模型创建,软件仿真,硬件实现,特别是通过引入回路硬件(HIL)模块,可以将硬件平台链接入由Simulink构建的仿真测试回路,进行软硬件协同仿真。文中通过设计基于直接频率合成器技术的多功能调制器(可用于中国地面数字电视广播传输标准DMB-TH),以及中国地面数字电视广播传输标准下的交织/解交织器来对这种开发方式进行研究,在提高开发效率的同时,得到了令人满意的结果。
关键词：DSP Builder,回路硬件,直接数字合成器,交织/解交织器
参考文献
[1]Altera.DSP Builder User Guide[EB/OL].[2009-04-20].http://www.altera.com/literature/ug/ug_dsp_builder.pdf.
[2]Altera.DSP Builder Reference Manual[EB/OL].[2009-04-20].http://www.altera.com/literature/manual/mnl_dsp_builder.pdf.
[3]马品红.基于SOPC的任意波形发生器的研究与开发[D].辽宁,大连:大连理工大学,2006.
[4]石玮.基于FPGA和双端口RAM的DDS任意波形发生器的实现[J].湖北师范学院学报:自然科学版,2008,28(1):41-45.
[5]徐孟侠.对中国地面数字电视广播传输标准的注解和评论[J].电视技术,2007,31(4):4-9.
软硬件协同 篇7
1 SOPC系统框架
SOPC即可编程的片上系统, 是Altera公司提出来的一种灵活, 高效的SOC解决方案, 它将处理器、存储器、I/O口等系统设计所需功能集成到一个可编程器件上, 构成了一个可编程的片上系统, 并支持NIOS可编程软核, 实现一个面向用户的, 可灵活定值的通用RISC嵌入式CPU, 即基于FPGA的嵌入式IP软核。用户可以定制基于硬件处理模块的指令, 把系统中软件处理耗时最多的关键算法用硬逻辑电路来实现, 使NIOS系统具有专用处理器才具有的特殊功能及软件算法灵活多变的特点。使用用户自定义指令, 用户能够向NIOS处理器的算术逻辑单元 (ALU) 和指令系统中增加用户自定义功能[2]。
简而言之, 用户指令就是让NIOS处理器完成某个特定的功能, 并且这个功能由硬件电路来实现, 这个硬件电路可以用VHDL与Verilog语言描述, 并且连接到NIOS处理器中ALU单元, 用户指令硬件与ALU共享两个输入端;用户指令硬件的连接到ALU输出多路选择器MUX上, 当使用用户指令时, ALU的操作结果被忽略。
2 人工神经网络的基本原理
神经网络是由大量神经元通过特殊形式的加权网络相互连接而形成, 主要由收集信号并且完成非线性变换的神经元细胞和完成各神经元之间加权互联的突触[3]两个基本单元构成。BP神经网络是最简单且运用较广泛的模型, BP神经网络即误差后向传播网络, 是一种前馈网络, 由输入层、隐含层和输出层构成。隐含层通过网络激活函数执行一种固定不变的非线性变化, 将输入空间映射到一个新的空间, 输出层节点则在新的空间进行线性加权组合[1]。
2.1 神经网络的学习方法
BP神经网络学习算法的主要思想是从后向前反向逐层传播输出层的误差, 间接计算隐层的误差。算法可以分为两个阶段:第一阶段是一个正向过程, 输入信息从输入层经隐层逐层计算个单元的输出值;第二阶段是一个反向传播过程, 输出层的误差逐层向前传播, 算出隐层个单元的误差, 并用误差修正权值。
2.2 神经网络的学习方法的公式实现
神经网络是由大量神经元细胞组成, 各个神经元细胞模型如图1所示。
神经元细胞模型是仿照生物神经元提出的, 神经元可以有N个输入:x1, x2, …, xN。每个输入端与神经元之间有一定的联接权值:w1, w2, …, wN。神经元总的输入为对每个输入加权求和, 同时减去阈值:
神经元的输出y是通过激励函数f (u) 对每个神经元总输入u的映射:
从公式1与公式2中可以看出, 在神经网络的FPGA实现中, 每个神经元都有大量的浮点数的乘法累加运算, 所以可以利用SOPC与NIOS定制基于硬件的用户指令来实现。而激励函数f (x) 具有非线性性, 其中Sigmoid函数运用最为广泛:
从公式3可以看出, Sigmoid函数是非线性函数, 在FPGA内利用VHDL实现难度较大。在文献[4]中提出了利用非线性函数和查表相结合来逼近Sigmoid函数的方法 (如表1所示) , 通过matlab仿真FPGA的输出值与Sigmoid理论值相差约0.8%, 具有较好的实现结果。
3 神经网络算法的软硬件协同设计
软硬件协同设计指对系统中的软硬件部分使用统一的描述和工具进行集成开发。其基本的设计流程是先用VHDL语言和C语言进行系统描述并进行模拟仿真和系统功能验证, 然后对软硬件实现功能划分, 分别用语言进行设计并将其综合起来进行功能验证和性能预测等仿真确认;其次进行软件和硬件详细设计;最后进行系统测试[7]。
3.1 采用Quartus II的浮点数乘法累加器的实现
在Quartus中新建工程, 顶层实体为原理图 (Block Design File, .bdf) , 利用浮点数宏模块, 添加浮点数乘法和加法器, 根据浮点数乘法器与加法器时序, 利用VHDL设计控制单元counter, 控制乘法器与加法器的使能端和时序, 然后进行仿真测试。因为在NIOS中用户定制指令只支持.vhd文件的转化, 所以将.bdf转化保存为.vhd格式。
3.2 建立SOPC硬件平台和用户定制指令的实现
在Quartus中建立新的工程, 添加PLL、控制单元和IO口等SOPC的外围电路, 启动SOPC-Builder, 添加CPU核 (NIOS II-f) 、SDRAM, I/O, Flash, UART-JTAG和Avalon三态桥等设备, 为了实现NiosⅡ处理器对EPCS Flash存储器的读写访问, 还要加入EPCS Serial F1ash Controller组件, 将FPGA配置的SOF文件和CPU运行的软件一并存于EPCS器件中。为了保证所有设备对Avalon总线的地址安排是合法的, 要对各组件地址实行地址自动分配;最后进行全程编译 (即分析、综合、适配和输出文件装配) , 完成NiosⅡ硬件系统的设计。
在SOPC-Builder的界面中, 点击CPU项, 选择Custom Instructions选项卡, 添加用户自定义指令CI_Float_multadd (data_w, data_x, N) , 在C语言中的调用格式为u=CI_Float_multadd (data_w, data_x, N) , CPU在第1个时钟以enable信号通知自定义逻辑电路开始运算, 第13个时钟到达时运算结果有效, CPU会去读取数据。
3.3 NIOS II下神经网络算法的实现
在BP网络中, 神经元做为整个网络的基本组成单元, 是进行学习和判断的主要器件, 在公式1中, 可以设阈值为0, 这样简化整个神经元的运算过程。启动NIOS IDE, 建立工程并加载SOPC建立的工程.ptf文件, 构建硬件平台。根据BP神经网络的需求配置各个神经元, 一个具有N输入神经元程序如图2所示。
4 试验结果和系统测试
本系统试验平台采用Altera公司CycloneII系列的EP2C8Q208-A-C8V4型FPGA。器片内资源丰富, 同时支持NIOS软核处理器。系统时序仿真采用Quartus 9.0内置的Simulation时序仿真, 两输入乘累加仿真结果时序图如图3所示。
从实验结果可看出, 完成一次浮点数乘累加需要12个时钟周期, 神经网络模块在第13个时钟周期后输出运算结果, 所以完成N输入神经元需要时间N*13*CPU时钟 (CLK) , 而且可以采用流水线设计, 指令的执行时间将会大大缩减。对于激励函数采用文献[4]中提供的逼近函数, 利用Matlab建模神经网络参数, 参考文献[4]中给出输出函数与理想Sigmoid输出之间的最大绝对误差为0.77%, 平均误差为0.27%。该仿真结果表明, 利用激励函数逼近算法作为FPGA神经网络实现的激励函数是可行的。
5 结语
本文采用SOPC软硬件协同设计用户定制指令, 模拟神经元组件神经网络处理, 以往需要调用多个函数, 耗费大量时间才能实现的功能, 现在仅需几个指令即可完成, 而且支持流水线和并行处理, 网络规模越大, 速度优势就越明显。同时, 本文不以VHDL语言来构建神经网络模型, 易于新型神经网络的快速扩展到FPGA中。
摘要：提出了一种基于SOPC的神经网络的软硬件协同设计的实现方法, 该方法以FPGA器件上SOPC为硬件载体, NIOS IP软核处理器为CPU, 采用用户自定义指令, 在NIOS中利用C语言编写神经网络算法程序, 实现神经元细胞中软硬件协同设计浮点数乘积累加操作。整个系统在Altera的cyclone Ⅱ器件上测试, 改变以往神经网络采用VHDL语言设计时出现的灵活性较差, 不利于新型的神经网络模型移植到FPGA中的劣势。
关键词：SOPC,神经网络,自定制指令,软硬件协同设计
参考文献
[1]杨银涛, 汪海波, 等.基于FPGA的人工神经网络实现方法的研究[J].现代电子技术, 2009, 305 (18) :170-174
[2]周立功.SOPC嵌入式系统教程[M].北京:北京航空航天大学出版社, 2006, 11
[3]薛维琴, 李莉华, 戴明.基于FPGA的人工神经网络系统的实现方法[J].电子工程设计, 2010, 18 (9) :151-153