本帖最后由 peng85246 于 2020-3-25 11:16 編輯
一、什么是異構(gòu)多核SoC處理器
顧名思義,單顆芯片內(nèi)集成多個(gè)不同架構(gòu)處理單元核心的SoC處理器,我們稱之為異構(gòu)多核SoC處理器,比如: - TI的OMAP-L138(DSP C674x + ARM9)、AM5708(DSP C66x + ARM Cortex-A15)SoC處理器等;
- Xilinx的ZYNQ(ARM Cortex-A9 + Artix-7/Kintex-7可編程邏輯架構(gòu))SoC處理器等。
二、異構(gòu)多核SoC處理器有什么優(yōu)勢 相對于單核處理器,異構(gòu)多核SoC處理器能帶來性能、成本、功耗、尺寸等更多的組合優(yōu)勢,不同架構(gòu)間各司其職,各自發(fā)揮原本架構(gòu)獨(dú)特的優(yōu)勢。比如: - ARM廉價(jià)、耗能低,擅長進(jìn)行控制操作和多媒體顯示;
- DSP天生為數(shù)字信號(hào)處理而生,擅長進(jìn)行專用算法運(yùn)算;
- FPGA擅長高速、多通道數(shù)據(jù)采集和信號(hào)傳輸。
同時(shí),異構(gòu)多核SoC處理器核間通過各種通信方式,快速進(jìn)行數(shù)據(jù)的傳輸和共享,可完美實(shí)現(xiàn)1+1>2的效果。
三、常見核間通信方式 要充分發(fā)揮異構(gòu)多核SoC處理器的性能,除開半導(dǎo)體廠家對芯片的硬件 封裝外,關(guān)鍵點(diǎn)還在于核間通信的軟硬件機(jī)制設(shè)計(jì),下面介紹幾種在TI、Xilinx異構(gòu)多核SoC處理器上常見的核間通信方式。 OpenCL(全稱Open Computing Language,開放運(yùn)算語言)是第一個(gè)面向異構(gòu)系統(tǒng)通用目的并行編程的開放式、免費(fèi)標(biāo)準(zhǔn),也是一個(gè)統(tǒng)一的編程環(huán)境,便于軟件開發(fā)人員編寫高效輕便的代碼,而且廣泛適用于多核心處理器(CPU)、圖形處理器(GPU)、Cell類型架構(gòu)以及數(shù)字信號(hào)處理器(DSP)等其他并行處理器,在能源電力、軌道交通、工業(yè)自動(dòng)化、醫(yī)療、通信、軍工等應(yīng)用領(lǐng)域都有廣闊的發(fā)展前景。
在異構(gòu)多核SoC處理器上,OpenCL將其中一個(gè)可編程內(nèi)核視為主機(jī),將其他內(nèi)核視為設(shè)備。在主機(jī)上運(yùn)行的應(yīng)用程序(即主機(jī)程序)管理設(shè)備上的代碼(內(nèi)核)的執(zhí)行,并且還負(fù)責(zé)使數(shù)據(jù)可用于設(shè)備。設(shè)備由一個(gè)或多個(gè)計(jì)算單元組成。比如,在TI AM5728異構(gòu)多核SoC處理器中,每個(gè)C66x DSP都是一個(gè)計(jì)算單元。
OpenCL運(yùn)行時(shí),一般包含如下兩個(gè)組件:
- 主機(jī)程序創(chuàng)建和提交內(nèi)核以供執(zhí)行的API。
- 用于表達(dá)內(nèi)核的跨平臺(tái)語言。
2.DCE DCE(Distributed Codec Engine)分布式編解碼器引擎,是TI基于AM57x異構(gòu)多核SoC處理器的視頻處理框架,提供的完整Gstreamer插件框架。
DCE由三部分硬件模塊組成,分別為MPU核心、IPU2核心以及IVA-HD硬件加速器,其主要功能如下:
MPU:基于ARM用戶空間Gstreamer應(yīng)用,控制libdce模塊。libdce模塊在ARM RPMSG框架上實(shí)現(xiàn)與IPU2的IPC通信。
IPU2:構(gòu)建DCE server,基于RPMSG框架與ARM實(shí)現(xiàn)通信,使用編解碼器引擎和幀組件控制IVA-HD加速器。
IVA-HD:實(shí)現(xiàn)視頻/圖像編解碼的硬件加速器。 3.IPC IPC(Inter-Processor Communication)是一組旨在促進(jìn)進(jìn)程間通信的模塊。通信包括消息傳遞、流和鏈接列表。這些模塊提供的服務(wù)和功能可用于異構(gòu)多核SoC處理器中ARM和DSP核心之間的通信。
如下為TI異構(gòu)多核SoC處理器常用的核間通信方式的優(yōu)缺點(diǎn)比較:
方式 | 優(yōu)點(diǎn) | 缺點(diǎn) | | - 易于在設(shè)備之間移植
- 無需了解內(nèi)存架構(gòu)
- 無需擔(dān)心MPAX和MMU
- 無需擔(dān)心一致性
- 無需在ARM和DSP之間構(gòu)建/配置/使用IPC
- 無需成為DSP代碼、架構(gòu)或優(yōu)化方面的專家
| - 無法控制系統(tǒng)內(nèi)存布局等以處理優(yōu)化的DSP代碼
| | - 加速多媒體編解碼處理
- 在與Gstreamer和TI Gstreamer插件連接時(shí)簡化多媒體應(yīng)用程序的開發(fā)
| - 不適合非編解碼算法
- 需要努力添加新的編解碼算法
- 需要DSP編程知識(shí)
| | - 完全控制DSP配置
- 能夠進(jìn)行DSP代碼優(yōu)化
- 在多個(gè)TI平臺(tái)上支持相同的API
| - 需要了解內(nèi)存架構(gòu)
- 需要了解DSP配置和編程
- 僅限于小型消息(小于512字節(jié))
- TI專有API
| 4.AXI
AXI(Advanced eXtensible Interface)是由ARM公司提出的一種總線協(xié)議,Xilinx從6系列的FPGA開始對AXI總線提供支持,目前使用AXI4版本。
ZYNQ有三種AXI總線:
(A)AXI4:(For high-performance memory-mapped requirements.)主要面向高性能地址映射通信的需求,是面向地址映射的接口,允許最大256輪的數(shù)據(jù)突發(fā)傳輸。
(B)AXI4-Lite:(For simple, low-throughput memory-mapped communication.)是一個(gè)輕量級(jí)的地址映射單次傳輸接口,占用很少的邏輯單元。
(C)AXI4-Stream:(For high-speed streaming data.)面向高速流數(shù)據(jù)傳輸,去掉了地址項(xiàng),允許無限制的數(shù)據(jù)突發(fā)傳輸規(guī)模。 AXI協(xié)議的制定是要建立在總線構(gòu)成之上的。因此,AXI4、AXI4-Lite、AXI4-Stream都是AXI4協(xié)議。AXI總線協(xié)議的兩端可以分為分為主(master)、從(slave)兩端,他們之間一般需要通過一個(gè)AXI Interconnect相連接,作用是提供將一個(gè)或多個(gè)AXI主設(shè)備連接到一個(gè)或多個(gè)AXI從設(shè)備的一種交換機(jī)制。
AXI Interconnect的主要作用是:當(dāng)存在多個(gè)主機(jī)以及從機(jī)器時(shí),AXIInterconnect負(fù)責(zé)將它們聯(lián)系并管理起來。由于AXI支持亂序發(fā)送,亂序發(fā)送需要主機(jī)的ID信號(hào)支撐,而不同的主機(jī)發(fā)送的ID可能相同,而AXI Interconnect解決了這一問題,他會(huì)對不同主機(jī)的ID信號(hào)進(jìn)行處理讓ID變得唯一。
AXI協(xié)議將讀地址通道、讀數(shù)據(jù)通道、寫地址通道、寫數(shù)據(jù)通道、寫響應(yīng)通道分開,各自通道都有自己的握手協(xié)議。每個(gè)通道互不干擾卻又彼此依賴。這是AXI高效的原因之一。
四、IPC核間通信開發(fā) 下面以創(chuàng)龍AM57x(AM5728/AM5708)評(píng)估板源碼為例,講解IPC核間通信開發(fā)。
- RTOS Processor-SDK 04.03.00.05。
- Linux-4.9.65/Linux-RT-4.9.65內(nèi)核。
- IPC開發(fā)包版本:3.47.01.00。
IPC(Inter-Processor Communication)提供了一個(gè)與處理器無關(guān)的API,可用于多處理核心環(huán)境中的核間通信、與同一處理核心上的其他線程的通信(進(jìn)程間)和與外圍設(shè)備(設(shè)備間)的通信。IPC定義了以下幾種通信組件,如下表所示,這些通信組件的接口都有以下幾個(gè)共同點(diǎn): | | | | | FrameQ(通常用于raw視頻數(shù)據(jù)) | | RingIO(通常用于音頻數(shù)據(jù)) |
- 所有IPC通信組件的接口都由系統(tǒng)規(guī)范化命名。
- 在HLOS端,所有IPC接口需要使用_setup()來初始化,使用_destroy()來銷毀相應(yīng)的IPC Module;部分初始化還需要提供配置接口_config()。
- 所有的實(shí)例化都需要使用_create()來創(chuàng)建,使用_delete()來刪除。
- 在更深層次使用IPC時(shí)需要用_open()來獲取handle,在結(jié)束使用IPC時(shí)需要用_close()來回收handle。
- IPC的配置多數(shù)都是在SYS/BIOS下完成配置的,對于支持XDC配置的則可以使用靜態(tài)配置方法。
- 每個(gè)IPC模塊都支持trace信息用于調(diào)試,而且支持不同的trace等級(jí)。
- 部分IPCs提供了專門的APIs來用于提取分析信息。
​​​​​​​
本小節(jié)主要演示MessageQ通信組件的運(yùn)用。
2.MessageQ機(jī)制 - 支持結(jié)構(gòu)化發(fā)送和接收可變長度消息。
- 一個(gè)MessageQ都將有一個(gè)讀者,多個(gè)編寫者。
- 既可用于同構(gòu)和異構(gòu)多處理器消息傳遞,也可用于線程之間的單處理器消息傳遞。
- 功能強(qiáng)大,簡單易用。
​​​​​​​
2.MessageQ機(jī)制代碼解釋
MessageQ的傳輸,主要區(qū)分為發(fā)送者,跟接收者,下述為常用API的功能描述: - MessageQ_Handle MessageQ_create (String name, MessageQ_Params *params):創(chuàng)建消息隊(duì)列,創(chuàng)建隊(duì)列名稱將成為后面MessageQ_open的依據(jù)。
- Int MessageQ_open(String name , MessageQ_QueueId * queueId):打開創(chuàng)建的消息隊(duì)列,獲取隊(duì)列ID值(ID值應(yīng)為唯一值,所以創(chuàng)建消息隊(duì)列時(shí)名稱要唯一)。
- MessageQ_Msg MessageQ_alloc(UInt16 heapId, UInt32 size):申請消息空間,從heap中申請,所以需要先打開heap獲取heapID,消息由MessageQ_Msg結(jié)構(gòu)體長度規(guī)定。
- MessageQ_registerHeap(HeapBufMP_Handle_upCast(heapHandle),HEAPID):注冊堆,分配heapID給這個(gè)堆,作為一個(gè)唯一標(biāo)識(shí)符。
- Int MessageQ_put(MessageQ_QueueId queueId, MessageQ_Msg msg):發(fā)送消息到queueId對應(yīng)的消息隊(duì)列。
- Int MessageQ_get(MessageQ_Handle handle,MessageQ_Msg *msg,UInt timeout):從消息隊(duì)列中接收消息。
- MessageQ_free(MessageQ_Msg *msg):釋放msg空間,注意不用的消息空間需要釋放,不然會(huì)導(dǎo)致內(nèi)存問題。以ex02_messageq例程為例,說明MessageQ機(jī)制的使用過程:
​​​​​​​
例程運(yùn)行流程圖如下: 結(jié)合實(shí)際代碼分析上述流程:
ARM:
a)創(chuàng)建host消息隊(duì)列,打開slave消息隊(duì)列。
b)發(fā)送消息至slave消息隊(duì)列,監(jiān)聽host消息隊(duì)列,等待返回信息 。 c)發(fā)送shutdown消息至slave隊(duì)列。
DSP:
a)創(chuàng)建slave消息隊(duì)列。
b)監(jiān)聽slave消息隊(duì)列,并返回消息至host端。 c)接收shutdown消息,停止任務(wù)。
3.內(nèi)存訪問與地址映射問題。 首先,對于DSP/IPU子系統(tǒng)和L3互連之間的存儲(chǔ)器管理單元(MMU),都用于將虛擬地址(即DSP/IPU子系統(tǒng)所查看的地址)轉(zhuǎn)換為物理地址(即從L3互連中看到的地址)。 DSP:MMU0用于DSP內(nèi)核,MMU1用于本地EDMA。 IPU:IPUx_UNICACHE_MMU用于一級(jí)映射,IPUx_MMU用于二級(jí)映射。 rsc_table_dspx.h,rsc_table_ipux.h資源表中,配置了DSP/IPU子系統(tǒng)的映射關(guān)系,在固件啟動(dòng)前,該映射關(guān)系將會(huì)寫入寄存器,完成映射過程。 物理地址跟虛擬地址之間的映射關(guān)系查看: DSP1:(默認(rèn)配置mmu1的配置與mmu2的配置是一樣的) cat /sys/kernel/debug/omap_iommu/40d01000.mmu/pagetable cat /sys/kernel/debug/omap_iommu/40d02000.mmu/pagetable
DSP2:(默認(rèn)配置mmu1的配置與mmu2的配置是一樣的) cat /sys/kernel/debug/omap_iommu/41501000.mmu/pagetable cat /sys/kernel/debug/omap_iommu/41502000.mmu/pagetable
IPU1: cat /sys/kernel/debug/omap_iommu/58882000.mmu/pagetable
IPU2: cat /sys/kernel/debug/omap_iommu/55082000.mmu/pagetable CMA內(nèi)存,用于存放IPC程序的堆棧,代碼以及數(shù)據(jù)段。
dts文件中,預(yù)留了幾段空間作為從核的段空間(DDR空間):
IPC-demo/shared/config.bld:用于配置段空間的起始地址,以及段大小。 以DSP1為例,說明DMA中的內(nèi)存映射關(guān)系:
通過系統(tǒng)中查看虛擬地址表,左邊da(device address)對應(yīng)的為虛擬地址,右邊對應(yīng)的為物理地址,那么虛擬地址的0x95000000的地址映射到的應(yīng)該是0x99100002的物理地址。 cat /sys/kernel/debug/omap_iommu/40d01000.mmu/pagetable
2.共享內(nèi)存 共享內(nèi)存:其實(shí)是一塊“大家”都可以訪問的內(nèi)存。
CMEM是一個(gè)內(nèi)核驅(qū)動(dòng)(ARM),是為了分配一個(gè)或多個(gè)block(連續(xù)的內(nèi)存分配),更好地去管理內(nèi)存的申請(一個(gè)或多個(gè)連續(xù)的內(nèi)存分配block),釋放以及內(nèi)存碎片的回收。
CMEM內(nèi)存:由linux預(yù)留,CMEM驅(qū)動(dòng)管理的一段空間。
arch/arm/boot/dts/am57xx-evm-cmem.dtsi中定義了CMEM,并預(yù)留了空間出來作為共享內(nèi)存(DDR & OCMC空間)。 cmem{}中最大分配的block數(shù)量為4個(gè),cmem-buf-pools的數(shù)量沒有限制。
實(shí)際使用上,DSP與IPU訪問的都是虛擬地址,所以還要完成虛擬地址到物理地址的映射關(guān)系。
dsp1/rsc_table_dsp1.h定義了虛擬地址到物理地址的映射表,虛擬地址(0x85000000)到物理地址0xA0000000的映射,那么在DSP端訪問0x85000000的地址時(shí),實(shí)際上通過映射訪問的物理地址應(yīng)是0xA0000000。 cat /sys/kernel/debug/omap_iommu/40d01000.mmu/pagetable
實(shí)際應(yīng)用:
a)初始化cmem。
b)申請內(nèi)存空間,并轉(zhuǎn)換為物理地址(msg傳輸?shù)臅r(shí)候傳輸?shù)氖俏锢淼刂罚駝t傳輸虛擬地址有不確定性)。
DSP端的處理:接收物理地址,轉(zhuǎn)換為虛擬地址進(jìn)行操作,發(fā)送操作完成的結(jié)果。這里DSP需要將地址返回給ARM的話,那應(yīng)該將虛擬地址轉(zhuǎn)換為物理地址,再傳給ARM端。
關(guān)于創(chuàng)龍
Tronlong專注于異構(gòu)多核SoC技術(shù)開發(fā),作為TI、Xilinx官方合作伙伴,擁有OMAP-L138、AM5708、AM5728、ZYNQ、MPSoC等眾多異構(gòu)多核SoC平臺(tái)產(chǎn)品,提供多種核間通信工程案例,可縮短開發(fā)周期,助力產(chǎn)品快速上市。 現(xiàn)Tronlong推出復(fù)工優(yōu)惠活動(dòng),AM5708、Z-7020評(píng)估板限時(shí)推廣特價(jià),僅需999元(含稅包郵),詳情訪問創(chuàng)龍官方商城。
|