双核处理器ARMDSP如何实现协同工作.docVIP

针对当前应用的复杂性，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到01的88MB空间给Linux内核使用；从001的16MB给CMEM的驱动，用来做ARM和DSP的大块数据交互，从001的24MB是DSP的代码和数据空间。 芯片的启动也是需要重点考虑的问题，一般情况下，是ARM启动，和传统的单核ARM一样，支持不同的启动方式，比如可以支持NAND，NOR，UART，SPI，USB，PCI等接口启动。DSP默认处于复位状态，只有通过ARM的应用下载代码并且解除复位以后，DSP才能跑起来。有些应用场景，需要DSP直接从外部上电就自启动，有些芯片也是支持这种模式的。 最后，关于芯片的通信和同步，这个是困扰很多工程师的问题，为了便于客户的开发和使用，TI提供了DSPLINK，CODEC ENGINE的DVSDK开发套件，基于DVSDK可以很方便的进行AR