双核处理器ARM+DSP如何实现协同工作

[复制链接]
2071|21
手机看帖
扫描二维码
随时随地手机跟帖
Sode|  楼主 | 2018-11-11 11:54 | 显示全部楼层 |阅读模式
双核处理器ARM+DSP如何实现协同工作


      针对当前应用的复杂性,SOC芯片更好能能满足应用和媒体的需求,集成众多接口,用ARM做为应用处理器进行多样化的应用开发和用户界面和接口,利用DSP进行算法加速,特别是媒体的编解码算法加速,既能够保持算法的灵活性,又能提供强大的处理能力。德州仪器(TI)继第一系列Davinci芯片DM644x之后,又陆续推出了DM643x,DM35x/36x,DM6467,OMAP35x,OMAPLx等一系列ARM+DSP或ARM+视频协处理器的多媒体处理器平台。众多有很强DSP开发经验的工程师,以及应用处理开发经验的工程师都转到使用达芬奇或OMAP平台上开发视频监控、视频会议及便携式多媒体终端等产品。基于ARM+DSP的芯片架构,如何进行开发实现做期望的嵌入式应用呢?
传统的芯片,基本是一个处理器内核,或者是通用处理器如ARM,或者是DSP。对于控制和用户接口,一般用通用处理器实现,算法处理或者媒体处理则依赖于DSP或者硬件芯片,很多系统都是双芯片的架构。开发模式也比较单纯,比如ARM芯片,有ARM的的仿真工具,基于OS之上进行应用开发;DSP有DSP的开发工具,如TI的CCS以及510、560的仿真器,可以进行算法的移植、优化、跟踪、调试等。这时,所需要的经验也比较单一。
     
     基于ARM+DSP的双核架构,很多工程师不知道如何入手进行开发,提出了很多的疑问,比如对ARM工程师,很困惑的是如何使用DSP的资源?如何进行数据的交互?如何保持双核之间的同步?对DSP工程师,则问到如何进行ARM调试?如何启动DSP?如果进行媒体加速,如何操作外设获取或发送数据等。基于不同的开发经验和基础,ARM工程师和DSP工程师会从完全不同的角度来看SOC的芯片,以至于拿到SOC的芯片根本不知道如何入手,这里就本人的经验与大家分享一下。
     
         首先ARM+DSP的芯片,他是一个双核的,对应ARM和DSP分别是不同的指令集和编译器,可以把SOC的芯片看成是两个单芯片的合成,需要两套不同的开发工具,CCS3.3可以进行芯片级的调试和仿真,但是对应ARM和DSP需要选择不同的平台。一般来说,ARM上面跑操作系统,比如Linux,Wince等,在ARM上的开发,除了bootloader以外,基本都是基于OS的开发,比如驱动,内核裁减,以及上层应用等,需要的调试和仿真主要靠log或者OS提供的调试器,如KGDB,Platform Builder等。基于DSP核的开发和传统单核DSP一样,需要用CCS+仿真器来进行开发调试。
     其次,对于芯片的外设接口,ARM核和DSP核都可以访问,典型的情况是ARM控制所有的外设,通过OS上的驱动去控制和管理,这部分和传统的ARM芯片类似;DSP主要是进行算法加速,只是和memory打交道,为了保持芯片的资源管理的一致性,尽量避免由DSP去访问外设。当然,根据具体的应用需求,DSP也是可以控制外设接口进行数据的收发,这时,需要做好系统的管理,避免双核操作的冲突。
     
          对memory的使用,非易失的存储空间,比如NAND、NOR Flash,基本也是由ARM访问,DSP的算法代码作为ARM端OS文件系统的一个文件存在,通过应用程序进行DSP程序的下载和DSP芯片的控制。外部RAM空间,即DDR存储区,是ARM和DSP共享存在的,但是在系统设计的时候,需要把ARM和DSP使用的内存严格物理地址分开,以及预留出一部分用来交互的内存空间。一般情况,ARM是用低端地址,DSP通过CMD文件分配高端地址,中间预留部分空间用来做数据交互,比如在OMAP3的Linux下的DVSDK中,128MB的DDR空间被分成三部分,低端地址从0x8000000到0x85800000-1的88MB空间给Linux内核使用;从0x85800000到0x86800000-1的16MB给CMEM的驱动,用来做ARM和DSP的大块数据交互,从0x86800000到0x88000000-1的24MB是DSP的代码和数据空间。
      芯片的启动也是需要重点考虑的问题,一般情况下,是ARM启动,和传统的单核ARM一样,支持不同的启动方式,比如可以支持NAND,NOR,UART,SPI,USB,PCI等接口启动。DSP默认处于复位状态,只有通过ARM的应用下载代码并且解除复位以后,DSP才能跑起来。有些应用场景,需要DSP直接从外部上电就自启动,有些芯片也是支持这种模式的。
   
        最后,关于芯片的通信和同步,这个是困扰很多工程师的问题,为了便于客户的开发和使用,TI提供了DSPLINK,CODEC ENGINE的DVSDK开发套件,基于DVSDK可以很方便的进行ARM+DSP的应用开发,下面对DVSDK的软件架构,各个软件模块的功能等做简要介绍。
   
        DVSDK是多个软件模块的集成,包括纯DSP端的软件模块,ARM的软件模块和双核交互的软件模块。DVSDK的软件包都是基于实时软件模块(Real-Time-Software-Component:RTSC)的,还需要安装RTSC的工具XDC,XDC是TI开源的一个工具,可以支持跨平台的开发,能够最大程度的代码重用;如果需要进行纯ARM的开发,还需要ARM的编译工具以及Linux内核或者Wince的BSP;如果需要进行DSP的算法开发或者DSP端开执行代码生成,还需要安装DSP的编译器cgtools和DSP/BIOS;为了便于配置生成DSP端的可执行代码,通过向导生成Codec的RTSC包和可执行代码,还可以选装ceutils和cg_xml。
     
         DVSDK的核心是Codec Engine,所有的其他软件模块基本都是围绕Codec Engine的。Codec Engine是连接ARM和DSP的桥梁,是介于应用层(ARM侧的应用程序)和信号处理层(DSP侧的算法)之间的软件模块,在编译DSP端可执行代码和ARM端应用程序时,都需要Codec Engine的支持。Codec Engine主要有两部分:
? ARM端应用适配层,提供了精简的API和对应的库给应用层使用。
? DSP的算法调用层,提供了DSP算法的接口封装规范,是的所有的算法通过简单的配置就可以编译到DSP的可执行程序中。
最终的应用程序需要通过Codec Engine的API接口来下载DSP代码,调用DSP端的封装好的算法,以及进行ARM和DSP的通信。
   
        Codec Engine底层ARM和DSP的通信是建立在DSP/BIOS Link之上的,DSP/BIOS Link真正实现ARM和DSP交互的软件模块。由于DSP/BIOS Link是跨平台的,也是有ARM部分和DSP部分组成,其中在ARM端,包括基于OS的驱动和供应用调用的库文件,DSP端,必须要用DSP/BIOS,DSP的可执行代码需要包含DSP/BIOS Link的库文件。DSP/BIOS

Link常用的主要有如下几部分的软件模块:
? PROC相关的,主要是用来做DSP芯片的控制,比如启动,停止等,下载DSP的可执行代码,以及直接读写DSP端的memory空间等
? MSGQ相关,ARM和DSP的通信是基于MSGQ的,MSGQ有轮询等待的方式或者中断的方式,MSG是基于共享内存池的方式。Codec Engine通过MSGQ交互一些关键数据,比如控制,和一些大块数据的地址指针等。大量的数据交互需要通过cmem实现。
       在ARM端,配合Codec Engine使用的软件模块有LinuxUtils或者WinceUtils,包含cmem,SDMA等,cmem是用来在OS之外分配连续物理内存空间,进行物理地址到虚地址,以及虚地址到物理地址空间转化的。为了避免数据的多次复制,需要开辟一块ARM和DSP共享的数据空间,ARM和DSP都可以直接访问,这部分空间需要通过CMEM管理。对ARM来说,CMEM是OS上的一个驱动程序,需要通过IOCTL来实现内存分配或者地址空间转化。由于DSP可以访问任何物理地址空间,通过ARM传给DSP的指针必须是物理地址。
  
       为了适配一些播放器的接口,DVSDK还提供了DMAI(Digital Media Application Interface),DMAI提供了更为精简的媒体接口和基于OS的音视频捕捉、回放等接口,在Linux下的gstreamer和Wince下的dshow filter都是基于DMAI的。并且DMAI也提供了最基本的测试应用例子,可以很方便的进行修改和测试。
   
      如果只是调用现成的或者第三方的算法库,可以只了解ARM端的软件模块,Codec Engine或者DMAI已经提供了丰富的应用接口,DSP可以认为是个单纯的媒体***,把ARM+DSP的芯片当作ASIC一样使用。如果要充分发挥DSP的性能,就需要对DSP进行开发了。Codec Engine对DSP的算法只是规范了接口,以便于和Codec Engine一起生成DSP的可执行程序。

相关帖子

zhangmangui| | 2018-11-11 21:00 | 显示全部楼层
目前不这么使用了     大部分直接用一片解决问题    多核DSP

使用特权

评论回复
51xlf| | 2018-11-12 22:45 | 显示全部楼层
功能强大的 FPGA 协处理器

使用特权

评论回复
i1mcu| | 2018-11-12 22:45 | 显示全部楼层
FPGA+DSP构建的灵活性

使用特权

评论回复
pmp| | 2018-11-12 22:46 | 显示全部楼层
ARM现在也集成了很强的数字运算能力

使用特权

评论回复
mmbs| | 2018-11-12 22:46 | 显示全部楼层
ARM和FPGA都集成了DSP的core

使用特权

评论回复
1988020566| | 2018-11-12 22:47 | 显示全部楼层
ARM最大的优势在于速度快、低功耗

使用特权

评论回复
lzbf| | 2018-11-12 22:47 | 显示全部楼层
数据处理方面用DSP

使用特权

评论回复
houjiakai| | 2018-11-12 22:47 | 显示全部楼层
最近要用到dsp和fpga协同工作

使用特权

评论回复
youtome| | 2018-11-12 22:48 | 显示全部楼层
实时性要求很高

使用特权

评论回复
cemaj| | 2018-11-12 22:48 | 显示全部楼层
能否用DSP完全替代ARM

使用特权

评论回复
uiint| | 2018-11-12 22:48 | 显示全部楼层
ARM、DSP等处理器集成了运算单元、存储单元及大量的总线接口

使用特权

评论回复
cemaj| | 2018-11-12 22:49 | 显示全部楼层
后期是不是可以单独使用一个处理器呢?

使用特权

评论回复
51xlf| | 2018-11-12 22:49 | 显示全部楼层
作为双芯片的协同系统

使用特权

评论回复
youtome| | 2018-11-12 22:49 | 显示全部楼层
处理器的性能、多处理器协同 工作的能力

使用特权

评论回复
i1mcu| | 2018-11-12 22:49 | 显示全部楼层
双核处理器ARM+DSP用的很少。

使用特权

评论回复
houjiakai| | 2018-11-12 22:49 | 显示全部楼层
现在难以取代FPGA+DSP的架构

使用特权

评论回复
pmp| | 2018-11-12 22:49 | 显示全部楼层
DSP也能做控制应用

使用特权

评论回复
lzbf| | 2018-11-12 22:49 | 显示全部楼层
一般的arm没有除法器,而是把除法变成加法等运算

使用特权

评论回复
mmbs| | 2018-11-12 22:49 | 显示全部楼层
DSP还是有自己的特长的,无可替代。

使用特权

评论回复
发新帖 我要提问
您需要登录后才可以回帖 登录 | 注册

本版积分规则

1049

主题

1522

帖子

8

粉丝