达芬奇平台简要介绍 汇报人:朱军 (控制组)

33
达达达达达达达达达 汇汇汇 汇汇 汇汇汇汇 ()

Upload: infinity

Post on 16-Jan-2016

105 views

Category:

Documents


0 download

DESCRIPTION

达芬奇平台简要介绍 汇报人:朱军 (控制组). 前端. 图像缩放工具. CCD 控制器 视频接口. 10b DAC. Histogram/3A. 10b DAC. 预览. 10b DAC. 10b DAC. TMS320DM644x ™ 处理器 框图. /6. DM6443. 视频处理子系统. 视频-影像协 处理器 (VICP). ARM 子系统. DSP 子系统. Video Processing Subsystem. ARM926EJ-S 300 MHz CPU. C64x+ TM DSP 600 MHz Core. - PowerPoint PPT Presentation

TRANSCRIPT

Page 1: 达芬奇平台简要介绍 汇报人:朱军 (控制组)

达芬奇平台简要介绍

汇报人朱军 (控制组)

Video Processing Subsystem

视频处理子系统

TMS320DM644xtrade 处理器 框图

外设

后端

ARM 子系统

DSP 子系统

视频-影像协处理器 (VICP)

前端CCD 控制器

视频接口

图像缩放工具Histogram3A

预览

屏幕菜单式调节 (OSD)

10b DAC10b DAC10b DAC10b DAC

EDMA

ATA Compact

Flash

Async EMIFNAND

SmartMedia

MMCSD

WatchdogTimer PWMPWMPWM

General-Purpose

Timer

DDR2Controller(16b32b)

USB20

PHYVLYNQ

EMACWith

MDIO

连接性

程序 数据存储

SPI UARTUARTUARTI2C

AudioSerialPort

串行接口

系统

DM6443

ARM926EJ-S 300 MHz

CPU

C64x+TM DSP 600 MHz

Core

资源交换中心 (SCR)

视频编码器 (VENC)

6

由上图可以看出 DM6446 提供 两个内核( DSP 和 ARM )视频处理子系统( VPSS )两个电源域

多个时钟树多个引脚独立和复用的外设 对于双核的达芬奇架构大家最关心的是两个核之间的资源分配通信

方式在 DM6446 中

ARM 独享( DSP 不可用)的外设有 UART012 I2C 看门狗定时器 PWM012 ARM 中断控制器 USB2

0 ATACF SPI VPSS GPIO EMACMDIO EMIFA VLYNQ MMCSD

DSP 独享( ARM 不可用)的外设有 DSP 中断控制器 VICP

ARM 和 DSP 共享的外设有 EDMA TIME01 Power Sleep Controller ASP EMIF Data

双核的外设分配

如下图可以很清楚的看到 ARM 可以访问 DSP 片内存储器( L2RAM 和 L1D L1P )DSP 可以访问 ARM 片内存储器 ARM 和 DSP 共享 DDR2 和 AEMIF

ARM 可以中断 DSP ( 4 个通用中断和 1 个不可屏蔽中断) DSP 可以中断 ARM ( 2 个通用中断) ARM 控制 DSP 的电源时钟复位和引导

DM6446 的初始化顺序

1 DM6446 复位 芯片的配置由 PSC 决定取决于 BTSEL[03] EM_WIDTH AEWA 和 DSP_B

T 的状态

2 ROM Boot Loader (如果被选) NAND 和 UART0 的初始化

3 引导加载 以 U-BOOT 为例 ( 1 )使能电源域 DDR2 和 DSP ( 2 )设置时钟频率( ARM DSP 和 DDR2 时钟乘除系数) ( 3 )设置引脚复用控制器 ( 4 )设置 ARM 引导启动操作系统

4 操作系统启动 以 LINUX 为例 ( 1 )初始化 ARM ( 2 )初始化硬件系统 ( 3 )初始化 LINUX 环境

软件架构 ARM + DSP

1048715ARM 为主处理器用户应用程序在 ARM 实现1048766 移植操作系统 OS LINUX WinCEhelliphellip

1048766 用户用下列 3 个 APIs 来构建自己的应用程序

1048715EPSI Easy Peripheral Software Interface 设备驱动程序1048715VISA Video Imaging Speech Audio 应用层音视频编解码引擎接口1048715xDM xDAISfor Digital Media 具体的音视频编解码算法接口由 VISA 调用

1048715DSP 为从处理器主要用来实现视频图像处理1048715 ARM 与 DSP 之间用 DSPBIOS LINK 来通信

1048715 DSP 主要用来实现视频图像编解码算法 xDM

操作系统和驱动程序

OS 已移植了基于 MontaVista 内核的 LINUX 2610

EPSI 基于 LINUX 的设备驱动程序1048766 串口 UART IIC SPI1048766 存储 ATA NAND MMC1048766 网络 10100M 以太网1048715USB 海量存储主机端和设备端驱动程序1048766 音频 OSS 音频驱动程序1048766 视频 V4L2 视频采集 FBDevDirectFB 视频显示

Codec Engine 达芬奇技术体系中引入了 Codec Engine 并创建了一整套

的应用开发平台 Codec Engine 为通用处理器 (GPP) 上的开发者提供更为简单的开发环境

Codec Engine 是一系列用于表示和运行数字多媒体标准化DSP 算法接口 (XDAIS) 及算法的 API XDAIS 定义了一整套的多媒体算法编程接口可单独在 GPP 或 DSP 上运行也可在 DSP 上运行而 GPP 通过 Codec Engine 对其实行控制对于所有支持的运算器结构运行方式及操作系统Codec Engine 都有相同的 API Codec Engine 定义了 4类编解码器算法接口标准分别是视频图像语音音频简称 VISA

VISA 1048766 复杂的信号处理层通过音视频编解码引擎和 VISA API 进行抽象

1048715VISA API 是音视频编解码的用户接口

1048715VISA 用来处理视频 Video 图像 Image 语音 Speech 音频 Audio

1048766 编码与解码的 API 组相互独立所以总有 8 组 API

1048715 VIDENC IMGENC SPHENC AUDENC1048715 VIDDEC IMGDEC SPHDEC AUDDEC

1048766 每个 VISA 组中关键的 API 有

1048715 xxx_create1048715 xxx_process1048715 xxx_control1048715 xxx_delete

Codec Engine 框架分析 Codec Engine 在解决达芬奇双处理器架构问题时首

先引入了远程过程控制 (RPC) 的概念 RPC 是指在另一个处理器上远程执行一个命令或过程 RPC有客户端和服务端客户端通过某种通信协议并最终通过物理链路向服务端发送一个命令服务端执行命令并通过相应的通信方式将结果返回给客户端

达芬奇 DM6446 芯片将 ARM 作为客户端 DSP 作为服务端两者之间的物理链路就是两个处理器之间共享的 DDR2 存储器而将物理链路上的通信协议称为 DSPLink

下图给出了这种框架的结构示意图图中共享 DDR2 存储器是 ARM与 DSP 之间共享的内存通过它进行物理数据的交换 DSPLink 是达芬奇架构双处理器间通信的基础软件为开发人员提供了一个通用的 API 用于描述 ARM 与 DSP 之间通信的物理链路的特征引擎功能层用于管理算法对象的实例例如创建一个对象的具体过程等 VISA 层是面向引擎功能层的一个接口用于定义创建删除和使用一个特定符合 XDM(XDAIS 的扩展专用于多媒体应用 ) 标准的算法的进程由于Codec Engine 的主要任务是为从 ARM 发起的 VISA 命令控制远程的 XDM 算法起到一个管道的作用因此 VISA 层实际上就是代表了 XDM 接口层

一般来讲软件系统分为应用层信号处理层和 IO 层三部分 TI 提供的达芬奇参考软件框架就是基于这样的结构如图所示 Davinci 的应用工程师可以在系统的用户空间在系统功能性上添加和发挥自己的特色信号处理层通常都运行在 DSP 一侧负责信号处理包括音视频编解码算法 Codec Engine DSP 的实时操作系统 DSPBIOS 及和 ARM通信的模块 IO 层就是我们通常所说的驱动是针对 Davinci 外设模块的驱动程序

其中应用层通过 Codec Engine 的 VISA(Video Image Speech Audio)API 来调用 DSP侧的算法通过 EPSI(Easy Peripheral Software Interface)API 来访问和操作 Davinci 的外设

如下图所示 DaVinci 的软件开发通常需要四个步骤

前面我们提到应用工程师通过调用 Codec Engine 的 API来调用和运行符合 xDAIS 的算法在 Davinci 软件中符合xDAIS 的音视频编解码算法 (即 xDM 算法 ) 的调用是通过 Codec Engine 的 VISA API完成的 Codec Engine 通过这套API 为算法的执行提供了一个标准的软件架构和接口

Codec Engine 是介于应用程序和具体算法之间的软件模块其中的 VISA API 通过 stub 和 skeleton 访问 Engine SPI 最终调用具体的算法因此 Codec Engine 的工作是通过完成 VISA API 的任务来体现的 VISA API 分为四部分 VISA createcontrolprocessdelete 我们以 codec 算法运行在 DSP 为例通过 VISA API 的执行过程了解 Codec Engine 的工作原理

在调用 VISA API 之前需要在应用程序中通过 Engine_open()这个 Engine API把 DSP 的可执行程序加载到 DSP 的 memory 同时把 DSP 从复位状态释放这时 DSP 开始运行DSP Server 的初始化程序在 DSP侧创建一个优先级最低的任务 RMS(Remote Management Server) RMS负责管理和维护对应到具体 codec 算法的 Instances 应用程序调用VISA create API 相应的 VISA create函数到 Engine SPI中的 Codec table 中查到这个 codec 运行在远端 DSP侧

接着 Engine SPI 通过 OSAL(Operating System Abstraction

Layer) DSP Link把 VISA create 的命令传到 DSP侧的 RMS RMS 通过 DSP侧 Engine SPI 的 codec table找到要调用的 codec 算法后就会在 RMS 中创建一个相应的 Instance(即一个 DSPBIOS 系统中的任务 ) VISA create会返回一个 Instance 的 Handle 以便于给这个 Instance做后续的 VISA controlprocessdelete 提供信息 VISA delete 和VISA create原理类似只是 RMS删除掉相应的 codec 算法的 Instance 和执行 codec 算法的任务

概括来说 VISA control 用来动态的修改 codec instance 的属性 VISA process 用来对算法的输入数据流做处理并返回一个输出数据流如下图所示应用程序在调用 VISA processcontrol 时会通过 xDM Stub把传递给 codec 算法的参数收集起来并且转换成 DSP 可以识别的物理地址 Stub把这些参数和相关的命令通过 Engine SPI OSAL 和 DSP Link传递到 DSP侧的 Instance Instance再通过 Skeleton把传递过来的参数和命令解析出来通过 DSP侧 VISA controlprocess 对 codec 算法执行 controlprocess

算法创建第一步需要基于 DSP利用 CCS 开发自己的音视

频编解码算法编译生成一个编解码算法的库文件lib(等同于 Linux 环境下的 a64P 直接在 Linux环境下修改文件后缀名即可 ) 由于需要确保算法可被 Codec Engine 使用和配置所以要确保这些算法实现需要符合 xDM(xDAIS(eXpress DSP Algorithm Interface Standard) for Digital Media) 标准

如果算法与 XDM 标准兼容 则可不经修改而直接被 Codec Engine 的 VISA API 远程执行如不兼容则需为其提供 Codec Engine 的框架和终端接口

服务集成 第二步生成一个在 DSP 上运行的可执行程序 x64P(即 out文件 ) 也就是 DSP Server

由于在双核环境中 Codec Engine 是在 DM6446 中的 DSP上执行而操作系统是由 DM6446 中的 ARM 通过 VISA API控制 Codec Engine 所以必须先在远程的 DSP生成一个 Codec Server Codec Server 是后缀为 x64P 的文件是一个集成了编解码器框架元件和系统代码的二进制库

在达芬奇 DM6446 平台中 Codec Server包含了一个为相应客户端 (ARM)生成编解码器提供系统运行信息 (包括指令和内存使用情况 ) 的 DSP BIOS任务线程客户端 (ARM) 的应用程序通过使用 VISA API 与在远程 DSP 上的编解码器联系

引擎集成第三步通过配置工具做大量的关于引擎配置的工

作包括引擎的名字每个引擎中包含什么编解码器编解码器是本地执行还是远程执行等如果这些编解码器在远程执行的则还需配置相应的 Codec Server 一般将所有的配置写到一个 cfg文件里面

这个配置文件包含的内容有 Codec Engine 运行的系统环境包括 xDC 通用模块和客户端操作系统类型等指明 Codec Engine需要用到的编解码器模块配置 Codec Engine 指明 Engine包含的内容

引擎引用 第四步应用工程师利用 Coedc Engine 的应用编程接口创

建删除配置好的引擎实例进而创建删除和控制编解码器由于 Codec Engine 不参与任何的 IO 操作只是纯粹的视频编解码算法处理因此应用工程师需要管理 IO 包括文件操作 (文件的打开读写与存储等 ) 和外设操作 ( 外设的打开关闭与控制等 )

应用工程师负责编写应用代码并将合适的内容加到最终的可执行文件中去应用工程师可使用以下资源从算法开发工程师得到的大量的编解码器软件包从服务集成工程师得到一个可以在 DSP 上运行的 Codec Server二进制文件一般为 x64P文件从引擎集成工程师得到一个引擎配置文件一般为 cfg文件应用工程师编写应用代码并结合这些资源再链接编译生成最终的可执行代码

虽然达芬奇技术带来了全新的开发平台和研发理念但是作为一项尚处于发展初期的技术仍然可能存在一些问题

首先是视频硬件加速器 VICP 的使用细节没有公开只有少数第三方厂商才能了解如何使用视频硬件加速器因此其他厂商开发 Codec 的难度就非常大

另外由于 DSP 与 ARM 双核结构的开发环境非常复杂 目前尚无一个完全集成 DSP 与 ARM 调试环境的集成开发环境因此需要同时进行 DSP 和 ARM 软件的跟踪调试必须运行两个独立的集成开发环境

另外 DSP 与 ARM 之间通信的协议接口也比较繁复

  • Slide 1
  • Slide 2
  • Slide 3
  • Slide 4
  • Slide 5
  • Slide 6
  • Slide 7
  • Slide 8
  • Slide 9
  • Slide 10
  • Slide 11
  • Slide 12
  • Slide 13
  • Slide 14
  • Slide 15
  • Slide 16
  • Slide 17
  • Slide 18
  • Slide 19
  • Slide 20
  • Slide 21
  • Slide 22
  • Slide 23
  • Slide 24
  • Slide 25
  • Slide 26
  • Slide 27
  • Slide 28
  • Slide 29
  • Slide 30
  • Slide 31
  • Slide 32
  • Slide 33
Page 2: 达芬奇平台简要介绍 汇报人:朱军 (控制组)

Video Processing Subsystem

视频处理子系统

TMS320DM644xtrade 处理器 框图

外设

后端

ARM 子系统

DSP 子系统

视频-影像协处理器 (VICP)

前端CCD 控制器

视频接口

图像缩放工具Histogram3A

预览

屏幕菜单式调节 (OSD)

10b DAC10b DAC10b DAC10b DAC

EDMA

ATA Compact

Flash

Async EMIFNAND

SmartMedia

MMCSD

WatchdogTimer PWMPWMPWM

General-Purpose

Timer

DDR2Controller(16b32b)

USB20

PHYVLYNQ

EMACWith

MDIO

连接性

程序 数据存储

SPI UARTUARTUARTI2C

AudioSerialPort

串行接口

系统

DM6443

ARM926EJ-S 300 MHz

CPU

C64x+TM DSP 600 MHz

Core

资源交换中心 (SCR)

视频编码器 (VENC)

6

由上图可以看出 DM6446 提供 两个内核( DSP 和 ARM )视频处理子系统( VPSS )两个电源域

多个时钟树多个引脚独立和复用的外设 对于双核的达芬奇架构大家最关心的是两个核之间的资源分配通信

方式在 DM6446 中

ARM 独享( DSP 不可用)的外设有 UART012 I2C 看门狗定时器 PWM012 ARM 中断控制器 USB2

0 ATACF SPI VPSS GPIO EMACMDIO EMIFA VLYNQ MMCSD

DSP 独享( ARM 不可用)的外设有 DSP 中断控制器 VICP

ARM 和 DSP 共享的外设有 EDMA TIME01 Power Sleep Controller ASP EMIF Data

双核的外设分配

如下图可以很清楚的看到 ARM 可以访问 DSP 片内存储器( L2RAM 和 L1D L1P )DSP 可以访问 ARM 片内存储器 ARM 和 DSP 共享 DDR2 和 AEMIF

ARM 可以中断 DSP ( 4 个通用中断和 1 个不可屏蔽中断) DSP 可以中断 ARM ( 2 个通用中断) ARM 控制 DSP 的电源时钟复位和引导

DM6446 的初始化顺序

1 DM6446 复位 芯片的配置由 PSC 决定取决于 BTSEL[03] EM_WIDTH AEWA 和 DSP_B

T 的状态

2 ROM Boot Loader (如果被选) NAND 和 UART0 的初始化

3 引导加载 以 U-BOOT 为例 ( 1 )使能电源域 DDR2 和 DSP ( 2 )设置时钟频率( ARM DSP 和 DDR2 时钟乘除系数) ( 3 )设置引脚复用控制器 ( 4 )设置 ARM 引导启动操作系统

4 操作系统启动 以 LINUX 为例 ( 1 )初始化 ARM ( 2 )初始化硬件系统 ( 3 )初始化 LINUX 环境

软件架构 ARM + DSP

1048715ARM 为主处理器用户应用程序在 ARM 实现1048766 移植操作系统 OS LINUX WinCEhelliphellip

1048766 用户用下列 3 个 APIs 来构建自己的应用程序

1048715EPSI Easy Peripheral Software Interface 设备驱动程序1048715VISA Video Imaging Speech Audio 应用层音视频编解码引擎接口1048715xDM xDAISfor Digital Media 具体的音视频编解码算法接口由 VISA 调用

1048715DSP 为从处理器主要用来实现视频图像处理1048715 ARM 与 DSP 之间用 DSPBIOS LINK 来通信

1048715 DSP 主要用来实现视频图像编解码算法 xDM

操作系统和驱动程序

OS 已移植了基于 MontaVista 内核的 LINUX 2610

EPSI 基于 LINUX 的设备驱动程序1048766 串口 UART IIC SPI1048766 存储 ATA NAND MMC1048766 网络 10100M 以太网1048715USB 海量存储主机端和设备端驱动程序1048766 音频 OSS 音频驱动程序1048766 视频 V4L2 视频采集 FBDevDirectFB 视频显示

Codec Engine 达芬奇技术体系中引入了 Codec Engine 并创建了一整套

的应用开发平台 Codec Engine 为通用处理器 (GPP) 上的开发者提供更为简单的开发环境

Codec Engine 是一系列用于表示和运行数字多媒体标准化DSP 算法接口 (XDAIS) 及算法的 API XDAIS 定义了一整套的多媒体算法编程接口可单独在 GPP 或 DSP 上运行也可在 DSP 上运行而 GPP 通过 Codec Engine 对其实行控制对于所有支持的运算器结构运行方式及操作系统Codec Engine 都有相同的 API Codec Engine 定义了 4类编解码器算法接口标准分别是视频图像语音音频简称 VISA

VISA 1048766 复杂的信号处理层通过音视频编解码引擎和 VISA API 进行抽象

1048715VISA API 是音视频编解码的用户接口

1048715VISA 用来处理视频 Video 图像 Image 语音 Speech 音频 Audio

1048766 编码与解码的 API 组相互独立所以总有 8 组 API

1048715 VIDENC IMGENC SPHENC AUDENC1048715 VIDDEC IMGDEC SPHDEC AUDDEC

1048766 每个 VISA 组中关键的 API 有

1048715 xxx_create1048715 xxx_process1048715 xxx_control1048715 xxx_delete

Codec Engine 框架分析 Codec Engine 在解决达芬奇双处理器架构问题时首

先引入了远程过程控制 (RPC) 的概念 RPC 是指在另一个处理器上远程执行一个命令或过程 RPC有客户端和服务端客户端通过某种通信协议并最终通过物理链路向服务端发送一个命令服务端执行命令并通过相应的通信方式将结果返回给客户端

达芬奇 DM6446 芯片将 ARM 作为客户端 DSP 作为服务端两者之间的物理链路就是两个处理器之间共享的 DDR2 存储器而将物理链路上的通信协议称为 DSPLink

下图给出了这种框架的结构示意图图中共享 DDR2 存储器是 ARM与 DSP 之间共享的内存通过它进行物理数据的交换 DSPLink 是达芬奇架构双处理器间通信的基础软件为开发人员提供了一个通用的 API 用于描述 ARM 与 DSP 之间通信的物理链路的特征引擎功能层用于管理算法对象的实例例如创建一个对象的具体过程等 VISA 层是面向引擎功能层的一个接口用于定义创建删除和使用一个特定符合 XDM(XDAIS 的扩展专用于多媒体应用 ) 标准的算法的进程由于Codec Engine 的主要任务是为从 ARM 发起的 VISA 命令控制远程的 XDM 算法起到一个管道的作用因此 VISA 层实际上就是代表了 XDM 接口层

一般来讲软件系统分为应用层信号处理层和 IO 层三部分 TI 提供的达芬奇参考软件框架就是基于这样的结构如图所示 Davinci 的应用工程师可以在系统的用户空间在系统功能性上添加和发挥自己的特色信号处理层通常都运行在 DSP 一侧负责信号处理包括音视频编解码算法 Codec Engine DSP 的实时操作系统 DSPBIOS 及和 ARM通信的模块 IO 层就是我们通常所说的驱动是针对 Davinci 外设模块的驱动程序

其中应用层通过 Codec Engine 的 VISA(Video Image Speech Audio)API 来调用 DSP侧的算法通过 EPSI(Easy Peripheral Software Interface)API 来访问和操作 Davinci 的外设

如下图所示 DaVinci 的软件开发通常需要四个步骤

前面我们提到应用工程师通过调用 Codec Engine 的 API来调用和运行符合 xDAIS 的算法在 Davinci 软件中符合xDAIS 的音视频编解码算法 (即 xDM 算法 ) 的调用是通过 Codec Engine 的 VISA API完成的 Codec Engine 通过这套API 为算法的执行提供了一个标准的软件架构和接口

Codec Engine 是介于应用程序和具体算法之间的软件模块其中的 VISA API 通过 stub 和 skeleton 访问 Engine SPI 最终调用具体的算法因此 Codec Engine 的工作是通过完成 VISA API 的任务来体现的 VISA API 分为四部分 VISA createcontrolprocessdelete 我们以 codec 算法运行在 DSP 为例通过 VISA API 的执行过程了解 Codec Engine 的工作原理

在调用 VISA API 之前需要在应用程序中通过 Engine_open()这个 Engine API把 DSP 的可执行程序加载到 DSP 的 memory 同时把 DSP 从复位状态释放这时 DSP 开始运行DSP Server 的初始化程序在 DSP侧创建一个优先级最低的任务 RMS(Remote Management Server) RMS负责管理和维护对应到具体 codec 算法的 Instances 应用程序调用VISA create API 相应的 VISA create函数到 Engine SPI中的 Codec table 中查到这个 codec 运行在远端 DSP侧

接着 Engine SPI 通过 OSAL(Operating System Abstraction

Layer) DSP Link把 VISA create 的命令传到 DSP侧的 RMS RMS 通过 DSP侧 Engine SPI 的 codec table找到要调用的 codec 算法后就会在 RMS 中创建一个相应的 Instance(即一个 DSPBIOS 系统中的任务 ) VISA create会返回一个 Instance 的 Handle 以便于给这个 Instance做后续的 VISA controlprocessdelete 提供信息 VISA delete 和VISA create原理类似只是 RMS删除掉相应的 codec 算法的 Instance 和执行 codec 算法的任务

概括来说 VISA control 用来动态的修改 codec instance 的属性 VISA process 用来对算法的输入数据流做处理并返回一个输出数据流如下图所示应用程序在调用 VISA processcontrol 时会通过 xDM Stub把传递给 codec 算法的参数收集起来并且转换成 DSP 可以识别的物理地址 Stub把这些参数和相关的命令通过 Engine SPI OSAL 和 DSP Link传递到 DSP侧的 Instance Instance再通过 Skeleton把传递过来的参数和命令解析出来通过 DSP侧 VISA controlprocess 对 codec 算法执行 controlprocess

算法创建第一步需要基于 DSP利用 CCS 开发自己的音视

频编解码算法编译生成一个编解码算法的库文件lib(等同于 Linux 环境下的 a64P 直接在 Linux环境下修改文件后缀名即可 ) 由于需要确保算法可被 Codec Engine 使用和配置所以要确保这些算法实现需要符合 xDM(xDAIS(eXpress DSP Algorithm Interface Standard) for Digital Media) 标准

如果算法与 XDM 标准兼容 则可不经修改而直接被 Codec Engine 的 VISA API 远程执行如不兼容则需为其提供 Codec Engine 的框架和终端接口

服务集成 第二步生成一个在 DSP 上运行的可执行程序 x64P(即 out文件 ) 也就是 DSP Server

由于在双核环境中 Codec Engine 是在 DM6446 中的 DSP上执行而操作系统是由 DM6446 中的 ARM 通过 VISA API控制 Codec Engine 所以必须先在远程的 DSP生成一个 Codec Server Codec Server 是后缀为 x64P 的文件是一个集成了编解码器框架元件和系统代码的二进制库

在达芬奇 DM6446 平台中 Codec Server包含了一个为相应客户端 (ARM)生成编解码器提供系统运行信息 (包括指令和内存使用情况 ) 的 DSP BIOS任务线程客户端 (ARM) 的应用程序通过使用 VISA API 与在远程 DSP 上的编解码器联系

引擎集成第三步通过配置工具做大量的关于引擎配置的工

作包括引擎的名字每个引擎中包含什么编解码器编解码器是本地执行还是远程执行等如果这些编解码器在远程执行的则还需配置相应的 Codec Server 一般将所有的配置写到一个 cfg文件里面

这个配置文件包含的内容有 Codec Engine 运行的系统环境包括 xDC 通用模块和客户端操作系统类型等指明 Codec Engine需要用到的编解码器模块配置 Codec Engine 指明 Engine包含的内容

引擎引用 第四步应用工程师利用 Coedc Engine 的应用编程接口创

建删除配置好的引擎实例进而创建删除和控制编解码器由于 Codec Engine 不参与任何的 IO 操作只是纯粹的视频编解码算法处理因此应用工程师需要管理 IO 包括文件操作 (文件的打开读写与存储等 ) 和外设操作 ( 外设的打开关闭与控制等 )

应用工程师负责编写应用代码并将合适的内容加到最终的可执行文件中去应用工程师可使用以下资源从算法开发工程师得到的大量的编解码器软件包从服务集成工程师得到一个可以在 DSP 上运行的 Codec Server二进制文件一般为 x64P文件从引擎集成工程师得到一个引擎配置文件一般为 cfg文件应用工程师编写应用代码并结合这些资源再链接编译生成最终的可执行代码

虽然达芬奇技术带来了全新的开发平台和研发理念但是作为一项尚处于发展初期的技术仍然可能存在一些问题

首先是视频硬件加速器 VICP 的使用细节没有公开只有少数第三方厂商才能了解如何使用视频硬件加速器因此其他厂商开发 Codec 的难度就非常大

另外由于 DSP 与 ARM 双核结构的开发环境非常复杂 目前尚无一个完全集成 DSP 与 ARM 调试环境的集成开发环境因此需要同时进行 DSP 和 ARM 软件的跟踪调试必须运行两个独立的集成开发环境

另外 DSP 与 ARM 之间通信的协议接口也比较繁复

  • Slide 1
  • Slide 2
  • Slide 3
  • Slide 4
  • Slide 5
  • Slide 6
  • Slide 7
  • Slide 8
  • Slide 9
  • Slide 10
  • Slide 11
  • Slide 12
  • Slide 13
  • Slide 14
  • Slide 15
  • Slide 16
  • Slide 17
  • Slide 18
  • Slide 19
  • Slide 20
  • Slide 21
  • Slide 22
  • Slide 23
  • Slide 24
  • Slide 25
  • Slide 26
  • Slide 27
  • Slide 28
  • Slide 29
  • Slide 30
  • Slide 31
  • Slide 32
  • Slide 33
Page 3: 达芬奇平台简要介绍 汇报人:朱军 (控制组)

由上图可以看出 DM6446 提供 两个内核( DSP 和 ARM )视频处理子系统( VPSS )两个电源域

多个时钟树多个引脚独立和复用的外设 对于双核的达芬奇架构大家最关心的是两个核之间的资源分配通信

方式在 DM6446 中

ARM 独享( DSP 不可用)的外设有 UART012 I2C 看门狗定时器 PWM012 ARM 中断控制器 USB2

0 ATACF SPI VPSS GPIO EMACMDIO EMIFA VLYNQ MMCSD

DSP 独享( ARM 不可用)的外设有 DSP 中断控制器 VICP

ARM 和 DSP 共享的外设有 EDMA TIME01 Power Sleep Controller ASP EMIF Data

双核的外设分配

如下图可以很清楚的看到 ARM 可以访问 DSP 片内存储器( L2RAM 和 L1D L1P )DSP 可以访问 ARM 片内存储器 ARM 和 DSP 共享 DDR2 和 AEMIF

ARM 可以中断 DSP ( 4 个通用中断和 1 个不可屏蔽中断) DSP 可以中断 ARM ( 2 个通用中断) ARM 控制 DSP 的电源时钟复位和引导

DM6446 的初始化顺序

1 DM6446 复位 芯片的配置由 PSC 决定取决于 BTSEL[03] EM_WIDTH AEWA 和 DSP_B

T 的状态

2 ROM Boot Loader (如果被选) NAND 和 UART0 的初始化

3 引导加载 以 U-BOOT 为例 ( 1 )使能电源域 DDR2 和 DSP ( 2 )设置时钟频率( ARM DSP 和 DDR2 时钟乘除系数) ( 3 )设置引脚复用控制器 ( 4 )设置 ARM 引导启动操作系统

4 操作系统启动 以 LINUX 为例 ( 1 )初始化 ARM ( 2 )初始化硬件系统 ( 3 )初始化 LINUX 环境

软件架构 ARM + DSP

1048715ARM 为主处理器用户应用程序在 ARM 实现1048766 移植操作系统 OS LINUX WinCEhelliphellip

1048766 用户用下列 3 个 APIs 来构建自己的应用程序

1048715EPSI Easy Peripheral Software Interface 设备驱动程序1048715VISA Video Imaging Speech Audio 应用层音视频编解码引擎接口1048715xDM xDAISfor Digital Media 具体的音视频编解码算法接口由 VISA 调用

1048715DSP 为从处理器主要用来实现视频图像处理1048715 ARM 与 DSP 之间用 DSPBIOS LINK 来通信

1048715 DSP 主要用来实现视频图像编解码算法 xDM

操作系统和驱动程序

OS 已移植了基于 MontaVista 内核的 LINUX 2610

EPSI 基于 LINUX 的设备驱动程序1048766 串口 UART IIC SPI1048766 存储 ATA NAND MMC1048766 网络 10100M 以太网1048715USB 海量存储主机端和设备端驱动程序1048766 音频 OSS 音频驱动程序1048766 视频 V4L2 视频采集 FBDevDirectFB 视频显示

Codec Engine 达芬奇技术体系中引入了 Codec Engine 并创建了一整套

的应用开发平台 Codec Engine 为通用处理器 (GPP) 上的开发者提供更为简单的开发环境

Codec Engine 是一系列用于表示和运行数字多媒体标准化DSP 算法接口 (XDAIS) 及算法的 API XDAIS 定义了一整套的多媒体算法编程接口可单独在 GPP 或 DSP 上运行也可在 DSP 上运行而 GPP 通过 Codec Engine 对其实行控制对于所有支持的运算器结构运行方式及操作系统Codec Engine 都有相同的 API Codec Engine 定义了 4类编解码器算法接口标准分别是视频图像语音音频简称 VISA

VISA 1048766 复杂的信号处理层通过音视频编解码引擎和 VISA API 进行抽象

1048715VISA API 是音视频编解码的用户接口

1048715VISA 用来处理视频 Video 图像 Image 语音 Speech 音频 Audio

1048766 编码与解码的 API 组相互独立所以总有 8 组 API

1048715 VIDENC IMGENC SPHENC AUDENC1048715 VIDDEC IMGDEC SPHDEC AUDDEC

1048766 每个 VISA 组中关键的 API 有

1048715 xxx_create1048715 xxx_process1048715 xxx_control1048715 xxx_delete

Codec Engine 框架分析 Codec Engine 在解决达芬奇双处理器架构问题时首

先引入了远程过程控制 (RPC) 的概念 RPC 是指在另一个处理器上远程执行一个命令或过程 RPC有客户端和服务端客户端通过某种通信协议并最终通过物理链路向服务端发送一个命令服务端执行命令并通过相应的通信方式将结果返回给客户端

达芬奇 DM6446 芯片将 ARM 作为客户端 DSP 作为服务端两者之间的物理链路就是两个处理器之间共享的 DDR2 存储器而将物理链路上的通信协议称为 DSPLink

下图给出了这种框架的结构示意图图中共享 DDR2 存储器是 ARM与 DSP 之间共享的内存通过它进行物理数据的交换 DSPLink 是达芬奇架构双处理器间通信的基础软件为开发人员提供了一个通用的 API 用于描述 ARM 与 DSP 之间通信的物理链路的特征引擎功能层用于管理算法对象的实例例如创建一个对象的具体过程等 VISA 层是面向引擎功能层的一个接口用于定义创建删除和使用一个特定符合 XDM(XDAIS 的扩展专用于多媒体应用 ) 标准的算法的进程由于Codec Engine 的主要任务是为从 ARM 发起的 VISA 命令控制远程的 XDM 算法起到一个管道的作用因此 VISA 层实际上就是代表了 XDM 接口层

一般来讲软件系统分为应用层信号处理层和 IO 层三部分 TI 提供的达芬奇参考软件框架就是基于这样的结构如图所示 Davinci 的应用工程师可以在系统的用户空间在系统功能性上添加和发挥自己的特色信号处理层通常都运行在 DSP 一侧负责信号处理包括音视频编解码算法 Codec Engine DSP 的实时操作系统 DSPBIOS 及和 ARM通信的模块 IO 层就是我们通常所说的驱动是针对 Davinci 外设模块的驱动程序

其中应用层通过 Codec Engine 的 VISA(Video Image Speech Audio)API 来调用 DSP侧的算法通过 EPSI(Easy Peripheral Software Interface)API 来访问和操作 Davinci 的外设

如下图所示 DaVinci 的软件开发通常需要四个步骤

前面我们提到应用工程师通过调用 Codec Engine 的 API来调用和运行符合 xDAIS 的算法在 Davinci 软件中符合xDAIS 的音视频编解码算法 (即 xDM 算法 ) 的调用是通过 Codec Engine 的 VISA API完成的 Codec Engine 通过这套API 为算法的执行提供了一个标准的软件架构和接口

Codec Engine 是介于应用程序和具体算法之间的软件模块其中的 VISA API 通过 stub 和 skeleton 访问 Engine SPI 最终调用具体的算法因此 Codec Engine 的工作是通过完成 VISA API 的任务来体现的 VISA API 分为四部分 VISA createcontrolprocessdelete 我们以 codec 算法运行在 DSP 为例通过 VISA API 的执行过程了解 Codec Engine 的工作原理

在调用 VISA API 之前需要在应用程序中通过 Engine_open()这个 Engine API把 DSP 的可执行程序加载到 DSP 的 memory 同时把 DSP 从复位状态释放这时 DSP 开始运行DSP Server 的初始化程序在 DSP侧创建一个优先级最低的任务 RMS(Remote Management Server) RMS负责管理和维护对应到具体 codec 算法的 Instances 应用程序调用VISA create API 相应的 VISA create函数到 Engine SPI中的 Codec table 中查到这个 codec 运行在远端 DSP侧

接着 Engine SPI 通过 OSAL(Operating System Abstraction

Layer) DSP Link把 VISA create 的命令传到 DSP侧的 RMS RMS 通过 DSP侧 Engine SPI 的 codec table找到要调用的 codec 算法后就会在 RMS 中创建一个相应的 Instance(即一个 DSPBIOS 系统中的任务 ) VISA create会返回一个 Instance 的 Handle 以便于给这个 Instance做后续的 VISA controlprocessdelete 提供信息 VISA delete 和VISA create原理类似只是 RMS删除掉相应的 codec 算法的 Instance 和执行 codec 算法的任务

概括来说 VISA control 用来动态的修改 codec instance 的属性 VISA process 用来对算法的输入数据流做处理并返回一个输出数据流如下图所示应用程序在调用 VISA processcontrol 时会通过 xDM Stub把传递给 codec 算法的参数收集起来并且转换成 DSP 可以识别的物理地址 Stub把这些参数和相关的命令通过 Engine SPI OSAL 和 DSP Link传递到 DSP侧的 Instance Instance再通过 Skeleton把传递过来的参数和命令解析出来通过 DSP侧 VISA controlprocess 对 codec 算法执行 controlprocess

算法创建第一步需要基于 DSP利用 CCS 开发自己的音视

频编解码算法编译生成一个编解码算法的库文件lib(等同于 Linux 环境下的 a64P 直接在 Linux环境下修改文件后缀名即可 ) 由于需要确保算法可被 Codec Engine 使用和配置所以要确保这些算法实现需要符合 xDM(xDAIS(eXpress DSP Algorithm Interface Standard) for Digital Media) 标准

如果算法与 XDM 标准兼容 则可不经修改而直接被 Codec Engine 的 VISA API 远程执行如不兼容则需为其提供 Codec Engine 的框架和终端接口

服务集成 第二步生成一个在 DSP 上运行的可执行程序 x64P(即 out文件 ) 也就是 DSP Server

由于在双核环境中 Codec Engine 是在 DM6446 中的 DSP上执行而操作系统是由 DM6446 中的 ARM 通过 VISA API控制 Codec Engine 所以必须先在远程的 DSP生成一个 Codec Server Codec Server 是后缀为 x64P 的文件是一个集成了编解码器框架元件和系统代码的二进制库

在达芬奇 DM6446 平台中 Codec Server包含了一个为相应客户端 (ARM)生成编解码器提供系统运行信息 (包括指令和内存使用情况 ) 的 DSP BIOS任务线程客户端 (ARM) 的应用程序通过使用 VISA API 与在远程 DSP 上的编解码器联系

引擎集成第三步通过配置工具做大量的关于引擎配置的工

作包括引擎的名字每个引擎中包含什么编解码器编解码器是本地执行还是远程执行等如果这些编解码器在远程执行的则还需配置相应的 Codec Server 一般将所有的配置写到一个 cfg文件里面

这个配置文件包含的内容有 Codec Engine 运行的系统环境包括 xDC 通用模块和客户端操作系统类型等指明 Codec Engine需要用到的编解码器模块配置 Codec Engine 指明 Engine包含的内容

引擎引用 第四步应用工程师利用 Coedc Engine 的应用编程接口创

建删除配置好的引擎实例进而创建删除和控制编解码器由于 Codec Engine 不参与任何的 IO 操作只是纯粹的视频编解码算法处理因此应用工程师需要管理 IO 包括文件操作 (文件的打开读写与存储等 ) 和外设操作 ( 外设的打开关闭与控制等 )

应用工程师负责编写应用代码并将合适的内容加到最终的可执行文件中去应用工程师可使用以下资源从算法开发工程师得到的大量的编解码器软件包从服务集成工程师得到一个可以在 DSP 上运行的 Codec Server二进制文件一般为 x64P文件从引擎集成工程师得到一个引擎配置文件一般为 cfg文件应用工程师编写应用代码并结合这些资源再链接编译生成最终的可执行代码

虽然达芬奇技术带来了全新的开发平台和研发理念但是作为一项尚处于发展初期的技术仍然可能存在一些问题

首先是视频硬件加速器 VICP 的使用细节没有公开只有少数第三方厂商才能了解如何使用视频硬件加速器因此其他厂商开发 Codec 的难度就非常大

另外由于 DSP 与 ARM 双核结构的开发环境非常复杂 目前尚无一个完全集成 DSP 与 ARM 调试环境的集成开发环境因此需要同时进行 DSP 和 ARM 软件的跟踪调试必须运行两个独立的集成开发环境

另外 DSP 与 ARM 之间通信的协议接口也比较繁复

  • Slide 1
  • Slide 2
  • Slide 3
  • Slide 4
  • Slide 5
  • Slide 6
  • Slide 7
  • Slide 8
  • Slide 9
  • Slide 10
  • Slide 11
  • Slide 12
  • Slide 13
  • Slide 14
  • Slide 15
  • Slide 16
  • Slide 17
  • Slide 18
  • Slide 19
  • Slide 20
  • Slide 21
  • Slide 22
  • Slide 23
  • Slide 24
  • Slide 25
  • Slide 26
  • Slide 27
  • Slide 28
  • Slide 29
  • Slide 30
  • Slide 31
  • Slide 32
  • Slide 33
Page 4: 达芬奇平台简要介绍 汇报人:朱军 (控制组)

如下图可以很清楚的看到 ARM 可以访问 DSP 片内存储器( L2RAM 和 L1D L1P )DSP 可以访问 ARM 片内存储器 ARM 和 DSP 共享 DDR2 和 AEMIF

ARM 可以中断 DSP ( 4 个通用中断和 1 个不可屏蔽中断) DSP 可以中断 ARM ( 2 个通用中断) ARM 控制 DSP 的电源时钟复位和引导

DM6446 的初始化顺序

1 DM6446 复位 芯片的配置由 PSC 决定取决于 BTSEL[03] EM_WIDTH AEWA 和 DSP_B

T 的状态

2 ROM Boot Loader (如果被选) NAND 和 UART0 的初始化

3 引导加载 以 U-BOOT 为例 ( 1 )使能电源域 DDR2 和 DSP ( 2 )设置时钟频率( ARM DSP 和 DDR2 时钟乘除系数) ( 3 )设置引脚复用控制器 ( 4 )设置 ARM 引导启动操作系统

4 操作系统启动 以 LINUX 为例 ( 1 )初始化 ARM ( 2 )初始化硬件系统 ( 3 )初始化 LINUX 环境

软件架构 ARM + DSP

1048715ARM 为主处理器用户应用程序在 ARM 实现1048766 移植操作系统 OS LINUX WinCEhelliphellip

1048766 用户用下列 3 个 APIs 来构建自己的应用程序

1048715EPSI Easy Peripheral Software Interface 设备驱动程序1048715VISA Video Imaging Speech Audio 应用层音视频编解码引擎接口1048715xDM xDAISfor Digital Media 具体的音视频编解码算法接口由 VISA 调用

1048715DSP 为从处理器主要用来实现视频图像处理1048715 ARM 与 DSP 之间用 DSPBIOS LINK 来通信

1048715 DSP 主要用来实现视频图像编解码算法 xDM

操作系统和驱动程序

OS 已移植了基于 MontaVista 内核的 LINUX 2610

EPSI 基于 LINUX 的设备驱动程序1048766 串口 UART IIC SPI1048766 存储 ATA NAND MMC1048766 网络 10100M 以太网1048715USB 海量存储主机端和设备端驱动程序1048766 音频 OSS 音频驱动程序1048766 视频 V4L2 视频采集 FBDevDirectFB 视频显示

Codec Engine 达芬奇技术体系中引入了 Codec Engine 并创建了一整套

的应用开发平台 Codec Engine 为通用处理器 (GPP) 上的开发者提供更为简单的开发环境

Codec Engine 是一系列用于表示和运行数字多媒体标准化DSP 算法接口 (XDAIS) 及算法的 API XDAIS 定义了一整套的多媒体算法编程接口可单独在 GPP 或 DSP 上运行也可在 DSP 上运行而 GPP 通过 Codec Engine 对其实行控制对于所有支持的运算器结构运行方式及操作系统Codec Engine 都有相同的 API Codec Engine 定义了 4类编解码器算法接口标准分别是视频图像语音音频简称 VISA

VISA 1048766 复杂的信号处理层通过音视频编解码引擎和 VISA API 进行抽象

1048715VISA API 是音视频编解码的用户接口

1048715VISA 用来处理视频 Video 图像 Image 语音 Speech 音频 Audio

1048766 编码与解码的 API 组相互独立所以总有 8 组 API

1048715 VIDENC IMGENC SPHENC AUDENC1048715 VIDDEC IMGDEC SPHDEC AUDDEC

1048766 每个 VISA 组中关键的 API 有

1048715 xxx_create1048715 xxx_process1048715 xxx_control1048715 xxx_delete

Codec Engine 框架分析 Codec Engine 在解决达芬奇双处理器架构问题时首

先引入了远程过程控制 (RPC) 的概念 RPC 是指在另一个处理器上远程执行一个命令或过程 RPC有客户端和服务端客户端通过某种通信协议并最终通过物理链路向服务端发送一个命令服务端执行命令并通过相应的通信方式将结果返回给客户端

达芬奇 DM6446 芯片将 ARM 作为客户端 DSP 作为服务端两者之间的物理链路就是两个处理器之间共享的 DDR2 存储器而将物理链路上的通信协议称为 DSPLink

下图给出了这种框架的结构示意图图中共享 DDR2 存储器是 ARM与 DSP 之间共享的内存通过它进行物理数据的交换 DSPLink 是达芬奇架构双处理器间通信的基础软件为开发人员提供了一个通用的 API 用于描述 ARM 与 DSP 之间通信的物理链路的特征引擎功能层用于管理算法对象的实例例如创建一个对象的具体过程等 VISA 层是面向引擎功能层的一个接口用于定义创建删除和使用一个特定符合 XDM(XDAIS 的扩展专用于多媒体应用 ) 标准的算法的进程由于Codec Engine 的主要任务是为从 ARM 发起的 VISA 命令控制远程的 XDM 算法起到一个管道的作用因此 VISA 层实际上就是代表了 XDM 接口层

一般来讲软件系统分为应用层信号处理层和 IO 层三部分 TI 提供的达芬奇参考软件框架就是基于这样的结构如图所示 Davinci 的应用工程师可以在系统的用户空间在系统功能性上添加和发挥自己的特色信号处理层通常都运行在 DSP 一侧负责信号处理包括音视频编解码算法 Codec Engine DSP 的实时操作系统 DSPBIOS 及和 ARM通信的模块 IO 层就是我们通常所说的驱动是针对 Davinci 外设模块的驱动程序

其中应用层通过 Codec Engine 的 VISA(Video Image Speech Audio)API 来调用 DSP侧的算法通过 EPSI(Easy Peripheral Software Interface)API 来访问和操作 Davinci 的外设

如下图所示 DaVinci 的软件开发通常需要四个步骤

前面我们提到应用工程师通过调用 Codec Engine 的 API来调用和运行符合 xDAIS 的算法在 Davinci 软件中符合xDAIS 的音视频编解码算法 (即 xDM 算法 ) 的调用是通过 Codec Engine 的 VISA API完成的 Codec Engine 通过这套API 为算法的执行提供了一个标准的软件架构和接口

Codec Engine 是介于应用程序和具体算法之间的软件模块其中的 VISA API 通过 stub 和 skeleton 访问 Engine SPI 最终调用具体的算法因此 Codec Engine 的工作是通过完成 VISA API 的任务来体现的 VISA API 分为四部分 VISA createcontrolprocessdelete 我们以 codec 算法运行在 DSP 为例通过 VISA API 的执行过程了解 Codec Engine 的工作原理

在调用 VISA API 之前需要在应用程序中通过 Engine_open()这个 Engine API把 DSP 的可执行程序加载到 DSP 的 memory 同时把 DSP 从复位状态释放这时 DSP 开始运行DSP Server 的初始化程序在 DSP侧创建一个优先级最低的任务 RMS(Remote Management Server) RMS负责管理和维护对应到具体 codec 算法的 Instances 应用程序调用VISA create API 相应的 VISA create函数到 Engine SPI中的 Codec table 中查到这个 codec 运行在远端 DSP侧

接着 Engine SPI 通过 OSAL(Operating System Abstraction

Layer) DSP Link把 VISA create 的命令传到 DSP侧的 RMS RMS 通过 DSP侧 Engine SPI 的 codec table找到要调用的 codec 算法后就会在 RMS 中创建一个相应的 Instance(即一个 DSPBIOS 系统中的任务 ) VISA create会返回一个 Instance 的 Handle 以便于给这个 Instance做后续的 VISA controlprocessdelete 提供信息 VISA delete 和VISA create原理类似只是 RMS删除掉相应的 codec 算法的 Instance 和执行 codec 算法的任务

概括来说 VISA control 用来动态的修改 codec instance 的属性 VISA process 用来对算法的输入数据流做处理并返回一个输出数据流如下图所示应用程序在调用 VISA processcontrol 时会通过 xDM Stub把传递给 codec 算法的参数收集起来并且转换成 DSP 可以识别的物理地址 Stub把这些参数和相关的命令通过 Engine SPI OSAL 和 DSP Link传递到 DSP侧的 Instance Instance再通过 Skeleton把传递过来的参数和命令解析出来通过 DSP侧 VISA controlprocess 对 codec 算法执行 controlprocess

算法创建第一步需要基于 DSP利用 CCS 开发自己的音视

频编解码算法编译生成一个编解码算法的库文件lib(等同于 Linux 环境下的 a64P 直接在 Linux环境下修改文件后缀名即可 ) 由于需要确保算法可被 Codec Engine 使用和配置所以要确保这些算法实现需要符合 xDM(xDAIS(eXpress DSP Algorithm Interface Standard) for Digital Media) 标准

如果算法与 XDM 标准兼容 则可不经修改而直接被 Codec Engine 的 VISA API 远程执行如不兼容则需为其提供 Codec Engine 的框架和终端接口

服务集成 第二步生成一个在 DSP 上运行的可执行程序 x64P(即 out文件 ) 也就是 DSP Server

由于在双核环境中 Codec Engine 是在 DM6446 中的 DSP上执行而操作系统是由 DM6446 中的 ARM 通过 VISA API控制 Codec Engine 所以必须先在远程的 DSP生成一个 Codec Server Codec Server 是后缀为 x64P 的文件是一个集成了编解码器框架元件和系统代码的二进制库

在达芬奇 DM6446 平台中 Codec Server包含了一个为相应客户端 (ARM)生成编解码器提供系统运行信息 (包括指令和内存使用情况 ) 的 DSP BIOS任务线程客户端 (ARM) 的应用程序通过使用 VISA API 与在远程 DSP 上的编解码器联系

引擎集成第三步通过配置工具做大量的关于引擎配置的工

作包括引擎的名字每个引擎中包含什么编解码器编解码器是本地执行还是远程执行等如果这些编解码器在远程执行的则还需配置相应的 Codec Server 一般将所有的配置写到一个 cfg文件里面

这个配置文件包含的内容有 Codec Engine 运行的系统环境包括 xDC 通用模块和客户端操作系统类型等指明 Codec Engine需要用到的编解码器模块配置 Codec Engine 指明 Engine包含的内容

引擎引用 第四步应用工程师利用 Coedc Engine 的应用编程接口创

建删除配置好的引擎实例进而创建删除和控制编解码器由于 Codec Engine 不参与任何的 IO 操作只是纯粹的视频编解码算法处理因此应用工程师需要管理 IO 包括文件操作 (文件的打开读写与存储等 ) 和外设操作 ( 外设的打开关闭与控制等 )

应用工程师负责编写应用代码并将合适的内容加到最终的可执行文件中去应用工程师可使用以下资源从算法开发工程师得到的大量的编解码器软件包从服务集成工程师得到一个可以在 DSP 上运行的 Codec Server二进制文件一般为 x64P文件从引擎集成工程师得到一个引擎配置文件一般为 cfg文件应用工程师编写应用代码并结合这些资源再链接编译生成最终的可执行代码

虽然达芬奇技术带来了全新的开发平台和研发理念但是作为一项尚处于发展初期的技术仍然可能存在一些问题

首先是视频硬件加速器 VICP 的使用细节没有公开只有少数第三方厂商才能了解如何使用视频硬件加速器因此其他厂商开发 Codec 的难度就非常大

另外由于 DSP 与 ARM 双核结构的开发环境非常复杂 目前尚无一个完全集成 DSP 与 ARM 调试环境的集成开发环境因此需要同时进行 DSP 和 ARM 软件的跟踪调试必须运行两个独立的集成开发环境

另外 DSP 与 ARM 之间通信的协议接口也比较繁复

  • Slide 1
  • Slide 2
  • Slide 3
  • Slide 4
  • Slide 5
  • Slide 6
  • Slide 7
  • Slide 8
  • Slide 9
  • Slide 10
  • Slide 11
  • Slide 12
  • Slide 13
  • Slide 14
  • Slide 15
  • Slide 16
  • Slide 17
  • Slide 18
  • Slide 19
  • Slide 20
  • Slide 21
  • Slide 22
  • Slide 23
  • Slide 24
  • Slide 25
  • Slide 26
  • Slide 27
  • Slide 28
  • Slide 29
  • Slide 30
  • Slide 31
  • Slide 32
  • Slide 33
Page 5: 达芬奇平台简要介绍 汇报人:朱军 (控制组)

DM6446 的初始化顺序

1 DM6446 复位 芯片的配置由 PSC 决定取决于 BTSEL[03] EM_WIDTH AEWA 和 DSP_B

T 的状态

2 ROM Boot Loader (如果被选) NAND 和 UART0 的初始化

3 引导加载 以 U-BOOT 为例 ( 1 )使能电源域 DDR2 和 DSP ( 2 )设置时钟频率( ARM DSP 和 DDR2 时钟乘除系数) ( 3 )设置引脚复用控制器 ( 4 )设置 ARM 引导启动操作系统

4 操作系统启动 以 LINUX 为例 ( 1 )初始化 ARM ( 2 )初始化硬件系统 ( 3 )初始化 LINUX 环境

软件架构 ARM + DSP

1048715ARM 为主处理器用户应用程序在 ARM 实现1048766 移植操作系统 OS LINUX WinCEhelliphellip

1048766 用户用下列 3 个 APIs 来构建自己的应用程序

1048715EPSI Easy Peripheral Software Interface 设备驱动程序1048715VISA Video Imaging Speech Audio 应用层音视频编解码引擎接口1048715xDM xDAISfor Digital Media 具体的音视频编解码算法接口由 VISA 调用

1048715DSP 为从处理器主要用来实现视频图像处理1048715 ARM 与 DSP 之间用 DSPBIOS LINK 来通信

1048715 DSP 主要用来实现视频图像编解码算法 xDM

操作系统和驱动程序

OS 已移植了基于 MontaVista 内核的 LINUX 2610

EPSI 基于 LINUX 的设备驱动程序1048766 串口 UART IIC SPI1048766 存储 ATA NAND MMC1048766 网络 10100M 以太网1048715USB 海量存储主机端和设备端驱动程序1048766 音频 OSS 音频驱动程序1048766 视频 V4L2 视频采集 FBDevDirectFB 视频显示

Codec Engine 达芬奇技术体系中引入了 Codec Engine 并创建了一整套

的应用开发平台 Codec Engine 为通用处理器 (GPP) 上的开发者提供更为简单的开发环境

Codec Engine 是一系列用于表示和运行数字多媒体标准化DSP 算法接口 (XDAIS) 及算法的 API XDAIS 定义了一整套的多媒体算法编程接口可单独在 GPP 或 DSP 上运行也可在 DSP 上运行而 GPP 通过 Codec Engine 对其实行控制对于所有支持的运算器结构运行方式及操作系统Codec Engine 都有相同的 API Codec Engine 定义了 4类编解码器算法接口标准分别是视频图像语音音频简称 VISA

VISA 1048766 复杂的信号处理层通过音视频编解码引擎和 VISA API 进行抽象

1048715VISA API 是音视频编解码的用户接口

1048715VISA 用来处理视频 Video 图像 Image 语音 Speech 音频 Audio

1048766 编码与解码的 API 组相互独立所以总有 8 组 API

1048715 VIDENC IMGENC SPHENC AUDENC1048715 VIDDEC IMGDEC SPHDEC AUDDEC

1048766 每个 VISA 组中关键的 API 有

1048715 xxx_create1048715 xxx_process1048715 xxx_control1048715 xxx_delete

Codec Engine 框架分析 Codec Engine 在解决达芬奇双处理器架构问题时首

先引入了远程过程控制 (RPC) 的概念 RPC 是指在另一个处理器上远程执行一个命令或过程 RPC有客户端和服务端客户端通过某种通信协议并最终通过物理链路向服务端发送一个命令服务端执行命令并通过相应的通信方式将结果返回给客户端

达芬奇 DM6446 芯片将 ARM 作为客户端 DSP 作为服务端两者之间的物理链路就是两个处理器之间共享的 DDR2 存储器而将物理链路上的通信协议称为 DSPLink

下图给出了这种框架的结构示意图图中共享 DDR2 存储器是 ARM与 DSP 之间共享的内存通过它进行物理数据的交换 DSPLink 是达芬奇架构双处理器间通信的基础软件为开发人员提供了一个通用的 API 用于描述 ARM 与 DSP 之间通信的物理链路的特征引擎功能层用于管理算法对象的实例例如创建一个对象的具体过程等 VISA 层是面向引擎功能层的一个接口用于定义创建删除和使用一个特定符合 XDM(XDAIS 的扩展专用于多媒体应用 ) 标准的算法的进程由于Codec Engine 的主要任务是为从 ARM 发起的 VISA 命令控制远程的 XDM 算法起到一个管道的作用因此 VISA 层实际上就是代表了 XDM 接口层

一般来讲软件系统分为应用层信号处理层和 IO 层三部分 TI 提供的达芬奇参考软件框架就是基于这样的结构如图所示 Davinci 的应用工程师可以在系统的用户空间在系统功能性上添加和发挥自己的特色信号处理层通常都运行在 DSP 一侧负责信号处理包括音视频编解码算法 Codec Engine DSP 的实时操作系统 DSPBIOS 及和 ARM通信的模块 IO 层就是我们通常所说的驱动是针对 Davinci 外设模块的驱动程序

其中应用层通过 Codec Engine 的 VISA(Video Image Speech Audio)API 来调用 DSP侧的算法通过 EPSI(Easy Peripheral Software Interface)API 来访问和操作 Davinci 的外设

如下图所示 DaVinci 的软件开发通常需要四个步骤

前面我们提到应用工程师通过调用 Codec Engine 的 API来调用和运行符合 xDAIS 的算法在 Davinci 软件中符合xDAIS 的音视频编解码算法 (即 xDM 算法 ) 的调用是通过 Codec Engine 的 VISA API完成的 Codec Engine 通过这套API 为算法的执行提供了一个标准的软件架构和接口

Codec Engine 是介于应用程序和具体算法之间的软件模块其中的 VISA API 通过 stub 和 skeleton 访问 Engine SPI 最终调用具体的算法因此 Codec Engine 的工作是通过完成 VISA API 的任务来体现的 VISA API 分为四部分 VISA createcontrolprocessdelete 我们以 codec 算法运行在 DSP 为例通过 VISA API 的执行过程了解 Codec Engine 的工作原理

在调用 VISA API 之前需要在应用程序中通过 Engine_open()这个 Engine API把 DSP 的可执行程序加载到 DSP 的 memory 同时把 DSP 从复位状态释放这时 DSP 开始运行DSP Server 的初始化程序在 DSP侧创建一个优先级最低的任务 RMS(Remote Management Server) RMS负责管理和维护对应到具体 codec 算法的 Instances 应用程序调用VISA create API 相应的 VISA create函数到 Engine SPI中的 Codec table 中查到这个 codec 运行在远端 DSP侧

接着 Engine SPI 通过 OSAL(Operating System Abstraction

Layer) DSP Link把 VISA create 的命令传到 DSP侧的 RMS RMS 通过 DSP侧 Engine SPI 的 codec table找到要调用的 codec 算法后就会在 RMS 中创建一个相应的 Instance(即一个 DSPBIOS 系统中的任务 ) VISA create会返回一个 Instance 的 Handle 以便于给这个 Instance做后续的 VISA controlprocessdelete 提供信息 VISA delete 和VISA create原理类似只是 RMS删除掉相应的 codec 算法的 Instance 和执行 codec 算法的任务

概括来说 VISA control 用来动态的修改 codec instance 的属性 VISA process 用来对算法的输入数据流做处理并返回一个输出数据流如下图所示应用程序在调用 VISA processcontrol 时会通过 xDM Stub把传递给 codec 算法的参数收集起来并且转换成 DSP 可以识别的物理地址 Stub把这些参数和相关的命令通过 Engine SPI OSAL 和 DSP Link传递到 DSP侧的 Instance Instance再通过 Skeleton把传递过来的参数和命令解析出来通过 DSP侧 VISA controlprocess 对 codec 算法执行 controlprocess

算法创建第一步需要基于 DSP利用 CCS 开发自己的音视

频编解码算法编译生成一个编解码算法的库文件lib(等同于 Linux 环境下的 a64P 直接在 Linux环境下修改文件后缀名即可 ) 由于需要确保算法可被 Codec Engine 使用和配置所以要确保这些算法实现需要符合 xDM(xDAIS(eXpress DSP Algorithm Interface Standard) for Digital Media) 标准

如果算法与 XDM 标准兼容 则可不经修改而直接被 Codec Engine 的 VISA API 远程执行如不兼容则需为其提供 Codec Engine 的框架和终端接口

服务集成 第二步生成一个在 DSP 上运行的可执行程序 x64P(即 out文件 ) 也就是 DSP Server

由于在双核环境中 Codec Engine 是在 DM6446 中的 DSP上执行而操作系统是由 DM6446 中的 ARM 通过 VISA API控制 Codec Engine 所以必须先在远程的 DSP生成一个 Codec Server Codec Server 是后缀为 x64P 的文件是一个集成了编解码器框架元件和系统代码的二进制库

在达芬奇 DM6446 平台中 Codec Server包含了一个为相应客户端 (ARM)生成编解码器提供系统运行信息 (包括指令和内存使用情况 ) 的 DSP BIOS任务线程客户端 (ARM) 的应用程序通过使用 VISA API 与在远程 DSP 上的编解码器联系

引擎集成第三步通过配置工具做大量的关于引擎配置的工

作包括引擎的名字每个引擎中包含什么编解码器编解码器是本地执行还是远程执行等如果这些编解码器在远程执行的则还需配置相应的 Codec Server 一般将所有的配置写到一个 cfg文件里面

这个配置文件包含的内容有 Codec Engine 运行的系统环境包括 xDC 通用模块和客户端操作系统类型等指明 Codec Engine需要用到的编解码器模块配置 Codec Engine 指明 Engine包含的内容

引擎引用 第四步应用工程师利用 Coedc Engine 的应用编程接口创

建删除配置好的引擎实例进而创建删除和控制编解码器由于 Codec Engine 不参与任何的 IO 操作只是纯粹的视频编解码算法处理因此应用工程师需要管理 IO 包括文件操作 (文件的打开读写与存储等 ) 和外设操作 ( 外设的打开关闭与控制等 )

应用工程师负责编写应用代码并将合适的内容加到最终的可执行文件中去应用工程师可使用以下资源从算法开发工程师得到的大量的编解码器软件包从服务集成工程师得到一个可以在 DSP 上运行的 Codec Server二进制文件一般为 x64P文件从引擎集成工程师得到一个引擎配置文件一般为 cfg文件应用工程师编写应用代码并结合这些资源再链接编译生成最终的可执行代码

虽然达芬奇技术带来了全新的开发平台和研发理念但是作为一项尚处于发展初期的技术仍然可能存在一些问题

首先是视频硬件加速器 VICP 的使用细节没有公开只有少数第三方厂商才能了解如何使用视频硬件加速器因此其他厂商开发 Codec 的难度就非常大

另外由于 DSP 与 ARM 双核结构的开发环境非常复杂 目前尚无一个完全集成 DSP 与 ARM 调试环境的集成开发环境因此需要同时进行 DSP 和 ARM 软件的跟踪调试必须运行两个独立的集成开发环境

另外 DSP 与 ARM 之间通信的协议接口也比较繁复

  • Slide 1
  • Slide 2
  • Slide 3
  • Slide 4
  • Slide 5
  • Slide 6
  • Slide 7
  • Slide 8
  • Slide 9
  • Slide 10
  • Slide 11
  • Slide 12
  • Slide 13
  • Slide 14
  • Slide 15
  • Slide 16
  • Slide 17
  • Slide 18
  • Slide 19
  • Slide 20
  • Slide 21
  • Slide 22
  • Slide 23
  • Slide 24
  • Slide 25
  • Slide 26
  • Slide 27
  • Slide 28
  • Slide 29
  • Slide 30
  • Slide 31
  • Slide 32
  • Slide 33
Page 6: 达芬奇平台简要介绍 汇报人:朱军 (控制组)

软件架构 ARM + DSP

1048715ARM 为主处理器用户应用程序在 ARM 实现1048766 移植操作系统 OS LINUX WinCEhelliphellip

1048766 用户用下列 3 个 APIs 来构建自己的应用程序

1048715EPSI Easy Peripheral Software Interface 设备驱动程序1048715VISA Video Imaging Speech Audio 应用层音视频编解码引擎接口1048715xDM xDAISfor Digital Media 具体的音视频编解码算法接口由 VISA 调用

1048715DSP 为从处理器主要用来实现视频图像处理1048715 ARM 与 DSP 之间用 DSPBIOS LINK 来通信

1048715 DSP 主要用来实现视频图像编解码算法 xDM

操作系统和驱动程序

OS 已移植了基于 MontaVista 内核的 LINUX 2610

EPSI 基于 LINUX 的设备驱动程序1048766 串口 UART IIC SPI1048766 存储 ATA NAND MMC1048766 网络 10100M 以太网1048715USB 海量存储主机端和设备端驱动程序1048766 音频 OSS 音频驱动程序1048766 视频 V4L2 视频采集 FBDevDirectFB 视频显示

Codec Engine 达芬奇技术体系中引入了 Codec Engine 并创建了一整套

的应用开发平台 Codec Engine 为通用处理器 (GPP) 上的开发者提供更为简单的开发环境

Codec Engine 是一系列用于表示和运行数字多媒体标准化DSP 算法接口 (XDAIS) 及算法的 API XDAIS 定义了一整套的多媒体算法编程接口可单独在 GPP 或 DSP 上运行也可在 DSP 上运行而 GPP 通过 Codec Engine 对其实行控制对于所有支持的运算器结构运行方式及操作系统Codec Engine 都有相同的 API Codec Engine 定义了 4类编解码器算法接口标准分别是视频图像语音音频简称 VISA

VISA 1048766 复杂的信号处理层通过音视频编解码引擎和 VISA API 进行抽象

1048715VISA API 是音视频编解码的用户接口

1048715VISA 用来处理视频 Video 图像 Image 语音 Speech 音频 Audio

1048766 编码与解码的 API 组相互独立所以总有 8 组 API

1048715 VIDENC IMGENC SPHENC AUDENC1048715 VIDDEC IMGDEC SPHDEC AUDDEC

1048766 每个 VISA 组中关键的 API 有

1048715 xxx_create1048715 xxx_process1048715 xxx_control1048715 xxx_delete

Codec Engine 框架分析 Codec Engine 在解决达芬奇双处理器架构问题时首

先引入了远程过程控制 (RPC) 的概念 RPC 是指在另一个处理器上远程执行一个命令或过程 RPC有客户端和服务端客户端通过某种通信协议并最终通过物理链路向服务端发送一个命令服务端执行命令并通过相应的通信方式将结果返回给客户端

达芬奇 DM6446 芯片将 ARM 作为客户端 DSP 作为服务端两者之间的物理链路就是两个处理器之间共享的 DDR2 存储器而将物理链路上的通信协议称为 DSPLink

下图给出了这种框架的结构示意图图中共享 DDR2 存储器是 ARM与 DSP 之间共享的内存通过它进行物理数据的交换 DSPLink 是达芬奇架构双处理器间通信的基础软件为开发人员提供了一个通用的 API 用于描述 ARM 与 DSP 之间通信的物理链路的特征引擎功能层用于管理算法对象的实例例如创建一个对象的具体过程等 VISA 层是面向引擎功能层的一个接口用于定义创建删除和使用一个特定符合 XDM(XDAIS 的扩展专用于多媒体应用 ) 标准的算法的进程由于Codec Engine 的主要任务是为从 ARM 发起的 VISA 命令控制远程的 XDM 算法起到一个管道的作用因此 VISA 层实际上就是代表了 XDM 接口层

一般来讲软件系统分为应用层信号处理层和 IO 层三部分 TI 提供的达芬奇参考软件框架就是基于这样的结构如图所示 Davinci 的应用工程师可以在系统的用户空间在系统功能性上添加和发挥自己的特色信号处理层通常都运行在 DSP 一侧负责信号处理包括音视频编解码算法 Codec Engine DSP 的实时操作系统 DSPBIOS 及和 ARM通信的模块 IO 层就是我们通常所说的驱动是针对 Davinci 外设模块的驱动程序

其中应用层通过 Codec Engine 的 VISA(Video Image Speech Audio)API 来调用 DSP侧的算法通过 EPSI(Easy Peripheral Software Interface)API 来访问和操作 Davinci 的外设

如下图所示 DaVinci 的软件开发通常需要四个步骤

前面我们提到应用工程师通过调用 Codec Engine 的 API来调用和运行符合 xDAIS 的算法在 Davinci 软件中符合xDAIS 的音视频编解码算法 (即 xDM 算法 ) 的调用是通过 Codec Engine 的 VISA API完成的 Codec Engine 通过这套API 为算法的执行提供了一个标准的软件架构和接口

Codec Engine 是介于应用程序和具体算法之间的软件模块其中的 VISA API 通过 stub 和 skeleton 访问 Engine SPI 最终调用具体的算法因此 Codec Engine 的工作是通过完成 VISA API 的任务来体现的 VISA API 分为四部分 VISA createcontrolprocessdelete 我们以 codec 算法运行在 DSP 为例通过 VISA API 的执行过程了解 Codec Engine 的工作原理

在调用 VISA API 之前需要在应用程序中通过 Engine_open()这个 Engine API把 DSP 的可执行程序加载到 DSP 的 memory 同时把 DSP 从复位状态释放这时 DSP 开始运行DSP Server 的初始化程序在 DSP侧创建一个优先级最低的任务 RMS(Remote Management Server) RMS负责管理和维护对应到具体 codec 算法的 Instances 应用程序调用VISA create API 相应的 VISA create函数到 Engine SPI中的 Codec table 中查到这个 codec 运行在远端 DSP侧

接着 Engine SPI 通过 OSAL(Operating System Abstraction

Layer) DSP Link把 VISA create 的命令传到 DSP侧的 RMS RMS 通过 DSP侧 Engine SPI 的 codec table找到要调用的 codec 算法后就会在 RMS 中创建一个相应的 Instance(即一个 DSPBIOS 系统中的任务 ) VISA create会返回一个 Instance 的 Handle 以便于给这个 Instance做后续的 VISA controlprocessdelete 提供信息 VISA delete 和VISA create原理类似只是 RMS删除掉相应的 codec 算法的 Instance 和执行 codec 算法的任务

概括来说 VISA control 用来动态的修改 codec instance 的属性 VISA process 用来对算法的输入数据流做处理并返回一个输出数据流如下图所示应用程序在调用 VISA processcontrol 时会通过 xDM Stub把传递给 codec 算法的参数收集起来并且转换成 DSP 可以识别的物理地址 Stub把这些参数和相关的命令通过 Engine SPI OSAL 和 DSP Link传递到 DSP侧的 Instance Instance再通过 Skeleton把传递过来的参数和命令解析出来通过 DSP侧 VISA controlprocess 对 codec 算法执行 controlprocess

算法创建第一步需要基于 DSP利用 CCS 开发自己的音视

频编解码算法编译生成一个编解码算法的库文件lib(等同于 Linux 环境下的 a64P 直接在 Linux环境下修改文件后缀名即可 ) 由于需要确保算法可被 Codec Engine 使用和配置所以要确保这些算法实现需要符合 xDM(xDAIS(eXpress DSP Algorithm Interface Standard) for Digital Media) 标准

如果算法与 XDM 标准兼容 则可不经修改而直接被 Codec Engine 的 VISA API 远程执行如不兼容则需为其提供 Codec Engine 的框架和终端接口

服务集成 第二步生成一个在 DSP 上运行的可执行程序 x64P(即 out文件 ) 也就是 DSP Server

由于在双核环境中 Codec Engine 是在 DM6446 中的 DSP上执行而操作系统是由 DM6446 中的 ARM 通过 VISA API控制 Codec Engine 所以必须先在远程的 DSP生成一个 Codec Server Codec Server 是后缀为 x64P 的文件是一个集成了编解码器框架元件和系统代码的二进制库

在达芬奇 DM6446 平台中 Codec Server包含了一个为相应客户端 (ARM)生成编解码器提供系统运行信息 (包括指令和内存使用情况 ) 的 DSP BIOS任务线程客户端 (ARM) 的应用程序通过使用 VISA API 与在远程 DSP 上的编解码器联系

引擎集成第三步通过配置工具做大量的关于引擎配置的工

作包括引擎的名字每个引擎中包含什么编解码器编解码器是本地执行还是远程执行等如果这些编解码器在远程执行的则还需配置相应的 Codec Server 一般将所有的配置写到一个 cfg文件里面

这个配置文件包含的内容有 Codec Engine 运行的系统环境包括 xDC 通用模块和客户端操作系统类型等指明 Codec Engine需要用到的编解码器模块配置 Codec Engine 指明 Engine包含的内容

引擎引用 第四步应用工程师利用 Coedc Engine 的应用编程接口创

建删除配置好的引擎实例进而创建删除和控制编解码器由于 Codec Engine 不参与任何的 IO 操作只是纯粹的视频编解码算法处理因此应用工程师需要管理 IO 包括文件操作 (文件的打开读写与存储等 ) 和外设操作 ( 外设的打开关闭与控制等 )

应用工程师负责编写应用代码并将合适的内容加到最终的可执行文件中去应用工程师可使用以下资源从算法开发工程师得到的大量的编解码器软件包从服务集成工程师得到一个可以在 DSP 上运行的 Codec Server二进制文件一般为 x64P文件从引擎集成工程师得到一个引擎配置文件一般为 cfg文件应用工程师编写应用代码并结合这些资源再链接编译生成最终的可执行代码

虽然达芬奇技术带来了全新的开发平台和研发理念但是作为一项尚处于发展初期的技术仍然可能存在一些问题

首先是视频硬件加速器 VICP 的使用细节没有公开只有少数第三方厂商才能了解如何使用视频硬件加速器因此其他厂商开发 Codec 的难度就非常大

另外由于 DSP 与 ARM 双核结构的开发环境非常复杂 目前尚无一个完全集成 DSP 与 ARM 调试环境的集成开发环境因此需要同时进行 DSP 和 ARM 软件的跟踪调试必须运行两个独立的集成开发环境

另外 DSP 与 ARM 之间通信的协议接口也比较繁复

  • Slide 1
  • Slide 2
  • Slide 3
  • Slide 4
  • Slide 5
  • Slide 6
  • Slide 7
  • Slide 8
  • Slide 9
  • Slide 10
  • Slide 11
  • Slide 12
  • Slide 13
  • Slide 14
  • Slide 15
  • Slide 16
  • Slide 17
  • Slide 18
  • Slide 19
  • Slide 20
  • Slide 21
  • Slide 22
  • Slide 23
  • Slide 24
  • Slide 25
  • Slide 26
  • Slide 27
  • Slide 28
  • Slide 29
  • Slide 30
  • Slide 31
  • Slide 32
  • Slide 33
Page 7: 达芬奇平台简要介绍 汇报人:朱军 (控制组)

操作系统和驱动程序

OS 已移植了基于 MontaVista 内核的 LINUX 2610

EPSI 基于 LINUX 的设备驱动程序1048766 串口 UART IIC SPI1048766 存储 ATA NAND MMC1048766 网络 10100M 以太网1048715USB 海量存储主机端和设备端驱动程序1048766 音频 OSS 音频驱动程序1048766 视频 V4L2 视频采集 FBDevDirectFB 视频显示

Codec Engine 达芬奇技术体系中引入了 Codec Engine 并创建了一整套

的应用开发平台 Codec Engine 为通用处理器 (GPP) 上的开发者提供更为简单的开发环境

Codec Engine 是一系列用于表示和运行数字多媒体标准化DSP 算法接口 (XDAIS) 及算法的 API XDAIS 定义了一整套的多媒体算法编程接口可单独在 GPP 或 DSP 上运行也可在 DSP 上运行而 GPP 通过 Codec Engine 对其实行控制对于所有支持的运算器结构运行方式及操作系统Codec Engine 都有相同的 API Codec Engine 定义了 4类编解码器算法接口标准分别是视频图像语音音频简称 VISA

VISA 1048766 复杂的信号处理层通过音视频编解码引擎和 VISA API 进行抽象

1048715VISA API 是音视频编解码的用户接口

1048715VISA 用来处理视频 Video 图像 Image 语音 Speech 音频 Audio

1048766 编码与解码的 API 组相互独立所以总有 8 组 API

1048715 VIDENC IMGENC SPHENC AUDENC1048715 VIDDEC IMGDEC SPHDEC AUDDEC

1048766 每个 VISA 组中关键的 API 有

1048715 xxx_create1048715 xxx_process1048715 xxx_control1048715 xxx_delete

Codec Engine 框架分析 Codec Engine 在解决达芬奇双处理器架构问题时首

先引入了远程过程控制 (RPC) 的概念 RPC 是指在另一个处理器上远程执行一个命令或过程 RPC有客户端和服务端客户端通过某种通信协议并最终通过物理链路向服务端发送一个命令服务端执行命令并通过相应的通信方式将结果返回给客户端

达芬奇 DM6446 芯片将 ARM 作为客户端 DSP 作为服务端两者之间的物理链路就是两个处理器之间共享的 DDR2 存储器而将物理链路上的通信协议称为 DSPLink

下图给出了这种框架的结构示意图图中共享 DDR2 存储器是 ARM与 DSP 之间共享的内存通过它进行物理数据的交换 DSPLink 是达芬奇架构双处理器间通信的基础软件为开发人员提供了一个通用的 API 用于描述 ARM 与 DSP 之间通信的物理链路的特征引擎功能层用于管理算法对象的实例例如创建一个对象的具体过程等 VISA 层是面向引擎功能层的一个接口用于定义创建删除和使用一个特定符合 XDM(XDAIS 的扩展专用于多媒体应用 ) 标准的算法的进程由于Codec Engine 的主要任务是为从 ARM 发起的 VISA 命令控制远程的 XDM 算法起到一个管道的作用因此 VISA 层实际上就是代表了 XDM 接口层

一般来讲软件系统分为应用层信号处理层和 IO 层三部分 TI 提供的达芬奇参考软件框架就是基于这样的结构如图所示 Davinci 的应用工程师可以在系统的用户空间在系统功能性上添加和发挥自己的特色信号处理层通常都运行在 DSP 一侧负责信号处理包括音视频编解码算法 Codec Engine DSP 的实时操作系统 DSPBIOS 及和 ARM通信的模块 IO 层就是我们通常所说的驱动是针对 Davinci 外设模块的驱动程序

其中应用层通过 Codec Engine 的 VISA(Video Image Speech Audio)API 来调用 DSP侧的算法通过 EPSI(Easy Peripheral Software Interface)API 来访问和操作 Davinci 的外设

如下图所示 DaVinci 的软件开发通常需要四个步骤

前面我们提到应用工程师通过调用 Codec Engine 的 API来调用和运行符合 xDAIS 的算法在 Davinci 软件中符合xDAIS 的音视频编解码算法 (即 xDM 算法 ) 的调用是通过 Codec Engine 的 VISA API完成的 Codec Engine 通过这套API 为算法的执行提供了一个标准的软件架构和接口

Codec Engine 是介于应用程序和具体算法之间的软件模块其中的 VISA API 通过 stub 和 skeleton 访问 Engine SPI 最终调用具体的算法因此 Codec Engine 的工作是通过完成 VISA API 的任务来体现的 VISA API 分为四部分 VISA createcontrolprocessdelete 我们以 codec 算法运行在 DSP 为例通过 VISA API 的执行过程了解 Codec Engine 的工作原理

在调用 VISA API 之前需要在应用程序中通过 Engine_open()这个 Engine API把 DSP 的可执行程序加载到 DSP 的 memory 同时把 DSP 从复位状态释放这时 DSP 开始运行DSP Server 的初始化程序在 DSP侧创建一个优先级最低的任务 RMS(Remote Management Server) RMS负责管理和维护对应到具体 codec 算法的 Instances 应用程序调用VISA create API 相应的 VISA create函数到 Engine SPI中的 Codec table 中查到这个 codec 运行在远端 DSP侧

接着 Engine SPI 通过 OSAL(Operating System Abstraction

Layer) DSP Link把 VISA create 的命令传到 DSP侧的 RMS RMS 通过 DSP侧 Engine SPI 的 codec table找到要调用的 codec 算法后就会在 RMS 中创建一个相应的 Instance(即一个 DSPBIOS 系统中的任务 ) VISA create会返回一个 Instance 的 Handle 以便于给这个 Instance做后续的 VISA controlprocessdelete 提供信息 VISA delete 和VISA create原理类似只是 RMS删除掉相应的 codec 算法的 Instance 和执行 codec 算法的任务

概括来说 VISA control 用来动态的修改 codec instance 的属性 VISA process 用来对算法的输入数据流做处理并返回一个输出数据流如下图所示应用程序在调用 VISA processcontrol 时会通过 xDM Stub把传递给 codec 算法的参数收集起来并且转换成 DSP 可以识别的物理地址 Stub把这些参数和相关的命令通过 Engine SPI OSAL 和 DSP Link传递到 DSP侧的 Instance Instance再通过 Skeleton把传递过来的参数和命令解析出来通过 DSP侧 VISA controlprocess 对 codec 算法执行 controlprocess

算法创建第一步需要基于 DSP利用 CCS 开发自己的音视

频编解码算法编译生成一个编解码算法的库文件lib(等同于 Linux 环境下的 a64P 直接在 Linux环境下修改文件后缀名即可 ) 由于需要确保算法可被 Codec Engine 使用和配置所以要确保这些算法实现需要符合 xDM(xDAIS(eXpress DSP Algorithm Interface Standard) for Digital Media) 标准

如果算法与 XDM 标准兼容 则可不经修改而直接被 Codec Engine 的 VISA API 远程执行如不兼容则需为其提供 Codec Engine 的框架和终端接口

服务集成 第二步生成一个在 DSP 上运行的可执行程序 x64P(即 out文件 ) 也就是 DSP Server

由于在双核环境中 Codec Engine 是在 DM6446 中的 DSP上执行而操作系统是由 DM6446 中的 ARM 通过 VISA API控制 Codec Engine 所以必须先在远程的 DSP生成一个 Codec Server Codec Server 是后缀为 x64P 的文件是一个集成了编解码器框架元件和系统代码的二进制库

在达芬奇 DM6446 平台中 Codec Server包含了一个为相应客户端 (ARM)生成编解码器提供系统运行信息 (包括指令和内存使用情况 ) 的 DSP BIOS任务线程客户端 (ARM) 的应用程序通过使用 VISA API 与在远程 DSP 上的编解码器联系

引擎集成第三步通过配置工具做大量的关于引擎配置的工

作包括引擎的名字每个引擎中包含什么编解码器编解码器是本地执行还是远程执行等如果这些编解码器在远程执行的则还需配置相应的 Codec Server 一般将所有的配置写到一个 cfg文件里面

这个配置文件包含的内容有 Codec Engine 运行的系统环境包括 xDC 通用模块和客户端操作系统类型等指明 Codec Engine需要用到的编解码器模块配置 Codec Engine 指明 Engine包含的内容

引擎引用 第四步应用工程师利用 Coedc Engine 的应用编程接口创

建删除配置好的引擎实例进而创建删除和控制编解码器由于 Codec Engine 不参与任何的 IO 操作只是纯粹的视频编解码算法处理因此应用工程师需要管理 IO 包括文件操作 (文件的打开读写与存储等 ) 和外设操作 ( 外设的打开关闭与控制等 )

应用工程师负责编写应用代码并将合适的内容加到最终的可执行文件中去应用工程师可使用以下资源从算法开发工程师得到的大量的编解码器软件包从服务集成工程师得到一个可以在 DSP 上运行的 Codec Server二进制文件一般为 x64P文件从引擎集成工程师得到一个引擎配置文件一般为 cfg文件应用工程师编写应用代码并结合这些资源再链接编译生成最终的可执行代码

虽然达芬奇技术带来了全新的开发平台和研发理念但是作为一项尚处于发展初期的技术仍然可能存在一些问题

首先是视频硬件加速器 VICP 的使用细节没有公开只有少数第三方厂商才能了解如何使用视频硬件加速器因此其他厂商开发 Codec 的难度就非常大

另外由于 DSP 与 ARM 双核结构的开发环境非常复杂 目前尚无一个完全集成 DSP 与 ARM 调试环境的集成开发环境因此需要同时进行 DSP 和 ARM 软件的跟踪调试必须运行两个独立的集成开发环境

另外 DSP 与 ARM 之间通信的协议接口也比较繁复

  • Slide 1
  • Slide 2
  • Slide 3
  • Slide 4
  • Slide 5
  • Slide 6
  • Slide 7
  • Slide 8
  • Slide 9
  • Slide 10
  • Slide 11
  • Slide 12
  • Slide 13
  • Slide 14
  • Slide 15
  • Slide 16
  • Slide 17
  • Slide 18
  • Slide 19
  • Slide 20
  • Slide 21
  • Slide 22
  • Slide 23
  • Slide 24
  • Slide 25
  • Slide 26
  • Slide 27
  • Slide 28
  • Slide 29
  • Slide 30
  • Slide 31
  • Slide 32
  • Slide 33
Page 8: 达芬奇平台简要介绍 汇报人:朱军 (控制组)

Codec Engine 达芬奇技术体系中引入了 Codec Engine 并创建了一整套

的应用开发平台 Codec Engine 为通用处理器 (GPP) 上的开发者提供更为简单的开发环境

Codec Engine 是一系列用于表示和运行数字多媒体标准化DSP 算法接口 (XDAIS) 及算法的 API XDAIS 定义了一整套的多媒体算法编程接口可单独在 GPP 或 DSP 上运行也可在 DSP 上运行而 GPP 通过 Codec Engine 对其实行控制对于所有支持的运算器结构运行方式及操作系统Codec Engine 都有相同的 API Codec Engine 定义了 4类编解码器算法接口标准分别是视频图像语音音频简称 VISA

VISA 1048766 复杂的信号处理层通过音视频编解码引擎和 VISA API 进行抽象

1048715VISA API 是音视频编解码的用户接口

1048715VISA 用来处理视频 Video 图像 Image 语音 Speech 音频 Audio

1048766 编码与解码的 API 组相互独立所以总有 8 组 API

1048715 VIDENC IMGENC SPHENC AUDENC1048715 VIDDEC IMGDEC SPHDEC AUDDEC

1048766 每个 VISA 组中关键的 API 有

1048715 xxx_create1048715 xxx_process1048715 xxx_control1048715 xxx_delete

Codec Engine 框架分析 Codec Engine 在解决达芬奇双处理器架构问题时首

先引入了远程过程控制 (RPC) 的概念 RPC 是指在另一个处理器上远程执行一个命令或过程 RPC有客户端和服务端客户端通过某种通信协议并最终通过物理链路向服务端发送一个命令服务端执行命令并通过相应的通信方式将结果返回给客户端

达芬奇 DM6446 芯片将 ARM 作为客户端 DSP 作为服务端两者之间的物理链路就是两个处理器之间共享的 DDR2 存储器而将物理链路上的通信协议称为 DSPLink

下图给出了这种框架的结构示意图图中共享 DDR2 存储器是 ARM与 DSP 之间共享的内存通过它进行物理数据的交换 DSPLink 是达芬奇架构双处理器间通信的基础软件为开发人员提供了一个通用的 API 用于描述 ARM 与 DSP 之间通信的物理链路的特征引擎功能层用于管理算法对象的实例例如创建一个对象的具体过程等 VISA 层是面向引擎功能层的一个接口用于定义创建删除和使用一个特定符合 XDM(XDAIS 的扩展专用于多媒体应用 ) 标准的算法的进程由于Codec Engine 的主要任务是为从 ARM 发起的 VISA 命令控制远程的 XDM 算法起到一个管道的作用因此 VISA 层实际上就是代表了 XDM 接口层

一般来讲软件系统分为应用层信号处理层和 IO 层三部分 TI 提供的达芬奇参考软件框架就是基于这样的结构如图所示 Davinci 的应用工程师可以在系统的用户空间在系统功能性上添加和发挥自己的特色信号处理层通常都运行在 DSP 一侧负责信号处理包括音视频编解码算法 Codec Engine DSP 的实时操作系统 DSPBIOS 及和 ARM通信的模块 IO 层就是我们通常所说的驱动是针对 Davinci 外设模块的驱动程序

其中应用层通过 Codec Engine 的 VISA(Video Image Speech Audio)API 来调用 DSP侧的算法通过 EPSI(Easy Peripheral Software Interface)API 来访问和操作 Davinci 的外设

如下图所示 DaVinci 的软件开发通常需要四个步骤

前面我们提到应用工程师通过调用 Codec Engine 的 API来调用和运行符合 xDAIS 的算法在 Davinci 软件中符合xDAIS 的音视频编解码算法 (即 xDM 算法 ) 的调用是通过 Codec Engine 的 VISA API完成的 Codec Engine 通过这套API 为算法的执行提供了一个标准的软件架构和接口

Codec Engine 是介于应用程序和具体算法之间的软件模块其中的 VISA API 通过 stub 和 skeleton 访问 Engine SPI 最终调用具体的算法因此 Codec Engine 的工作是通过完成 VISA API 的任务来体现的 VISA API 分为四部分 VISA createcontrolprocessdelete 我们以 codec 算法运行在 DSP 为例通过 VISA API 的执行过程了解 Codec Engine 的工作原理

在调用 VISA API 之前需要在应用程序中通过 Engine_open()这个 Engine API把 DSP 的可执行程序加载到 DSP 的 memory 同时把 DSP 从复位状态释放这时 DSP 开始运行DSP Server 的初始化程序在 DSP侧创建一个优先级最低的任务 RMS(Remote Management Server) RMS负责管理和维护对应到具体 codec 算法的 Instances 应用程序调用VISA create API 相应的 VISA create函数到 Engine SPI中的 Codec table 中查到这个 codec 运行在远端 DSP侧

接着 Engine SPI 通过 OSAL(Operating System Abstraction

Layer) DSP Link把 VISA create 的命令传到 DSP侧的 RMS RMS 通过 DSP侧 Engine SPI 的 codec table找到要调用的 codec 算法后就会在 RMS 中创建一个相应的 Instance(即一个 DSPBIOS 系统中的任务 ) VISA create会返回一个 Instance 的 Handle 以便于给这个 Instance做后续的 VISA controlprocessdelete 提供信息 VISA delete 和VISA create原理类似只是 RMS删除掉相应的 codec 算法的 Instance 和执行 codec 算法的任务

概括来说 VISA control 用来动态的修改 codec instance 的属性 VISA process 用来对算法的输入数据流做处理并返回一个输出数据流如下图所示应用程序在调用 VISA processcontrol 时会通过 xDM Stub把传递给 codec 算法的参数收集起来并且转换成 DSP 可以识别的物理地址 Stub把这些参数和相关的命令通过 Engine SPI OSAL 和 DSP Link传递到 DSP侧的 Instance Instance再通过 Skeleton把传递过来的参数和命令解析出来通过 DSP侧 VISA controlprocess 对 codec 算法执行 controlprocess

算法创建第一步需要基于 DSP利用 CCS 开发自己的音视

频编解码算法编译生成一个编解码算法的库文件lib(等同于 Linux 环境下的 a64P 直接在 Linux环境下修改文件后缀名即可 ) 由于需要确保算法可被 Codec Engine 使用和配置所以要确保这些算法实现需要符合 xDM(xDAIS(eXpress DSP Algorithm Interface Standard) for Digital Media) 标准

如果算法与 XDM 标准兼容 则可不经修改而直接被 Codec Engine 的 VISA API 远程执行如不兼容则需为其提供 Codec Engine 的框架和终端接口

服务集成 第二步生成一个在 DSP 上运行的可执行程序 x64P(即 out文件 ) 也就是 DSP Server

由于在双核环境中 Codec Engine 是在 DM6446 中的 DSP上执行而操作系统是由 DM6446 中的 ARM 通过 VISA API控制 Codec Engine 所以必须先在远程的 DSP生成一个 Codec Server Codec Server 是后缀为 x64P 的文件是一个集成了编解码器框架元件和系统代码的二进制库

在达芬奇 DM6446 平台中 Codec Server包含了一个为相应客户端 (ARM)生成编解码器提供系统运行信息 (包括指令和内存使用情况 ) 的 DSP BIOS任务线程客户端 (ARM) 的应用程序通过使用 VISA API 与在远程 DSP 上的编解码器联系

引擎集成第三步通过配置工具做大量的关于引擎配置的工

作包括引擎的名字每个引擎中包含什么编解码器编解码器是本地执行还是远程执行等如果这些编解码器在远程执行的则还需配置相应的 Codec Server 一般将所有的配置写到一个 cfg文件里面

这个配置文件包含的内容有 Codec Engine 运行的系统环境包括 xDC 通用模块和客户端操作系统类型等指明 Codec Engine需要用到的编解码器模块配置 Codec Engine 指明 Engine包含的内容

引擎引用 第四步应用工程师利用 Coedc Engine 的应用编程接口创

建删除配置好的引擎实例进而创建删除和控制编解码器由于 Codec Engine 不参与任何的 IO 操作只是纯粹的视频编解码算法处理因此应用工程师需要管理 IO 包括文件操作 (文件的打开读写与存储等 ) 和外设操作 ( 外设的打开关闭与控制等 )

应用工程师负责编写应用代码并将合适的内容加到最终的可执行文件中去应用工程师可使用以下资源从算法开发工程师得到的大量的编解码器软件包从服务集成工程师得到一个可以在 DSP 上运行的 Codec Server二进制文件一般为 x64P文件从引擎集成工程师得到一个引擎配置文件一般为 cfg文件应用工程师编写应用代码并结合这些资源再链接编译生成最终的可执行代码

虽然达芬奇技术带来了全新的开发平台和研发理念但是作为一项尚处于发展初期的技术仍然可能存在一些问题

首先是视频硬件加速器 VICP 的使用细节没有公开只有少数第三方厂商才能了解如何使用视频硬件加速器因此其他厂商开发 Codec 的难度就非常大

另外由于 DSP 与 ARM 双核结构的开发环境非常复杂 目前尚无一个完全集成 DSP 与 ARM 调试环境的集成开发环境因此需要同时进行 DSP 和 ARM 软件的跟踪调试必须运行两个独立的集成开发环境

另外 DSP 与 ARM 之间通信的协议接口也比较繁复

  • Slide 1
  • Slide 2
  • Slide 3
  • Slide 4
  • Slide 5
  • Slide 6
  • Slide 7
  • Slide 8
  • Slide 9
  • Slide 10
  • Slide 11
  • Slide 12
  • Slide 13
  • Slide 14
  • Slide 15
  • Slide 16
  • Slide 17
  • Slide 18
  • Slide 19
  • Slide 20
  • Slide 21
  • Slide 22
  • Slide 23
  • Slide 24
  • Slide 25
  • Slide 26
  • Slide 27
  • Slide 28
  • Slide 29
  • Slide 30
  • Slide 31
  • Slide 32
  • Slide 33
Page 9: 达芬奇平台简要介绍 汇报人:朱军 (控制组)

VISA 1048766 复杂的信号处理层通过音视频编解码引擎和 VISA API 进行抽象

1048715VISA API 是音视频编解码的用户接口

1048715VISA 用来处理视频 Video 图像 Image 语音 Speech 音频 Audio

1048766 编码与解码的 API 组相互独立所以总有 8 组 API

1048715 VIDENC IMGENC SPHENC AUDENC1048715 VIDDEC IMGDEC SPHDEC AUDDEC

1048766 每个 VISA 组中关键的 API 有

1048715 xxx_create1048715 xxx_process1048715 xxx_control1048715 xxx_delete

Codec Engine 框架分析 Codec Engine 在解决达芬奇双处理器架构问题时首

先引入了远程过程控制 (RPC) 的概念 RPC 是指在另一个处理器上远程执行一个命令或过程 RPC有客户端和服务端客户端通过某种通信协议并最终通过物理链路向服务端发送一个命令服务端执行命令并通过相应的通信方式将结果返回给客户端

达芬奇 DM6446 芯片将 ARM 作为客户端 DSP 作为服务端两者之间的物理链路就是两个处理器之间共享的 DDR2 存储器而将物理链路上的通信协议称为 DSPLink

下图给出了这种框架的结构示意图图中共享 DDR2 存储器是 ARM与 DSP 之间共享的内存通过它进行物理数据的交换 DSPLink 是达芬奇架构双处理器间通信的基础软件为开发人员提供了一个通用的 API 用于描述 ARM 与 DSP 之间通信的物理链路的特征引擎功能层用于管理算法对象的实例例如创建一个对象的具体过程等 VISA 层是面向引擎功能层的一个接口用于定义创建删除和使用一个特定符合 XDM(XDAIS 的扩展专用于多媒体应用 ) 标准的算法的进程由于Codec Engine 的主要任务是为从 ARM 发起的 VISA 命令控制远程的 XDM 算法起到一个管道的作用因此 VISA 层实际上就是代表了 XDM 接口层

一般来讲软件系统分为应用层信号处理层和 IO 层三部分 TI 提供的达芬奇参考软件框架就是基于这样的结构如图所示 Davinci 的应用工程师可以在系统的用户空间在系统功能性上添加和发挥自己的特色信号处理层通常都运行在 DSP 一侧负责信号处理包括音视频编解码算法 Codec Engine DSP 的实时操作系统 DSPBIOS 及和 ARM通信的模块 IO 层就是我们通常所说的驱动是针对 Davinci 外设模块的驱动程序

其中应用层通过 Codec Engine 的 VISA(Video Image Speech Audio)API 来调用 DSP侧的算法通过 EPSI(Easy Peripheral Software Interface)API 来访问和操作 Davinci 的外设

如下图所示 DaVinci 的软件开发通常需要四个步骤

前面我们提到应用工程师通过调用 Codec Engine 的 API来调用和运行符合 xDAIS 的算法在 Davinci 软件中符合xDAIS 的音视频编解码算法 (即 xDM 算法 ) 的调用是通过 Codec Engine 的 VISA API完成的 Codec Engine 通过这套API 为算法的执行提供了一个标准的软件架构和接口

Codec Engine 是介于应用程序和具体算法之间的软件模块其中的 VISA API 通过 stub 和 skeleton 访问 Engine SPI 最终调用具体的算法因此 Codec Engine 的工作是通过完成 VISA API 的任务来体现的 VISA API 分为四部分 VISA createcontrolprocessdelete 我们以 codec 算法运行在 DSP 为例通过 VISA API 的执行过程了解 Codec Engine 的工作原理

在调用 VISA API 之前需要在应用程序中通过 Engine_open()这个 Engine API把 DSP 的可执行程序加载到 DSP 的 memory 同时把 DSP 从复位状态释放这时 DSP 开始运行DSP Server 的初始化程序在 DSP侧创建一个优先级最低的任务 RMS(Remote Management Server) RMS负责管理和维护对应到具体 codec 算法的 Instances 应用程序调用VISA create API 相应的 VISA create函数到 Engine SPI中的 Codec table 中查到这个 codec 运行在远端 DSP侧

接着 Engine SPI 通过 OSAL(Operating System Abstraction

Layer) DSP Link把 VISA create 的命令传到 DSP侧的 RMS RMS 通过 DSP侧 Engine SPI 的 codec table找到要调用的 codec 算法后就会在 RMS 中创建一个相应的 Instance(即一个 DSPBIOS 系统中的任务 ) VISA create会返回一个 Instance 的 Handle 以便于给这个 Instance做后续的 VISA controlprocessdelete 提供信息 VISA delete 和VISA create原理类似只是 RMS删除掉相应的 codec 算法的 Instance 和执行 codec 算法的任务

概括来说 VISA control 用来动态的修改 codec instance 的属性 VISA process 用来对算法的输入数据流做处理并返回一个输出数据流如下图所示应用程序在调用 VISA processcontrol 时会通过 xDM Stub把传递给 codec 算法的参数收集起来并且转换成 DSP 可以识别的物理地址 Stub把这些参数和相关的命令通过 Engine SPI OSAL 和 DSP Link传递到 DSP侧的 Instance Instance再通过 Skeleton把传递过来的参数和命令解析出来通过 DSP侧 VISA controlprocess 对 codec 算法执行 controlprocess

算法创建第一步需要基于 DSP利用 CCS 开发自己的音视

频编解码算法编译生成一个编解码算法的库文件lib(等同于 Linux 环境下的 a64P 直接在 Linux环境下修改文件后缀名即可 ) 由于需要确保算法可被 Codec Engine 使用和配置所以要确保这些算法实现需要符合 xDM(xDAIS(eXpress DSP Algorithm Interface Standard) for Digital Media) 标准

如果算法与 XDM 标准兼容 则可不经修改而直接被 Codec Engine 的 VISA API 远程执行如不兼容则需为其提供 Codec Engine 的框架和终端接口

服务集成 第二步生成一个在 DSP 上运行的可执行程序 x64P(即 out文件 ) 也就是 DSP Server

由于在双核环境中 Codec Engine 是在 DM6446 中的 DSP上执行而操作系统是由 DM6446 中的 ARM 通过 VISA API控制 Codec Engine 所以必须先在远程的 DSP生成一个 Codec Server Codec Server 是后缀为 x64P 的文件是一个集成了编解码器框架元件和系统代码的二进制库

在达芬奇 DM6446 平台中 Codec Server包含了一个为相应客户端 (ARM)生成编解码器提供系统运行信息 (包括指令和内存使用情况 ) 的 DSP BIOS任务线程客户端 (ARM) 的应用程序通过使用 VISA API 与在远程 DSP 上的编解码器联系

引擎集成第三步通过配置工具做大量的关于引擎配置的工

作包括引擎的名字每个引擎中包含什么编解码器编解码器是本地执行还是远程执行等如果这些编解码器在远程执行的则还需配置相应的 Codec Server 一般将所有的配置写到一个 cfg文件里面

这个配置文件包含的内容有 Codec Engine 运行的系统环境包括 xDC 通用模块和客户端操作系统类型等指明 Codec Engine需要用到的编解码器模块配置 Codec Engine 指明 Engine包含的内容

引擎引用 第四步应用工程师利用 Coedc Engine 的应用编程接口创

建删除配置好的引擎实例进而创建删除和控制编解码器由于 Codec Engine 不参与任何的 IO 操作只是纯粹的视频编解码算法处理因此应用工程师需要管理 IO 包括文件操作 (文件的打开读写与存储等 ) 和外设操作 ( 外设的打开关闭与控制等 )

应用工程师负责编写应用代码并将合适的内容加到最终的可执行文件中去应用工程师可使用以下资源从算法开发工程师得到的大量的编解码器软件包从服务集成工程师得到一个可以在 DSP 上运行的 Codec Server二进制文件一般为 x64P文件从引擎集成工程师得到一个引擎配置文件一般为 cfg文件应用工程师编写应用代码并结合这些资源再链接编译生成最终的可执行代码

虽然达芬奇技术带来了全新的开发平台和研发理念但是作为一项尚处于发展初期的技术仍然可能存在一些问题

首先是视频硬件加速器 VICP 的使用细节没有公开只有少数第三方厂商才能了解如何使用视频硬件加速器因此其他厂商开发 Codec 的难度就非常大

另外由于 DSP 与 ARM 双核结构的开发环境非常复杂 目前尚无一个完全集成 DSP 与 ARM 调试环境的集成开发环境因此需要同时进行 DSP 和 ARM 软件的跟踪调试必须运行两个独立的集成开发环境

另外 DSP 与 ARM 之间通信的协议接口也比较繁复

  • Slide 1
  • Slide 2
  • Slide 3
  • Slide 4
  • Slide 5
  • Slide 6
  • Slide 7
  • Slide 8
  • Slide 9
  • Slide 10
  • Slide 11
  • Slide 12
  • Slide 13
  • Slide 14
  • Slide 15
  • Slide 16
  • Slide 17
  • Slide 18
  • Slide 19
  • Slide 20
  • Slide 21
  • Slide 22
  • Slide 23
  • Slide 24
  • Slide 25
  • Slide 26
  • Slide 27
  • Slide 28
  • Slide 29
  • Slide 30
  • Slide 31
  • Slide 32
  • Slide 33
Page 10: 达芬奇平台简要介绍 汇报人:朱军 (控制组)

Codec Engine 框架分析 Codec Engine 在解决达芬奇双处理器架构问题时首

先引入了远程过程控制 (RPC) 的概念 RPC 是指在另一个处理器上远程执行一个命令或过程 RPC有客户端和服务端客户端通过某种通信协议并最终通过物理链路向服务端发送一个命令服务端执行命令并通过相应的通信方式将结果返回给客户端

达芬奇 DM6446 芯片将 ARM 作为客户端 DSP 作为服务端两者之间的物理链路就是两个处理器之间共享的 DDR2 存储器而将物理链路上的通信协议称为 DSPLink

下图给出了这种框架的结构示意图图中共享 DDR2 存储器是 ARM与 DSP 之间共享的内存通过它进行物理数据的交换 DSPLink 是达芬奇架构双处理器间通信的基础软件为开发人员提供了一个通用的 API 用于描述 ARM 与 DSP 之间通信的物理链路的特征引擎功能层用于管理算法对象的实例例如创建一个对象的具体过程等 VISA 层是面向引擎功能层的一个接口用于定义创建删除和使用一个特定符合 XDM(XDAIS 的扩展专用于多媒体应用 ) 标准的算法的进程由于Codec Engine 的主要任务是为从 ARM 发起的 VISA 命令控制远程的 XDM 算法起到一个管道的作用因此 VISA 层实际上就是代表了 XDM 接口层

一般来讲软件系统分为应用层信号处理层和 IO 层三部分 TI 提供的达芬奇参考软件框架就是基于这样的结构如图所示 Davinci 的应用工程师可以在系统的用户空间在系统功能性上添加和发挥自己的特色信号处理层通常都运行在 DSP 一侧负责信号处理包括音视频编解码算法 Codec Engine DSP 的实时操作系统 DSPBIOS 及和 ARM通信的模块 IO 层就是我们通常所说的驱动是针对 Davinci 外设模块的驱动程序

其中应用层通过 Codec Engine 的 VISA(Video Image Speech Audio)API 来调用 DSP侧的算法通过 EPSI(Easy Peripheral Software Interface)API 来访问和操作 Davinci 的外设

如下图所示 DaVinci 的软件开发通常需要四个步骤

前面我们提到应用工程师通过调用 Codec Engine 的 API来调用和运行符合 xDAIS 的算法在 Davinci 软件中符合xDAIS 的音视频编解码算法 (即 xDM 算法 ) 的调用是通过 Codec Engine 的 VISA API完成的 Codec Engine 通过这套API 为算法的执行提供了一个标准的软件架构和接口

Codec Engine 是介于应用程序和具体算法之间的软件模块其中的 VISA API 通过 stub 和 skeleton 访问 Engine SPI 最终调用具体的算法因此 Codec Engine 的工作是通过完成 VISA API 的任务来体现的 VISA API 分为四部分 VISA createcontrolprocessdelete 我们以 codec 算法运行在 DSP 为例通过 VISA API 的执行过程了解 Codec Engine 的工作原理

在调用 VISA API 之前需要在应用程序中通过 Engine_open()这个 Engine API把 DSP 的可执行程序加载到 DSP 的 memory 同时把 DSP 从复位状态释放这时 DSP 开始运行DSP Server 的初始化程序在 DSP侧创建一个优先级最低的任务 RMS(Remote Management Server) RMS负责管理和维护对应到具体 codec 算法的 Instances 应用程序调用VISA create API 相应的 VISA create函数到 Engine SPI中的 Codec table 中查到这个 codec 运行在远端 DSP侧

接着 Engine SPI 通过 OSAL(Operating System Abstraction

Layer) DSP Link把 VISA create 的命令传到 DSP侧的 RMS RMS 通过 DSP侧 Engine SPI 的 codec table找到要调用的 codec 算法后就会在 RMS 中创建一个相应的 Instance(即一个 DSPBIOS 系统中的任务 ) VISA create会返回一个 Instance 的 Handle 以便于给这个 Instance做后续的 VISA controlprocessdelete 提供信息 VISA delete 和VISA create原理类似只是 RMS删除掉相应的 codec 算法的 Instance 和执行 codec 算法的任务

概括来说 VISA control 用来动态的修改 codec instance 的属性 VISA process 用来对算法的输入数据流做处理并返回一个输出数据流如下图所示应用程序在调用 VISA processcontrol 时会通过 xDM Stub把传递给 codec 算法的参数收集起来并且转换成 DSP 可以识别的物理地址 Stub把这些参数和相关的命令通过 Engine SPI OSAL 和 DSP Link传递到 DSP侧的 Instance Instance再通过 Skeleton把传递过来的参数和命令解析出来通过 DSP侧 VISA controlprocess 对 codec 算法执行 controlprocess

算法创建第一步需要基于 DSP利用 CCS 开发自己的音视

频编解码算法编译生成一个编解码算法的库文件lib(等同于 Linux 环境下的 a64P 直接在 Linux环境下修改文件后缀名即可 ) 由于需要确保算法可被 Codec Engine 使用和配置所以要确保这些算法实现需要符合 xDM(xDAIS(eXpress DSP Algorithm Interface Standard) for Digital Media) 标准

如果算法与 XDM 标准兼容 则可不经修改而直接被 Codec Engine 的 VISA API 远程执行如不兼容则需为其提供 Codec Engine 的框架和终端接口

服务集成 第二步生成一个在 DSP 上运行的可执行程序 x64P(即 out文件 ) 也就是 DSP Server

由于在双核环境中 Codec Engine 是在 DM6446 中的 DSP上执行而操作系统是由 DM6446 中的 ARM 通过 VISA API控制 Codec Engine 所以必须先在远程的 DSP生成一个 Codec Server Codec Server 是后缀为 x64P 的文件是一个集成了编解码器框架元件和系统代码的二进制库

在达芬奇 DM6446 平台中 Codec Server包含了一个为相应客户端 (ARM)生成编解码器提供系统运行信息 (包括指令和内存使用情况 ) 的 DSP BIOS任务线程客户端 (ARM) 的应用程序通过使用 VISA API 与在远程 DSP 上的编解码器联系

引擎集成第三步通过配置工具做大量的关于引擎配置的工

作包括引擎的名字每个引擎中包含什么编解码器编解码器是本地执行还是远程执行等如果这些编解码器在远程执行的则还需配置相应的 Codec Server 一般将所有的配置写到一个 cfg文件里面

这个配置文件包含的内容有 Codec Engine 运行的系统环境包括 xDC 通用模块和客户端操作系统类型等指明 Codec Engine需要用到的编解码器模块配置 Codec Engine 指明 Engine包含的内容

引擎引用 第四步应用工程师利用 Coedc Engine 的应用编程接口创

建删除配置好的引擎实例进而创建删除和控制编解码器由于 Codec Engine 不参与任何的 IO 操作只是纯粹的视频编解码算法处理因此应用工程师需要管理 IO 包括文件操作 (文件的打开读写与存储等 ) 和外设操作 ( 外设的打开关闭与控制等 )

应用工程师负责编写应用代码并将合适的内容加到最终的可执行文件中去应用工程师可使用以下资源从算法开发工程师得到的大量的编解码器软件包从服务集成工程师得到一个可以在 DSP 上运行的 Codec Server二进制文件一般为 x64P文件从引擎集成工程师得到一个引擎配置文件一般为 cfg文件应用工程师编写应用代码并结合这些资源再链接编译生成最终的可执行代码

虽然达芬奇技术带来了全新的开发平台和研发理念但是作为一项尚处于发展初期的技术仍然可能存在一些问题

首先是视频硬件加速器 VICP 的使用细节没有公开只有少数第三方厂商才能了解如何使用视频硬件加速器因此其他厂商开发 Codec 的难度就非常大

另外由于 DSP 与 ARM 双核结构的开发环境非常复杂 目前尚无一个完全集成 DSP 与 ARM 调试环境的集成开发环境因此需要同时进行 DSP 和 ARM 软件的跟踪调试必须运行两个独立的集成开发环境

另外 DSP 与 ARM 之间通信的协议接口也比较繁复

  • Slide 1
  • Slide 2
  • Slide 3
  • Slide 4
  • Slide 5
  • Slide 6
  • Slide 7
  • Slide 8
  • Slide 9
  • Slide 10
  • Slide 11
  • Slide 12
  • Slide 13
  • Slide 14
  • Slide 15
  • Slide 16
  • Slide 17
  • Slide 18
  • Slide 19
  • Slide 20
  • Slide 21
  • Slide 22
  • Slide 23
  • Slide 24
  • Slide 25
  • Slide 26
  • Slide 27
  • Slide 28
  • Slide 29
  • Slide 30
  • Slide 31
  • Slide 32
  • Slide 33
Page 11: 达芬奇平台简要介绍 汇报人:朱军 (控制组)

下图给出了这种框架的结构示意图图中共享 DDR2 存储器是 ARM与 DSP 之间共享的内存通过它进行物理数据的交换 DSPLink 是达芬奇架构双处理器间通信的基础软件为开发人员提供了一个通用的 API 用于描述 ARM 与 DSP 之间通信的物理链路的特征引擎功能层用于管理算法对象的实例例如创建一个对象的具体过程等 VISA 层是面向引擎功能层的一个接口用于定义创建删除和使用一个特定符合 XDM(XDAIS 的扩展专用于多媒体应用 ) 标准的算法的进程由于Codec Engine 的主要任务是为从 ARM 发起的 VISA 命令控制远程的 XDM 算法起到一个管道的作用因此 VISA 层实际上就是代表了 XDM 接口层

一般来讲软件系统分为应用层信号处理层和 IO 层三部分 TI 提供的达芬奇参考软件框架就是基于这样的结构如图所示 Davinci 的应用工程师可以在系统的用户空间在系统功能性上添加和发挥自己的特色信号处理层通常都运行在 DSP 一侧负责信号处理包括音视频编解码算法 Codec Engine DSP 的实时操作系统 DSPBIOS 及和 ARM通信的模块 IO 层就是我们通常所说的驱动是针对 Davinci 外设模块的驱动程序

其中应用层通过 Codec Engine 的 VISA(Video Image Speech Audio)API 来调用 DSP侧的算法通过 EPSI(Easy Peripheral Software Interface)API 来访问和操作 Davinci 的外设

如下图所示 DaVinci 的软件开发通常需要四个步骤

前面我们提到应用工程师通过调用 Codec Engine 的 API来调用和运行符合 xDAIS 的算法在 Davinci 软件中符合xDAIS 的音视频编解码算法 (即 xDM 算法 ) 的调用是通过 Codec Engine 的 VISA API完成的 Codec Engine 通过这套API 为算法的执行提供了一个标准的软件架构和接口

Codec Engine 是介于应用程序和具体算法之间的软件模块其中的 VISA API 通过 stub 和 skeleton 访问 Engine SPI 最终调用具体的算法因此 Codec Engine 的工作是通过完成 VISA API 的任务来体现的 VISA API 分为四部分 VISA createcontrolprocessdelete 我们以 codec 算法运行在 DSP 为例通过 VISA API 的执行过程了解 Codec Engine 的工作原理

在调用 VISA API 之前需要在应用程序中通过 Engine_open()这个 Engine API把 DSP 的可执行程序加载到 DSP 的 memory 同时把 DSP 从复位状态释放这时 DSP 开始运行DSP Server 的初始化程序在 DSP侧创建一个优先级最低的任务 RMS(Remote Management Server) RMS负责管理和维护对应到具体 codec 算法的 Instances 应用程序调用VISA create API 相应的 VISA create函数到 Engine SPI中的 Codec table 中查到这个 codec 运行在远端 DSP侧

接着 Engine SPI 通过 OSAL(Operating System Abstraction

Layer) DSP Link把 VISA create 的命令传到 DSP侧的 RMS RMS 通过 DSP侧 Engine SPI 的 codec table找到要调用的 codec 算法后就会在 RMS 中创建一个相应的 Instance(即一个 DSPBIOS 系统中的任务 ) VISA create会返回一个 Instance 的 Handle 以便于给这个 Instance做后续的 VISA controlprocessdelete 提供信息 VISA delete 和VISA create原理类似只是 RMS删除掉相应的 codec 算法的 Instance 和执行 codec 算法的任务

概括来说 VISA control 用来动态的修改 codec instance 的属性 VISA process 用来对算法的输入数据流做处理并返回一个输出数据流如下图所示应用程序在调用 VISA processcontrol 时会通过 xDM Stub把传递给 codec 算法的参数收集起来并且转换成 DSP 可以识别的物理地址 Stub把这些参数和相关的命令通过 Engine SPI OSAL 和 DSP Link传递到 DSP侧的 Instance Instance再通过 Skeleton把传递过来的参数和命令解析出来通过 DSP侧 VISA controlprocess 对 codec 算法执行 controlprocess

算法创建第一步需要基于 DSP利用 CCS 开发自己的音视

频编解码算法编译生成一个编解码算法的库文件lib(等同于 Linux 环境下的 a64P 直接在 Linux环境下修改文件后缀名即可 ) 由于需要确保算法可被 Codec Engine 使用和配置所以要确保这些算法实现需要符合 xDM(xDAIS(eXpress DSP Algorithm Interface Standard) for Digital Media) 标准

如果算法与 XDM 标准兼容 则可不经修改而直接被 Codec Engine 的 VISA API 远程执行如不兼容则需为其提供 Codec Engine 的框架和终端接口

服务集成 第二步生成一个在 DSP 上运行的可执行程序 x64P(即 out文件 ) 也就是 DSP Server

由于在双核环境中 Codec Engine 是在 DM6446 中的 DSP上执行而操作系统是由 DM6446 中的 ARM 通过 VISA API控制 Codec Engine 所以必须先在远程的 DSP生成一个 Codec Server Codec Server 是后缀为 x64P 的文件是一个集成了编解码器框架元件和系统代码的二进制库

在达芬奇 DM6446 平台中 Codec Server包含了一个为相应客户端 (ARM)生成编解码器提供系统运行信息 (包括指令和内存使用情况 ) 的 DSP BIOS任务线程客户端 (ARM) 的应用程序通过使用 VISA API 与在远程 DSP 上的编解码器联系

引擎集成第三步通过配置工具做大量的关于引擎配置的工

作包括引擎的名字每个引擎中包含什么编解码器编解码器是本地执行还是远程执行等如果这些编解码器在远程执行的则还需配置相应的 Codec Server 一般将所有的配置写到一个 cfg文件里面

这个配置文件包含的内容有 Codec Engine 运行的系统环境包括 xDC 通用模块和客户端操作系统类型等指明 Codec Engine需要用到的编解码器模块配置 Codec Engine 指明 Engine包含的内容

引擎引用 第四步应用工程师利用 Coedc Engine 的应用编程接口创

建删除配置好的引擎实例进而创建删除和控制编解码器由于 Codec Engine 不参与任何的 IO 操作只是纯粹的视频编解码算法处理因此应用工程师需要管理 IO 包括文件操作 (文件的打开读写与存储等 ) 和外设操作 ( 外设的打开关闭与控制等 )

应用工程师负责编写应用代码并将合适的内容加到最终的可执行文件中去应用工程师可使用以下资源从算法开发工程师得到的大量的编解码器软件包从服务集成工程师得到一个可以在 DSP 上运行的 Codec Server二进制文件一般为 x64P文件从引擎集成工程师得到一个引擎配置文件一般为 cfg文件应用工程师编写应用代码并结合这些资源再链接编译生成最终的可执行代码

虽然达芬奇技术带来了全新的开发平台和研发理念但是作为一项尚处于发展初期的技术仍然可能存在一些问题

首先是视频硬件加速器 VICP 的使用细节没有公开只有少数第三方厂商才能了解如何使用视频硬件加速器因此其他厂商开发 Codec 的难度就非常大

另外由于 DSP 与 ARM 双核结构的开发环境非常复杂 目前尚无一个完全集成 DSP 与 ARM 调试环境的集成开发环境因此需要同时进行 DSP 和 ARM 软件的跟踪调试必须运行两个独立的集成开发环境

另外 DSP 与 ARM 之间通信的协议接口也比较繁复

  • Slide 1
  • Slide 2
  • Slide 3
  • Slide 4
  • Slide 5
  • Slide 6
  • Slide 7
  • Slide 8
  • Slide 9
  • Slide 10
  • Slide 11
  • Slide 12
  • Slide 13
  • Slide 14
  • Slide 15
  • Slide 16
  • Slide 17
  • Slide 18
  • Slide 19
  • Slide 20
  • Slide 21
  • Slide 22
  • Slide 23
  • Slide 24
  • Slide 25
  • Slide 26
  • Slide 27
  • Slide 28
  • Slide 29
  • Slide 30
  • Slide 31
  • Slide 32
  • Slide 33
Page 12: 达芬奇平台简要介绍 汇报人:朱军 (控制组)

一般来讲软件系统分为应用层信号处理层和 IO 层三部分 TI 提供的达芬奇参考软件框架就是基于这样的结构如图所示 Davinci 的应用工程师可以在系统的用户空间在系统功能性上添加和发挥自己的特色信号处理层通常都运行在 DSP 一侧负责信号处理包括音视频编解码算法 Codec Engine DSP 的实时操作系统 DSPBIOS 及和 ARM通信的模块 IO 层就是我们通常所说的驱动是针对 Davinci 外设模块的驱动程序

其中应用层通过 Codec Engine 的 VISA(Video Image Speech Audio)API 来调用 DSP侧的算法通过 EPSI(Easy Peripheral Software Interface)API 来访问和操作 Davinci 的外设

如下图所示 DaVinci 的软件开发通常需要四个步骤

前面我们提到应用工程师通过调用 Codec Engine 的 API来调用和运行符合 xDAIS 的算法在 Davinci 软件中符合xDAIS 的音视频编解码算法 (即 xDM 算法 ) 的调用是通过 Codec Engine 的 VISA API完成的 Codec Engine 通过这套API 为算法的执行提供了一个标准的软件架构和接口

Codec Engine 是介于应用程序和具体算法之间的软件模块其中的 VISA API 通过 stub 和 skeleton 访问 Engine SPI 最终调用具体的算法因此 Codec Engine 的工作是通过完成 VISA API 的任务来体现的 VISA API 分为四部分 VISA createcontrolprocessdelete 我们以 codec 算法运行在 DSP 为例通过 VISA API 的执行过程了解 Codec Engine 的工作原理

在调用 VISA API 之前需要在应用程序中通过 Engine_open()这个 Engine API把 DSP 的可执行程序加载到 DSP 的 memory 同时把 DSP 从复位状态释放这时 DSP 开始运行DSP Server 的初始化程序在 DSP侧创建一个优先级最低的任务 RMS(Remote Management Server) RMS负责管理和维护对应到具体 codec 算法的 Instances 应用程序调用VISA create API 相应的 VISA create函数到 Engine SPI中的 Codec table 中查到这个 codec 运行在远端 DSP侧

接着 Engine SPI 通过 OSAL(Operating System Abstraction

Layer) DSP Link把 VISA create 的命令传到 DSP侧的 RMS RMS 通过 DSP侧 Engine SPI 的 codec table找到要调用的 codec 算法后就会在 RMS 中创建一个相应的 Instance(即一个 DSPBIOS 系统中的任务 ) VISA create会返回一个 Instance 的 Handle 以便于给这个 Instance做后续的 VISA controlprocessdelete 提供信息 VISA delete 和VISA create原理类似只是 RMS删除掉相应的 codec 算法的 Instance 和执行 codec 算法的任务

概括来说 VISA control 用来动态的修改 codec instance 的属性 VISA process 用来对算法的输入数据流做处理并返回一个输出数据流如下图所示应用程序在调用 VISA processcontrol 时会通过 xDM Stub把传递给 codec 算法的参数收集起来并且转换成 DSP 可以识别的物理地址 Stub把这些参数和相关的命令通过 Engine SPI OSAL 和 DSP Link传递到 DSP侧的 Instance Instance再通过 Skeleton把传递过来的参数和命令解析出来通过 DSP侧 VISA controlprocess 对 codec 算法执行 controlprocess

算法创建第一步需要基于 DSP利用 CCS 开发自己的音视

频编解码算法编译生成一个编解码算法的库文件lib(等同于 Linux 环境下的 a64P 直接在 Linux环境下修改文件后缀名即可 ) 由于需要确保算法可被 Codec Engine 使用和配置所以要确保这些算法实现需要符合 xDM(xDAIS(eXpress DSP Algorithm Interface Standard) for Digital Media) 标准

如果算法与 XDM 标准兼容 则可不经修改而直接被 Codec Engine 的 VISA API 远程执行如不兼容则需为其提供 Codec Engine 的框架和终端接口

服务集成 第二步生成一个在 DSP 上运行的可执行程序 x64P(即 out文件 ) 也就是 DSP Server

由于在双核环境中 Codec Engine 是在 DM6446 中的 DSP上执行而操作系统是由 DM6446 中的 ARM 通过 VISA API控制 Codec Engine 所以必须先在远程的 DSP生成一个 Codec Server Codec Server 是后缀为 x64P 的文件是一个集成了编解码器框架元件和系统代码的二进制库

在达芬奇 DM6446 平台中 Codec Server包含了一个为相应客户端 (ARM)生成编解码器提供系统运行信息 (包括指令和内存使用情况 ) 的 DSP BIOS任务线程客户端 (ARM) 的应用程序通过使用 VISA API 与在远程 DSP 上的编解码器联系

引擎集成第三步通过配置工具做大量的关于引擎配置的工

作包括引擎的名字每个引擎中包含什么编解码器编解码器是本地执行还是远程执行等如果这些编解码器在远程执行的则还需配置相应的 Codec Server 一般将所有的配置写到一个 cfg文件里面

这个配置文件包含的内容有 Codec Engine 运行的系统环境包括 xDC 通用模块和客户端操作系统类型等指明 Codec Engine需要用到的编解码器模块配置 Codec Engine 指明 Engine包含的内容

引擎引用 第四步应用工程师利用 Coedc Engine 的应用编程接口创

建删除配置好的引擎实例进而创建删除和控制编解码器由于 Codec Engine 不参与任何的 IO 操作只是纯粹的视频编解码算法处理因此应用工程师需要管理 IO 包括文件操作 (文件的打开读写与存储等 ) 和外设操作 ( 外设的打开关闭与控制等 )

应用工程师负责编写应用代码并将合适的内容加到最终的可执行文件中去应用工程师可使用以下资源从算法开发工程师得到的大量的编解码器软件包从服务集成工程师得到一个可以在 DSP 上运行的 Codec Server二进制文件一般为 x64P文件从引擎集成工程师得到一个引擎配置文件一般为 cfg文件应用工程师编写应用代码并结合这些资源再链接编译生成最终的可执行代码

虽然达芬奇技术带来了全新的开发平台和研发理念但是作为一项尚处于发展初期的技术仍然可能存在一些问题

首先是视频硬件加速器 VICP 的使用细节没有公开只有少数第三方厂商才能了解如何使用视频硬件加速器因此其他厂商开发 Codec 的难度就非常大

另外由于 DSP 与 ARM 双核结构的开发环境非常复杂 目前尚无一个完全集成 DSP 与 ARM 调试环境的集成开发环境因此需要同时进行 DSP 和 ARM 软件的跟踪调试必须运行两个独立的集成开发环境

另外 DSP 与 ARM 之间通信的协议接口也比较繁复

  • Slide 1
  • Slide 2
  • Slide 3
  • Slide 4
  • Slide 5
  • Slide 6
  • Slide 7
  • Slide 8
  • Slide 9
  • Slide 10
  • Slide 11
  • Slide 12
  • Slide 13
  • Slide 14
  • Slide 15
  • Slide 16
  • Slide 17
  • Slide 18
  • Slide 19
  • Slide 20
  • Slide 21
  • Slide 22
  • Slide 23
  • Slide 24
  • Slide 25
  • Slide 26
  • Slide 27
  • Slide 28
  • Slide 29
  • Slide 30
  • Slide 31
  • Slide 32
  • Slide 33
Page 13: 达芬奇平台简要介绍 汇报人:朱军 (控制组)

如下图所示 DaVinci 的软件开发通常需要四个步骤

前面我们提到应用工程师通过调用 Codec Engine 的 API来调用和运行符合 xDAIS 的算法在 Davinci 软件中符合xDAIS 的音视频编解码算法 (即 xDM 算法 ) 的调用是通过 Codec Engine 的 VISA API完成的 Codec Engine 通过这套API 为算法的执行提供了一个标准的软件架构和接口

Codec Engine 是介于应用程序和具体算法之间的软件模块其中的 VISA API 通过 stub 和 skeleton 访问 Engine SPI 最终调用具体的算法因此 Codec Engine 的工作是通过完成 VISA API 的任务来体现的 VISA API 分为四部分 VISA createcontrolprocessdelete 我们以 codec 算法运行在 DSP 为例通过 VISA API 的执行过程了解 Codec Engine 的工作原理

在调用 VISA API 之前需要在应用程序中通过 Engine_open()这个 Engine API把 DSP 的可执行程序加载到 DSP 的 memory 同时把 DSP 从复位状态释放这时 DSP 开始运行DSP Server 的初始化程序在 DSP侧创建一个优先级最低的任务 RMS(Remote Management Server) RMS负责管理和维护对应到具体 codec 算法的 Instances 应用程序调用VISA create API 相应的 VISA create函数到 Engine SPI中的 Codec table 中查到这个 codec 运行在远端 DSP侧

接着 Engine SPI 通过 OSAL(Operating System Abstraction

Layer) DSP Link把 VISA create 的命令传到 DSP侧的 RMS RMS 通过 DSP侧 Engine SPI 的 codec table找到要调用的 codec 算法后就会在 RMS 中创建一个相应的 Instance(即一个 DSPBIOS 系统中的任务 ) VISA create会返回一个 Instance 的 Handle 以便于给这个 Instance做后续的 VISA controlprocessdelete 提供信息 VISA delete 和VISA create原理类似只是 RMS删除掉相应的 codec 算法的 Instance 和执行 codec 算法的任务

概括来说 VISA control 用来动态的修改 codec instance 的属性 VISA process 用来对算法的输入数据流做处理并返回一个输出数据流如下图所示应用程序在调用 VISA processcontrol 时会通过 xDM Stub把传递给 codec 算法的参数收集起来并且转换成 DSP 可以识别的物理地址 Stub把这些参数和相关的命令通过 Engine SPI OSAL 和 DSP Link传递到 DSP侧的 Instance Instance再通过 Skeleton把传递过来的参数和命令解析出来通过 DSP侧 VISA controlprocess 对 codec 算法执行 controlprocess

算法创建第一步需要基于 DSP利用 CCS 开发自己的音视

频编解码算法编译生成一个编解码算法的库文件lib(等同于 Linux 环境下的 a64P 直接在 Linux环境下修改文件后缀名即可 ) 由于需要确保算法可被 Codec Engine 使用和配置所以要确保这些算法实现需要符合 xDM(xDAIS(eXpress DSP Algorithm Interface Standard) for Digital Media) 标准

如果算法与 XDM 标准兼容 则可不经修改而直接被 Codec Engine 的 VISA API 远程执行如不兼容则需为其提供 Codec Engine 的框架和终端接口

服务集成 第二步生成一个在 DSP 上运行的可执行程序 x64P(即 out文件 ) 也就是 DSP Server

由于在双核环境中 Codec Engine 是在 DM6446 中的 DSP上执行而操作系统是由 DM6446 中的 ARM 通过 VISA API控制 Codec Engine 所以必须先在远程的 DSP生成一个 Codec Server Codec Server 是后缀为 x64P 的文件是一个集成了编解码器框架元件和系统代码的二进制库

在达芬奇 DM6446 平台中 Codec Server包含了一个为相应客户端 (ARM)生成编解码器提供系统运行信息 (包括指令和内存使用情况 ) 的 DSP BIOS任务线程客户端 (ARM) 的应用程序通过使用 VISA API 与在远程 DSP 上的编解码器联系

引擎集成第三步通过配置工具做大量的关于引擎配置的工

作包括引擎的名字每个引擎中包含什么编解码器编解码器是本地执行还是远程执行等如果这些编解码器在远程执行的则还需配置相应的 Codec Server 一般将所有的配置写到一个 cfg文件里面

这个配置文件包含的内容有 Codec Engine 运行的系统环境包括 xDC 通用模块和客户端操作系统类型等指明 Codec Engine需要用到的编解码器模块配置 Codec Engine 指明 Engine包含的内容

引擎引用 第四步应用工程师利用 Coedc Engine 的应用编程接口创

建删除配置好的引擎实例进而创建删除和控制编解码器由于 Codec Engine 不参与任何的 IO 操作只是纯粹的视频编解码算法处理因此应用工程师需要管理 IO 包括文件操作 (文件的打开读写与存储等 ) 和外设操作 ( 外设的打开关闭与控制等 )

应用工程师负责编写应用代码并将合适的内容加到最终的可执行文件中去应用工程师可使用以下资源从算法开发工程师得到的大量的编解码器软件包从服务集成工程师得到一个可以在 DSP 上运行的 Codec Server二进制文件一般为 x64P文件从引擎集成工程师得到一个引擎配置文件一般为 cfg文件应用工程师编写应用代码并结合这些资源再链接编译生成最终的可执行代码

虽然达芬奇技术带来了全新的开发平台和研发理念但是作为一项尚处于发展初期的技术仍然可能存在一些问题

首先是视频硬件加速器 VICP 的使用细节没有公开只有少数第三方厂商才能了解如何使用视频硬件加速器因此其他厂商开发 Codec 的难度就非常大

另外由于 DSP 与 ARM 双核结构的开发环境非常复杂 目前尚无一个完全集成 DSP 与 ARM 调试环境的集成开发环境因此需要同时进行 DSP 和 ARM 软件的跟踪调试必须运行两个独立的集成开发环境

另外 DSP 与 ARM 之间通信的协议接口也比较繁复

  • Slide 1
  • Slide 2
  • Slide 3
  • Slide 4
  • Slide 5
  • Slide 6
  • Slide 7
  • Slide 8
  • Slide 9
  • Slide 10
  • Slide 11
  • Slide 12
  • Slide 13
  • Slide 14
  • Slide 15
  • Slide 16
  • Slide 17
  • Slide 18
  • Slide 19
  • Slide 20
  • Slide 21
  • Slide 22
  • Slide 23
  • Slide 24
  • Slide 25
  • Slide 26
  • Slide 27
  • Slide 28
  • Slide 29
  • Slide 30
  • Slide 31
  • Slide 32
  • Slide 33
Page 14: 达芬奇平台简要介绍 汇报人:朱军 (控制组)

前面我们提到应用工程师通过调用 Codec Engine 的 API来调用和运行符合 xDAIS 的算法在 Davinci 软件中符合xDAIS 的音视频编解码算法 (即 xDM 算法 ) 的调用是通过 Codec Engine 的 VISA API完成的 Codec Engine 通过这套API 为算法的执行提供了一个标准的软件架构和接口

Codec Engine 是介于应用程序和具体算法之间的软件模块其中的 VISA API 通过 stub 和 skeleton 访问 Engine SPI 最终调用具体的算法因此 Codec Engine 的工作是通过完成 VISA API 的任务来体现的 VISA API 分为四部分 VISA createcontrolprocessdelete 我们以 codec 算法运行在 DSP 为例通过 VISA API 的执行过程了解 Codec Engine 的工作原理

在调用 VISA API 之前需要在应用程序中通过 Engine_open()这个 Engine API把 DSP 的可执行程序加载到 DSP 的 memory 同时把 DSP 从复位状态释放这时 DSP 开始运行DSP Server 的初始化程序在 DSP侧创建一个优先级最低的任务 RMS(Remote Management Server) RMS负责管理和维护对应到具体 codec 算法的 Instances 应用程序调用VISA create API 相应的 VISA create函数到 Engine SPI中的 Codec table 中查到这个 codec 运行在远端 DSP侧

接着 Engine SPI 通过 OSAL(Operating System Abstraction

Layer) DSP Link把 VISA create 的命令传到 DSP侧的 RMS RMS 通过 DSP侧 Engine SPI 的 codec table找到要调用的 codec 算法后就会在 RMS 中创建一个相应的 Instance(即一个 DSPBIOS 系统中的任务 ) VISA create会返回一个 Instance 的 Handle 以便于给这个 Instance做后续的 VISA controlprocessdelete 提供信息 VISA delete 和VISA create原理类似只是 RMS删除掉相应的 codec 算法的 Instance 和执行 codec 算法的任务

概括来说 VISA control 用来动态的修改 codec instance 的属性 VISA process 用来对算法的输入数据流做处理并返回一个输出数据流如下图所示应用程序在调用 VISA processcontrol 时会通过 xDM Stub把传递给 codec 算法的参数收集起来并且转换成 DSP 可以识别的物理地址 Stub把这些参数和相关的命令通过 Engine SPI OSAL 和 DSP Link传递到 DSP侧的 Instance Instance再通过 Skeleton把传递过来的参数和命令解析出来通过 DSP侧 VISA controlprocess 对 codec 算法执行 controlprocess

算法创建第一步需要基于 DSP利用 CCS 开发自己的音视

频编解码算法编译生成一个编解码算法的库文件lib(等同于 Linux 环境下的 a64P 直接在 Linux环境下修改文件后缀名即可 ) 由于需要确保算法可被 Codec Engine 使用和配置所以要确保这些算法实现需要符合 xDM(xDAIS(eXpress DSP Algorithm Interface Standard) for Digital Media) 标准

如果算法与 XDM 标准兼容 则可不经修改而直接被 Codec Engine 的 VISA API 远程执行如不兼容则需为其提供 Codec Engine 的框架和终端接口

服务集成 第二步生成一个在 DSP 上运行的可执行程序 x64P(即 out文件 ) 也就是 DSP Server

由于在双核环境中 Codec Engine 是在 DM6446 中的 DSP上执行而操作系统是由 DM6446 中的 ARM 通过 VISA API控制 Codec Engine 所以必须先在远程的 DSP生成一个 Codec Server Codec Server 是后缀为 x64P 的文件是一个集成了编解码器框架元件和系统代码的二进制库

在达芬奇 DM6446 平台中 Codec Server包含了一个为相应客户端 (ARM)生成编解码器提供系统运行信息 (包括指令和内存使用情况 ) 的 DSP BIOS任务线程客户端 (ARM) 的应用程序通过使用 VISA API 与在远程 DSP 上的编解码器联系

引擎集成第三步通过配置工具做大量的关于引擎配置的工

作包括引擎的名字每个引擎中包含什么编解码器编解码器是本地执行还是远程执行等如果这些编解码器在远程执行的则还需配置相应的 Codec Server 一般将所有的配置写到一个 cfg文件里面

这个配置文件包含的内容有 Codec Engine 运行的系统环境包括 xDC 通用模块和客户端操作系统类型等指明 Codec Engine需要用到的编解码器模块配置 Codec Engine 指明 Engine包含的内容

引擎引用 第四步应用工程师利用 Coedc Engine 的应用编程接口创

建删除配置好的引擎实例进而创建删除和控制编解码器由于 Codec Engine 不参与任何的 IO 操作只是纯粹的视频编解码算法处理因此应用工程师需要管理 IO 包括文件操作 (文件的打开读写与存储等 ) 和外设操作 ( 外设的打开关闭与控制等 )

应用工程师负责编写应用代码并将合适的内容加到最终的可执行文件中去应用工程师可使用以下资源从算法开发工程师得到的大量的编解码器软件包从服务集成工程师得到一个可以在 DSP 上运行的 Codec Server二进制文件一般为 x64P文件从引擎集成工程师得到一个引擎配置文件一般为 cfg文件应用工程师编写应用代码并结合这些资源再链接编译生成最终的可执行代码

虽然达芬奇技术带来了全新的开发平台和研发理念但是作为一项尚处于发展初期的技术仍然可能存在一些问题

首先是视频硬件加速器 VICP 的使用细节没有公开只有少数第三方厂商才能了解如何使用视频硬件加速器因此其他厂商开发 Codec 的难度就非常大

另外由于 DSP 与 ARM 双核结构的开发环境非常复杂 目前尚无一个完全集成 DSP 与 ARM 调试环境的集成开发环境因此需要同时进行 DSP 和 ARM 软件的跟踪调试必须运行两个独立的集成开发环境

另外 DSP 与 ARM 之间通信的协议接口也比较繁复

  • Slide 1
  • Slide 2
  • Slide 3
  • Slide 4
  • Slide 5
  • Slide 6
  • Slide 7
  • Slide 8
  • Slide 9
  • Slide 10
  • Slide 11
  • Slide 12
  • Slide 13
  • Slide 14
  • Slide 15
  • Slide 16
  • Slide 17
  • Slide 18
  • Slide 19
  • Slide 20
  • Slide 21
  • Slide 22
  • Slide 23
  • Slide 24
  • Slide 25
  • Slide 26
  • Slide 27
  • Slide 28
  • Slide 29
  • Slide 30
  • Slide 31
  • Slide 32
  • Slide 33
Page 15: 达芬奇平台简要介绍 汇报人:朱军 (控制组)

在调用 VISA API 之前需要在应用程序中通过 Engine_open()这个 Engine API把 DSP 的可执行程序加载到 DSP 的 memory 同时把 DSP 从复位状态释放这时 DSP 开始运行DSP Server 的初始化程序在 DSP侧创建一个优先级最低的任务 RMS(Remote Management Server) RMS负责管理和维护对应到具体 codec 算法的 Instances 应用程序调用VISA create API 相应的 VISA create函数到 Engine SPI中的 Codec table 中查到这个 codec 运行在远端 DSP侧

接着 Engine SPI 通过 OSAL(Operating System Abstraction

Layer) DSP Link把 VISA create 的命令传到 DSP侧的 RMS RMS 通过 DSP侧 Engine SPI 的 codec table找到要调用的 codec 算法后就会在 RMS 中创建一个相应的 Instance(即一个 DSPBIOS 系统中的任务 ) VISA create会返回一个 Instance 的 Handle 以便于给这个 Instance做后续的 VISA controlprocessdelete 提供信息 VISA delete 和VISA create原理类似只是 RMS删除掉相应的 codec 算法的 Instance 和执行 codec 算法的任务

概括来说 VISA control 用来动态的修改 codec instance 的属性 VISA process 用来对算法的输入数据流做处理并返回一个输出数据流如下图所示应用程序在调用 VISA processcontrol 时会通过 xDM Stub把传递给 codec 算法的参数收集起来并且转换成 DSP 可以识别的物理地址 Stub把这些参数和相关的命令通过 Engine SPI OSAL 和 DSP Link传递到 DSP侧的 Instance Instance再通过 Skeleton把传递过来的参数和命令解析出来通过 DSP侧 VISA controlprocess 对 codec 算法执行 controlprocess

算法创建第一步需要基于 DSP利用 CCS 开发自己的音视

频编解码算法编译生成一个编解码算法的库文件lib(等同于 Linux 环境下的 a64P 直接在 Linux环境下修改文件后缀名即可 ) 由于需要确保算法可被 Codec Engine 使用和配置所以要确保这些算法实现需要符合 xDM(xDAIS(eXpress DSP Algorithm Interface Standard) for Digital Media) 标准

如果算法与 XDM 标准兼容 则可不经修改而直接被 Codec Engine 的 VISA API 远程执行如不兼容则需为其提供 Codec Engine 的框架和终端接口

服务集成 第二步生成一个在 DSP 上运行的可执行程序 x64P(即 out文件 ) 也就是 DSP Server

由于在双核环境中 Codec Engine 是在 DM6446 中的 DSP上执行而操作系统是由 DM6446 中的 ARM 通过 VISA API控制 Codec Engine 所以必须先在远程的 DSP生成一个 Codec Server Codec Server 是后缀为 x64P 的文件是一个集成了编解码器框架元件和系统代码的二进制库

在达芬奇 DM6446 平台中 Codec Server包含了一个为相应客户端 (ARM)生成编解码器提供系统运行信息 (包括指令和内存使用情况 ) 的 DSP BIOS任务线程客户端 (ARM) 的应用程序通过使用 VISA API 与在远程 DSP 上的编解码器联系

引擎集成第三步通过配置工具做大量的关于引擎配置的工

作包括引擎的名字每个引擎中包含什么编解码器编解码器是本地执行还是远程执行等如果这些编解码器在远程执行的则还需配置相应的 Codec Server 一般将所有的配置写到一个 cfg文件里面

这个配置文件包含的内容有 Codec Engine 运行的系统环境包括 xDC 通用模块和客户端操作系统类型等指明 Codec Engine需要用到的编解码器模块配置 Codec Engine 指明 Engine包含的内容

引擎引用 第四步应用工程师利用 Coedc Engine 的应用编程接口创

建删除配置好的引擎实例进而创建删除和控制编解码器由于 Codec Engine 不参与任何的 IO 操作只是纯粹的视频编解码算法处理因此应用工程师需要管理 IO 包括文件操作 (文件的打开读写与存储等 ) 和外设操作 ( 外设的打开关闭与控制等 )

应用工程师负责编写应用代码并将合适的内容加到最终的可执行文件中去应用工程师可使用以下资源从算法开发工程师得到的大量的编解码器软件包从服务集成工程师得到一个可以在 DSP 上运行的 Codec Server二进制文件一般为 x64P文件从引擎集成工程师得到一个引擎配置文件一般为 cfg文件应用工程师编写应用代码并结合这些资源再链接编译生成最终的可执行代码

虽然达芬奇技术带来了全新的开发平台和研发理念但是作为一项尚处于发展初期的技术仍然可能存在一些问题

首先是视频硬件加速器 VICP 的使用细节没有公开只有少数第三方厂商才能了解如何使用视频硬件加速器因此其他厂商开发 Codec 的难度就非常大

另外由于 DSP 与 ARM 双核结构的开发环境非常复杂 目前尚无一个完全集成 DSP 与 ARM 调试环境的集成开发环境因此需要同时进行 DSP 和 ARM 软件的跟踪调试必须运行两个独立的集成开发环境

另外 DSP 与 ARM 之间通信的协议接口也比较繁复

  • Slide 1
  • Slide 2
  • Slide 3
  • Slide 4
  • Slide 5
  • Slide 6
  • Slide 7
  • Slide 8
  • Slide 9
  • Slide 10
  • Slide 11
  • Slide 12
  • Slide 13
  • Slide 14
  • Slide 15
  • Slide 16
  • Slide 17
  • Slide 18
  • Slide 19
  • Slide 20
  • Slide 21
  • Slide 22
  • Slide 23
  • Slide 24
  • Slide 25
  • Slide 26
  • Slide 27
  • Slide 28
  • Slide 29
  • Slide 30
  • Slide 31
  • Slide 32
  • Slide 33
Page 16: 达芬奇平台简要介绍 汇报人:朱军 (控制组)

概括来说 VISA control 用来动态的修改 codec instance 的属性 VISA process 用来对算法的输入数据流做处理并返回一个输出数据流如下图所示应用程序在调用 VISA processcontrol 时会通过 xDM Stub把传递给 codec 算法的参数收集起来并且转换成 DSP 可以识别的物理地址 Stub把这些参数和相关的命令通过 Engine SPI OSAL 和 DSP Link传递到 DSP侧的 Instance Instance再通过 Skeleton把传递过来的参数和命令解析出来通过 DSP侧 VISA controlprocess 对 codec 算法执行 controlprocess

算法创建第一步需要基于 DSP利用 CCS 开发自己的音视

频编解码算法编译生成一个编解码算法的库文件lib(等同于 Linux 环境下的 a64P 直接在 Linux环境下修改文件后缀名即可 ) 由于需要确保算法可被 Codec Engine 使用和配置所以要确保这些算法实现需要符合 xDM(xDAIS(eXpress DSP Algorithm Interface Standard) for Digital Media) 标准

如果算法与 XDM 标准兼容 则可不经修改而直接被 Codec Engine 的 VISA API 远程执行如不兼容则需为其提供 Codec Engine 的框架和终端接口

服务集成 第二步生成一个在 DSP 上运行的可执行程序 x64P(即 out文件 ) 也就是 DSP Server

由于在双核环境中 Codec Engine 是在 DM6446 中的 DSP上执行而操作系统是由 DM6446 中的 ARM 通过 VISA API控制 Codec Engine 所以必须先在远程的 DSP生成一个 Codec Server Codec Server 是后缀为 x64P 的文件是一个集成了编解码器框架元件和系统代码的二进制库

在达芬奇 DM6446 平台中 Codec Server包含了一个为相应客户端 (ARM)生成编解码器提供系统运行信息 (包括指令和内存使用情况 ) 的 DSP BIOS任务线程客户端 (ARM) 的应用程序通过使用 VISA API 与在远程 DSP 上的编解码器联系

引擎集成第三步通过配置工具做大量的关于引擎配置的工

作包括引擎的名字每个引擎中包含什么编解码器编解码器是本地执行还是远程执行等如果这些编解码器在远程执行的则还需配置相应的 Codec Server 一般将所有的配置写到一个 cfg文件里面

这个配置文件包含的内容有 Codec Engine 运行的系统环境包括 xDC 通用模块和客户端操作系统类型等指明 Codec Engine需要用到的编解码器模块配置 Codec Engine 指明 Engine包含的内容

引擎引用 第四步应用工程师利用 Coedc Engine 的应用编程接口创

建删除配置好的引擎实例进而创建删除和控制编解码器由于 Codec Engine 不参与任何的 IO 操作只是纯粹的视频编解码算法处理因此应用工程师需要管理 IO 包括文件操作 (文件的打开读写与存储等 ) 和外设操作 ( 外设的打开关闭与控制等 )

应用工程师负责编写应用代码并将合适的内容加到最终的可执行文件中去应用工程师可使用以下资源从算法开发工程师得到的大量的编解码器软件包从服务集成工程师得到一个可以在 DSP 上运行的 Codec Server二进制文件一般为 x64P文件从引擎集成工程师得到一个引擎配置文件一般为 cfg文件应用工程师编写应用代码并结合这些资源再链接编译生成最终的可执行代码

虽然达芬奇技术带来了全新的开发平台和研发理念但是作为一项尚处于发展初期的技术仍然可能存在一些问题

首先是视频硬件加速器 VICP 的使用细节没有公开只有少数第三方厂商才能了解如何使用视频硬件加速器因此其他厂商开发 Codec 的难度就非常大

另外由于 DSP 与 ARM 双核结构的开发环境非常复杂 目前尚无一个完全集成 DSP 与 ARM 调试环境的集成开发环境因此需要同时进行 DSP 和 ARM 软件的跟踪调试必须运行两个独立的集成开发环境

另外 DSP 与 ARM 之间通信的协议接口也比较繁复

  • Slide 1
  • Slide 2
  • Slide 3
  • Slide 4
  • Slide 5
  • Slide 6
  • Slide 7
  • Slide 8
  • Slide 9
  • Slide 10
  • Slide 11
  • Slide 12
  • Slide 13
  • Slide 14
  • Slide 15
  • Slide 16
  • Slide 17
  • Slide 18
  • Slide 19
  • Slide 20
  • Slide 21
  • Slide 22
  • Slide 23
  • Slide 24
  • Slide 25
  • Slide 26
  • Slide 27
  • Slide 28
  • Slide 29
  • Slide 30
  • Slide 31
  • Slide 32
  • Slide 33
Page 17: 达芬奇平台简要介绍 汇报人:朱军 (控制组)

算法创建第一步需要基于 DSP利用 CCS 开发自己的音视

频编解码算法编译生成一个编解码算法的库文件lib(等同于 Linux 环境下的 a64P 直接在 Linux环境下修改文件后缀名即可 ) 由于需要确保算法可被 Codec Engine 使用和配置所以要确保这些算法实现需要符合 xDM(xDAIS(eXpress DSP Algorithm Interface Standard) for Digital Media) 标准

如果算法与 XDM 标准兼容 则可不经修改而直接被 Codec Engine 的 VISA API 远程执行如不兼容则需为其提供 Codec Engine 的框架和终端接口

服务集成 第二步生成一个在 DSP 上运行的可执行程序 x64P(即 out文件 ) 也就是 DSP Server

由于在双核环境中 Codec Engine 是在 DM6446 中的 DSP上执行而操作系统是由 DM6446 中的 ARM 通过 VISA API控制 Codec Engine 所以必须先在远程的 DSP生成一个 Codec Server Codec Server 是后缀为 x64P 的文件是一个集成了编解码器框架元件和系统代码的二进制库

在达芬奇 DM6446 平台中 Codec Server包含了一个为相应客户端 (ARM)生成编解码器提供系统运行信息 (包括指令和内存使用情况 ) 的 DSP BIOS任务线程客户端 (ARM) 的应用程序通过使用 VISA API 与在远程 DSP 上的编解码器联系

引擎集成第三步通过配置工具做大量的关于引擎配置的工

作包括引擎的名字每个引擎中包含什么编解码器编解码器是本地执行还是远程执行等如果这些编解码器在远程执行的则还需配置相应的 Codec Server 一般将所有的配置写到一个 cfg文件里面

这个配置文件包含的内容有 Codec Engine 运行的系统环境包括 xDC 通用模块和客户端操作系统类型等指明 Codec Engine需要用到的编解码器模块配置 Codec Engine 指明 Engine包含的内容

引擎引用 第四步应用工程师利用 Coedc Engine 的应用编程接口创

建删除配置好的引擎实例进而创建删除和控制编解码器由于 Codec Engine 不参与任何的 IO 操作只是纯粹的视频编解码算法处理因此应用工程师需要管理 IO 包括文件操作 (文件的打开读写与存储等 ) 和外设操作 ( 外设的打开关闭与控制等 )

应用工程师负责编写应用代码并将合适的内容加到最终的可执行文件中去应用工程师可使用以下资源从算法开发工程师得到的大量的编解码器软件包从服务集成工程师得到一个可以在 DSP 上运行的 Codec Server二进制文件一般为 x64P文件从引擎集成工程师得到一个引擎配置文件一般为 cfg文件应用工程师编写应用代码并结合这些资源再链接编译生成最终的可执行代码

虽然达芬奇技术带来了全新的开发平台和研发理念但是作为一项尚处于发展初期的技术仍然可能存在一些问题

首先是视频硬件加速器 VICP 的使用细节没有公开只有少数第三方厂商才能了解如何使用视频硬件加速器因此其他厂商开发 Codec 的难度就非常大

另外由于 DSP 与 ARM 双核结构的开发环境非常复杂 目前尚无一个完全集成 DSP 与 ARM 调试环境的集成开发环境因此需要同时进行 DSP 和 ARM 软件的跟踪调试必须运行两个独立的集成开发环境

另外 DSP 与 ARM 之间通信的协议接口也比较繁复

  • Slide 1
  • Slide 2
  • Slide 3
  • Slide 4
  • Slide 5
  • Slide 6
  • Slide 7
  • Slide 8
  • Slide 9
  • Slide 10
  • Slide 11
  • Slide 12
  • Slide 13
  • Slide 14
  • Slide 15
  • Slide 16
  • Slide 17
  • Slide 18
  • Slide 19
  • Slide 20
  • Slide 21
  • Slide 22
  • Slide 23
  • Slide 24
  • Slide 25
  • Slide 26
  • Slide 27
  • Slide 28
  • Slide 29
  • Slide 30
  • Slide 31
  • Slide 32
  • Slide 33
Page 18: 达芬奇平台简要介绍 汇报人:朱军 (控制组)

服务集成 第二步生成一个在 DSP 上运行的可执行程序 x64P(即 out文件 ) 也就是 DSP Server

由于在双核环境中 Codec Engine 是在 DM6446 中的 DSP上执行而操作系统是由 DM6446 中的 ARM 通过 VISA API控制 Codec Engine 所以必须先在远程的 DSP生成一个 Codec Server Codec Server 是后缀为 x64P 的文件是一个集成了编解码器框架元件和系统代码的二进制库

在达芬奇 DM6446 平台中 Codec Server包含了一个为相应客户端 (ARM)生成编解码器提供系统运行信息 (包括指令和内存使用情况 ) 的 DSP BIOS任务线程客户端 (ARM) 的应用程序通过使用 VISA API 与在远程 DSP 上的编解码器联系

引擎集成第三步通过配置工具做大量的关于引擎配置的工

作包括引擎的名字每个引擎中包含什么编解码器编解码器是本地执行还是远程执行等如果这些编解码器在远程执行的则还需配置相应的 Codec Server 一般将所有的配置写到一个 cfg文件里面

这个配置文件包含的内容有 Codec Engine 运行的系统环境包括 xDC 通用模块和客户端操作系统类型等指明 Codec Engine需要用到的编解码器模块配置 Codec Engine 指明 Engine包含的内容

引擎引用 第四步应用工程师利用 Coedc Engine 的应用编程接口创

建删除配置好的引擎实例进而创建删除和控制编解码器由于 Codec Engine 不参与任何的 IO 操作只是纯粹的视频编解码算法处理因此应用工程师需要管理 IO 包括文件操作 (文件的打开读写与存储等 ) 和外设操作 ( 外设的打开关闭与控制等 )

应用工程师负责编写应用代码并将合适的内容加到最终的可执行文件中去应用工程师可使用以下资源从算法开发工程师得到的大量的编解码器软件包从服务集成工程师得到一个可以在 DSP 上运行的 Codec Server二进制文件一般为 x64P文件从引擎集成工程师得到一个引擎配置文件一般为 cfg文件应用工程师编写应用代码并结合这些资源再链接编译生成最终的可执行代码

虽然达芬奇技术带来了全新的开发平台和研发理念但是作为一项尚处于发展初期的技术仍然可能存在一些问题

首先是视频硬件加速器 VICP 的使用细节没有公开只有少数第三方厂商才能了解如何使用视频硬件加速器因此其他厂商开发 Codec 的难度就非常大

另外由于 DSP 与 ARM 双核结构的开发环境非常复杂 目前尚无一个完全集成 DSP 与 ARM 调试环境的集成开发环境因此需要同时进行 DSP 和 ARM 软件的跟踪调试必须运行两个独立的集成开发环境

另外 DSP 与 ARM 之间通信的协议接口也比较繁复

  • Slide 1
  • Slide 2
  • Slide 3
  • Slide 4
  • Slide 5
  • Slide 6
  • Slide 7
  • Slide 8
  • Slide 9
  • Slide 10
  • Slide 11
  • Slide 12
  • Slide 13
  • Slide 14
  • Slide 15
  • Slide 16
  • Slide 17
  • Slide 18
  • Slide 19
  • Slide 20
  • Slide 21
  • Slide 22
  • Slide 23
  • Slide 24
  • Slide 25
  • Slide 26
  • Slide 27
  • Slide 28
  • Slide 29
  • Slide 30
  • Slide 31
  • Slide 32
  • Slide 33
Page 19: 达芬奇平台简要介绍 汇报人:朱军 (控制组)

引擎集成第三步通过配置工具做大量的关于引擎配置的工

作包括引擎的名字每个引擎中包含什么编解码器编解码器是本地执行还是远程执行等如果这些编解码器在远程执行的则还需配置相应的 Codec Server 一般将所有的配置写到一个 cfg文件里面

这个配置文件包含的内容有 Codec Engine 运行的系统环境包括 xDC 通用模块和客户端操作系统类型等指明 Codec Engine需要用到的编解码器模块配置 Codec Engine 指明 Engine包含的内容

引擎引用 第四步应用工程师利用 Coedc Engine 的应用编程接口创

建删除配置好的引擎实例进而创建删除和控制编解码器由于 Codec Engine 不参与任何的 IO 操作只是纯粹的视频编解码算法处理因此应用工程师需要管理 IO 包括文件操作 (文件的打开读写与存储等 ) 和外设操作 ( 外设的打开关闭与控制等 )

应用工程师负责编写应用代码并将合适的内容加到最终的可执行文件中去应用工程师可使用以下资源从算法开发工程师得到的大量的编解码器软件包从服务集成工程师得到一个可以在 DSP 上运行的 Codec Server二进制文件一般为 x64P文件从引擎集成工程师得到一个引擎配置文件一般为 cfg文件应用工程师编写应用代码并结合这些资源再链接编译生成最终的可执行代码

虽然达芬奇技术带来了全新的开发平台和研发理念但是作为一项尚处于发展初期的技术仍然可能存在一些问题

首先是视频硬件加速器 VICP 的使用细节没有公开只有少数第三方厂商才能了解如何使用视频硬件加速器因此其他厂商开发 Codec 的难度就非常大

另外由于 DSP 与 ARM 双核结构的开发环境非常复杂 目前尚无一个完全集成 DSP 与 ARM 调试环境的集成开发环境因此需要同时进行 DSP 和 ARM 软件的跟踪调试必须运行两个独立的集成开发环境

另外 DSP 与 ARM 之间通信的协议接口也比较繁复

  • Slide 1
  • Slide 2
  • Slide 3
  • Slide 4
  • Slide 5
  • Slide 6
  • Slide 7
  • Slide 8
  • Slide 9
  • Slide 10
  • Slide 11
  • Slide 12
  • Slide 13
  • Slide 14
  • Slide 15
  • Slide 16
  • Slide 17
  • Slide 18
  • Slide 19
  • Slide 20
  • Slide 21
  • Slide 22
  • Slide 23
  • Slide 24
  • Slide 25
  • Slide 26
  • Slide 27
  • Slide 28
  • Slide 29
  • Slide 30
  • Slide 31
  • Slide 32
  • Slide 33
Page 20: 达芬奇平台简要介绍 汇报人:朱军 (控制组)

引擎引用 第四步应用工程师利用 Coedc Engine 的应用编程接口创

建删除配置好的引擎实例进而创建删除和控制编解码器由于 Codec Engine 不参与任何的 IO 操作只是纯粹的视频编解码算法处理因此应用工程师需要管理 IO 包括文件操作 (文件的打开读写与存储等 ) 和外设操作 ( 外设的打开关闭与控制等 )

应用工程师负责编写应用代码并将合适的内容加到最终的可执行文件中去应用工程师可使用以下资源从算法开发工程师得到的大量的编解码器软件包从服务集成工程师得到一个可以在 DSP 上运行的 Codec Server二进制文件一般为 x64P文件从引擎集成工程师得到一个引擎配置文件一般为 cfg文件应用工程师编写应用代码并结合这些资源再链接编译生成最终的可执行代码

虽然达芬奇技术带来了全新的开发平台和研发理念但是作为一项尚处于发展初期的技术仍然可能存在一些问题

首先是视频硬件加速器 VICP 的使用细节没有公开只有少数第三方厂商才能了解如何使用视频硬件加速器因此其他厂商开发 Codec 的难度就非常大

另外由于 DSP 与 ARM 双核结构的开发环境非常复杂 目前尚无一个完全集成 DSP 与 ARM 调试环境的集成开发环境因此需要同时进行 DSP 和 ARM 软件的跟踪调试必须运行两个独立的集成开发环境

另外 DSP 与 ARM 之间通信的协议接口也比较繁复

  • Slide 1
  • Slide 2
  • Slide 3
  • Slide 4
  • Slide 5
  • Slide 6
  • Slide 7
  • Slide 8
  • Slide 9
  • Slide 10
  • Slide 11
  • Slide 12
  • Slide 13
  • Slide 14
  • Slide 15
  • Slide 16
  • Slide 17
  • Slide 18
  • Slide 19
  • Slide 20
  • Slide 21
  • Slide 22
  • Slide 23
  • Slide 24
  • Slide 25
  • Slide 26
  • Slide 27
  • Slide 28
  • Slide 29
  • Slide 30
  • Slide 31
  • Slide 32
  • Slide 33
Page 21: 达芬奇平台简要介绍 汇报人:朱军 (控制组)

虽然达芬奇技术带来了全新的开发平台和研发理念但是作为一项尚处于发展初期的技术仍然可能存在一些问题

首先是视频硬件加速器 VICP 的使用细节没有公开只有少数第三方厂商才能了解如何使用视频硬件加速器因此其他厂商开发 Codec 的难度就非常大

另外由于 DSP 与 ARM 双核结构的开发环境非常复杂 目前尚无一个完全集成 DSP 与 ARM 调试环境的集成开发环境因此需要同时进行 DSP 和 ARM 软件的跟踪调试必须运行两个独立的集成开发环境

另外 DSP 与 ARM 之间通信的协议接口也比较繁复

  • Slide 1
  • Slide 2
  • Slide 3
  • Slide 4
  • Slide 5
  • Slide 6
  • Slide 7
  • Slide 8
  • Slide 9
  • Slide 10
  • Slide 11
  • Slide 12
  • Slide 13
  • Slide 14
  • Slide 15
  • Slide 16
  • Slide 17
  • Slide 18
  • Slide 19
  • Slide 20
  • Slide 21
  • Slide 22
  • Slide 23
  • Slide 24
  • Slide 25
  • Slide 26
  • Slide 27
  • Slide 28
  • Slide 29
  • Slide 30
  • Slide 31
  • Slide 32
  • Slide 33