Synthetic Simulation Platformの内側
投稿者：Jakob Engblom, 2012/07/03
ウインドリバーは、Wind River Simics最新版に搭載される、QSP（Quick-Start Platform）というシミュレーション専用のSimicsターゲットマシンを発表しました。QSPは、Simicsを活用して即座にスタートでき、ソフトウェア開発におけるシミュレーションの利点を得られるSimicsターゲットをすべてのユーザに提供するものです。今回の記事では、QSPの知らせざる仕組みについてご紹介します。
QSPは、仮想化専用ハードウェアの一部をなるべくシンプルに設計しつつ、実際のOSのシミュレータを実行し、通常のハードウェアでの動作を確認できるように作られています。
このアイデアは新しいものではありません。これまでにもSimicsチームや他のシミュレーション事業者が類似した取り組みを行ってきました。しかしながら、Simics QSPを活用したボトムアップ設計はこれまでありませんでした。通常は、既存のプラットフォームのシステム・コントローラとコア・コンプレックスの部分から設計を始めます。その後、様々なIO向け統合デバイスを使います。私の経験を振り返りますと、2006年の学生プロジェクトで、SMP Linuxを縮小版のSimics PowerPCプラットフォームにポートしました。最近では、同僚がVxWorksを、プロセッサ、メモリ、シリアルポートと割り込みコントローラだけというシンプルな構成のユニプロセッサSIモデル（既存のPICに似せてモデリングされた）にポートしました。VxWorksチームは、新アーキテクチャへのOSポーティングに高度に簡素化されたプラットフォームを活用しました。
Simics QSPでは、設計作業の幅広さと深さが新たに加わっています。既存のハードウェア・モデルを縮小して複雑性を排除するのではなく、空白ページでシステム上のデバイスごとに設計をすることで、なるべく使いやすくシンプルなものに仕上げられることができます。また、デバイスには柔軟性と拡張性を持たせ、システムの設定に不要かつ偶発的な制約をかけないようにしました。エンジニアに仕様を伝えた後、私は少数のシンプルなデバイスで構成されたプラットフォームが提示されることを期待していました。しかし実際は、最新のOSを機能させるために驚くほどの多くのハードウェア・サービスが必要であることがわかりました。その結果、初期のQSPでは、プロセッサ・コア以外にも9種類のデバイスが使われていました。
現在当社が提供しているQSPのブロック図を上に示しています。ハードウェアの数の少なさに気付いていただけるかと思います。OSを動かすには、プロセッサが必要です。プロセッサは、コードやデータの格納先としてRAMを必要とします。定期的な割り込みのためにはタイマーが必要です（基本的なニーズはPower Architectureの内部機能で対応できても、ARMやその他のアーキテクチャ用に追加のタイマーが必要となる場合があります）。デバイスからや、プロセッサ間の割り込みを処理するには、割り込みコントローラが、そして、プライマリ以外のプロセッサをマルチコア・システムで起動するには、システムコントローラが必要です。大規模なファイルシステムの格納にディスクを使用する際など、正確な日付を保持するには、リアルタイムクロック（RTC）が必要となります。
これらのコア・デバイスとは別に、シリアル、イーサーネットやLEDなどには、入出力機能が必要です。ディスクやフラッシュディスクを追加し、大規模なファイルシステムやフラッシュベースのアプリケーションに対応します。すべての構成においてすべてのIOユニットが必要なわけではなく、ユーザの判断に依存します。
柔軟性を高めるために、一部のアプリケーションが複数のプロセッサや重要な機能性デバイスを必要とする場合には追加できるようにしています。これは仮想プラットフォームのため、実際のハードウェアの物理的な制約は受けません。私たちはこの利点をユーザも享受できるようにしたいと考えました。そこで、BSPとターゲット・ハードウェアの両方に書き込む手段が最も効果を発します。最も現実的なマルチコア・ハードウェアでは、シミュレータで使用できるコア数に制約をかけていなくても、システムコントローラのレジスタに恣意的な制約を持たせているか、割り込みコントローラの設計上、制約が発生します。拡張性の高いハードウェア・インターフェースやそれを動かすBSPを設計することで、理論上ではシステムをいかなるコア数にも拡張できることになります。現状の上限は128ですが、将来的にはもっと増える可能性があります。
デバイス自体の設計を見てみると、プロジェクト開始時の想定よりさらに多くの詳細が必要なことがわかりました。
例えば、イーサーネットは割り込みの送受信が必要です。理想的な状況では、送信は不要だと思いますよね。しかし、帯域幅を無限にすると既存のソフトウェアに混乱を与えてしまうため、帯域幅に上限を設定しなければならず、そうなると、パケットの送信時間がかかってしまい、送信が完了した割り込みのみが割り込みとみなされることになります（または、ポーリング・ドライバ付きの送信完了フラグと同等）。また、デバイス内にシンプルなバッファを持つ代わりに、ネットワーク用の既存のドライバ・スタックが求めているRAMに記述子テーブルを持たせました。
もう1つ驚いたのは（NOR）フラッシュメモリのシミュレーションに、フラッシュ・コマンドセットを実際に実装する方法が最善であった点です。ファイルシステムとフラッシュドライバのスタックは、フラッシュが特定のオペレーション・パターンをたどることを期待しています。例えば、複数の書き込みがあった時に書き込みモードに変える、などです。常套手段と思えるフラッシュを不揮発性RAMメモリとしてモデリングするだけでは上手く行かなかったのです。
全体としては、QSPの作業を進めるに従い、最近のハードウェア・インターフェースのデザインが、いかにOSの構造に多大な影響を与えているのかがわかりました。LinuxやVxWorksなどのOS上のBSPやHAL（ハードウェア抽象化レイヤ）では、ハードウェアがOSより下で動かすことはできません。ハードウェアで機能を表現するのに最もシンプルな方法だろう、と一般に想定されるものとは異なる振る舞いのパターンが期待されているのです。QSPデバイスをより軽量化するには、複雑性が増してしまい、OSカーネルやデバイスドライバの構成により深い変更が必要になってしまったことでしょう。
最終的にリリースできたものは、特定のハードウェア・モデルを使用したりモデリングせずにアプリケーション開発やその他の開発作業を進めることができる、強力な仮想ハードウェアでした。Simicsが使用されている多くのタスクには、特定のハードウェアボードのモデルが必要ですが、その場合にはあくまでQSPは従来のSimicsモデルの置換えではなく補完的な役割で使用されています。
原文はこちら：http://blogs.windriver.com/tools/2012/07/inside-a-synthetic-simulation-platform.html
本社ブログサイト：http://blogs.windriver.com/
