情報処理学会研究報告
IPSJ SIG Technical Report

ヘテロジニアスプロセッサ向け通信ライブラリ MDCOM
大竹 史紘1

本田 晋也2

高田 広章2

概要：近年，組込み向けプロセッサは，高パフォーマンスに加えて低消費電力を求められている．一般的に，高パフォーマンスと低消費電力はトレードオフの関係にあり，単一のコアで両方の要件を満たすことは難しい．そこで，この問題を解決するアーキテクチャとしてヘテロジニアスプロセッサがある．ヘテロジ
ニアスプロセッサとは，1 つのチップ上に複数の異なるアーキテクチャのコアが乗るプロセッサのことで，それぞれのコアが高パフォーマンスと低消費電力を実現する．ヘテロジニアスプロセッサを利用する場合，それぞれのコアが協調して処理を行うためにコア間通信が必要になる．これを実現するライブラリとして，
MDCOM（Multi Domain COmmunication Module）を提案する．本研究では，MDCOM と既存技術である OpenAMP との比較を行う．また，TOPPERS の API との実行時間，MDCOM と OpenAMP の通信時間を評価する．これらの結果から，MDCOM の優位性を示す．

MDCOM, communication library for heterogeneous processor
Fumihiro Ohtake1

Shinya HONDA2

Takada Hiroaki2

Abstract: Recently, the processors for embedded system are required high-performance and low-energy.
Generally, they are trade-oﬀ, it is diﬃcult to fullfill them with uni-core. There is a heterogeneous processor which solve this problem. Heterogeneous processor has various architecture cores on a chip. Somecores realize high-performance, another cores realize low-energy. When we utilize heterogeneous processor,
inter-core communication is necessary for each cores to cooperate. We propose a inter-core communicationlibrary, MDCOM. In this research, MDCOM and OpenAMP are compared. Additionally, TOPPERS API,
commucation time of MDCOM and OpenAMP are evaluated. Then we indicate that MDCOM is superior
to OpenAMP.

1. はじめにの異なるアーキテクチャのコアが乗るプロセッサである．
メリットとして，様々なコアを利用することによる高効率

近年，組込み機器の高機能化が進み，要求される機能がなコンピューティングが挙げられる．すなわち，処理の特より多く，複雑になった．これまでは，リアルタイム性の徴によって振り分けるコアを選択することにより，プロ保証が重要な機能だったが，現在ではそれに加えて，リッセッサ全体のスループットが上昇する．一方，デメリット

チな GUI やメディアの再生機能などが必要となっている．

として開発コストが増加が挙げられる．ヘテロジニアスプ

そのため，組込み向けプロセッサには，低消費電力に加えロセッサでは，異なるアーキテクチャのコアが混在するたて高パフォーマンスが求められるようになった．一般的に，め，それぞれのコアに対して適切な処理を記述する必要が

これらはトレードオフの関係にあり，単一のコアで両方のある．

要件を満たすことは難しい．そこで，この問題を解決する

ヘテロジニアスプロセッサを利用する場合，それぞれのアーキテクチャとしてヘテロジニアスプロセッサがある．

コアが協調して処理を行うためにコア間通信が必要になる．

ヘテロジニアスプロセッサとは，1 つのチップ上に複数既存技術として，Multicore Association が策定した Ope-1

2

名古屋大学 工学部電気電子情報工学科
Department of Information Engineering, Nagoya University
名古屋大学 大学院情報科学研究科
Graduate School of Information Science, Nagoya University

c 1959 Information Processing Society of Japan⃝nAMP がある．これは，Linux の機能である remoteprocと RPMsg を利用しており，他のプロセッサに対して，制御と通信を可能とする．NXP 社による実装と拡張があり，

1

情報処理学会研究報告
IPSJ SIG Technical Report$'RPDLQが一般的である．
また，i.MX7Dual では，CPU ごとにドメインという概念*326

3HULSKHUDOV+3&&RUWH[$6(0$を持つ．これは，それぞれの CPU からアクセスできるメモリ領域を表しており，RDC（Resource Domain Controller）

*+]によって管理される．MDCOM では，排他処理を実現す
る SEMA4 と MU（Messaging Unit）が持つコア間割り込

6\VWHP

0HVVDJLQJ
8QLW

み機能，情報の送受信に利用される共有メモリを使用する．

5726

6KDUHG
0HPRU\

2.2 コア間通信の機構/(&&RUWH[0

3HULSKHUDOV%XV

ヘテロジニアスプロセッサを用いたシステム開発における課題としてコア間通信が挙げられる．ヘテロジニアスプ
ロセッサを利用してあるシステムを構築する場合，各プロ

0+]

0'RPDLQ

セッサで協調処理が必要となり，コア間通信のしくみが必

図 1: HAP（i.MX7Dual）のアーキテクチャ要となる．コア間通信を行う場合，共有メモリを利用する方法が容易である．その場合は，共有メモリの読み書きを行う際にロックを取得するようにしないとメモリの一貫性

RTOS でのゼロコピー送受信を実現している．しかし，OpenAMP，特に RPMsg については，リアルタイムシス
テムへの利用を考えた時，いくつかの問題点がある．

が保てない [3]．

3. 関連研究

そこで，本論文では MDCOM（Multi Domain COm-マルチプロセッサ向けの通信仕様として，MCAPI[4]，munication Module）を 提 案 す る ．現 在 ，MDCOM はMRAPI，OpenAMP がある．このうち，HAP を対象としi.MX6SoloX と i.MX7Dual，ZynqMP ZCU102 においてている OpenAMP について説明する．

動作する．
本研究では，MDCOM の評価と既存技術である Ope-nAMP との比較を行う．また，TOPPERS カーネルの API
実行時間，MDCOM と OpenAMP の通信時間を比較する．

2. ヘテロジニアスプロセッサ

3.1 OpenAMP
3.1.1 概要
OpenAMP とは，Multicore Association が策定したコア間通信に関する仕様であり，実装がオープンソースとして公開されている [5]．OpenAMP は HPC で動作する Linuxと，LEC で動かす FreeRTOS と呼ばれるリアルタイム OS

2.1 概要ヘテロジニアスプロセッサとは，1 つのチップの上に異なるコアを実装したプロセッサのことである [1]．コアの組み合わせには様々な構成が存在する．本研究では，図 1の OS 間通信をサポートする．機能は 2 種類あり，1 つはremoteproc，もう 1 つは RPMsg である．
remoteproc はリモートプロセッサの制御を行う仕組みでに示すように，，高機能な汎用 OS（GPOS）を動作させるあり，Linux から FreeRTOS が動作するコア（リモートプ高パフォーマンスコアと高信頼や高いリアルタイム性を実ロセッサ）を制御する機能である．具体的な制御としては，現する RTOS を動作させる低消費電力コアを組み合わせリモートプロセッサの電源のオン・オフ，ファームウェアたヘテロジニアスプロセッサを対象とする．高パフォーマのロードとスタートが挙げられる．

ンスコアと低消費電力コアをそれぞれ High Performance

RPMsg はコア間通信を実現する機能であり，その概要

Core（HPC），Low Energy Core（LEC）と略す．また，を図 2 に示す．通信はチャネルとエンドポイントを利用しこのようなタイプのヘテロジニアスプロセッサを HAPて行われる．ユーザーはあらかじめカーネルによって用意（Heterogeneous Architecture Processor）と呼ぶことにすされているチャネルに対して，エンドポイントと呼ばれる

る．HAP の例として，NXP 社の i.MX や Xilinx 社の Zynq

通信インターフェースを作成し，それを通じて通信を行う．

MPSoC やルネサスエレクトロニクス社のこのとき，同時に通信できるチャネルは 1 本のみである．

R-Car H3 等がある．ヘテロジニアスプロセッサの利用例

また，通信の開始や終了は，remoteproc と同様に Linux 側として，HEMS とカーナビゲーションシステムが挙げらからのみ行うことができる．

Ultrascale+れる．

RPMsg でサポートしている API を表 1 に示す．印がつ

図 1 のとおり，i.MX7Dual[2] は Cortex-A7 と Cortex-M4

いている API は OpenAMP で定められている標準の APIからなる HAP である．Cortex-A7 が HPC，Cortex-M4 がである．データ送信は送信 API（rpmsg send()）によってLEC にあたり，それぞれ GPOS と RTOS を動作させるの行う．一方，データ受信は，データ受信用のコールバック

c 1959 Information Processing Society of Japan⃝2

情報処理学会研究報告
IPSJ SIG Technical Report

3.1.3 OpenAMP の問題点

/LQX[57260DVWHU$SSOLFDWLRQ

5HPRWH$SSOLFDWLRQ

現状の OpenAMP には仕様と実装に以下の問題がある．

• 通信の開始や終了を Linux しか担えないこと• エラー時のタイムアウト時間が 15 秒の固定値.HUQHO0RGXOH(QGSRLQWV(QGSRLQWV&KDQQHO&KDQQHO• 同時に通信できるチャネルが 1 つのみ• ユーザーアプリケーションレベルの通信ができない• virtio による通信バッファサイズの制限

530VJ
YLUWLR

例えば，組込みシステムにおいてヘテロジニアスプロ
セッサを採用する場合，LEC にリアルタイム性の必要な処

6KDUHG
0HPRU\7;UHJLRQ

5;UHJLRQ理，HPC にメディアなどの重たい処理を割り当てる場合がある．このとき，制御は信頼系に実行させる方が自然だが，

図 2: OpenAMP RPMsg の構成仕様として，OpenAMP では RTOS での制御はできない．
コア間通信を行っている以上，非信頼系が停止したと

表 1: OpenAMP の API

しても信頼系は変わらず処理を続ける必要がある．しかAPI機能し，OpenAMP では送信に失敗した場合，15 秒処理をブ〇

rpmsg create ept()

エンドポイントの作成

ロックしたのち制御が戻る API があるため，問題がある．

〇

rpmsg destroy ept()

エンドポイントの破棄

OpenAMP には様々な送信関数があり，即座に制御が戻る〇

rpmsg send()

データを送信．空きバッファ

rpmsg trysend() を利用すれば信頼系でのコントロールをがない場合，15 秒後タイムアウト〇

rpmsg trysend()

データを送信．空きバッファがない場合，ただちにエラーを返す

rpmsg rtos alloc tx buﬀer() 送信バッファの割り当て失わないが，RTOS ではそのような API が実装されていないため，十分な実装ができているとは言い難い．

RPMsg の仕様では，同時に通信できるチャネルは 1 本のみである．そのため，複数のプロセス・タスク間で同時に通信を行うことはできない．しかし，アプリケーション

rpmsg rtos send()

データを送信はチャネルに対して複数のエンドポイントを扱うことがで

rpmsg rtos send nocopy()

データを nocopy で送信きるので，1 対のプロセス・タスク間で複数の通信路を利用できる．

関数が用意され，データを受信するとその関数が呼ばれる．

Linux で RPMsg を利用する場合，ユーザーアプリケー

RPMsg の実装に関しては，Linux が標準で備えているションでの利用はできず，カーネルモジュールとして実装仮想マシン向けの送信機構である virtio を利用している．

する必要がある．そのため，実際のアプリケーションに応通信バッファには virtio による上限があり，これを超え用するときには不都合が生じうる．virtio にはバッファ制た場合，通信に失敗する．現状公開されている実装では，限があり，512byte を超えたデータを送信すると通信に失OpenAMP の各機能はカーネルモジュールに対してのみ提敗する．そのため，Linux から 512byte を超えるデータを供されている．

送信したい場合は，通信を複数に分割する必要がある．

3.1.2 RTOS 向け拡張
前述の RPMsg の仕様は Linux に向けた仕様であり，リアルタイム OS で実現するには以下の課題がある．

4. MDCOM
前述の OpenAMP の問題を解決するため，我々は独自• 割り込みコンテキストでのデータ処理のヘテロジニアスプロセッサ向けの通信仕様と実装である• ブロックキング受信 API が未実装

MDCOM を開発した．

• ゼロコピー送受信が未実装• RTOS でのタイムアウト受信の未実装• Linux アップストリーム非互換

4.1 仕様ドメインとは，システム上の OS を意味する．通信は，これらの課題を解決した RPMsg の API の拡張仕様とそ

ドメインは単一の Master と 1 つ以上の Remote に分類さの実装が存在する．これを表 1 の印のついていない API

れる．Master は通信の開始や終了を制御を行い，一般的にとして示す．

は LEC で動作する RTOS である．一方，Remote は HPC

送受信関数は大きく分けて 2 種類ある．nocopy で行うで動く Linux もしくは RTOS である．サポートする環境関数と内部コピーを行う関数である．nocopy で送信を行

は，Master として TOPPERS カーネル，Remote としてう場合，あらかじめ rpmsg alloc tx buﬀer() などを呼び，Linux と TOPPERS カーネルが使用できる．ドメイン間送信用のバッファを確保する必要がある．の通信は，共有メモリとコア間割り込みとコア間排他制御

c 1959 Information Processing Society of Japan⃝

3情報処理学会研究報告
IPSJ SIG Technical Report

表 2: MDCOM の API送受信できない．つまり，FIFO チャネルと SMEM チャ
ネルは，一度に送信できるメッセージの数が異なる．

API機能

mdcom init()

MDCOM の初期化

mdcom term()

MDCOM の終了組みとしてフィルターがある．特定の条件を満たしたとき

mdcom sense process()

Remote のプロセス数を取得に初めて通信を行うことで通信を低減する．例えば，偶数

mdcom sense fifoch()

FIFOCH の使用状況の取得

回目の通信要求を受けた時，通信を行うなどである．

mdcom fifoch alloc()

FIFOCH からブロックを割当て

4.1.3 基本的な通信フロー

mdcom fifoch free()

FIFOCH へのブロックの解放

mdcom fifoch get()

FIFOCH のブロックのポインタの取得

mdcom fifoch enqueue()

FIFOCH の FIFO キューへのブ
ロック ID の送付

また，ユーザーアプリケーションでの通信を低減する仕MDCOM の基本的な通信フローを図 4 に示す．図において，Master と Remote 間の矢印は共有メモリを利用した通知とその方向を表す．
まず，Master と Remote とそれぞれで mdcom init() を呼FIFOCH の FIFO キューからのび，MDCOM の初期化を行う．このとき，初期化は Masterブロック ID の取得から行われるが，関数呼び出しのタイミングはどちらが先

mdcom fifoch notify()

FIFOCH のイベント送付でも構わない．

mdcom fifoch wait()

FIFOCH のイベント受信

mdcom filter set()

FIFOCH へフィルターをセットmdcom fifoch init()

FIFOCH の再初期化

mdcom smemch get()

SMEMCH の共有メモリのポイ

mdcom fifoch dequeue()ンタの取得

mdcom smemch trylock()

SMEMCH のロック取得の試行

mdcom smemch unlock()

SMEMCH のロックの解放

次に，FIFO チャネル上に送信用の領域を確保する．これを実現するのが，mdcom fifoch alloc() である．この関数を実行すると FIFO チャネル上に Block を確保し，Blockの ID が分かる．
メッセージの書き込みを行うためには，Block のポインタを取得するために，mdcom fifoch get() を実行する．

Block に対して memcpy() などでメッセージを書き込ん機構を利用して行われる．この時，メッセージや MDCOMだのち，Remote が Block の ID を受け取れるように md-の制御情報は共有メモリ上に配置される．

com fifoch enqueue() を呼び出し，FIFO キューへ Block のMDCOM では，チャネルと呼ばれるオブジェクトによりコア間の通信を実現する．チャネルは以下の 2 種類が用意されている．

ID を入れる．
その後，mdcom fifoch notify() を実行することで，Re-mote へとイベントの通知を行う．

• SMEM チャネル

イベントの通知を受け取るため，Remote ではあらかじ• FIFO チャネル

め mdcom fifoch wait() を実行しなくてはならない．このそれぞれのチャネルの詳細については後述する．これら

とき，待ち時間は任意時間，無限待ち，ポーリングから選のチャネルを用いて，複数のプロセスと複数のタスクの間択できる．

で同時に通信することができる．さらに，Linux において通知を受け取ったら，mdcom fifoch dequeue() を呼び，はユーザープロセスに対してドライバとライブラリの組みFIFO キューから Block の ID を受け取る．Master 同様に，合わせでこれらの機能を提供する．

MDCOM のコンフィギュレーションは専用の API を記述し，コンフィギュレータに読ませることで生成される．
また，MDCOM の API を表 2 に示す．ただし，この表

mdcom fifoch get() と memcpy() などのメモリアクセス関数でメッセージを受け取ることができる．
最後に，Remtoe から Master に対してイベントの通知を行い，送信が完了したことを伝える．

においてチャネルを CH と略すことにする．

4.1.1 SMEM チャネル

4.2 実装SMEM チャネルは共有メモリを提供するチャネルであMDCOM の実装は，特定のアーキテクチャに依存しなる．図 3(a) にあるように通信に利用する領域に対してロッい共通部と，アーキテクチャに依存したターゲット依存部

クを取得し，共有メモリの読み書きを行い，ロックを開放に分かれている．

することで他のドメインにアクセスさせる．

4.2.1 共通部

4.1.2 FIFO チャネル

ファイル構成としては，ユーザー向けインクルードファ

FIFO チャネルは，FIFO を利用した通信を提供するチャ

イル，ライブラリ本体とハードウェア依存部，Linux では加ネルである．図 3(b) のように，メッセージの読み書きはえてキャラクタデバイス，カーネルモジュールが実装されBlock を使用して行い，FIFO キューに Block の ID を送付ている．Linux における通信の仕組みとしては，ユーザーすることによって，複数のメッセージを送信することがでが API を叩くと，キャラクタデバイスを通してカーネルモきる．SMEM チャネルの場合は，単一のメッセージしかジュールに命令が渡され，共有メモリへの読み書きが行わ

c 1959 Information Processing Society of Japan⃝4

情報処理学会研究報告
IPSJ SIG Technical Report

(b)

(a)

図 3: チャネルの設計

5HPRWH

rpmsg trysend() 関数を利用することにより即座にエラー

PGFRPBLQLWが返るが，RTOS 向けの拡張 API ではブロックしタイム

0DVWHU&7/B05B5(4B,1,7

PGFRPBLQLW

アウトするのは 15 秒後であり，リアルタイム性が低い．
PGFRPBILIRFKBDOORF

一方，MDCOM では任意のタイムアウト時間を指定してAPI を実行することが可能である．

PGFRPBILIRFKBJHW&7/B05B5(4B127,)<

PHPFS\PGFRPBILIRFKBZDLWPGFRPBILIRFKBHQTXHXHPGFRPBILIRFKBGHTXHXHPGFRPBILIRFKBQRWLI\PGFRPBILIRFKBJHW&7/B50B5(4B127,)<PGFRPBZDLW

次に，同時通信に関しては，OpenAMP では同時に 1 本のチャネルしか作成できないのに対して，MDCOM では，任意のチャネルを作成することができる．

OpenAMP での下位レイヤーの実装は virtio を利用している．そのため，バッファの最大数が 512byte となっていPGFRPBILIRFKBQRWLI\

図 4: MDCOM の通信フローる．一方，MDCOM にはこのような制約はなく，任意のサイズにチャネルをコンフィギュレーションすることが可能である．

れる．TOPPERS カーネルでは，ユーザー API が低レベ
ル API を呼び出し，ハードウェアを直接制御する．

4.2.2 ターゲット依存部（i.MX7Dual）
ターゲット依存部の例として i.MX7Dual の依存部を説明する．i.MX7Dual のターゲット依存部では，図 1 のうち，排他処理を実現する SEMA4 と MU（Messaging Unit）が持つ割り込み機能，情報の送受信のために共有メモリを使用する．

SEMA4 は排他のための仕組みで，それぞれの CPUが”Hardware gate”に対してロックを取得することにより排他を実現する．”Hardware gate”は 16 個あり，MDCOM
ではそのうちの 1 つを利用する．

Messaging Unit は，i.MX7Dual が持つハードウェアでプロセッサ間通信を実現する．メッセージを受信するとCPU に対して割り込みをかける機能があり，MDCOM ではこれを利用する．
また，共有メモリはメッセージの送受信に使われるが，加えて，MDCOM の状態を記憶したり，mdcom init() やmdcom fifoch notify() などを実行した際に，相手の CPUに対して通知を行うためにも使用される．

4.3 OpenAMP との定性的な比較
OpenAMP との定性的な比較を表 3 に示す．
まずリアルタイム性に関しては，OpenAMP では送信実行環境は，OpenAMP は Linux と RTOS の組み合わせのみをサポートしているのに対して，MDCOM は，RTOSと RTOS の組み合わせもサポートしている．

Linux における API の提供先は，OpenAMP ではカーネルモジュールであるのに対して，MDCOM はユーザープ
ログラム API を提供する．

5. 評価
実行環境は，MDCOM では，HPC で Linux，LEC で TOP-PERS カーネルを実行した．また，RPMsg では，HPC でLinux，LEC で FreeRTOS とした．
5.1 API 実行時間
MDCOM の API 実行時間を表 4 に示す．また，TOPPERS カーネルの API 実行時間は，act tsk()，wup tsk()，chg pri() の実行時間を測定し，最頻値はそれぞれ，900，500，1000nsec であった．
他の関数と比較して，mdcom fifoch enqueue() と md-com fifoch dequque() の実行時間が長く，FIFO チャネルを使用する場合，これらの関数を必ず使用する．一方で，SMEM チャネルを使用する場合は，その必要はない．つまり，FIFO チャネルと SMEM チャネルは，実行速度と複数のメッセージを送れるかという点でトレードオフといえる．

キューに空きがないとき，Linux やベアメタルにおいては，

c 1959 Information Processing Society of Japan⃝5

情報処理学会研究報告
IPSJ SIG Technical Report

表 3: MDCOM と OpenAMP の比較
OpenAMP

MDCOM

リアルタイム性

RTOS では処理をブロックし，15 秒でタイムアウト

即座にエラーが返る

同時通信

1 本のみ

複数チャネルで同時に通信できる

下位レイヤーの実装

Linux では virtio を利用，RTOS では自前で実装

自前で実装

実行環境

Master: Linux / Remote: RTOS，ベアメタル

Master: RTOS / Remote: RTOS，LinuxAPI の提供先（Linux）

カーネルモジュールユーザープログラム

表 4: MDCOM の API 実行時間 (nsec)

RPMsg に比べて，MDCOM の方が送信時間にばらつきが生じた．これは，プログラムの実行優先度の違いによる

API

最頻値

平均

標準偏差

mdcom fifoch alloc()

1800

1778

61

mdcom fifoch free()

700

669

28

また，RPMsg に比べて MDCOM が約 3.6 倍速い結果に

mdcom fifoch get()

600

61848なった．これは，RPMsg 内部でデータのコピーが複数回mdcom fifoch notify()

1000

928

29発生したためだと考えられる．

mdcom fifoch enqueue()

1800

1806

68

mdcom fifoch dequeue()

1900

1823

77

ものと考えられる．

6. おわりに
本論文では，MDCOM の評価と既存技術である RPMsgの比較を行った．評価内容は，MDCOM の API 実行時間，

TOPPERS カーネルの API 実行時間，MDCOM と RPMsgの RTOS 側が送信完了までの時間，Linux から RTOS への送信時間であった．
評価により，各チャネルのトレードオフの関係性，RTOS側の送信完了までの時間，Linux から RTOS への送信時間についての MDCOM の優位性を示した．
図 5: 通信時間の評価
参考文献

5.2 RTOS 側の送信時間[1]

MDCOM における RTOS 側の送信時間を図 5 の RTOSsend(MDCOM) に示す．また，RPMsg における RTOS 側の送信時間を図 5 の RTOS send(RPMsg) に示す．ただし，測定には送信バッファを確保する処理を含めていない．
測定した範囲は，それを除いた，RTOS 側で送信完了す[2][3]るまでに必要な処理である．すなわち，MDCOM は送信バッファの書き込みを完了し，FIFO キューにブロック IDを送付したのちにイベントの通知を行うまで，RPMsg は[4]送信バッファの書き込みを完了し，nocopy 送信関数を呼ぶまでである．これは，RPMsg に確保した送信バッファを開放する関数が存在しないためである．
[5]

F. Baum, A. Raghuraman, ”Making Full use of Emerging
ARM-based Heterogeneous Multicore SoCs”, Proceedingsof the 8th European Congress on Embedded Real Time
Software and Systems (ERTS 2016), Jan 2016.
i.MX7D: i.MX 7Dual Processors - Heterogeneous Processing with dual ARM Cortex-A7 cores and Cortex-M4 core
O. Tomoutzoglou, D. Mbakoyannis, G. Kornaros, M. Coppola, ”Eﬃcient Communication in Heterogeneous SoCs
with Unified Address Space”, Proc. Int. Symp. on Reconfigurable Communication-centric Systems-on-Chip - ReCoSoC, May 2016.
Thiago Raupp da Rosa, T. Mesquida, R. Lemaire, F.
Clermidy, ”MCAPI-compliant Hardware Buﬀer Manager
mechanism to support communication in multi-core architectures”, Design, Automation & Test in Europe Conference & Exhibition (DATE), March 2016
OpenAMP 入手先 ⟨https://github.com/OpenAMP/openamp⟩ （参照 2016-01-24）

5.3 Linux 送信から RTOS 受信までの時間
MDCOM における Linux 送信から RTOS 受信までの時間を図 5 の Linux to RTOS(MDCOM) に示す．また，

RPMsg における Linux 送信から RTOS 受信までの時間を
図 5 の Linux to RTOS(RPMsg) に示す．このとき，RPMsg
では拡張によって追加された nocopy 送受信関数ではなく，標準の送受信関数を利用した．さらに，MDCOM はユーザープログラムとして，RPMsg はカーネルモジュールとして実装した．

c 1959 Information Processing Society of Japan⃝6