まず、ヘテロジニアスマルチプロセッサSoCのは何ですか
名前が示唆するように、シングルチップは、異なるプロセッサアーキテクチャ我々のような、異種マルチコアプロセッサのSoCを呼び出すコアユニットのSOCを複数集積しました。
- TIのOMAP-L138（DSP C674x + ARM9）、AM5708（DSP C66x + ARMのCortex-A15）のSoCプロセッサ。
- ザイリンクスのあるZynq（ARMのCortex-A9 +のArtix-7 /のKintex-7プログラマブルロジックアーキテクチャ）のSoCプロセッサ。
第二に、ヘテロジニアスマルチコアのSoCプロセッサの利点は何ですか
シングルコアプロセッサと比較すると、強度が異なるアーキテクチャ間で、など多くの性能、コスト、消費電力、サイズを、もたらす組み合わせたヘテロジニアスマルチコアのSoCプロセッサは、その職務を行うと元の建築のユニークな利点を果たしています。例えば：
- 安価、低消費電力、優れた制御およびマルチメディアディスプレイの動作をARM。
- 天然の緑色、良好な専用の演算を処理するDSPデジタル信号。
- FPGAは、高速、多チャンネルデータ収集及び信号伝送で良好です。
一方、コアのSoC異種プロセッサ・コア、素早く完全効果1 + 1> 2を達成するために、通信の多様を介してデータを転送し、共有。
第三に、共通コア間通信
いくつかのTIの以下の説明では、ハードウェアパッケージ、コア間通信の設計におけるハードウェアキー機構嘘の半導体チップメーカーの開口部に加えて、ヘテロジニアスマルチコアプロセッサのSoCの性能を最大化するために、ザイリンクスヘテロジニアスマルチプロセッサのSoC共通のコア間通信。
- OpenCLの
OpenCLの（オープンコンピューティング言語、オープンコンピューティング言語のフルネーム）は異種システムのオープン、無料のスタンダードの汎用並列プログラミングのための最初で、ソフトウェア開発者を容易にするための統一されたプログラミング環境は、ポータブルかつ効率的なコードを書くだけでなく、広く適用されますマルチコアプロセッサ（CPU）、グラフィック処理ユニット（GPU）、セル型アーキテクチャ、およびデジタル信号プロセッサ（DSP）および他の並列プロセッサ、エネルギー、電力、鉄道輸送、産業オートメーション、医療、通信、軍事およびその他のアプリケーションフィールドには、開発のための広範な展望を持っています。
SoCのヘテロジニアスマルチコアプロセッサ上で、OpenCLのホストと見なされたプログラマブルコアは、デバイスは、他のコアとみなします。ホスト（すなわち、ホストプログラム）コード（カーネル）で実行されるアプリケーションは、管理装置上で実行され、また、データ使用可能な装置を作るための責任があります。1つ以上のユニットによって、コンピューティングデバイス。例えば、TI AM5728 SoCのヘテロジニアスマルチコアプロセッサ、C66x DSPの各々は、コンピューティングユニットです。
OpenCLのランタイムは、一般的に次の二つの成分を含みます：
- カーネルAPIの実行を作成し、提出するためのホストプログラム。
- クロスプラットフォームの言語カーネルのため。
2.DCE
DCEは、（分散コーデックエンジン）分散コーデックエンジンは、ウィジェットフレームワークが提供される、完全なGStreamerのTI映像処理フレームAM57xヘテロジニアスマルチコアプロセッサベースのSoCです。
DCE三個のハードウェアモジュールで構成され、それぞれ、MPUコア、IPU2 IVA-HDコアおよびハードウェアアクセラレータ、その主な機能は次の通りであります：
MPU：ARMベースのGStreamerユーザ空間アプリケーション、制御モジュールlibdce。libdceモジュールは、ARM RPMSGフレームにIPC IPU2と通信します。
IPU2：建設DCEサーバ、通信のためのフレームとRPMSG ARMに基づいて、エンジンを制御するコーデック、フレームアセンブリIVA-HDアクセラレータを使用。
IVA-HD：ビデオ/画像コーデックハードウェアアクセラレータのために。
3.IPC
IPC（プロセッサ間通信）は、プロセス間通信モジュールを促進するために設計されたグループです。通信はメッセージパッシング、フローおよびリンクリストが含まれます。サービス及びこれらのモジュールの機能は、ARMとDSPのSoCコアに異種マルチコアプロセッサ間の通信のために提供されてもよいです。
コア間通信TIヘテロジニアスマルチたSoCの従来のプロセッサの次の利点と欠点の比較：
| 道 |
利点 |
短所 |
| OpenCLの |
|
|
| 12月 |
|
|
| IPC |
|
|
4AXI
AXI（アドバンス拡張可能なインタフェース）ARM社が提案したバス・プロトコルである、ザイリンクスは現在、AXI4バージョンを使用して、6シリーズFPGAからAXIバスのサポートの提供を開始しました。
Zynq 3つのAXIバス：
（A）AXI4：（高性能メモリマップ要件について）主に高性能通信アドレスマッピングのニーズのために、アドレスマッピングは、データ伝送256が最も大きいバーストせるためのインタフェースです。
（B）AXI4-Liteは：（簡単のために、低スループットメモリマップ通信）軽量単一アドレスマッピング伝送インターフェースであり、論理ユニットは、ほとんど占め。
（C）AXI4-ストリーム：データ（高速データをストリーミングするための）高速データ伝送ストリームの場合、アドレスの項目が削除され、許可無制限のバースト転送サイズ。
AXIプロトコルは、構成バスの上に構築されるように開発されています。そのため、AXI4、AXI4-Liteは、AXI4-StreamがAXI4プロトコルです。端部AXIバスプロトコルは、それらの間に一般的に必要とするAXIインターコネクトによって接続された両端（スレーブ）から、それはマスター又はAXIへの1つ以上の接続装置を提供することで、サブ主（マスター）に分割することができます一つのメカニズムのAXI装置から複数のスイッチング。
AXIインターコネクトの主な役割は以下のとおりです。そこに複数のホストで、連絡先のマシンから、AXIInterconnect責任とそれらを管理する場合。、オーダーID信号をサポートホストのニーズ、およびホストのうち順番のうちAXIのサポートは、AXIインターコネクト、この問題を解決しながら、異なるIDが、同じであってもよい送信するので、そのIDになるので、彼は別のホストID信号が処理されていますユニーク。
AXIプロトコルアドレスは、リードチャネル、読み出しデータチャネル、チャネルの書き込みアドレス、書き込みデータチャネルと書き込み応答チャネルは別に、各チャンネルには独自の握手契約を締結しています。互いに干渉が、各チャネルに依存しないでください。これは、効率的な理由のAXIの一つです。
四、IPCコア間通信の開発
以下は、ロングAM57x（AM5728 / AM5708）出典評価ボードは、例えば、コア間通信の開発IPCを説明します。
- 開発環境の説明
- RTOSプロセッサ-SDK 04.03.00.05。
- Linuxの-4.9.65 / Linuxの-RT-4.9.65カーネル。
- IPC Development Kitバージョン：3.47.01.00。
IPC（プロセッサ間通信）は、マルチコア環境のために、同一の処理コア（プロセス間）に他のスレッドとインター通信コア間通信処理プロセッサに依存しないAPI、および周辺機器（デバイスを提供します）通信。IPCは、以下の表中の成分を以下の通信を定義し、通信コンポーネントインターフェイスは共通で次ました。
| 知らせます |
MessageQ |
| ListMp |
GateMp |
| HeapBufMp |
FrameQ（一般的に使用される生の映像データ） |
| HeapMemMp |
RingIO（通常はオーディオデータに使用） |
- IPC名前標準化された通信コンポーネントによって、すべてのシステム・インタフェース。
- HLOS端で、すべての必要なインターフェースIPCザ_setup（）は、対応するIPC Module1のを破壊する_destroy（）を使用して初期化し、部分的にインタフェース_configを提供することも望ましい初期化（）。
- 削除する（、使用_deleteを作成する_CREATEを使用する必要のすべてのインスタンス（））。
- _open必要が深いIPCを使用する場合は（）IPCの終わりに、ハンドルを取得するためには、ハンドルを回復するために_close（）を必要としていました。
- IPCの設定ほとんどの設定は、静的な設定方法を使用することができますXDC構成をサポートするために、SYS / BIOSで行われます。
- 各モジュールは、デバッグのためにIPCトレース情報をサポートし、さまざまなトレースレベルをサポートしています。
- IPCのセクションは、情報分析を抽出するために使用する特定のAPIを提供します。
このセクションでは、MessageQ主要な通信コンポーネントの使用方法を示します。
2.MessageQメカニズム
- MessageQモジュールの機能
- 可変長メッセージの送受信の構造を支持します。
- A MessageQはリーダー、複数のライターを持っています。
- 同種および異種の両方マルチメッセージングのため、それはまた、スレッド間を通過する単一のプロセッサ・メッセージのために使用することができます。
- パワフルで使いやすいです。
コードを説明する2.MessageQメカニズム
主に受信機と送信側に分けMessageQ伝送、共通API関数の次の説明：
- MessageQ_Handle MessageQ_create（文字列名、MessageQ_Params *のparams）：メッセージ・キューを作成し、キュー名は、後でMessageQ_open基礎を作成されます。
- int型MessageQ_open（文字列名、MessageQ_QueueId *キューID）：オープンメッセージキューが作成され、キューID値へのアクセス（ID値が一意であることをメッセージキュー名を作成し、固有の値でなければなりません）。
- MessageQ_Msg MessageQ_alloc（UInt16型heapId、UInt32型のサイズ）：ヒープからアプリケーション・メッセージ・スペースアプリケーション、オープンヒープ取得heapID、所定のメッセージ長MessageQ_Msg構成する必要があるので。
- MessageQ_registerHeap（HeapBufMP_Handle_upCast（heapHandle）、HEAPID）：登録ヒープ、heapIDは、一意の識別子として、ヒープに割り当てられています。
- INT MessageQ_put（MessageQ_QueueIdキューID、MessageQ_Msg MSG）：メッセージキューキューIDに対応するメッセージを送信します。
- int型MessageQ_get（MessageQ_Handleハンドル、MessageQ_Msg * MSG、UINTタイムアウト）：メッセージキューからメッセージを受信します。
- MessageQ_free（MessageQ_Msgは* MSG）：MSGリリーススペースは、ニュースリリースに必要なスペースに注意を払っていないそれ以外の場合は、メモリの問題につながります。MessageQメカニズムを使用するプロセスを説明するためのルーチンをex02_messageqするには：
次のように日常の動作フローチャートです。
実際のコードの解析処理は、上述しました：
腕：
a）は、ホストメッセージキュー、メッセージキューのオープンスレーブを作成します。
b）はスレーブメッセージキューにメッセージを送信し、メッセージキューリスナーのホスト、情報を返すために待っています。
C）スレーブキューのシャットダウンにメッセージを送信します。
DSP：
a）は、スレーブメッセージ・キューを作成します。
B）モニタスレーブメッセージキュー、およびホスト端末へのメッセージを返します。
シャットダウンメッセージを受信C）、タスクを停止します。
3.メモリー・アクセスおよびアドレスマッピングの問題。
- アドレスマッピング
すべての仮想アドレスの最初、DSP / IPU及びL3相互接続サブシステムとの間のメモリ管理ユニット（MMU）、（すなわちアドレスDSP / IPUサブシステムは、見て）相互から物理アドレス（すなわち、へL3アドレスを参照してください）。
DSP：DSPコア用MMU0、ローカルEDMAためMMU1。
IPU：マップのIPUx_UNICACHE_MMU、2つのマッピングのためのIPUx_MMU。
rsc_table_dspx.h、rsc_table_ipux.hリソーステーブルは、マッピング関係は、レジスタマッピング関係に書き込まれるファームウェアの起動前に、マッピング処理が完了すると、DSP / IPUサブシステムを構成しました。
仮想アドレスビューとの間のマッピングと物理アドレス：
デフォルトの設定mmu1構成とmmu2構成はDSP1と同じである:(）
猫/sys/kernel/debug/omap_iommu/40d01000.mmu/pagetable
猫/sys/kernel/debug/omap_iommu/40d02000.mmu/pagetable
デフォルトの設定mmu1構成とmmu2構成はDSP2と同じである:(）
猫/sys/kernel/debug/omap_iommu/41501000.mmu/pagetable
猫/sys/kernel/debug/omap_iommu/41502000.mmu/pagetable
IPU1：
猫/sys/kernel/debug/omap_iommu/58882000.mmu/pagetable
IPU2;
猫/sys/kernel/debug/omap_iommu/55082000.mmu/pagetable
Resource_physToVirt（UInt32pa、UInt32型*ダ）。
Resource_virtToPhys（UInt32da、UInt32型* PA）;
- メモリアクセス
- CMAメモリ
スタックIPCプログラムコードとデータセグメントを記憶するためのCMAメモリ。
DTSファイルは、脇のスペースセグメントコア（DDR空間）として宇宙からのいくつかの段落を設定します。
IPC-デモ/共有/ config.bld：コンフィギュレーション空間の開始セグメントアドレス、およびセグメントサイズ。
DSP1へのDMAメモリマッピングとの関係を説明するために：
システム仮想アドレステーブルを表示することによって、仮想アドレスに対応するDA（デバイスアドレス）を左、右に対応する物理アドレスは、仮想アドレス0x95000000のアドレスは0x99100002の物理アドレスにマッピングされなければなりません。
猫/sys/kernel/debug/omap_iommu/40d01000.mmu/pagetable
2.共有メモリ
共有メモリは：実際には、メモリ「皆」缶のアクセスです。
CMEMは、カーネルモードドライバ（ARM）で良好メモリアプリケーション（または連続したメモリアロケーションブロックの複数）を管理するために、一つ以上のブロック（連続したメモリ割り当て）に割り当てられ、解放されたメモリの断片を回収します。
CMEMメモリ：Linuxではによって予約、CMEMはスペースドリブン管理です。
アーチ/アーム/ブート/ DTS CMEM定義/ am57xx-EVM-cmem.dtsi、共有メモリ（DDR＆OCMC空間）のために予約された領域のうち。
CMEM {}ブロック数分布の最大値が4である、CMEM-BUF-プールの数は限定されるものではありません。
実際の使用では、DSPとIPUへのアクセスは、仮想アドレスであるが、関係の仮想アドレスから物理アドレスへのマッピングを完了させます。
DSP1物理アドレスマッピングテーブルへ/ rsc_table_dsp1.h定義する仮想アドレス、仮想アドレスの物理アドレスへのマッピング（0x85000000）0xA0000000番地、次いでDSP側のアクセスアドレス0x85000000が実際に物理アドレスがマッピングされるべきアクセス0xA0000000番地。
猫/sys/kernel/debug/omap_iommu/40d01000.mmu/pagetable
実用的なアプリケーション：
a）の初期cmemの。
B）アプリケーションのメモリ空間、および物理アドレスに変換（送信は、物理アドレスまたは仮想アドレス送信不確実であるMSG送信）。
DSP側処理：仮想アドレス変換動作に物理アドレスを受信し、送信動作結果が完了する。ここでは、それが仮想アドレスを物理アドレスに変換する必要があり、その後、ARM側に、DSP ARMに対処する必要があります。
