SoCでもマルチコア化は進むのか？（2/2 ページ）

[Ron Wilson，EDN]

インターコネクトとキャッシュ

　SoC上の処理エレメントが同一のものに近づくに連れ、インターコネクト（相互接続）とメモリーアーキテクチャに関する問題が大きくなる。OSのカーネルが自由にタスクを割り当てられるよう、プロセッサを完全な対称構造に並べたいという願望と、データの共有用途に特殊なインターコネクトを用いたいという要求が当然のように生じる。最も簡単な解決策は、サーバーで用いられている手法を模倣することである。つまり、大容量の共有メモリーを用いて、すべてのプロセッサ向けにL1およびL2ローカルキャッシュを設けるのだ（図1）。この場合、すべてのプロセッサがすべてのメモリーにいつでもアクセス可能なプログラミングモデルを利用できる。

図1　8個のプロセッサすべてにL1/L2ローカルキャッシュを搭載した例　Freescale社の「P4080」は、8個のプロセッサを搭載したSoCである。ハードウエアアクセラレータを搭載したシングルCPUのSoCからマルチコアSoCへの進化を象徴したものだと言える。

　この手法では、ハードウエアによるキャッシュコヒーレンシを完全にサポートしなければならない。カナダのQNX Software Systems社で製品管理担当ディレクタを務めるKerry Johnson氏は、「すべてのプロセッサに対してキャッシュコヒーレンシをサポートするハードウエアが必要だ」と述べる。ハードウエアによるコヒーレンシを使わずにシステムを稼働することも可能だが、ソフトウエアにかかるオーバーヘッドが大きすぎると考えられている。

　共有メモリーだけが、プロセッサ間の論理的接続方法であるとは限らない。AMCC社のBouvier氏は、「ハードウエアによるメッセージパッシングやそのほかの直接的なプロセッサ間通信リンク、I/O仮想化をサポートしてもよいだろう」と提案する。そうすればシステムがあるプロセッサにタスクを割り当てるとき、そのプロセッサがI/Oストリームへの接続を失わずに済む。OSのタスクを固定するのではなく、ほかへの割り当てが行えるようにするには、割り込み制御やDMA（Direct Memory Access）を集中管理にするか、均一に分散することにより、コア間の対称性を保つ必要がある。

　では、どのようにしてこれらの機能を、オーバーヘッドを抑えた形でハードウエアに実装すればよいのだろうか。これを実現するのは、容易なことではない。ローカルキャッシュを共有メモリーに接続するだけでも難しく、さらに従来の共有バスからスイッチベースのバスや複雑なマルチレベルのバスへ移行することが必要になる。加えて、プロセッサ間のダイレクトメッセージングを加えるならば、問題はより複雑になるだろう。

　米Freescale Semiconductor社のプラットフォーム担当ディレクタであるDac Pham氏は、「消費電力の上限を超えることなく、いかにしてすべてのプロセッサに電力を供給するかが問題の1つだ。個々のデータフローの帯域幅と遅延の両方の要件を考慮しなければ、CPUが“飢餓状態”になってしまう」と述べる。

　また、Freescale社でシニアシステムアーキテクトを務めるSteve Cole氏は「1つの方法ですべてを解決できるとは限らない」と指摘する。さらに、Pham氏は「最近、われわれはコンフィギュラブル（構成可能）なキャッシュコヒーレンシを採用した。この機能によって、設計者はメモリー構造を拡張できる。ここで重要なのは、単に流れているだけのデータなど、コヒーレンシが不要な部分に対してコヒーレンシを適用しないことだ。それにより、消費電力や遅延について考慮する必要がなくなる」と説明を加えた。

未解決の問題

　ここまで述べてきたように、従来のSoCから対称型マルチコアSoCへのロードマップは、明確にできあがっているように思える。しかし、未解決の問題もいくつか残っている。例えば、アプリケーションにおける並列性の抽出、ハードリアルタイム処理への対応などが未解決の問題として挙げられる。ここでは、そうした未解決の問題について触れておく。

■並列性の抽出

　並列性の抽出は、マルチコアを利用するシステム設計を行う上で必要となる最初のステップである。例えばビデオ圧縮におけるマクロブロックの処理など、そもそも並列性がデータの並列性によってもたらされる場合は、この問題には比較的容易に対処できるだろう。しかし、既存のアルゴリズムにおいて、独立したプログラムスレッドを検出することで並列性を抽出しなければならない場合には、解析的な解決策は存在しない。そのため、労力と知恵、さらには「運」が必要となる。Freescale社のCole氏は、「組み込みの世界でも、マルチスレッドアプリケーションが開発されるようになるだろう。しかし、そのコードはおそらくゼロから開発するか、新興企業から買収することになり、既存のシングルスレッドのコードが書き直されることはないだろう」と述べる。

■ハードリアルタイム処理への対応

　ハードリアルタイム処理への対応も大きな問題である。米Microsoft社による「十分に高速であれば、非決定的なシステムでもリアルタイムな処理を実現できる」という主張は、ハードリアルタイムを要するSoCの世界では通用しないかもしれない。

　データの正確な送信元がわからなければ、動作時の遅延を予測することはできない。しかし、キャッシュコヒーレントなSMPのシステムにおいて、遅延は非決定的であり予測できないものだ。また、動的にタスクを割り当てるシステムにおける割り込みの応答時間についても、割り込みがデコードされた瞬間のタスクの割り当て状況と、プロセッサや電力管理の状態に大きく依存するため、遅延を予測できない。

　このようにSMPとリアルタイム処理との間には、ハードウエアへの要求事項に明確な境界があることから、「リアルタイムのタスクはSMP以外の専用プロセッサに静的に割り当てるべきだ」と考える設計者もいる。Bouvier氏は、「SMPとは独立した、独自のリアルタイムOSが稼働するプロセッサが混在するようになるだろう」と述べた。

■真の分散OS

　OSの進化の方向性に合わせて、プロセッサの開発は進められている。SMPをSoCに採用するには、真の分散OSが登場する必要がある。つまり、特定のプロセッサ上で稼働するマスターのカーネルが1つ存在するのではなく、各プロセッサ上にマイクロカーネルがあり、そのほかのOSスレッドをプロセッサに動的に割り当てるようなOSである。組み込みLinuxの開発者は、この目標に向けて作業を進めているが、完成品はまだ存在しない。

■デバッグ

　もう1つ、デバッグという大きな問題がある。Open-Silicon社のBoppana氏は、「分散アプリケーションでは、従来とはまったく異なるデバッグ手法が必要になる。並列化された処理にアクセスしてその状態を調査する手段と、イベントが生じるまでの動作を再現する信頼性の高い方法が必要だ。アクティビティモニターや熱モニターなどにおいても、従来と比較して求められる情報の種類が多くなる」と指摘する。Bouvier氏も同意見で、「1つの大きなスレッドの代わりに多数の細かいスレッドが用いられるということは、プロセッサ間の依存度が高いということだ。複数のプロセッサを同時にデバッグするのは、かなり困難な作業となる。どのようにして互いに依存するマルチプロセッサシステムを実行/停止/トレースするのか。膨大なデータの取得は可能だとしても、それをどのようにしてチップの外に取り出すのか」とSMPにおけるデバッグの難しさを強調した。

　現在、デバッグの問題に関する多くの研究が行われているので、その成果に期待がかかる。

---

　本稿の最後に述べたような未解決の問題があるのにもかかわらず、SMPを部分的に採用したSoCがすでに存在している。また、ネットワーク処理や科学技術計算などのように並列性の高いアプリケーションでは、すでに多数のプロセッサを搭載したシステムが稼働している。今後もこの傾向は間違いなく継続し、より拡大していくはずである。それに伴い、ハードウエアの実装にかかわる複雑さはソフトウエアへと移行し、SoC設計チームの構成にも変化が現れるだろう。