News and Views 2010 Autumn
[Feature Story 2 | Embedded Software]
MCAPI事例: マルチコア設計におけるCPU間通信
マルチコアをターゲットとした組込みシステムの開発はますます一般的になりつつあり、事実、わずか1、2年のうちに標準となる兆候があります。本稿では、まず、マルチコア設計について簡単に紹介し、SMPとAMPの比較、およびマルチOSシステムの使用などソフトウェアに関連する部分を扱います。本稿の中核を成すのは、Multicore Associationによって策定された新しい標準であるMCAPIです。これは、プロセッサ・コア間の通信を実装するための合理的な方法をソフトウェア開発者に提供します。複数の異種OS間の場合にも対応しており、MCAPI標準の概要を示すと共に、Mentor Embedded Nucleus OSおよびLinuxオープンソース・ソフトウェアのフレームワーク内でのMCAPI標準の実装について説明します。
マルチコアとは
「マルチコア」という用語は通常、単一チップ上に複数コアを搭載するという形態を意味しますが、装置のハードウェア上に複数のCPUという形態や、2つの形態の任意の組み合わせにも、実は同じ考え方が当てはまります。非常に単純化して考えた場合、マルチコアのアーキテクチャは、対称型マルチプロセッシング(SMP)と非対称型マルチプロセッシング(AMP)の2つに大別されます。
SMPとAMP
SMPシステムは、同じアーキテクチャを持つ複数のコアで構成され、多くの場合、「ホモジニアス・マルチコア」と呼ばれます。OSの単一インスタンスがすべてのコアで動作し、コア間での作業の分散を制御します。一般的に、処理能力の増大のニーズによってマルチコアへの移行が推進される場合、SMP手法は魅力的なソリューションになります。
逆に、AMPシステムでは、すべてが同じアーキテクチャを持つコアで構成される場合もあれば、アーキテクチャが異なる場合もあり、ホモジニアスあるいはヘテロジニアスとしてシステムが設計されていることを意味します。いずれの場合も、各CPUは、OSのインスタンスをCPUごと別々に実行します。OSはコアごとに自由に選択できるため、複数のOSが実装されるケースが多く見られます。
AMPが適している環境は、数多く存在します。コアのアーキテクチャが異なると特長とする機能も異なるため、設計しているデバイスに最適な機能を、異なるアーキテクチャを持った複数のコアによって実現する場合が考えられます。また、実行コードの一部を他のコード部分から確実に切り離す必要がある場合にも適切です。
マルチコア・プロセッサ
今日、多種多様なマルチコア・プロセッサが存在しており、その多くはここ数年もしくは最近出てきた新しいプロセッサですが、Texas Instruments(TI)製のOMAPファミリのようなプロセッサは市場で流通してから一定の期間が経過しています。事実、OMAPはマルチコア進化の好例で、バージョンアップの度に、コアや実行ユニットの数を増加させています。この追加は最初、専用コア群(グラフィックス・プロセッサやアクセラレータの追加)で行われましたが、より汎用のコアがOMAP 4(Cortex-A9 MPCore×2)に追加され、高精度化が図られています。
フリースケール・セミコンダクタのQorIQには、2、4、または8個のPowerアーキテクチャコアが組み込まれています。これは、設計者に明確な進化の方針を示した、最新のホモジニアス・マルチコア・デバイスの一例です。
MCAPIインタフェース
Multicore Communications API(MCAPI)は、AMPシステム内のコア間でデータをやり取りするためのアプリケーション・プログラム・インタフェース(API)です。2008年にMulticore Association(MCA)によって初めて公開されました。このAPIの主な目的は、ソースコードの互換性を複数OSにまたがって提供する一方で、性能やフットプリントを本来の組込みソフトウェアのあるべき姿に適合するように調整するための柔軟性も提供することです。
MCAPIにおける注意点
しかし、MCAPIはプロトコル仕様ではないことに注意することが重要です。当然のことながら、プロトコルとは実装の1種です。様々なベンダから提供されるMCAPI実装環境間の接続性は、このAPIが意図する部分ではありません。代わりに、すべてのアプリケーション・ソースコードを異なるMCAPI実装環境間で完全に移植可能にすることを、強く目指しています。
MCAPIの設計
MCAPIは、数多くのマルチコア・アーキテクチャに適し、分かりやすく適用が簡単な小さなAPIとして設計されました。他のCPU間通信方式を排除したり締め出したりすることもありません。
MCAPIはまた、シリコン・ベンダにとっても、ハードウェアをCPU間通信向けに最適化し、さらにはAPIをハードウェアに実装する契機となります。MCAPIは、OSまたはハイパーバイザ上で動作するほか、OSが存在しない状態でも動作します。ハードウェア・アクセラレーション機能との関係も良好です。マルチコア・アーキテクチャと複数の異なるOSを使用した設計での使用が可能で、メモリシステム設計に関する前提条件はありません。
MCAPIの概念
MCAPIの主要概念のいくつかは、ネットワークの知識があれば、かなり馴染み深く感じられます。最初の概念はドメインで、ネットワーク用語ではサブネットに例えることができます。MCAPIを使用するシステムには1つ以上のドメインがあり、各ドメインにはいくつかのノードが含まれています。各ノードが属することのできるドメインは1つに限られ、そこには階層構造が存在します。ドメインの概念は他のMCA策定APIによって使用されるため、この概念は一貫している必要があります。
ノードは抽象的な概念ですが、大枠で考えると、コード実行の流れとみなすことができます。プロセス、スレッド、タスク、コアもノードであり、他にも、ノードとして定義できるものがあるでしょう。あるノードの性質は、与えられたMCAPI実装環境に応じて指定されます。ノードは、mcapi_initialize() APIを呼び出すことで初期化されます。このAPIが呼び出されるのは、与えられたノードに対して1回のみです。ノードを再初期化するには、mcapi_finalize()を呼び出してから、mcapi_initialize()をもう一度呼び出します。
エンドポイントは、メッセージの送信先または接続の確立先であり、ネットワークにおけるソケットに似ています。各エンドポイントには、<ドメインID, ノードID,ポートID>という組になった固有の識別子があり、ノードには複数のエンドポイントが存在することがあります。作成側のノードは1つのエンドポイントから受信しますが、エンドポイントにはどのノードからも送信できます。
この事例(図1)でのノードは、OSのインスタンスとして定義されています。ノード0はLinuxシステムで、ノード1はNucleusです。通信は、2つのノードのエンドポイント間で論理的に行なわれます。実際の通信は、共有メモリを介して2つのMCAPI実装環境のトランスポート層間で行われますが、アプリケーション・プログラマがこの存在を意識することはありません。もちろん、共有メモリは通信インタフェースの一例に過ぎません。他に、イーサネットなどの選択肢も容易に使用できます。さらにMCAPIは、データの転送に対して高い柔軟性を提供します。
MCAPIの実装環境
MCAPIの多くの側面は、実装環境にある程度依存しているため、商用のMCAPI製品を検討している場合は、ベンダに対していくつかの疑問点をクリアにしておく必要があります。以下に、Mentor Embedded MCAPI実装環境の詳細についての考察を示し、メンター・グラフィックスが提供するMCAPI環境について説明します。 Mentor Embedded MCAPIの実証では、設計上の決定がいくつか行われました。まず、動的メモリ割り当てを使用しないことが決定されました。これは、組込みアプリケーションにとって一般的な慣習です。この実装環境では、下位階層のOSとの通信が抽象化層を介して行われ、OSへの依存性が最小限に抑えられ、移植性が向上します。
この実装環境では、MCAPI仕様による要求に従い、トポロジ全体がコンパイル時に決定される静的構成を特長としています。サービスに関連付けられたエンドポイントの登録と検出を行うため、管理サービスが組み込まれます。これにより、データを送受信するための柔軟性の高いトポロジが可能になります。
共有メモリの初期化は、システムまたはアプリケーション・コードにより実行される必要があります。また、ノード間のマスタ/スレーブ関係は、ブート順序の結果、実行時に設定されます。
多くのAPI呼び出しがブロック化されるため、スレッド中断メカニズムが必要です。Nucleusではイベント・フラグが使用され、Linuxでは条件変数が使用されます。
トランスポート層は、共有メモリ内にあるバッファの配列として実装され、共有メモリは各ノードのリング・キューおよび割り当てビットマップによって管理されます。移植性を最大限まで高めるため、プラットフォーム固有の層が設計されました。
アドレス空間に関して問題が1つあります。NucleusのようなスレッドモデルのリアルタイムOS(RTOS)は物理アドレスを使用しますが、Linuxはプロセス指向であるため、メモリを仮想アドレスに再マップします。問題を回避するため、MCAPI実装環境は、共有メモリ領域内部でのオフセットの面で機能します。
Mentor Embeddedとマルチコア
マルチコアに対するMentor Embeddedのサポートを表す「全体図」を図2に示します。ここには4つのコアがあり、Nucleusか、Linuxのバリアントを実行しています。Mentor Embedded Inflexion UIは、最新のユーザ・インタフェース(UI)により製品の差別化を可能にします。紫色の四角形は、組込みソフトウェア開発向けソフトウェア・ツールの範囲として、シミュレーションやUI設計からデバッグおよびプロファイリングまで示しており、複数のOSを内部に実装しているシステムの開発が中心部に位置しています。最後に、オレンジ色の四角形は、Mentor Embeddedによって提供されるサービスである、サポート、コンサルティング、およびトレーニングを示しています。Mentor Embeddedでは、お客様のマルチコア設計を成功に導くお手伝いをするために、独自の技術を習得したエンジニアを揃えています。
■Nucleus SMP
Nucleus SMPは、シングル・プロセッサ向けのNucleus RTOSを直接進化させてマルチ・プロセッサ対応にしたもので、シームレスな後方互換性を提供し、エンジニアの幅広い知識を現場で活用できます。
■MCAPI
NucleusおよびLinuxは、どちらも多種多様な非対称型マルチプロセッシング・プラットフォームでサポートされており、移植レイヤにより、自社開発OSやその他の3rdパーティ製OSに容易に移行できます。MCAPIを実装すると、AMPの構成は完了します。
まとめ
Mentor EmbeddedによるMCAPI実装環境は、軽量でスケーラブルであり、MCA規格に完全に準拠しています。この実装環境は、異なるターゲット・デバイス、トランスポート・アーキテクチャ、およびOSにかかわらず高い移植性を確保するように設計されています。この実装環境に対してはテストや実証が十分に積み重ねられており、開発段階において1,100種類のテストケースにかけられました。Mentor Embeddedは、MCAPI作業部会のメンバであり、MCAPIの実装環境一式を含む一連のソフトウェアIP、ツール、およびサービスをマルチコア・ソフトウェア開発者に提供しています。
マルチコア設計向けのソフトウェア実装には課題が残っていますが、MCAPI仕様は、CPU間通信の重要な問題に対する優れた解決方法を提供しており、普及しつつある規格の1つになっています。

