myAlteraアカウントへログイン

myAlteraユーザーネーム、パスワードを忘れた場合

myAlteraアカウントをお持ちでない方

消費電力と複雑性:AMP へようこそ

非対称型マルチプロセッシング (AMP) は、2016 年を代表する技術略語の選抜候補リストに載っています。しかし、そもそも AMP とはどのようなもので、なぜ必要なのでしょうか。より有益な疑問として、AMP をエンベデッド・システムに実装する際、どのような考慮事項や課題があるのでしょうか。

まず定義から始めましょう。対称型マルチプロセッシング (SMP) システムは、すべてのプロセッサーがアプリケーション・レベルより下はほとんど同じであるシステムで、基本的にソフトウェア・スタック、インストラクション・セット、メモリー・コンフィグレーション、および CPU ハードウェアは同じです (図 1)。ほとんどの SMP システムでは、CPU ごとに異なるアプリケーション・スレッドを実行し、通常は CPU ごとに別のペリフェラルおよび割り込み要求接続を行うことができます。しかし、それ以外はすべて同じです。

1. SMP システムは、1 つの L2 キャッシュとバス構造を共有する同一 CPU のバンクを備えていることが多い

us-systemdesign-journal-apm-spm-system

 

SMP はデータセンターでよく用いられます。均一性により、何万もの CPU コア間でタスクを割り当てる際に高い柔軟性が得られるからです。組込みの世界では、SMP は多数のスレッドを並列実行することにより、スレッドが豊富なタスクの速度を向上させることができます。また、冗長システムで比較または投票回路と共に使用して信頼性を高めることも可能です。

では、AMP とはどのようなものなのでしょうか。簡単に言えば、AMP システムはプロセッサーがアプリケーション・レベルより下はほとんど同じでないマルチプロセッシング・システムで、オペレーティング・システム (OS)、メモリー、またはプロセッシング・ハードウェアも異なることがあります。

なぜ非対称型なのか?

SMP は簡潔性とある程度の洗練性を備えています。それを台無しにする理由があるのでしょうか。なぜタスクを特定のプロセッサーにバインドするのでしょうか。インテルの WindRiver 製品ライン担当マネージャーである Michel Chabroux によれば、いくつかの正当な理由があり、「ほとんどの AMP のユースケースでは、目的はタスク間の分離を維持することです」と言います。例えば、アーキテクトは、リアルタイム・デッドラインがあるものを含む複数のタスクを統合することがあります。その場合、設計者は、一方は Linux、もう一方はリアルタイム OS (RTOS) が稼働する 2 つの CPU コアを使用することを選択できます。

別の状況として、コアの物理的な分離が重要な場合が考えられます。例えば、レイテンシーが重要なタスクを別のコアに移動すれば、システムレベルの割り込みから保護することができます。あるいは、Chabroux が提案するように、自律走行車の安全監視タスクを別の CPU コアで実行すれば、残りのシステムの機能が停止した場合でもタスクの実行継続を確保することが可能になります。

3 番目の動機は専用ハードウェアの必要性です。これは、メイン CPU コアのインスタンスで実行すると要件を満たすことができないタスクがある場合です。一例として、ARM 社の big.LITTLE テクノロジーが挙げられます。big.LITTLE は、一方は低速で消費電力が非常に低く、もう一方は高速ながら消費電力が大きい 2 つのバイナリー互換 CPU コアを搭載することにより、監視コードがタスクを自由に移動して消費電力またはエネルギー消費に最適化することを可能にします。その結果、性能要件を満たすと共に、エネルギー消費量が非常に少ないシステムを実現できます。

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

最も重要な考慮事項

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

プロセッサーとしてのハードウェアの選択は、初期の設計目標によって決まります。目標が単に一部のタスクを残りのシステムから物理的に分離することである場合、一般に最も簡単なアプローチは、同じ CPU コアの複数のインスタンスを使用しながら、いくつかのコアで他のコアとは異なるオペレーティング・システムを実行することでしょう。これは、例えば一方が両方のシステム・コールをすべて処理する 2 つの Linux カーネルなど、同じ OS の異なるビルドを意味するほか、例えば一方のコアは Linux、もう一方のコアは RTOS またはベアメタル・アプリケーションを実行するといった、全く異なる環境を意味することも考えられます。

システム制約により、OS だけでなくハードウェアも異なるものを使用しなければならない場合もあります。例えば、前世代で特定のマイクロコントローラー・ユニット (MCU) コア上で実行されていたコアは、引き続きそのコア上で実行するのが最善かもしれません。ASIC または FPGA にレガシー MCU を実装する IP (Intellectual Property) を探すことは比較的容易です。何としても大昔の 8051 アセンブリー・コード・ファイルをリバースエンジニアリングして、64 ビット ARM®コア向けに C で書き直したいなどと考える人はいません。

さらに、タイミング、消費電力、およびエネルギーも異種性に頼る理由になり得ます。時として、タスクをシステム割り込みから分離するだけでは不十分で、タスクの確定的レイテンシーがより短い CPU が必要になることもあります。したがって、レイテンシー制約が厳しい場合、制御ループをメイン ARM Cortex-A コアから別の Cortex-R コアに移動するのは理にかなっているかもしれません。また、前述したように、消費電力またはエネルギー制約により、要求は厳しくないものの持続的なタスク向けの低消費電力コアや、集中的で計算を多用するタスク向けのパワー・ゲーティング機能搭載の超高速コアなど、特定のタスク向けに特別のコアが要求される場合もあります。

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

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

us-systemdesign-journal-apm-different-cache

 

制御の問題

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

SMP システムの場合、SMP OS によってこれらの問題に対処することが多く、各プロセッサー上の OS インスタンスがほとんど同じであるためメッセージ交換が可能です。それに対し、各プロセッサーの実行環境が全く異なることがある AMP の場合、事態はより複雑になります。Multicore Association の OpenAMP など、プロセッサーと各種オペレーティング・システムの間にホモジニアス・ハードウェア・アダプテーション層を設け、OpenAMP の場合は同団体の Multicore Communications API (MCAPI) をベースにした、タスク間通信用の共通リソースセットを開発する取り組みがあります。同様に、各種プロセッサー上のベアメタル上で動作し、各種オペレーティング・システムに一連の「行儀のよい」仮想マシンを提供する Type-1 ハイパーバイザーもあります。しかし、制御の実装作業の一部は依然としてベアメタル機能に関する仕様の形で提供されるため、プロセッサーへの実装は自分で行わなければなりません。

これらの要件は、少なくとも 2 つの異なる視点から眺めることができます。つまり、アプリケーションから見てどう映るのか、そしてシリコンから見てどう映るのかです。アプリケーションから見て、システム内の各タスクはマイクロプロセッシング API (Application Programming Interface) を通じて情報交換や同期を行う、自律的なものとして映るかもしれません。あるいは、明確な制御階層がある場合、メインプログラムから見て、他のプロセッサー上のタスクは呼出可能な関数、あるいはデバイスドライバーを通じてアクセスする I/O 操作として映るかもしれません。

他のプロセッサー上のタスクとのこれらの関わり合い方はそれぞれ、要求まではしないものの特定のハードウェア実装を示唆しています。タスクが自律的である場合、メッセージ受け渡しメカニズムを備え、おそらく一部のプロセッサーに接続された大容量専用メモリーによって強化された非同期共有メモリーシステムとして実装されるはずです。タスクが同じデータ構造を同時に処理する場合、同期共有メモリーシステムが推奨されるかもしれません。そうしたシステムはほとんどの市販 CPU コアによって容易にサポートされますが、共有メモリー管理またはキャッシュ・コヒーレンシーをネイティブにサポートしないアクセラレーターを開発するとなれば、難題となる可能性があります。

補助タスクを関数として扱うと、共有メモリーよりも単純なハードウェア実装が可能になります。関数を実行するプロセッサーを AMBA® AXI™ のような広帯域幅シリコン・インターコネクトまたは PCI Express® (PCIe®) などのオフダイバスに接続し、ローカルメモリーやコントロール/ステータスレジスターをメイン CPU にさらすことが可能です (図 2)。さらにもう一歩踏み込んで、タスクを I/O 操作として扱う場合には、AMBA APB™ のようなペリフェラル・バス上にプロセッサーを配置することも可能です。

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

データが重要

AMP システムの実装に際して最も重要な決定の 1 つは、プロセッサーをシステムメモリー階層にどう適合させるかです。この決定は、主に各種プロセッサー上のタスクがデータにアクセスする方法に基づくべきです。SMP システムの場合、プロセッサー上で実行されるすべてのタスクが 1 つの共有メモリースペースに同様にアクセスするキャッシュ・コヒーレントな共有メモリー構成が標準の選択です。一方、一部のタスクが特定のプロセッサー上でのみ実行される AMP システムでは、多くの場合、メモリー・アーキテクチャーを個々のタスクのアクセスパターンに合わせて調整する機会があります。

この調整は、タスクによるメモリーの使用方法、特に参照の局所性、アクセスの経時変化、および必要な帯域幅によって決まります。通常の共有メモリーシステムの場合、L1 または L2 データキャッシュに十分に収まる比較的小さい隣接データセットをタスクが受け取り、しばらくそのセットを集中的に処理した後、別の隣接データセットに移るのが理想的です。このパターンにより、ほぼすべてのロード/ストアでローカルキャッシュにヒットさせることが可能です。

残念ながら、多くの重要なアルゴリズムは決して協調的ではありません。ある最近の論文では、ビッグデータ解析タスクにおけるキャッシュミス率は 90 % 以上に及ぶ可能性があると推定されています。また、非常に大規模なテーブルまたはリンクリストを使用するアプリケーションも、極めて散発的なアクセスパターンを示す可能性があります。これらの場合、タスクを実行するプロセッサー専用の大容量ローカルメモリーを搭載するのが理にかなうこともあります。このメモリーはキャッシュとして管理できますが、多くの場合、ソフトウェアで明示的に管理した方がよいかもしれません。時として、キャッシュは平均アクセス時間を短縮することが全くできないことがあり、その場合、メモリー・アクセス・レイテンシーを隠す方法 (深いマルチスレッディングなど) を他に探す必要があります。なお、そうしたアイデアは、ローカルメモリーとしてプロセッサーに直接接続された大容量フラッシュアレイなどの新たな概念につながります。

特殊なケースとして、データが絶えずタスクにストリーム入力され、一連の短い操作でのみ使用された後、受け渡されたり、フラッシュされたりする場合が考えられます。そうした状況は、ネットワーク・パケット交換、信号処理、制御システムへの伝達関数の実装などにおいて発生することがあります。最善の実装は、ダイレクト・メモリー・アクセス (DMA) をプロセッサーのローカルメモリーに直接ストリーム入出力することかもしれません。そうすれば、メイン CPU とメモリーをバイパスし、ストリーミング・タスクをメイン CPU からほぼ独立して実行することが可能になります。

そこで生じる最後の疑問は、AMP プロセッサーはどのようにして外部と関わるのかということです。プロセッサーは、少なくとも初期化および例外回復時に I/O レジスタ・コントロールおよびステータス・トランザクションが行えるように、システムと I/O バスで接続されるものと考えられます。ストリーム処理の場合、つまりプロセッサーが実際のイベントを割り込み駆動型でリアルタイム処理している場合、そのプロセッサーを外部と直接 I/O 接続することができます。しかし、AMP システムにおける割り込みや I/O トランザクションは、どちらかと言えば中央の CPU で処理され、メインメモリーを通じてデータがバッファーされます。

仮想化に有効

以上紹介したかなり幅広いハードウェア・レベルの代替手段は、AMP の大きな利点を物語っています。それは、システム内の最も要求の厳しい各タスクに合わせてハードウェアや OS 環境をカスタマイズできることです。その一方で、AMP の最大のリスクも示しています。それは、注意しないと、システム内のすべての重要なタスクが異なる実行/通信/デバッグ環境や異なるメモリーモデルに直面する恐れがあることです。

そこで役立つのが OpenAMP のような標準です。また、エンベデッド・ハイパーバイザーも同様に役立ちます。

「ハイパーバイザーとは、仮想マシンをスケジューリングし、仮想マシン同士が相互に通信できるようにする RTOS と考えることです」と前出の Chabroux は助言します。ハイパーバイザーは、MMU のセットアップだけでなく、適切なコードを適切なプロセッサーにバインドする、仮想メモリー、デバイス、およびネットワーク接続を作成する、FPGA 内のソフト・プロセッサーをインスタンス化する、さらにはタスク間通信のための統一的な手段を提供することも可能です。

これらのサービスにより、各ワークロードを望ましい仮想システムで処理できるように、AMP システムをソフトウェア定義にすることが可能です。その一方で代償もあります。ハイパーバイザーは、CPU サイクル、メモリー、および電力を消費するほか、割り込み応答時間などのクリティカル・パスにレイテンシーを追加する可能性があります。そして、Chabroux が指摘するように、ソフトウェアの急激な複雑化を回避するには、ハイパーバイザーに対するハードウェア・サポートが必要です。例えば、CPU によるマルチスレッディング、FPGA によるライブ・パーシャル・リコンフィグラビリティ、DRAM コントローラー/バス・コントローラー/DMA コントローラーによる複数のアクティブチャネルをサポートするためのレジスターは、いずれもソフトウェアの複雑性の大幅な低減やハイパーバイザーのレイテンシー短縮につながります。

ハイパーバイザーを使用するかどうかはともかく、AMP はシステム要件を満たすための最善の手段となり得ます。しかし、フラットパック家具メーカーの担当者が言いそうなことですが、やはり「ある程度の組み立てが必要」であることが大きな問題です。


CATEGORIES : All, Design Challenges, Embedded system, System Architecture/ AUTHOR : Ron Wilson

Write a Reply or Comment

Your email address will not be published.