软硬件协同范文（精选6篇）
软硬件协同 第1篇
关键词：SOPC,FPGA:软核处理器,协同设计,软硬件划分
0 引言
可编程器件的片上系统(SOPC),或者说是基于大规模FPGA的单片系统,目标是利用FPGA设计一种较完整的电子系统,这种系统包括嵌入式处理器、接口、硬件协处理器或加速器、DSP、数字通信、存储电路等。
SOPC在电子设计技术上给出了一种软硬件综合解决方案。要求设计者除了了解基本的EDA软件、硬件描述语言和FPGA器件相关知识外,还必须熟悉计算机组成和接口、汇编语言和C语言、DSP算法、数字通信、片上系统构建与测试知识。
1 软核Nios II概述
1.1 Nios II软核处理器
显然,必须具备一个嵌入式处理器是可以进行软件开发的前提,否则硬件功能通过软件实现就无法完成。Nios II系列是Altera推出的第二代软核嵌入式处理器解决方案。其内核是一个32位的RISC处理器,具有共享的通用指令集结构。提供32位处理器基本结构组成,如32位数据和地址总线、可配置的指令或数据cache、支持256条定制指令和支持自定义外设等。
Nios II系列包含了3种独特的内核,可以让设计者在逻辑资源和处理器性能之间综合考虑,设计非常灵活。Nios II支持实现最通用的嵌入式设计,可以建立最合适的处理器、外设、接口和存储器组合方案。开发工具为GNU tools套件,支持C/C++、PASCAL及汇编等语言。
1.2 Avalon总线
Avalon总线是专为基于SOPC的处理器而设计的。Avalon总线规范为描述外设的端口提供了基础。一个基于Avalon总线的典型系统包括许多功能模块。有2种基本访问方式,主端口(Master Port)和从端口(Slave Port)。所有的Avalon端口都是与Avalon总线模块相连从而使得系统各部分能协调工作,实现设计功能。
2 软硬件协同设计
嵌入式系统发展的初期,主要存在2种开发方式。一是针对某一特定的硬件系统进行软件开发;二是根据已有的软件系统实现其具体的硬件结构。
软硬件协同设计出现以后,从系统功能描述开始,将软硬件完成的功能作均衡考虑。在设计实现时,始终保持软件和硬件设计的并行进行。在设计后期对整个系统进行验证,最终设计出满足条件约束的目标系统。
SOPC的核心技术是系统功能集成。设计方法较传统方法有根本改变,即从以功能设计为基础的传统流程转变到以功能组装为基础的全新流程。
软硬件协同设计在实际应用中表现为软硬件协同设计平台的开发。首先对不同的任务目标找到最恰当的设计方案。然后进行软硬件划分,产生硬件描述、软件描述和软硬件边界描述3个部分。
软硬件划分是软硬件协同设计的关键步骤,其基本任务是在满足某些约束的条件下,将系统功能行为“最优地”分配到一定的软硬件系统结构上进行设计规划。SOPC系统中,有以下3种硬件加速方式可以大大提高软件处理速度:① 自定义指令方式;② 自定义外设方式;③ C2H方式。
完整的用户自定义指令包括用户自定义逻辑和软件宏2个部分。使用自定义指令,可以将用户自定义逻辑加入Nios II的算术逻辑单元(ALU)和指令系统中。
自定义外设方式,是指将一些重复使用频率较高的模块,预先通过FPGA设计的方法完成,然后挂接在Avalon总线上。
C2H方式,是指可以将C代码中的某些函数,通过C2H指令,由硬件电路实现,用户不必关心此模块的实现方式及挂接方式。如对下述乘加函数:
若采用传统CPU指令执行方式,所需指令周期将非常大,而采用C2H硬件加速,则本函数只需几个时钟周期即可完成,提升效率非常明显。
3 案例分析
3.1 任务分析
笔者所承担的某大型通信设备中,模拟用户接口板是该设备中所需数量最多的接口板之一,提供多路模拟用户接口,该电路板可以认定为是一个通信系统。
本电路板所包含的功能模块包括: DTMF/MFB模块、脉冲拨号检测模块、 TDM交换矩阵、FSK来电显示、单路有线入口规约CPC信令、维护管理及CC信令等。
3.2 软硬件划分
传统解决方案划分:由专用的分立CPU和DSP(如TI的C54xx和C67xx等)完成软件(包括编解码软件)处理,由FPGA(如Altera的Cyclone或CycloneII等)实现硬件功能。即: ① CPU完成:摘挂机上报、维护管理及CC信令、包格式适配解适配; ② DSP完成:DTMF、CVSD编解码、FSK来电显示、回波抵消; ③ FPGA完成:TDM交换矩阵、CPC信令、摘挂机检测、脉冲拨号检测、TDM适配;
可以看出,由于CPU和FPGA的各自实现方式上的差异,使得有些功能模块需要拆分,才能达到所需性能要求。如适配处理拆分成TDM码流和包格式2种不同处理方式,分别在FPGA和CPU中完成,类似还有摘挂机处理,需要在FPGA中进行检测,而CPU完成上报。这样就增加了许多模块间并不必要的接口。如图1所示。
基于SOPC的软硬件划分:则可以摒弃传统划分方案的CPU和DSP,仅仅依靠FPGA来完成:
硬件部分:TDM交换矩阵、CPC信令、摘挂机检测、脉冲拨号检测、TDM适配;
软件部分:维护管理及CC信令、DTMF、CVSD编解码、FSK来电显示、回波抵消。如图2所示。
3.3 软件系统设计
软件开发:在Nios II IDE创建系统工程。将3.2节中划分的软件设计代码放入。根据各模块需要来确定调度关系。
外设驱动:本案例中,需要的外设包括TIMER、UART、SDRAM、FLASH及自定义外设。以UART和SDRAM为例,利用HAL(硬件抽象层)提供的外设驱动函数,使其正常工作。
UART驱动:Nios II系统中,UART作为SOPC Builder组件库中的一个组件模块包含在开发包中。开发包中定义了UART的数据结构。在Nios II IDE里在所建工程的系统库中,将标准输入输出设置为UART,然后就在软件程序中可以使用printf()、getchar()等输入输出函数直接操作。
SDRAM控制器:以MT48LC8M32B2为例,根据其数据手册,设置位宽、片选、行列、时序等符合手册要求,设置参数。然后设置基址,即可在程序中应用。
3.4 硬件系统设计
模块设计:工程所需的TIMER、UART、SDRAM、FLASH等模块可以直接调用IP核使用,对于TDM交换矩阵、CPC信令、摘挂机检测、脉冲拨号检测、数据适配等模块,属于专用模块。需要在设计之初,用传统FPGA设计方法进行设计,并提供总线接口,以便接入Avalon总线。
SOPC构建:在QuartusII中,打开SOPC Builder,根据对目标任务的分析知其为计算密集型的应用,系统采用快速型的Nios II/f软核。时钟选择外频66 MHz通过FPGA内部PLL倍频到133MHz进行工作。关于各种软核的性能请参阅Altera相关手册。
还需要加入定时器、SDRAM控制器、Flash控制器、UART控制器、并行端口PIO、JTAG UART等组件,同时打开数据和指令cache。
3.5 软硬件协同调试
在NiosII IDE中创建工程,并建立新的系统库。然后编写C程序代码,根据定时器和中断控制,考虑好各主要任务函数的调度问题。 最后Build Project,成功后,选择Debug as Hardware,即可在线进行调试,纠正程序中尚存在的一些问题。程序运行正常后,重新Build Project,生成可执行代码,选择Flash Programmer,下载到指定Flash中,验证目标系统功能。
此时,可以根据FPGA的资源消耗和程序的执行效率情况综合考虑,在资源比较充足的情况下,利用C2H功能,尽量提升系统效率。或将更多的内容纳入软件处理范围,利用编写软件代码借助软核处理器实现。
3.6 系统分析
进行基于SOPC的软硬件协同设计后,所采用的芯片数量大大减少,布线面积、成本、功耗也大大降低。还可以针对不同的需求,进行定制设计,比如,考虑FPGA容量和设计周期,可以保留回波抵消和CVSD编码器2个DSP,而来电显示和DTMF/MFB采用SOPC实现。
4 结束语
基于SOPC的软硬件协同设计技术,可以将传统上需要分立的CPU、DSP、FPGA处理的功能集成到单片大规模FPGA上实现,可以最大限度地完成软件到硬件及硬件到软件的转换。利用硬件加速功能,可以轻松实现一个定制硬件逻辑,完成软件函数到硬件的转化,获得CPU和DSP难以比拟的高处理速度;对于硬件上难于实现的协议处理等功能,则利用软核处理器通过编写软件代码完成。
使用SOPC技术,使得IP核的复用更加简单。当然,如何将各种IP核连接到CPU的总线上依然是一个重点考虑因素。随着SOPC的应用,FPGA的设计规模不可避免地变得庞大。可以利用QuartusII开发环境中的逻辑锁定和增量布局布线2大工具对设计进行优化。同时,内嵌逻辑分析仪SignalTapII使FPGA的调试也更加简单。
综上所述,基于SOPC的软硬件协同设计有着传统软件或硬件设计所无法比拟的优势。因此,有理由相信,熟练掌握和应用该项技术,将对工程开发起到巨大的推动作用。
参考文献
[1]吴继华,王诚.Altera FPGA/CPLD设计高级篇[M].北京:人民邮电出版社,2005.
[2]潘松,黄继业,曾毓.SOPC技术实用教程[M].北京:清华大学出版社,2005.
软硬件协同 第2篇
就在人们渐渐淡忘了谷歌所谓的“革命性”计划时，这家硅谷巨头又适时站出来抖了下包袱。
6月2日，台北国际电脑展(Computex 2010)上，谷歌全球副总裁桑德尔·皮扎伊表示，如果一切进展顺利，谷歌桌面操作系统Chrome OS有望于“今年秋季末”正式发布。
皮扎伊没有透露产品正式发布的具体时间，只是称将首先在北美市场销售。他强调，Chrome OS的设计初衷是应用于笔记本电脑。早在去年11月，谷歌就已经展示了这款基于互联网应用的开源操作系统，但这之后，业内有关Chrome OS的消息甚少。
市场研究公司Technology Business Re-search分析师斯图亚特·威廉斯认为，谷歌需要尽早发布Chrome OS，因为随着越来越多的科技公司加入桌面操作系统领域的争夺，行业竞争将比当下更为惨烈。
为了与即将展开的市场行动相配合，就在几天前，谷歌对行业“带头大哥”微软下手了。
新的恩怨
近日，英国《金融时报》报道称，出于安全原因，谷歌员工将被禁止在公司内部使用微软的Windows操作系统，转而使用苹果Mac或者Linux开源平台。该公司一名员工称，那些希望继续使用Windows的员工必须得到公司“高层人士”的批准。目前，谷歌在全球有超过2万名员工。
谷歌方面称，封杀Windows的理由是“微软产品易受到黑客攻击和电脑病毒侵扰”。不过，这样的理由在安全专家们看来有些牵强。
著名网络安全公司ESET项目主管兰迪·阿卜拉姆斯表示，从Windows转向其他操作系统对谷歌的整体安全状况并没有多大改善。因为猖獗的网络攻击与系统平台无关，“如果Chromo OS获得较高的市场份额，它将受到和Windows一样多的攻击。”
业界人士普遍认为，安全因素只是谷歌的一个借口，其真实用意或许是为了高调推广它们正在酝酿上市的Chrome OS操作系统。一位谷歌员工声称，公司最终希望能在Chrome OS上运行自己的业务。
不管谷歌的真实意图如何，此举已经意味着，继互联网搜索、办公软件、浏览器之后，谷歌与微软之间的战火已经蔓延到后者最核心的业务领域，这也被视作谷歌网络布局的最后一步棋。
不过，市场份额过九成的微软对谷歌在开发开源操作系统方面的努力有些不屑。在Computex 2010上，微软OEM全球副总裁史蒂夫·古杰海默表示，微软花了20年才逐步建立起计算机产业的生态链，其它厂商很难在短时间内超越，谷歌和苹果都还差得很远。他认为，在谷歌平台下软件开发人员必须用同一个应用程序为不同的品牌终端创建不同的版本。
皮扎伊随后反驳这种说法，他声称Chrome OS采用的是网页应用程序，其基本核心的一致性决定了软件公司不必重新编写新版本，“Chrome OS是少数未来的操作系统之一，已经有数百万应用程序可以使用。”
以搜索引擎见长的谷歌公司凭借庞大的软件开发资源进入微软腹地，尽管这个硅谷巨人一如既往地雄心勃勃，但细数近几年来的业绩，华尔街分析师还是为他们捏了一把汗。除了在互联网搜索和网络广告方面依然保持绝对领先之外，在其他大多数领域，谷歌的建树并不多。
根据6月4日尼尔森公布的研究报告，一季度微软智能手机操作系统Windows Mobile的市场份额为19％，谷歌的Android仅占9％；此前被业界寄予厚望的谷歌Chrome浏览器也并未引起太大的反响。市场调研公司Net Applications的数据显示，Chmme浏览器5月份的市场份额为7.1％，远落后于微软IE浏览器59.7％的市占率。在办公软件领域，至少到目前为止，微软Office还算成功地抵御了谷歌Apps的进攻。
对于谷歌搅局操作系统市场，古杰海默表示，市场上的竞争一直都会有，两年前上网本盛行时，一开始厂商也是以Linux操作系统为主，但99％的消费者还是选择了微软操作系统，原因就在于Windows能够提供良好的用户体验。
谷歌操作系统并非—无是处。Chrome OS的优势在于速度快，仅为7秒钟的启动时间无疑让Windows操作系统相形见绌。不过，谷歌互联网应用模式也带来其他问题。
《纽约时报》发表文章称，运行Chrome OS的产品需要持续接收软件更新以获得更多安全保护，这将对使用者的行为进行严格限制，会让那些初级用户有点为难。
市场仍在观望
最近，硅谷一些行业专家呼吁，谷歌应该趁早直截了当地放弃Chrome OS开发计划。但谷歌依然坚信，这一定位于“云计算”的操作系统能让用户有更多时间呆在互联网上，以便成为自己的“提款机”。
在数周前召开的开发者大会上，谷歌移动工程副总裁维克·冈多特拉表示，我们一贯认为，Chrome OS是我们的战略业务，它将影响整个互联网世界。
悲观者们则继续唱衰谷歌的新战略。市场研究公司Interpret分析师迈克尔·加腾伯格指出，Chrome OS操作系统是一个赌注，赌的是未来我们可以超越各种应用程序，所有一切都通过互联网完成，但那样的时刻还没有到来，“很大程度上，这两年的Chrome OS都只是一项科学研究而已。”
谷歌并不想就此收手。在Computex 2010上，皮扎伊称，我们将选择进入这个市场的方式，因为我们要提供极好的用户体验，公司正在考虑软件和硬件层次的问题。
但到目前为止，谷歌还没有公布与合作伙伴之间将要进行的商业模式。谷歌CEO埃里克·施密特曾表示，可能与电信运营商的相关服务进行捆绑。
值得注意的是，皮扎伊这次极力安抚硬件厂商，称谷歌还没有自己生产电脑产品的计划。他表示，谷歌看中的是规模，希望让更多用户使用其平台，不会自己做电脑硬件。此前一天，古杰海默提出警告说，谷歌可能与其他厂商合作生产硬件，也可能自己做。硬件厂商与谷歌是合作伙伴还是竞争对手，不得而知。但古杰海默的话，确实让部分硬件厂商认真考量谷歌的真正动机。
现在很多人相信，谷歌可能计划推出自有品牌的上网本。此前，谷歌曾让宏达电代工自有品牌手机Nexus One。美国知名IT杂志《eWeek》早些时候撰文指出，如果谷歌推出Chrome OS上网本，第三方销售商或许就会退出销售预装有Chrome OS操作系统的电脑，以免与谷歌产生直接竞争。
5月中旬，业界有传言称，宏碁将在两周内推出Chrome OS上网本，但台湾企业立刻出面对此表示否认，称Chrome OS上网本将
是令人兴奋的产品，自己在短期内还没有推出Chrome OS上网本的计划。半年前，宏碁董事长王振堂曾表示，该公司将成为首家推出Chrome OS的厂商。这次谣言风波或许意味着，宏碁与谷歌的合作计划目前尚不明朗。
今年4月，施密特对外宣称，采用Chrome OS的产品售价将与上网本相仿，定价为300美元至400美元。由于Chrome OS的成本接近于零，在低端上网本领域该操作系统可能会有一定的竞争力。不过，市场方面目前并没有泛起多少波澜。
分析人士认为，让硬件厂商犹豫不决的原因可能与Chrome OS系出同门的Android操作系统有关。Android于2007年11月发布，这是一款基于同样开源平台的智能手机操作系统。随着技术的成熟，一些厂商也有意推出预装该系统的上网本，宏碁之前已经推出基于该系统的上网本。
谷歌高层多次耐心解释Android与Chrome OS的区别，但皮扎伊此次表态还是有些模棱两可，“谷歌的任务就是准备好Chrome OS和Android这两种操作系统，后续一切交由硬件厂商决定”。
群雄揭竿而起
不管现在的市场反应如何，Chrome OS操作系统已被谷歌当成日后克敌制胜的杀手锏。
在5月13日召开的股东大会上，埃里克·施密特宣称，Chrome OS将不断发展壮大，该平台将成为微软Windows和苹果Mac OS之外可供消费者和企业选择的第三种主要计算平台。
眼看谷歌已经把脚伸进自家后院，微软并没有坐视不理。去年就有国外媒体注意到微软Gazelle计划可能是与Chrome OS类似的项目。最近，微软宣布要与全球PC厂商合作开发“精简版”互联网操作系统Windows Cioud。微软表示，Gazelle计划即Windows Cloud的前身。根据测试，Windows Cloud可实现在5秒钟内开机，关机时间更是不到1秒。
对于微软的Windows Clond，分析人士普遍认为这是微软阻击谷歌Chrome OS的“杀伤性武器”。市场研究机构IDC指出，微软长期以来与PC厂商建立了良好合作关系，这可能会让谷歌Chrome OS更难打入PC市场。
据悉，惠普、宏碁、戴尔和华硕等PC厂商表示将加入微软的Windows Cloud计划。并会赶在今年底之前推出预装Windows Cloud的上网本，这可能会与在年底开始推出的谷歌Chrome OS上网本展开正面交锋。
依靠多年建立起来的稳固生态系统，微软Windows虽遭遇多次挑战，但是始终没有遇见真正的敌人。不过，随着云计算和移动互联网领域竞争日趋激烈，越来越多的“硬件大鳄”也加入这场硝烟弥漫的鏖战。
6月3日，在Computex 2010展会上，芯片设计厂商ARM召集包括飞思卡尔、IBM、三星电子、意法爱立信和德州仪器在内的六家芯片业老对头，成立了非赢利性质的行业组织Linaro。该组织主要开发基于ARM平台的Linux操作系统。微软的盟友英特尔也在现场大秀与诺基亚合作开发的MeeGo操作系统，希望为智能手机、笔记本、电视等提供全新的操作环境。
不仅如此，惠普CEO马克·赫德最近表示，惠普收购智能手机制造商Palm主要目的并非为了制造智能手机产品，而是为了对方Web OS操作系统的知识产权，以便在市场上与谷歌Chrome OS这类开源操作系统竞争。
软硬件协同 第3篇
关键词：3D,FPGA,Handel-C,DMA,协同验证
在数字集成电路的设计中,需要通过仿真来检验设计是否可实现预期的功能。仿真需要为设计项目建立一个测试平台,为设计项目提供尽可能完备的测试激励和可供观测的输出响应,根据输出响应信息可判断设计项目是否可实现预期的功能。随着系统设计复杂性的不断增加,当设计集成度超过百万门后,设计正确性的验证就比设计本身还要困难,系统仿真的实时性很难满足要求。在对复杂电路进行软件仿真时,系统的仿真时间往往占据了设计的大部分,系统某些电路功能的仿真验证常常需要几个小时甚至几天。因此,如何提高仿真效率、减少仿真复杂度、缩短仿真时间,成为系统设计中的关键问题。
为了方便而快速地实现仿真验证,及时得到测试结果,本文提出运用硬件加速的思想,并以Open GL-ES算法中的坐标变换算法为例,将其作为待验证的IP放在整个Open GL-ES软件平台上进行测试。利用Handel-C语言对该IP进行FPGA实现,并采用Bus Master DMA的通信方式在软、硬件之间进行通信,实现软硬件协同加速仿真。选用以Open GL-ES为例是因为该算法为开源的;采用C++实现,存在大量矩阵运算,将其用FPGA实现,可充分利用硬件并行的特性。同时,也因为Handel-C与C语言的高度相似性,开发周期得到了明显的缩短。
1 Open GL ES及相关算法分析
Open GL ES 1.1的绘图主要分两个阶段:几何处理阶段和光栅化处理阶段[1,2],如图1所示。
本文关注的是几何处理阶段中的坐标转换模块。通过线性代数的方法将物件的三维空间模型进行移动、缩放和变形等,借助由控制物体上每个点的坐标变动,可以实现对物体的移动、缩放和旋转。对应的三种顶点坐标变换算法为平移变换、缩放变换和旋转变换,均通过顶点坐标构成的矩阵相乘来实现,其中旋转变换算法的运算量最大。现以绕任意轴的旋转变换算法为例,简单介绍其实现步骤。
设旋转轴AB由任意一点A(xa,ya,za)及其方向向量(a,b,c)定义,空间一点Q(xq,yq,zq)绕AB轴旋转θ角到Q′(xq′,yq′,zq′),则可以通过下列步骤来实现Q点的旋转:
(1)将A点移到坐标原点。
(2)使AB分别绕X轴、Y轴旋转适当角度与Z轴重合。
(3)将AB绕Z轴旋转准。
(4)作上述变换的逆变换,使AB回到原来位置。即:
其中,RAB(θ)=T-1(xa,ya,za)Rx-1(α)Ry-1(β)Rz(θ)Rx(α)T(xa,ya,za),矩阵T为平移矩阵,R为绕某坐标轴的旋转矩阵,而α、β分别为AB在YOZ平面与XOY平面的投影与Z轴的夹角。
该系统采用的演示程序中,旋转轴为单位轴(nx,ny,nz),则旋转矩阵RAB(θ)为如下形式:
2 HANDEL-C及开发流程
本设计采用Handel-C、硬件描述语言和C++协同开发的方式,其一般开发流程如图2所示。
Handel-C的代码默认从顶部开始串行执行到底部,每一条语句占用一个时钟周期[3]。但Handel-C同样支持并行处理机制,这是通过使用关键字“par”来实现的。坐标变换算法中涉及到大量的矩阵乘法运算,而矩阵乘法运算中乘积矩阵的所有元素互相独立、互不相关,可以将其并行实现。因此该设计充分利用了Handel-C的并行机制,使矩阵乘法的效率大大提高。
Handel-C支持和C语言一样的数组形式。Handel-C中的数组可以让所有变量在一个时钟周期内被并行地访问,从而提高变量的存储和读取效率。例如用来求定点数平方根倒数的函数EGL_Inv Sqrt()中用到了查表法,表的大小只有8×16 bit,而该函数在旋转算法中被大量用到。因此为了提高效率,采用数组的形式定义该表。
但索引一个大数组将耗用大量的硬件资源,这时可以换成用RAM或ROM来实现。Handel-C提供了“ram”或“rom”关键字来解决该问题[4]。例如在旋转变换算法中,涉及到三角函数运算sine和cosine,同样采用查表法来实现,而表的大小为1 024×16 bit,这时必须用ROM来实现,使用“rom”关键字定义该表即可。
由以上特点可以看出,该设计采用Handel-C可以从开发流程的各个环节降低开发难度,从而缩短开发周期。
3 系统设计与实现
为了满足整个系统的实时数据处理要求,该设计选用PCI Express接口在FPGA与PC之间实现数据传输。当采用8通道的PCI Express数据传输时,可实现4 GB/s的传输速率,满足该系统对数据处理的实时性要求。
本设计采用BMD(Bus Master DMA)的实现方式,BMD的DMA引擎被内嵌在PCI Express架构的endpoint端,负责在系统内存与endpoint之间移动数据。end-point即为该系统的硬件部分,即内嵌了DMA引擎的坐标变换模块。
3.2 系统硬件设计
采用Handel-C与Verilog混合设计的方法对该系统的硬件平台进行设计,其中较多涉及到调度及状态转换的模块用Handel-C设计,涉及到较为严格的时序要求的模块用Verilog设计。该系统的硬件整体框图(省略BMD控制部分)如图3所示。
其中PC部分为系统软件部分,包括Open GL-ES中除坐标变换算法以外的其他部分,以及DMA传输控制的软件部分;RX和TX模块分别为DMA的接收和发送引擎,即BMD架构中Initiator Logic模块里的Rx和Tx。可见,DMA已经内嵌在系统硬件设计中;myram1和myram2为双口RAM,具有独立的数据读写和时钟端口,作为输入和输出缓存,同时隔离了用户IP和PCIe两部分的时钟,为实现双时钟工作提供了条件;genclock为DCM模块,对PCIe的输入时钟进行5分频,得到50 MHz的时钟供用户ip使用,除了myram1的clkb、myram2的clka以及myip的clk为50 MHz外,其他时钟均为250 MHz;control模块为控制信号的跨时钟域转换模块,因为控制信号rx_done_output从频率高的时钟域输出到频率低的时钟域,必须对其进行转换,才能使其在频率低的时钟域内被有效识别。
myip部分内含my Transform IP核,这部分为用户自定义的IP,其内部结构如图4所示。
其中,my Transform模块为由Handel-C转换而来的坐标变换模块,它有4个数据输入口(angle,x,y,z)和10个数据输出口(my_m_elements_1~my_m_elements_a)。而myip为1个数据输入口和1个数据输出口,即串行输入和串行输出。为了将my Transform模块封装成myip的串行输入、输出形式,在输入、输出端分别有一个4 bit串/并转换模块4-bit Serial2Par和10 bit并/串转换模块10-bit Par2Serial;而Control_Logic为myip模块的逻辑控制模块,主要实现以下功能:
(1)对各模块的开始(start)与完成(done)信号进行处理,并根据这两个信号对各模块的工作进行调度。包括整个myip模块、my Transform模块、串/并模块和并/串模块。
(2)对外部两个双口ram的读写进行控制,包括地址和写使能信号的控制。
这里的用户IP即my Transform模块,根据用户IP的数据输入、输出形式,只要改变串/并转换的位数和并/串转换的位数,即可实现用户IP模块与myip模块的整合,而无需改变myip模块的接口以及控制信号,为该系统的通用性提供了保证。
3.3 系统软件设计
软件包括两部分:DMA通信部分和Open GL-ES中除了坐标变换算法以外的其他部分。
DMA通信部分又分为驱动层和应用层接口。驱动层的设计涉及到Windows下PCIe驱动程序的编写,不是本文的讨论重点;应用层接口是在驱动层的基础上生成API,用以在应用程序中进行相关的DMA操作(主要包括DMA器件的打开和关闭、读写DMA的设置、DMA启动以及DMA各寄存器的读写操作等)。
将原始的Open GL-ES中坐标变换模块用DMA操作代替:首先打开DMA器件、复位DMA器件、设置DMA传输中各寄存器的值,再将输入参数放到相应内存(TL-PRead Buffer)中,然后启动DMA操作,将该内存的值通过PCIe传到开发板上进行处理,处理完后的数据再通过DMA写操作写进PC相应的内存(TLPWrite Buffer)中。通过不断读取写操作完成寄存器的值,来判断写操作是否完成。如果写操作未完成,则继续读取该寄存器值来判断,若读取次数超出设定值,则重新启动DMA。当写操作完成时,从相应内存(TLPWrite Buffer)中读取处理完的数据,即为坐标变换模块的返回值。软件工作流程如图5所示。
启动DMA操作实际上包括启动DMA读和写的操作。DMA硬件会先启动读操作,将内存中的值读入开发板,然后经过用户IP进行处理完后,写回内存。因此只需要确定DMA写操作完成即可,此时整个DMA读写操作也一定完成。
4 性能分析与验证
经过软件仿真验证各模块功能完全正确之后,将该设计进行软、硬件联合验证。
本设计采用的硬件验证平台为Avnet公司的AES-XLX-V5SXT-PCIE50-G开发板,该开发板的FPGA芯片型号为Xilinx公司Virtex5系列的xc5vsx50t[5]。
针对一些运行时间较长的单元,在Handel-C中加入par并行处理进行优化,在ISE11.1中用XST进行综合。表1体现了加入par之前和之后所耗资源的对比。
由表1可以看出,加入并行处理后资源消耗有所增加,但处于合理范围内。
用ISE11.1对综合后的网表进行实现,生成.bit文件并下载到开发板中,联合软件部分进行协同验证。为了将其与传统Modelsim仿真速度作对比,这里将模块处理复杂度扩大10 000倍,即可明显看出该验证方法的速度优势。表2给出了在PC主频2.66 GHz下,从Rst信号到Done信号之间仿真消耗的时间对比。由表中可看出,本文采用的验证方法在仿真速度上是传统Model Sim仿真的778倍,即使对经过Modelsim优化后的节点进行仿真,也快了202倍。
本文用Handel-C设计和实现了Open GL-ES的坐标变换算法,并将其与软件平台进行软、硬件协同验证。结果表明,Handel-C能够用来实现复杂的算法,并且比传统的HDL设计方法更为高效;通过该方法建立的软、硬件仿真平台对IP进行验证,具有更高的效率。
参考文献
[1]孙家广.计算机图形学(第三版)[M].北京:清华大学出版社,1999.
[2]Munshi.OpenGL ES common/common-lite profile specifi-cation[S].2004.
[3]Celoxica.Handel-C language reference manual[Z].2005.
[4]Celoxica.Handel-C code optimization[Z].2003.
软硬件协同 第4篇
USB由于具有传输速度快、支持即插即用和热插拔、供电方式灵活、总线结构简单、使用和扩展灵活等优点,已经成为业界主流的工业接口标准,并在SoC设计中得到了广泛的应用。在典型的应用案例中,USB主控器作为SoC中的一个子模块,和其他子模块有复杂的互联、通信关系,同时也受系统主CPU的控制。在这样一个复杂的系统中,如何验证USB主控器设计的正确性以及其和SoC系统其他模块协同工作的完整性对项目成功与否是非常关键的。本文设计了一种软硬件协同仿真平台来验证应用在数字电视SoC中的USB 2.0主控器,本平台为SoC的验证提供了一个高效、系统的解决方案。结果表明效果良好。
1待验证USB 2.0主控器系统结构
本文验证的USB 2.0主控器完全兼容USB 1.1规范,EHCI主机控制器接口规范和OCHI主机控制器接口规范。该USB 2.0主控制器包含一个高速主控器和一个全速主控制器,其中高速主控器基于EHCI接口规范实现,用来和连接到根端口的高速(传输速率为480 Mb/s)模式外设进行通信。全速模式主控制器基于OHCI接口规范实现,使USB 2.0主控器可以与全速和低速(传输速率为12 Mb/s 和1.5 Mb/s)外设进行通信。系统CPU可以通过该主控器的AHB Slave接口对其进行控制。该主控器中还包含AHB Master接口单元,能够扮演AHB Master的角色直接控制主控器与系统存储器之间的数据交换,不需要通过外部DMA控制器的控制,方便系统集成,加快该主控器与系统内存之间的数据交换。该主控器的物理接口端提供满足UTMI+接口规范的接口,通过与PHY相连,可以直接与外设进行通信。图1为该主控器的系统结构框图,图中主控器的列表处理器模块是系统中主要的控制器,其包含多个状态机用来处理规范中描述符定义的内容。
2验证仿真系统介绍
2.1 使用传统平台验证USB主控器的不足
USB主控器真实的工作环境需要有硬件和软件协同配合,在传统验证平台下,从整个验证过程来看,硬件人员需要描述一套基于Verilog HDL的测试激励模拟软件环境验证其功能,之后软件人员还要再写一遍基于C程序的软件环境验证其功能,这样造成工作的重叠。同时传统验证平台使用Verilog HDL编写,抽象层次较低,在描述高抽象结构(如USB的描述符的数据结构)时比较复杂,而使用抽象层次更高的C语言会相对简单。
2.2 本文设计的软硬协同仿真系统介绍
相对使用传统验证方法,本文设计的软硬件协同仿真系统使用抽象度较高的C语言编写测试激励,通过调用系统中CPU模型对外提供的API完成激励生成与响应检查。基于本引擎编写的测试激励可以方便的移植,所以在硬件仿真阶段就能调试SoC系统软件,不必等到FPGA平台设计完成或芯片设计完成后,从而大大节省了项目开发时间。图2是本文验证USB主控器功能的软硬件协同仿真的系统架构图。本验证环境由3大部分组成:联合仿真引擎,即CPU模型;总线架构及系统内存模块,包括一个DDR模型和DDR控制器;USB协议实现、检查模块,包括待验证的USB 主控器、支持UTMI+接口的PHY、外设模型。在该平台下,联合仿真引擎(CPU模型)替换掉SoC中原有的CPU,是整个验证系统的核心也是整个系统设计的核心。通过使能信号触发联合仿真引擎工作来执行C程序,将软件对USB主控器的控制转化成总线时序,将软件和硬件交互的行为模拟到RTL侧。下文将对仿真平台中各个模块,重点对联合仿真引擎进行详细介绍。
2.2.1 基于TLM建模的联合仿真引擎及设计
使用软硬件协同仿真的方法验证USB主控器,只需要用C语言编写USB主控器驱动并将其集到成系统中进行仿真测试,因此要求CPU模型能够简单、高效地执行驱动程序,CPU在SoC中都是直接通过AHB Master接口连接到总线(BUS)上,对SoC中要验证的IP来讲,CPU就是一个总线Master,IP并不关心CPU是什么指令集,采用何种方式实现。基于此,本联合仿真引擎设计的CPU模型并没有采用基于特定指令集设计的复杂方法,而是采用基于SystemC 事物级建模(TLM)技术[1]构造了一个基于AHB协议的总线功能模型(BFM),实现了对CPU对SoC中其他模块所呈现的AHB Master接口的时序封装。这个BFM能和要验证的RTL模块进行连接和通信,它能够编译并解释基于C语言编写的驱动程序,并把这个驱动程序要执行的操作翻译成对应的AHB总线信号。通过层次化的封装,本联合仿真引擎把基于时钟时序精度的RTL的抽象层提升到没有任何时钟和时间概念的软件抽象层。同时,本引擎能取代任何CPU。不管SoC中真正使用的CPU是MIPS指令集、ARM指令集还是其他CPU,都能被本联合仿真引擎替代。
本引擎的CPU模型使用系统仿真用的工作站或者服务器的宿主CPU来运行验证工程师编写的基于C语言的测试激励程序,将需要的具体硬件行为通过Channel向下传送到RTL端。相对于直接使用SoC中CPU IP核的RTL的仿真,该引擎省去了CPU IP核取指令和运行指令的复杂的仿真、运算过程,大大节省了仿真运行的时间。本联合仿真引擎为软件人员和硬件验证人员分别提供了一些总线访问和中断处理的API,为了满足硬件验证的需要,另外设计了一些API可以实现让系统等待一定时钟周期或者时间、停止或重新开始仿真、不通过总线而可以快速访问系统存储器等功能。在系统中CPU模型对USB主控器和DDR控制器的配置均通过这2个模块对外提供的AHB Slave接口。
2.2.2 仿真系统的其他模块介绍
DDR2/3为系统内存,存储USB主控器正常工作需要的描述符和收发的数据。由于本系统中DDR2/3控制器只提供AXI Slave的数据接口,系统中CPU和USB主控器需要通过AHB桥将AHB从机的接口时序转换成AXI Master的接口时序,保证2个模块之间正常的数据通信。系统工作过程中AXI,AHB总线监控器监控2个总线活动,打印出报告信息, 方便仿真结果检查。
USB主控器是待验证的主控器(DUT)。PHY模型提供UTMI+接口,有USB 2.0和USB 1.1两种接口分别支持EHCI接口和OHCI接口实现。外设模型包括一个PHY 验证IP(VIP)和一个USB外设验证IP,模拟USB外设的行为。USB外设VIP中包含一个USB监控器模型,负责协议检查,记录事物传输进程,监控高速、全速和低速的USB传输,提供数据包级和事物级传输的监控,同时可以监控挂起、恢复和复位信号。
3基于本验证系统的USB主控器验证过程
由于使用了联合仿真引擎,测试激励既可以使用Verilog HDL编写也可以使用C语言编写。运行C语言编写的测试激励时,需要在测试平台中预先置位使能信号打开联合仿真引擎,触发仿真工具(如NCVerilog)调用C测试激励程序的主函数。在C测试激励顺序执行时,整个RTL的仿真时间会停在当前时刻。只有当C测试激励调用了基本的读/写函数、中断响应之类的底层函数,硬件仿真时间才会向前推进,RTL仿真器继续往前运行。直到RTL反馈后,C测试激励程序才会继续往下一行执行。USB主控器验证系统仿真引擎交互过程如图4所示。
具体过程包括:HDL仿真工具执行Verilog HDL描述的USB的外设模型初始化过程;HDL仿真工具使能联合仿真引擎,测试用例进入联合仿真引擎继续执行;联合仿真引擎初始化待验证USB主控器;联合仿真引擎执行特定API函数,测试用例进入HDL仿真过程;通过调用外设的attatch命令,使外设模型连接到待验证的USB主控器;联合仿真引擎等待外设模型连接中断,停止在当前时刻,直到中断有效;联合仿真引擎执行外设模型连接中断处理;测试用例继续执行HDL仿真过程。主控器与外设模型按照配置速度,传输类型,传输方向,传送的数据包的工作速度;C驱动循环等待中断信号有效,进行中断处理。AHB监控器、AXI 监控器和USB监控器监测主控器AHB端和USB端的工作,进行协议检查,给出报告信息,仿真过程可以通过日志文件方便监测。基于上述思路编写的验证USB主控器各个不同功能的测试用例,在不需要使用任何PLI(编程语言接口)函数的情况下,能够快速、方便地实现USB 2.0主控器各个不同层级的Driver的功能,从而保证能够全面的验证此主控器的特性。表1是在不同的仿真环境下,测试USB主控器与外设进行进行高速传输2 Mb数据所需要的时间。从表中可以看出,系统中使用RTL级CPU IP核的系统,仿真速度最慢;基于ISS指令集模拟器的仿真系统,速度次之;本环境的仿真速度最快。
4结语
本文设计的用于USB主控器IP验证的软硬件协同仿真系统具有仿真速度快、仿真系统资源占用小、减少软硬件集成验证测试的时间的特点,经实践证明,效果良好。通过使用本系统,软件人员能在硬件设计验证的早期就能进入IP的软件硬件联调,缩短了研发时间。同时,本系统具有良好的可重用性,对其他IP的验证同样有效,可为其他IP的验证提供参考。
摘要：为了能够充分、快速验证USB 2.0主控器的功能,设计了一个软硬件协同仿真平台。其中,CPU模型部分采用一种高效的SystemC模型,而不使用基于指令集的复杂CPU模型。测试用例采用抽象层次更高的C语言编写,通过调用仿真平台对外提供的API完成激励生成与响应检查。结果表明,该方式能够有效降低对仿真资源的占用,减少仿真时间;同时使软件人员能在IP的硬件验证阶段就能完成软件的设计测试工作,缩短软硬件接口整合时间,加快开发进度。
关键词：软硬协同,联合仿真引擎,CPU模型,通用串行总线,主控器,片上系统
参考文献
[1]GHENASSIA Fran.Transaction-level modeling with Sys-temC:TLM concepts and applications for embedded sys-tems[M].New York:Springer,2005.
[2]朱明,边计年,薛宏熙.软硬件协同验证系统平台间通讯设计[J].计算机工程与应用,2003(12):59-62.
[3]BERGERON J.Writing testbenches:functional verificationof HDL models[M].2nd ed.New York:Springer,2003.
[4]Intel.USB2.0transceiver macrocell interface(UTMI)specification,version 1.05[M].USA:Intel,2001.
[5]Synopsys lnc.DesignWare USB verification IP databook,version 8.20a[M].USA:Synopsys lnc.,2010.
[6]Compaq Microsoft National Conductor.Open host controllerinterface specification for USB[M].USA:Compaq Mi-crosoft National Conductor,1999.
[7]Intel.Enhanced host controller interface specification foruniversal serial bus,revision 1.0[M].USA:Intel,2002.
[8]Intel.Universal serial bus specification revision 2.0[M].USA:Intel,2000.
[9]陈星宇.基于EHCI协议的OTG USB 2.0FPGA设计与实现[D].成都:电子科技大学,2008.
[10]Cadence Inc.Incisive simulation acceleration deployment[M].[S.l.]:Cadence Inc.,2003.
软硬件协同 第5篇
半个世纪以来,集成电路设计规模和设计复杂度不断增加[1]。在这个过程中,集成电路片上设计对总线的要求也在不断地提高。目前计算机中采用较多的总线标准有AMBA总线、ISA总线、SPI总线、PCI总线等。其中PCI总线作为一种系统总线在计算机上得到广泛应用[2],而AMBA总线由于其高性能、高带宽的特点在片内总线市场占有率最高,成为一种最流行的工业标准片内总线结构[3]。
AMBA Rev2.0规范中包含两级总线[4]:AHB(Advanced High Performance Bus)系统总线和APB(Advanced Peripheral Bus)外围总线。其中,AHB总线采用地址/数据分离的流水式操作,支持突发传送,分裂事务传送特性和多个主设备的总线管理,具有高带宽、高性能特性,适合于嵌入式处理器与高性能外围设备,片内存储器及接口功能单元的连接[5]。
PCI总线之所以成为局部总线的主流[6],是由一些显著特点决定的,如运行速度快、可扩展性好、兼容性好、稳定可靠等特点。
本文利用软硬件协同的技术,搭建了一个对AHB-PCI[7]桥功能验证的平台。与常用的Verilog验证相比,本文中的方法更能保证硬件的正确性,减少了从仿真到综合中由于综合工具优化导致功能验证的不一致性,同时节约了开发周期。
1 AHB-PCI桥的结构
AHB-PCI桥实现AHB到PCI的协议转换。主要包括两部分,即AHB一端作为主机,完成AHB到PCI的信号转换;另一个PCI一端作为主机,能够实现PCI相关寄存器的配置和数据的传输。两个模块均需要进行时钟的同步。拓扑结构如图1所示。
图1 AHB-PCI桥拓扑结构
图中最大矩形方框为AHB_PCI桥转换电路的顶。它由模块I和模块II两个模块构成。当有一个AHB主设备(例如图形处理器)启动一个事务时,其目标为一个挂接在PCI总线上的从设备,则模块I负责相应的协议转换和数据缓冲,并在PCI总线上启动一个适当的事务。而当有一个PCI主设备启动一个事务时,其目标为一个挂接在AHB总线上的从设备(例如片上存储器),模块II负责相应的协议转换和数据缓冲,并在AHB总线上启动一个适当的事务。
2 基于FPGA的软硬件协同的测试平台
2.1 测试平台概述
本文所完成的测试平台主要目的是对AHB-PCI桥的功能进行测试,并确保符合标准的协议。系统上电后,通过软件对PCI相应寄存器进行配置,然后对AHB作为从设备进行读写操作,最后启动AHB作为主设备,对PCI作为从的一端进行读写。通过这样不断地操作,完成对桥的功能验证。平台使用操作系统版本Red Hat2.16.0,vivado版本15.4,FPGA为Xllinx的7vx690tffg1930-1,带有PCI插槽的主机。
2.2 基于FPGA的测试平台设计与实现
2.2.1 测试平台的结构
基于FPGA的测试平台所实现的所有测试电路必须可综合。测试平台主要由软件和硬件两部分构成。软件部分主要实现对PCI一端通过驱动程序进行驱动,实现PCI主从的时序,硬件部分主要由两个符合AHB标准的RAM构成。平台硬件结构如图2所示。
2.2.2 测试软件设计
在系统中所有的PCI设备,包括PCI-PCI桥接器在内,都有一个需要配置的数据结构,它通常位于PCI配置地址空间中。PCI的配置头是用于系统标识与控制设备。配置头在PCI配置空间的位置取决于系统中PCI设备的拓扑结构。例如将一个PCI网卡插入不同的PCI插槽,虽然其配置头的位置会变化,但是对整个系统没影响,系统将找到挂接在其上的每个PCI设备与桥接器,并使用配置头中的信息来配置寄存器。如图3所示为普通PCI的配置寄存器分布。
图2 基于FPGA的测试平台结构
图3 普通PCI配置头标区
命令寄存器是一个必备的寄存器,该寄存器可读/写,格式如图4所示。根据使用中的需要将该寄存器利用驱动程序配置为0x0246,bit 1写为1,存储器地址空间使能,接受以该设备为目标的存储器事务;bit 2写为1,总线主设备使能,允许该设备发出请求,占用总线;bit 6奇偶校验使能;bit 10写为0,中断使能,允许产生INTX的中断消息。
图4 命令寄存器
状态寄存器为只读寄存器,记录PCI总线有关的状态信息,格式如图5所示。
在一般PCI设备中,除了拥有配置空间外,还具有两个物理空间:memory空间和I/O空间。想要访问这两个地址空间,就必须使用配置空间中的基址寄存器。一般PCI设备或桥中涉及3种基址寄存器:内存空间基址寄存器、I/O空间基址寄存器和扩展ROM基址寄存器。
Linux内核提供了3种数据结构来描述PCI控制器、PCI设备以及PCI总线。其中PCI控制器用pci_controller结构来描述,PCI总线用pci_bus结构来描述,PCI设备用pci_dev结构来描述。PC对PCI进行初始化流程如下:
图5 状态寄存器
(1)Linux分配数据结构pci_contoller,并且初始化,包括PCI的memory/io空间和访问PCI配置空间所需的handler。
(2)PCI设备的枚举:扫描系统上所有PCI设备,包括PCI桥,并初始化它们的配置空间(硬件上的初始化)。
(3)用数据结构将PCI设备信息联系起来,在系统中构建PCI树(软件上的初始化)。
(4)加载PCI设备的驱动程序。
驱动程序通过读取和配置相应的寄存器,对PCI进行配置操作和对memory/io空间的访问。
2.2.3 AHB作从RAM的硬件电路设计
AHB作为从的RAM由AHB控制部分和RAM部分构成。其中RAM由vivado的IP核生成。控制部分主要是根据AHB的时序生成RAM的读写时序并对桥做出相应的操作。结构如图6所示。
图6 ahbs_ram结构
该RAM支持AHB的所有传输类型,接受的传输字大小为32 bit,即hsize_s为010b。写时序如图7所示,写时序以一个INCR的传输类型为例,写4个32 bit的数据。整个传输过程hwrite_s为高,表示桥对RAM进行写操作。开始传输时,主机会将htrans_s的信号置为2,表示非连续传输,并且发送地址a0和传输类型hburst_s,如果hready_s为高即从机准备好,则将htrans_s信号置为3,表示连续传输,并发送第二个地址a2和第一个地址对应的数据d1,此时RAM控制部分将地址a0发给ram_addr,并将数据d0发给ram_wdata,ram_write置高,将数据写入RAM,直到等到传输完成,所有信号置为默认状态。
图7 ahbs_ram写时序
如图8所示为读时序,读时序以一个INCR的传输为例,读取4个32 bit的数据。整个传输过程中hwrite_s为低,表示桥对RAM进行读操作。开始传输时,主机会将htrans_s的信号置为2,表示非连续传输,并且发送地址a0和传输类型hburst_s,如果hready_s为高即从机准备好,则将htrans_s信号置为3,表示连续传输,否则信号持续直到hready_s拉高,从机准备好接受第一个地址,控制部分将地址传送给ram_addr,RAM一拍后出数据,将数据传给hrdata_s,如此往复,直到传输完成,所有信号置为默认状态。
图8 ahbs_ram读时序
控制部分内部实现了一个同步的FIFO。该FIFO的主要功能是统计AHB作为从进行的读写次数,将这个计数器的值发送给AHB作为主的硬件电路,这样方便软件对作主电路的控制。
2.2.4 AHB作主RAM的硬件电路设计
AHB作主的硬件电路主要由AHB作为主的控制部分和RAM部分构成。这部分的RAM是由vivado的IP核生成,保证存储数据的正确性。控制部分生成AHB需要的时序和RAM的读写时序。
用状态机实现生成AHB作主的时序,如图9所示。初始状态为IDLE,当AHB作为从的计数器由9变为10的时候,触发一个上升沿,此时发送请求占用总线信号hbusreq_m,等到桥接电路回馈一个授权信号hgrant_m和从机准备好传输信号hready_m,则将状态转到TRANS_NONSEQ,并将本次传输数据的计数器置零,否则维持本状态。当状态机处于TRANS_NONSEQ时,会判断传输数据的计数器和本次要传输的数据是否相等,如果相等则进入状态TRANS_END,否则进入状态TRANS_SEQ。在TRANS_SEQ的状态时,处理办法和在状态TRANS_NON-SEQ相同。状态TRANS_END完成本次传输,状态机进入初始状态。
图9 AHB做主的状态机
该部分硬件能够实现AHB传输类型中比较常用的几种传输方式,单一传输(single)、增量传输(INCR)、4个数据增量传输(INCR4)、8个数据增量传输(INCR8)、16个数据的增量传输(INCR16)。每次传输的开始由ahbs_ram中的计数器进行控制,即用软件操作作从的读写数据,来启动AHB作主的电路。
3 测试结果与分析
利用该平台在FPGA上对AHB-PCI桥进行验证,使用vivado15.4进行综合,添加Debug core对信号进行采样,生成bit,在FPGA上验证。实验进行了大量的测试,测试结果与预期的一致,下面对其中的一部分进行介绍。
(1)PCI的写操作:软件由驱动发出对PCI进行写操作,从测试波形可以看出,所采的地址和数据与软件发出的一致,从而测试了桥PCI到AHB的写通路正确。
(2)PCI的读操作:软件由驱动对PCI进行读操作,从测试波形可以知道,软件所读出来的数据和开始写入的数据一致,从而测试了桥PCI到AHB的读通路正确。
(3)AHB的写操作:此处AHB的触发由ahbs_ram中的计数器进行控制,所以利用软件写固定个数,触发了一次写操作,实验结果波形可以看出写操作的传输类型为INCR,传输了32个32 bit的数据。利用软件读取该部分存储的值,和硬件写入的值一致,从而测试了桥AHB到PCI的写通路正确。
(4)AHB的读操作:同写操作一样,软件做相应的操作,触发一次读操作,实验结果波形可以看出来,本次读操作的传输类型为INCR,读取了32个32 bit的数据,利用软件写入的数据和波形上读取的数据一致,从而测试了桥AHB到PCI的读通路正确。
4 总结
本文运用软件与硬件相结合的技术搭建的测试平台对AHB-PCI桥进行了功能验证。该平台相对于modelsim搭建的测试平台在硬件的验证中更有说服力,利用FPGA对功能验证,极大地保证了硬件的正确性,节约了开发时间。平台运用软硬件协同技术,对于同类的硬件测试具有非常大的借鉴意义。
本文的方法可以测试硬件的基本功能和硬件的正确性,而未能将硬件功能测试完全,可利用System Verilog搭建平台解决这个问题。
参考文献
[1]詹文法,李丽,程作仁,等.一种基于总线的可重用验证平台研究[J].电子技术应用,2006,32(5):92-96.
[2]史茂森,邵翠萍,龚龙庆.一种PCI总线Master模块接口设计[J].计算机技术与发展,2012,22(7):207-210.
[3]颜伟成,陈朝阳,沈绪榜.AMBA-AHB总线接口的设计与实现[J].计算机与数字工程,2005,33(10):130-136.
[4]AMBA(tm)Specification.Revision 2.0.May,1999.http://www.arm.com/.
[5]王晨旭,桑胜田,王进祥,等.AHB-PCI桥的设计及其验证方法[J].微处理机,2004,2(1):8-13.
[6]李鉴.PCI系列总线及其应用[J].现代电子技术,2002,135(2):76-79.
软硬件协同 第6篇
要使OMAP3530发挥ARM+DSP双核架构的优势,必须要使ARM和DSP协同工作。目前关于如何使ARM和DSP协同工作的参考资料不多,因此本文在研究实践的基础上,就如何搭建协同开发环境以及ARM和DSP协同开发方法进行了说明。
1 开发环境的搭建
1.1 PC端系统的搭建
OMAP3530几乎支持所有嵌入式操作系统(例如Win CE、Symbian OS、EPOC、Linux等),由于大部分嵌入式操作系统都要收费,所以这里采用Linux系统,它不仅应用广泛,而且免费和开源。
为了能够开发OMAP3530,首先要搭建开发环境,在PC端,需要安装虚拟机VMware Workstation,配置超级终端;然后在虚拟机上安装Linux操作系统。除此之外,还需要在Linux系统上安装交叉编译器、NFS服务器、FTP服务器等一些必要的开发工具。
1.2 OMAP3530系统启动方式及分析
OMAP3530上运行的Linux系统的组成结构如图1所示。其中,x-loader是一级引导程序,主要作用是初始化CPU和拷贝u-boot到内存中运行[3],然后把控制权交给u-boot。u-boot为二级引导程序,主要用于与用户进行交互,以及提供镜像更新、引导内核等功能。kernel为Linux内核,是操作系统的核心,负责管理系统的进程、内存、设备驱动程序、文件和网络系统,决定着系统的性能和稳定性。rootfs为根文件系统,在嵌入式Linux操作系统中,文件系统作为操作系统的重要组成部分,用于控制对数据文件及设备的存取,并提供对文件和目录的分层组织形式、数据缓冲以及对文件存取权限的控制。根文件系统是Linux系统不可或缺的组件,在嵌入式Linux中,内核在启动期间,必须调用根文件系统才能启动。Linux系统将自身划分为两部分,一部分为核心软件,即kernel(也称作内核空间);另一部分为普通应用程序,这部分称为用户空间(user area)。
可以通过配置及编译x-loader、u-boot、kernel、busybox源码文件来获得OMAP3530所需的镜像文件,然后把镜像文件拷贝进SD卡,这样就可通过SD卡启动Linux系统。
为了便于开发,通常使用交叉网线连接PC和OMAP3530开发板,然后通过由NFS挂载根文件系统的方法来启动Linux系统。该方法的好处是能直接在虚拟机中修改OMAP3530端Linux的文件系统,就可以直接在PC上开发OMAP3530端的程序。
2 搭建ARM与DSP之间的桥梁
2.1 DVSDK简介
为了使ARM与DSP建立连接,TI公司推出了DVSDK(Digital Video Software Development Kit)软件开发包,它集成了多种软件工具,包括支持独立DSP处理器和ARM处理器组件以及双核系统交互组件,各个组件之间紧密联系,形成了完整的开发套件[4,5]。DVSDK部分软件模块介绍如下。
(1)DSP/BIOS for Linux:是一个可扩缩的实时DSP核,可以理解为在DSP端独立运行的实时系统。
(2)TI Codegen Tools for Linux:是Linux环境下DSP程序的编译器、连接器及相关工具,类似于Windows环境下的CCS软件(在Windows环境下的CCS软件用来编译和调试DSP程序)。
(3)Framework Component:负责DSP端的Memory和DMA资源管理。
(4)x DAIS:定义了DSP算法接口的标准。
(5)DSP/BIOS Link:是实现ARM和DSP之间通信的底层软件。
(6)Codec Engine:是DVSDK的核心,所有其他软件模块基本上都是围绕Codec Engine来设计的。
2.2 DVSDK的安装与编译
首先要在虚拟机上的Linux系统中安装DVSDK软件包。DVSDK软件包可以从TI公司的官方网站上获取,软件包获取后执行如下命令即可实现其安装:
完成安装后会生成一个文件夹,里面包含了所有DVSDK软件模块。然后还需要对DVSDK内部的一些文件进行配置,主要的配置是指定各个模块编译所需要的编译工具以及相应目录的相对位置,配置好以后就可以对各个模块进行编译。
编译成功后,在DVSDK相应的目录下会生成cmem ko(内存管理模块)、dsplink.ko(ARM与DSP连接模块)、lpm_omap3530.ko(电源管理模块)等内核模块。为了使ARM与DSP建立连接,必须要有DSPLINK模块的支持,系统需要通过DSPLINK来完成ARM与DSP端之间底层的数据通信。DSPLINK提供了一套通用的API,从应用层抽象出ARM与DSP的物理连接特性,从而降低用户开发程序的难度。
2.3 内存的分配
由于ARM端运行的是Linux操作系统,DSP端运行的是DSP/BIOS操作系统,为了使两个系统协同工作,两者之间需要开辟一块ARM端和DSP端共享的内存空间。这部分的工作由CMEM来完成,所以在加载cmem.ko时,需要对其进行内存分配设置。CMEM还能够将内存的物理地址转化为操作系统能够识别的虚拟地址,避免了操作系统对物理地址的直接访问。这样无论是Linux操作系统还是DSP/BIOS操作系统都是通过CMEM对内存进行管理。
加载完上述各个功能模块后就可以开发可供ARM端调用的DSP程序。
3 供ARM端调用的DSP程序的开发
为了开发可供ARM端调用的DSP程序,必须了解Codec Engine。Codec Engine是连接ARM和DSP协处理器的桥梁,是介于应用层(ARM端的应用程序)和信号处理层(DSP端的算法程序)之间的软件模块。在编译DSP端和ARM端程序时,都需要Codec Engine的支持。当ARM端应用程序调用Codec Engine的VISA(Video,Image,Speech,Audio)API,例如图2中VIDENC_process(a,b,c)时,Codec Engine的stub(ARM端)会把参数a、b、c以及要调用DSP端的process信息打包,通过消息队列(message queue)传递到DSP。Codec Engine的skeleton(DSP端)会解开这个参数包,把参数a、b、c转换成DSP端对应的参数x、y、z;DSP端的server会根据process这一信息创建一个DSP端的process(x,y,z)任务,最终实现VIDENC_process(a,b,c)的操作。
DSP端的算法程序开发一般有两种:
(1)在Windows的CCS下直接开发DSP端运行的程序,然后打包成固定的格式,使其能够被Codec Engine调用。这种方法的优点是能够通过优化程序最大限度地提高DSP的运行效率。目前大多数DSP虽然都支持C语言编程,但是在实际工程应用中,具体的算法模块以及比较耗时的功能模块还是采用汇编语言来编写。这是因为C语言虽然具有易读性、可移植性等优点,但是它不便于对系统硬件资源的直接控制,无法发挥DSP自身的特点,无法充分利用DSP系统结构中有限的资源。特别是在硬实时性系统中,用汇编语言进行编程可利用DSP自身硬件结构的特点对汇编程序进行优化和精简,往往能够使一些复杂的算法及功能模块在实时性方面取得非常好的效果。但是这种方法也有其缺点,那就是算法程序的可移植性非常差,基本上针对每一个应用都要开发不同的DSP程序,这是比较致命的问题。
(2)通过DVSDK开发套件在宿主机上直接开发算法程序,其开发方法遵照TI公司制订的基于e Xpress DSP算法互用性标准。这种方法虽然会使DSP的运行效率受到一定影响,但为系统的整体性能和二次开发提供了可靠的保证。下面以示例程序来说明其开发方法。
(1)进入DVSDK安装后生成目录/dvsdk_3_01_00_10/codec_engine_2_25_02_11/examples/ti/sdo/ce/examples/codecs/imgdec_copy,如图3所示。该目录下的程序是DVSDK提供的示例程序,其中imgdec_copy.c是DSP端的程序,该程序实现了将ARM端读进的in.bmp图像拷贝成当前目录下的out.bmp图像的功能。
然后把该程序封装成库文件。为此要对该程序进行编译(在该目录下执行make命令即可),编译完成后会在该目录的lib子目录下生成imgdec_copy.a64P等库文件,如图4所示。
(2)把imgdec_copy.a64P库文件封装成x64P格式的文件。进入目录/dvsdk_3_01_00_10/codec_engine_2_25_02_11/examples/ti/sdo/ce/examples/servers/all_codecs,如图5所示。在该目录下执行make命令进行编译,即可把imgdec_copy.a64P文件封装成x64P格式。编译完成后会在该目录的bin/ti_platforms_evm3530子目录下生成all.x64P文件,如图6所示。至此,DSP端算法程序的编译和封装已经完成。
(3)编译ARM端的程序。进入ARM端应用程序目录/dvsdk_3_01_00_10/codec_engine_2_25_02_11/examples/ti/sdo/ce/examples/apps/image_copy,如图7所示。该目录下app.c是在ARM端运行的应用程序,该程序的主要功能就是从当前目录读取in.bmp文件,然后调用DSP端的程序,让DSP去实现图像拷贝。对该程序进行编译(执行make命令),编译完成后会在该目录的bin子目录下生成ARM端的应用程序app_remote.xv5T,如图8所示。
至此,DSP端的算法程序和ARM端的应用程序都已经编译完成。最后,把生成的app_remote.xv5T和all x64P拷贝到OMAP3530的根文件目录下。
(4)启动OMAP3530,待系统启动完成后,就把cmem.ko、dsplink.ko、lpm_omap3530.ko等模块加载入内核,加载成功后,在文件目录中找到app_remote.xv5T、all.x64P、in.bmp文件,如图9所示;然后运行app_remote.xv5T程序,就可以利用DSP实现图像的拷贝,如图10所示。out.bmp就是应用层调用DSP算法实现in.bmp图像拷贝后的结果。这就是DSP算法程序开发的第二种方法。
本文阐述了OMAP3530中两种ARM和DSP协同开发方法,并对其进行了比较。一种方法是在CCS下直接开发DSP端的算法程序,其优点是能够通过优化算法程序最大限度地提高DSP端数字信号处理的效率,缺点是算法程序的可移植性差。另一种方法是利用DVSDK开发套件开发算法程序,其优点是算法的可移植性好,能够有效缩短开发周期,但是无法对DSP端运行的算法程序进行实时在线调试,而且DSP多流水线处理方式的优势难以得到充分发挥,所以算法程序也并不是最优化的。在实际开发中,可以根据具体的情况选择一种开发方法。
摘要：以OMAP3530为硬件平台,以DVSDK为软件工具,介绍了协同开发环境的搭建方法。说明了OMAP3530中ARM和DSP协同开发的两种方法,并对两种方法的优缺点进行了比较。
关键词：OMAP3530,ARM,DSP,DVSDK,Codec Engine
参考文献
[1]冼进,毕盛.基于OMAP3530双核的嵌入式系统实验平台设计[J].信息系统工程,2010(7):72-73.
[2]王伟,刘培德.OMAP3530平台移动多媒体的视频解码方案[J].单片机与嵌入式系统,2010(6):31-34.
[3]宋宝华.Linux设备驱动开发详解[M].北京:人民邮电出版社,2010.
[4]张起贵,张胜,张刚.最新DSP技术[M].北京:国防工业出版社,2009.