处理器SDK概览

前面介绍的主要是关于是芯片产品类的产品

就是芯片像 Sitara 系列 Keystone 系列

还有 Sitara 的应用

然后接下来我们可能

主要谈一下关于我们这个 processor SDK

因为现在这个我们这个产品主要是一个 ARM

和加 DSP 核的这种异构的架构

所以很多客户在做这个

在这个 soc 上去开发产品的话

可能会遇到很多的麻烦吧

就是因为你要熟悉 ARM 核 要熟悉 DSP 核

而且还要熟悉这个核与核之间的通信

这里基于这个情况的话

我们软件那边就是

把 ARM DSP 还有核间通信

以及可能在 ARM 和 DSP 上

会用到的一些基础的这种

软件都把它合并到一起

然后就是组成了这个叫做

processor SDK

这一部分我们分成三个章节

一个是讲就是我们首先是一个基本的一个介绍

然后是介绍关于 processor SDK Linux 这一块

Linux 这一块当然主要是跑在 ARM 上面

然后是关于 processor SDK RTOS 这一块

RTOS 其实既可以跑在 ARM

也可以跑在 DSP上

但是一般情况下可能客户在 ARM上跑 Linux

在 DSP 上跑 RTOS 这种情况会比较多一些

首先我们来看看一个基本的介绍

这个图是一个最大

就是等于是分层的一个框图

底层是我们的硬件产品

这里只列出了 AM57 这个系列

当然其实 335 437

还有 Keystone Keystone2

这些系列都是现在都有对应的

processor SDK 来支持

然后往上就是硬件的抽象层

抽象层这一块就是我们的

像 CSL 库 PDK 这些驱动

然后它把所有的这种底层驱动

都包含在硬件抽象层里面

往上一层就是这个操作系统

操作系统主要就是 Linux

real time 的 Linux 和我们现在TI 的 RTOS

RTOS 沿用的就是原来 bios

cis bios dsp bios 那套核心

然后在操作系统上面就是我们的用户代码

然后就是基于 bios

或者是基于 Linux 用户的 代码

这是个 AM57 的框图

刚才介绍了很多

这里就不细讲了

对于我们这个操作系统来看的话

大家可以看到在 AM57 这个系统里面的话

我们有不同的这个处理器的核

像 A15

像这个 DSP

还有我们的 M4

以及 PRU

然后从一般的情况来看的话

我们能会在 A15 里面跑 Linux 的操作系统

当然你也可以跑我们 TI 的

实时的 RTOS 的操作系统

其它当然还有像我们QX

都会有一些很多的操作系统

都可以跑在我们 ARM 的处理器上

然后 c66 这一块的话

大部分可能用的都是 TI 的 RTOS

就是我们的这个原来的 DSP bios

这一块依然可能是作为我们

processor SDK 里面支持的主流的平台

但是也有许多客户说

我需要一个最强的实时的系统

也需要我自己能够很好的

去控制 DSP 底层的东西

然后它可能会使用

实际上就是一个裸跑的方式

再我们自己在里面实现中断

自己在里面可能实现一些简单的任务调度

这个是由客户自己来定制的

然后 M4 里面也是同样的

我们 M4 里面也可以去跑我们的 TI RTOS

就是我们 bios 操作系统的内核

因为 bios 本身是可以裁剪的

你可以根据它

根据核的不同

根据你的需要来裁剪不同的模块

然后 PRU 这边

我们因为 TI 都是有提供对应的firmware

或者是我们第三方提供的firmware

这个就不细讲了

然后对于我们在 A15上的软件架构来说

一般情况下我们在 A15 里面跑的是

Linux 的操作系统

而我们开发的上位机也一般都是

用 Linux 的操作系统来做

然后 DSP 这边一般是跑

我们刚才也讲了

主要是跑 bios ROTS 系统

然后我们现在 DSP 的话

主要的调试都是通过 CCS来做

这种具体的调试工作

还是跟原来一样

就是以连接 JTAG 用 bios

不管你是用 bios 也好

还是你自己的代码也好

都是用 CCS 然后用 JTAG 连上 DSP核

来做这种 DSP 核上的调试

我们其实在 processor SDK 里面

已经实现了 OpenCL 的架构

然后我们可以实现 ARM 和DSP 之间的任务

进程的互相通信和调度

整个基于的是 OpenCL 的框架

M4 这边的话就是刚才也讲到我们

有跑 RTOS

也有自己写的一些代码

可以这种 open 的一种形式

然后它是通过这种我们的 IPC

就是我们核间通信的 library 来做这个通信的

PRU 这一块可能主要的还是

firmware 本身是定制的

所以firmware具体怎么跟设备通信

这个里面我们要根据不同的firmware来看

同样的如果可能有些客户要求

比如说你不需要再跑这个

就因为 Linux 的实时性毕竟是有限

可能有些客户希望一个简单的

就是一个简单的实时性更好的一个操作系统

就会在我们的 A15 上运行 TI 的 RTOS

然后同样的在 DSP 上

也是运行 TI 的 RTOS 的操作系统

这样的话我们是通过 IPC 来进行通信的

IPC 是我们实现的一个

就是在跨核

不同的核之间进行这个

数据通信也好或者是事件通信也好

这样的一个 library

这样的一个 library

然后它能够在 ARM 上

比如说跑一个 IPC 的进程

比如说跑一个 IPC 的进程

然后在 DSP上跑一个进程

然后就可以在这两个进程之间

进行数据的交换和通信

所以其实对于我们的客户来讲

应该说选择也比较多

然后可能 ARM 这一块呢

就是刚才讲选 Linux 的可能会更多一些

像 DSP 啊 M4啊这一块

可能选这个 RTOS 的会更多一些

当然这个其实

应该说是给了大家比较大的自由选择的空间

前面介绍的主要是关于是芯片产品类的产品

就是芯片像 Sitara 系列 Keystone 系列

还有 Sitara 的应用

然后接下来我们可能

主要谈一下关于我们这个 processor SDK

因为现在这个我们这个产品主要是一个 ARM

和加 DSP 核的这种异构的架构

所以很多客户在做这个

在这个 soc 上去开发产品的话

可能会遇到很多的麻烦吧

就是因为你要熟悉 ARM 核 要熟悉 DSP 核

而且还要熟悉这个核与核之间的通信

这里基于这个情况的话

我们软件那边就是

把 ARM DSP 还有核间通信

以及可能在 ARM 和 DSP 上

会用到的一些基础的这种

软件都把它合并到一起

然后就是组成了这个叫做

processor SDK

这一部分我们分成三个章节

一个是讲就是我们首先是一个基本的一个介绍

然后是介绍关于 processor SDK Linux 这一块

Linux 这一块当然主要是跑在 ARM 上面

然后是关于 processor SDK RTOS 这一块

RTOS 其实既可以跑在 ARM

也可以跑在 DSP上

但是一般情况下可能客户在 ARM上跑 Linux

在 DSP 上跑 RTOS 这种情况会比较多一些

首先我们来看看一个基本的介绍

这个图是一个最大

就是等于是分层的一个框图

底层是我们的硬件产品

这里只列出了 AM57 这个系列

当然其实 335 437

还有 Keystone Keystone2

这些系列都是现在都有对应的

processor SDK 来支持

然后往上就是硬件的抽象层

抽象层这一块就是我们的

像 CSL 库 PDK 这些驱动

然后它把所有的这种底层驱动

都包含在硬件抽象层里面

往上一层就是这个操作系统

操作系统主要就是 Linux

real time 的 Linux 和我们现在TI 的 RTOS

RTOS 沿用的就是原来 bios

cis bios dsp bios 那套核心

然后在操作系统上面就是我们的用户代码

然后就是基于 bios

或者是基于 Linux 用户的 代码

这是个 AM57 的框图

刚才介绍了很多

这里就不细讲了

对于我们这个操作系统来看的话

大家可以看到在 AM57 这个系统里面的话

我们有不同的这个处理器的核

像 A15

像这个 DSP

还有我们的 M4

以及 PRU

然后从一般的情况来看的话

我们能会在 A15 里面跑 Linux 的操作系统

当然你也可以跑我们 TI 的

实时的 RTOS 的操作系统

其它当然还有像我们QX

都会有一些很多的操作系统

都可以跑在我们 ARM 的处理器上

然后 c66 这一块的话

大部分可能用的都是 TI 的 RTOS

就是我们的这个原来的 DSP bios

这一块依然可能是作为我们

processor SDK 里面支持的主流的平台

但是也有许多客户说

我需要一个最强的实时的系统

也需要我自己能够很好的

去控制 DSP 底层的东西

然后它可能会使用

实际上就是一个裸跑的方式

再我们自己在里面实现中断

自己在里面可能实现一些简单的任务调度

这个是由客户自己来定制的

然后 M4 里面也是同样的

我们 M4 里面也可以去跑我们的 TI RTOS

就是我们 bios 操作系统的内核

因为 bios 本身是可以裁剪的

你可以根据它

根据核的不同

根据你的需要来裁剪不同的模块

然后 PRU 这边

我们因为 TI 都是有提供对应的firmware

或者是我们第三方提供的firmware

这个就不细讲了

然后对于我们在 A15上的软件架构来说

一般情况下我们在 A15 里面跑的是

Linux 的操作系统

而我们开发的上位机也一般都是

用 Linux 的操作系统来做

然后 DSP 这边一般是跑

我们刚才也讲了

主要是跑 bios ROTS 系统

然后我们现在 DSP 的话

主要的调试都是通过 CCS来做

这种具体的调试工作

还是跟原来一样

就是以连接 JTAG 用 bios

不管你是用 bios 也好

还是你自己的代码也好

都是用 CCS 然后用 JTAG 连上 DSP核

来做这种 DSP 核上的调试

我们其实在 processor SDK 里面

已经实现了 OpenCL 的架构

然后我们可以实现 ARM 和DSP 之间的任务

进程的互相通信和调度

整个基于的是 OpenCL 的框架

M4 这边的话就是刚才也讲到我们

有跑 RTOS

也有自己写的一些代码

可以这种 open 的一种形式

然后它是通过这种我们的 IPC

就是我们核间通信的 library 来做这个通信的

PRU 这一块可能主要的还是

firmware 本身是定制的

所以firmware具体怎么跟设备通信

这个里面我们要根据不同的firmware来看

同样的如果可能有些客户要求

比如说你不需要再跑这个

就因为 Linux 的实时性毕竟是有限

可能有些客户希望一个简单的

就是一个简单的实时性更好的一个操作系统

就会在我们的 A15 上运行 TI 的 RTOS

然后同样的在 DSP 上

也是运行 TI 的 RTOS 的操作系统

这样的话我们是通过 IPC 来进行通信的

IPC 是我们实现的一个

就是在跨核

不同的核之间进行这个

数据通信也好或者是事件通信也好

这样的一个 library

这样的一个 library

然后它能够在 ARM 上

比如说跑一个 IPC 的进程

比如说跑一个 IPC 的进程

然后在 DSP上跑一个进程

然后就可以在这两个进程之间

进行数据的交换和通信

所以其实对于我们的客户来讲

应该说选择也比较多

然后可能 ARM 这一块呢

就是刚才讲选 Linux 的可能会更多一些

像 DSP 啊 M4啊这一块

可能选这个 RTOS 的会更多一些

当然这个其实

应该说是给了大家比较大的自由选择的空间