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

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

　3番目の動機は専用ハードウェアの必要性です。これは、メインCPUコアのインスタンスで実行すると要件を満たせないタスクがある場合です。一例として、ARMの「big.LITTLE」が挙げられます。

　big.LITTLEは、一方は低速で消費電力が非常に低く、もう一方は高速ながら消費電力が大きい2つのバイナリ互換CPUコアを搭載することにより、監視コードがタスクを自由に移動して、消費電力の最適化を可能にします。その結果、性能要件を満たしながらもエネルギー消費量が非常に少ないシステムを実現できます。

　しかし、多くの場合にAMPシステムのタスクは移植できません。プロセッサの種類が根本的に異なるからです。移植できないものとしては、GPUやFPGA、特定用途向けSoCに見られる特定機能向けアクセラレータなどのハードウェアアクセラレータが挙げられます。

最も重要な考慮事項

　AMPを選ぶ理由にかかわらず、実装に影響する重要な問題がいくつかあります（実際にはマルチプロセッシングシステムに共通する問題です）。それはタスクの実行および制御方法、システム内でのデータの移動方法、タスクから外部へのアクセス方法などです。

　プロセッサとしてのハードウェア選択は、初期の設計目標によって決まります。目標が単に一部のタスクを残りのシステムから物理的に分離することである場合、一般に最も簡単なアプローチは、同じCPUコアの複数インスタンスを使用しながら、いくつかのコアで他のコアとは異なるOSを実行することでしょう。

　これは一方が両方のシステムコールを全て処理する2つのLinuxカーネルなど、同じOSの異なるビルドを意味する他、例えば一方のコアはLinux、もう一方のコアはRTOSまたはベアメタルアプリケーションを実行するといった、全く異なる環境を意味することも考えられます。

　システム制約により、OSだけでなくハードウェアも異なるものを使用しなければならない場合もあります。例えば、前世代で特定のマイクロコントローラーユニット（MCU）上で実行されていたコアは、引き続きそのコア上で実行するのが最善かもしれません。

　ASICまたはFPGAにレガシーMCUを実装するIP（Intellectual Property）を探すことは比較的容易ですし、何としても大昔の8051アセンブリコードファイルをリバースエンジニアリングして、64bit ARMコア向けにCで書き直したいなどと考える人はいません。

　さらに、タイミングや消費電力なども異種性に頼る理由になり得ます。時として、タスクをシステム割り込みから分離するだけでは不十分で、タスクの確定的レイテンシがより短いCPUが必要になることもあります。従って、レイテンシ制約が厳しい場合、制御ループをメインのARM Cortex-Aコアから別のCortex-Rコアに移動するのは理にかなっているかもしれません。

　また、前述したよう、消費電力またはエネルギー制約により、要求は厳しくないものの持続的なタスク向けの低消費電力コアや、集中的で計算を多用するタスク向けのパワーゲーティング機能搭載の超高速コアなど、特定のタスク向けに特別のコアが要求される場合もあります。

　とはいえ、多くの場合、問題は計算を多用するタスクの性能そのものです。そこで視野に入ってくるのがハードウェアアクセラレータです（図 2）。ハードウェアアクセラレータには、DSPやGPUなどプログラマブルサブシステムもあれば、暗号エンジン、プロトコルオフロードエンジン、ビジョンプロセッサなどの固定機能アクセラレータ、さらにはFPGA内のカスタム並列エンジンやパイプラインエンジンもあります。

図 2. AMPシステムでは、異なる種類のプロセッサがLキャッシュを共有したり、プロセッサを高速バスあるいはペリフェラルバスに接続したりすることができる