可能性と複雑性に満ちあふれた「AMP」へようこそ：SYSTEM DESIGN JOURNAL（3/5 ページ）

「AMP」（非対称型マルチプロセッシング）は今まさに注目すべき技術ですが、AMPとは何であり、なぜ必要なのでしょう。何より、組み込みシステムにおいてAMPの実装にはどんな利点や課題があるのでしょうか。

[Ron Wilson，（Editor-in-chief,Altera）,MONOist]

制御の問題

　別のプロセッサで実行されるタスクをどう制御するかは、常にマルチプロセッシングにおける重要な課題です。

タスクの初期化、開始／停止、メッセージ交換といった問題に加え、ステータス情報の取得、タスクへの割り込み受け渡し、例外処理、さらに重要なこととして、マイクロプロセッサのデバッグのための十分な可観測性と制御性の実現など、あまり知られていない問題もあります。

　SMPシステムの場合、SMP対応OSによってこれらの問題に対処することが多く、各プロセッサ上のOSインスタンスがほとんど同じであるためメッセージ交換が可能です。それに対し、各プロセッサの実行環境が異なることがあるAMPの場合、事態はより複雑になります。

　Multicore Association「OpenAMP」のように、プロセッサと各種OSの間にホモジニアスハードウェアアダプテーション層を設け、タスク間通信用の共通リソースセットを開発する取り組みがあります（OpenAMPの場合は、同団体のMulticore Communications APIをベースにしています）。

　同様に各種プロセッサ上のベアメタルで動作し、各種OSに一連の「行儀のよい」仮想マシンを提供するType1 ハイパーバイザーもあります。しかし、制御実装の一部は依然としてベアメタル機能に関する仕様の形で提供されるため、プロセッサへの実装は自分で行わなければなりません。

　これらの要件は、少なくとも2つの異なる視点から眺めることができます。つまり、アプリケーションから見てどう映るのか、そしてシリコンから見てどう映るのかです。

　アプリケーションから見て、システム内の各タスクはマイクロプロセッシングAPIを通じて情報交換や同期を行う、自律的なものとして映るかもしれません。あるいは、明確な制御階層がある場合、メインプログラムから見て、他のプロセッサ上のタスクは呼出可能な関数、あるいはデバイスドライバを通じてアクセスするI/O操作として映るかもしれません。

　他のプロセッサ上のタスクとのこれらの関わり合い方はそれぞれ、要求まではしないものの特定のハードウェア実装を示唆しています。タスクが自律的である場合、メッセージ受け渡しメカニズムを備えて（恐らく、一部のプロセッサに接続された大容量専用メモリによって強化された非同期共有メモリシステムとして）実装されるはずです。

　タスクが同じデータ構造を同時処理する場合、同期共有メモリシステムが推奨されるかもしれません。そうしたシステムはほとんどの市販CPUコアによってサポートされていますが、共有メモリ管理またはキャッシュコヒーレンシをネイティブにサポートしないアクセラレータを開発するとなれば、難題となる可能性があります。

　補助タスクを関数として扱うと、共有メモリよりも単純なハードウェア実装が可能になります。関数を実行するプロセッサをAMBAR AXIのような広帯域幅シリコンインタコネクトまたはPCI Express（PCIe）などのオフダイバスに接続し、ローカルメモリやコントロール／ステータスレジスタをメインCPUにさらすことが可能です。

　さらにもう一歩踏み込んでタスクをI/O操作として扱う場合、AMBA APBのようなペリフェラルバス上にプロセッサを配置することも可能です。

　しかし、タスクに対するアプリケーションの視点とハードウェアの物理的な接続方法の間に必要な関係はありません。妥当なレイテンシと帯域幅が得られる最も単純なアプローチをハードウェア設計者が採用するのであれば、目的のアプリケーションレベルの視点が何であろうとソフトウェアでエミュレートできます。