软硬件协同设计（精选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
随着集成电路设计规模的不断扩大, 复杂度越来越高, 在系统级别进行软硬件规划对SOC (System on Chip) 系统性能的影响日趋增大。数字视频解码芯片是多媒体领域的核心, AVS (Audio Video coding Standard) 音视频编码标准采用了最新视频编码技术对压缩效果有很大改善, 但其压缩效率的提高也是以算法复杂度的增加为代价的, 因此造成了单纯用软件解码难以达到很高的性能。本文在研究了AVS视频编码标准和数字视频解码芯片系统结构的基础上, 设计了硬件与H.264模块兼容, 并且支持AVS Part-2的SOC视频解码芯片结构。基于电子系统级设计ESL (Electronic System Level) , 利用ARM SOC Designer ESL平台分析系统的瓶颈实现软硬划分。通过SystemC 对硬件单元周期精确建模, 实现软硬件协同仿真验证。
1 解码器结构软硬件协同建模
AVS 标准的开发路线是基于可以合法免费使用的开放技术和自主研发的专利技术相结合, 在具体实现上, AVS-P2主要采用H.264作为模版使用基于PCM结构的压缩方式。AVS解码器模块大致可分为以下几个部分:首先是码流熵解码, 然后经由重排序对其残差信息进行反量化和反变换。在宏块级进行帧内预测和帧间运动补偿, 然后进行环路滤波消除块效应, 最后恢复出编码前图像, 具体流程如图1所示。
1.1 硬件平台搭建
为了便于对整个解码器系统所有模块做整体评估, 以便于软硬件划分, 首先需要搭建一个简单的测试平台。硬件方面使用ARM公司SoC Designer Canvas工具搭建一个简单的模块评估平台, 如图2所示所有硬件模块均为SystemC模拟实现。系统中CPU选用ARM926, 通过AHB总线连接P-Memory和D-Memory以及APB Bridge, APB总线上挂接Timer模块和中断控制器。软件方面从代码移植入手, 根据AVS标准工作组提供的基于PC平台的AVS解码器代码移植到ARM平台。
1.2 软件代码移植
软件从x86平台的C++语言向ARM平台的C语言移植的过程中所做修改主要包括: (1) 替换原来x86汇编指令为ARM指令。 (2) 修改C++语法为C语言语法, 如指针申请与释放new替换为malloc, 数据类型转换, 如bool型替换为int;修改头C++文件为C语言头文件。 (3) ARM平台语法移植。在源代码数据类型强制转换的地方根据ARM平台的系统结构修改变量大数端和小数端;修改数据的对齐方式;x86和ARM的移位操作, x86移入的数为1, 而ARM移入的数为0, 所以也要对源代码中的移位运算做修改。
2 软硬件结构划分
将移植修改之后的代码用ADS 1.2编译之后生成.axf文件, 使用SoC Designer Simulator 工具载入该文件运行。使用自带的Profiling软件, 分析解码器解5帧数据每个模块所运行的时间, 如表1所示。
从统计结果可以看到, InterPredLuma, InterPredChorma等帧间预测函数占用系统时钟比例最大, invtransformB8整数型离散余弦变换 (IDCT) , IntraPredLum, IntraPredChroma帧内预测等函数也占相当大的CPU资源, 其他占用系统资源的还有环路滤波, 帧重建等函数。从系统调用次数及深度, 以及硬件电路实现成本和复杂度考虑, 适宜将整数离散余弦变换 (IDCT) 模块、帧内预测模块、帧间预测模块以及环路滤波模块使用硬件加速, 其它码流控制信息等使用软件实现。
3 硬件加速模块实现
3.1 可重用性设计
AVS标准与H.264标准在协议层上有高度的兼容性, 作为芯片的扩展功能本文使用了一种与H.264兼容的硬件设计方案, 即所有设计的硬件加速模块可同时作为H.264解码器的模块使用, 用户只需要修改软件代码部分即可使用本系统结构解H.264 baseline和main profile的码流。
IDCT模块AVS标准使用的是8×8矩阵, 而H.264使用的是4×4矩阵, 但实现上都是进行两次一维IDCT变换, 对输入的4×4的H.264矩阵进行两次一维IDCT变换, 先分别对4行的数据进行快速蝶行算法, 再分别对4列的数据进行快速蝶行算法, 8×8的AVS矩阵进行两次一维IDCT变换, 先分别对8行的数据进行AVS快速蝶行算法, 再分别对8列的数据进行AVS快速蝶行算法, 可根据以上算法分别写出AVS和H.264的IDCT变换函数, 在解码时判断需要调用哪一个函数。详见参考文献[5]。
其它帧内预测, 帧间预测以及环路滤波的模块也是根据输入的参数不同, 在模块执行前加判断组合逻辑, 根据不同的执行条件决定运行H.264还是AVS解码。
3.2 硬件接口与实现
实验使用ARM工具集中系统级平台工具SoC Designer模拟上节分析结果中需要硬件实现的模块。SoC Designer工具本身兼容SystemC, 并且提供了很多实现好的系统模块库供使用, 使得建模的时候可以更专注于系统模块之间的接口设计, 而不用过多的关注硬件方面等细节问题。SoC Designer提供了各种类型的组件库, 有Bus, Core, Memory等等不同类型。用户可以通过拖拽的方式方便地搭建起自己的系统。SoC Designer还支持了用户自定制库的方式。它可以根据用户的要求生成一个基本的框架, 具有基本的类和函数, 用户也可以进行相应的设计, 并可以用VC .NET将其编译成DLL动态链接库添加到SoC Designer的库列表里, 使开发者可以与其他库一样调用自己定制的模块库。
硬件需要其它一些必要的时钟信号和AHB总线接口由ESL自动生成, 功能模块的实现主要集中在communicate和update函数中, 将原来在软件函数中相应的功能用SystemC实现, 并添加到update和communicate函数中。模块的硬件接口寄存器声明是根据软件函数中的参数来定义的, 即把软件代码函数传输的参数修改成硬件的接口信号和寄存器;然后修改软件和硬件的接口部分使其能正常通信。由于查询方式占用CPU较多, 系统使用中断方式进行模块间消息通信, 使用硬件加速与软件协同后的解码器结构如图3所示。
4 实验结果
表2是使用纯软件AVS解码与使用SOC系统软硬件协同解码前后解码7帧AVS测试序列的对比情况。使用的测试序列为IPPPPP, QCIF (176×144) 格式。
从试验结果可以看出, 使用SOC软硬件协同解码对解码性能有很大提高。硬件模型所需要的周期是软件解码时间的1/25到1/12, 整个芯片解码速度提高16.3倍, 可以实现实时解码需求。
5 结束语
实践结果证明基于软硬件协同设计进行系统设计不仅可以加快视频解码器SOC的开发速度, 并且设计的视频解码芯片软硬件结构更为合理, 使用硬件加速模块可以有效提高系统的性能, 也有利于以后系统功能的扩充。
参考文献
[1]信息技术先进音视频编码第2部分:视频 (报批稿) [S].2004.
[2]高文, 黄铁军.信源编码标准AVS及其在数字电视中的应用[J].电视技术, 2003 (11) :4-6.
[3]彭聪.多模数字视频解码SOC芯片设计及研究[D].博士毕业论文, 2006.
[4]Thomas Wiegand, GaryJ Sullivan.Overviewof the H.264/AVC VideoCoding Standard[J].IEEE TRANSACTIONS ON CIRCUITS ANDSYSTEMS FOR VIDEOTECHNOLOGY, 2003, 13 (7) .
[5]Rindert Schutten.基于ESL并采用SystemC和SystemVerilog的设计流程[J].EDN电子设计技术, 2006 (4) .
软硬件协同设计 篇3
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.
软硬件协同设计 篇4
本文采用软硬件协同的设计思想,设计了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.
软硬件协同设计 篇5
随着航天用FPGA复杂度的不断增加, 其验证的复杂度就越来越高, 设计验证的过程往往比设计本身更复杂, 复杂系统的功能验证正成为FPGA设计的一个重大挑战。传统的HDL_testbench数字系统硬件验证方法使得验证过程非常缓慢[1,2], 为提高验证效率, 本文提出了系统级仿真器与RTL级仿真器的协同仿真方法, 在高效协同仿真接口的支撑下, 一体化验证平台是提高系统功能验证效率的必然途径。
本文对软硬件一体化协同验证平台的搭建进行详细描述, 基本框图如图1所示。在此平台上对AES算法的RTL实现进行了全面验证。经验证, 软硬件协同仿真大大缩短了开发周期并提高了验证效率。
2 软硬件一体化协同验证平台搭建
软硬件协同验证的本质在于快速地实现FPGA设计中的硬件模块, 让软件模块在真正的硬件上高速运行。
软硬件协同仿真平台包括三大部分:
(1) 以AES算法规范为基础的ESL model (C model) [3]。
(2) 以HDL语言描述的AES算法RTL model[4,5,6,7]。
(3) C model与RTL model通信接口及测试输入/输出文件[8]。
平台架构框图如图2所示, ESL model为AES算法的C语言模型[9], 该模型根据算法运行参数和输入文件, 对当前输入数据进行AES加/解密操作, 并将当前输入数据的加/解密结果输出到结果文件中。输入文件可以由用户指定, 也可以由模型自动随机产生。输入/输出文件均以TXT文件形式存储。
RTL model为AES算法的HDL语言模型, 即待验证模型。该模型时钟周期为行为粒度, 对当前输入数据进行硬件加/解密操作, 并将输出结果以FSDB波形的形式存储。
C model与RTL model通信接口以C语言和HDL语言的文件操作为基础, 在RTL model的testbench中实现测试输入数据的共享及测试输出数据的比对。
3 软硬件协同仿真平台测试流程
在启动AES算法RTL验证之前, 需要做如下准备工作:
(1) 完成AES算法Cmodel及makefile, 并通过AES标准测试数据保证Cmodel的正确性。
AES算法C model源程序main函数提供9个可配置参数, 包含AES加解密工作模式、测试数据来源、AES加解密工作步长、测试源文件及结果文件名。
AES可执行文件在执行过程中会打印出相关的控制参数, 以便后续的分析和调试。
(2) 完成AES算法RTL model及testbench。
(3) 完成软硬件协同验证调度文件aes_test, 该文件主要功能是生成aes.exe文件、执行aes.exe文件、执行RTL simulation、执行bit2bit比对并打印比对结果。
aes_test文件包含3个可执行程序或命令:make、aes.exe、aes_top_sim, 如图3所示。
make命令调用aes_makefile.txt, 完成AES算法C model编译, 生成aes.exe可执行文件;aes.exe文件为AES算法的可执行文件, 运行可执行文件需提供了相关参数及文件名;aes_top_sim为AES算法RTL仿真启动命令, 该命令调用aes_top_tb执行硬件仿真。
自动协同验证流程图如图4所示。
逐比特对比是最容易也是最稳妥的方式, 所以在C模型和RTL模型输出数据时, 对输出结果进行bit级的对比。如果比对成功, 则打印出比对正确的信息, 硬件仿真可以继续进行下去, 直到所有输出数据比对完成;如果对比不成功, 则要判断是哪里出错, 出错的信息要容易判读, 所以出错信息的可读性就非常重要。当对比不成功时, 将出错的数据位信息打印至屏幕上, 并中断硬件仿真, 随时进行RTL代码的debug。
软硬件协同仿真基于NC-sim仿真器。AES算法的工作模式在aes_test中通过控制参数传递给可执行文件, 并打印至屏幕, 测试数据源为随机数。在C model完成测试数据的准备后, 启动NCverilog硬件仿真过程, 并将仿真结果实时打印至屏幕上, 如图5所示。
当测试数据源全部输入完毕, 输出结果同时比对正确, 硬件仿真即正常退出并自动结束, 同时保存执行过程的日志文件, 以便后续的查询及分析, 如图6所示。
4 软硬件协同仿真平台验证评估
本文提出的软硬件协同仿真平台旨在在更高级的语言环境中创建和维护HDL设计, 提供比HDL仿真器更快的测试和验证基准;只以HDL实现可综合的设计部分, 在系统级和HDL仿真器之间提供快速协同仿真;可以对多个HDL硬件设计进行分布式验证, 从而明显提高验证效率。
通过对AES算法的HDL实现进行验证, 由图7中可以看出基于软硬件协同仿真平台的验证比传统的手工HDL输入测试向量的方法速度提高了20倍;软硬件协同仿真平台由高级语言自动产生测试向量, 保证了测试向量的正确性, 将验证的可靠度提高了1倍;硬件协同仿真平台由高级语言随机产生测试向量, 避免了人工逐条输入测试向量的随意性, 从测试方法的角度保证了测试的覆盖度, 验证不存在缺项、漏项, 将验证的可靠度提高了4倍。
5 结语
随着航天产品功能的不断增加, 性能的不断提高, 其FPGA设计规模及复杂度在飞速的增长。为了验证整个设计在各种工作环境、工作模式下的正确性, 需要做大量的验证工作, 本文提出的灵活可配置的软硬件统一验证平台大大提高了FPGA设计验证的效率、可靠度和测试覆盖度, 可以广泛应用于航天产品的FPGA验证中。
摘要：随着FPGA设计功能越来越强、器件结构越来越复杂, 其验证的复杂度就越来越高。对于一个大规模FPGA设计, 其逻辑验证的效率和可靠性往往决定了任务的成败。本文介绍了一种软硬件自动协同仿真平台的搭建, 在此平台上对AES算法的RTL实现进行测试验证, 与传统RTL级验证相比, 软硬件协同仿真大大提高了逻辑验证的验证效率和测试覆盖率。
关键词：软硬件协同仿真平台,AES算法,逻辑验证
参考文献
[1]J Bhasker.Verilog HDL Synthesis A Practical Primer[M].北京:清华大学出版社, 2004.
[2]Michael D Ciletti.Advanced Digital Design With the Verilog HDL[M].Beijing, China:Pub.House of Electronics Industry, 2004.
[3]谭浩强等.C程序设计 (第2版) [M].北京:清华大学出版社, 1999.
[4]Samir Palnitkar.夏宇闻, 胡燕祥, 刁岚松, 等译.夏宇闻审校.Verilog HDL数字设计与综合 (第2版) [M].北京:电子工业出版社, 2007.
[5]曹晓丽, 王爱强.AES算法研究[J].洛阳师范学院学报, 2011, 30 (8) :74-75.
[6]Kshirsagar, Vyawahare.FPGA Implementations of AES Algorithm[C].IEEE Electronics Computer Technology, 2011, 3 (3) :401-405.
[7]Xinmiao Zhang, Parhi K K.High-speed VLSI architectures for the AES algorithm.Very Large Scale Integration (VLSI) Systems, IEEE transactions on Volume12, Issue 9, Sept.2004:957.
[8]章立生, 韩承德.SOC芯片设计方法及标准化[J].计算机研究与发展, 2002, 29 (1) :1-2.
软硬件协同设计 篇6
随着电子技术的发展，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.
软硬件协同设计 篇7
传统使用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.