組込みソフトウェア開発のためのSoCバーチャルプラットフォームをつくるには CircuitSutra Technologies

1. はじめに

SoCの開発にあたって、多くのシステム設計者がSystemCベースのバーチャルプラットフォームを用いた設計検証を採り入れるようになってきました。バーチャルプラットフォームの構築にあたっては、その用途に応じて適切な抽象度を選択することが大切です。モデル開発の労力とシミュレーション速度に大きな影響を与えるからです。本稿では組込みソフトウェア開発のためのSoCバーチャルプラットフォームを中心に、SystemC / TLM2.0でどのように構築したらよいのかについて述べます。

さて、昨今のSoCは、マルチメディアやネットワーク・アプリケーション用途に向けた高度のソリューションを提供する様々な処理エレメントや多種多様な入出力機能を持ち、高速通信プロトコルを備えたマルチコアシステムになっています。演算、通信、マルチメディアデータ処理など膨大な機能をひとつのチップに集積するため、SoCのハードウェアインテグレーションとソフトウェア開発、いずれにおいてもその複雑性が増大し、加えてカスタマイズの容易さやプログラム性を考慮し、ソフトウェア集約型になってきています。

ソフトウェアの構成は、ファームウェア、デバイスドライバ、通信スタック、OSコード、アプリケーションソフトウェアなど膨大であり、その開発と検証環境の整備は大きな課題です。このソフトウェア開発における難題を解決するひとつの手法として導入されたのが、抽象度の高いSoCのシミュレーションモデル、すなわちバーチャルプラットフォームです。ソフトウェア開発に必要十分な実行速度と精度を備えたモデルを用意することで、チップ設計と並行してソフトウェア開発を進めることができ、製品の開発期間を短縮し市場への早期投入を可能とします。

バーチャルプラットフォームを採り入れる何よりも大きなメリットは、従来のFPGAボードを用いた組込みソフトウェア開発手法に比べて強力で柔軟なデバッグ機能を得られることです。マルチコアSoCの膨大かつ複雑なソフトウェア開発、検証、デバッグ作業をより速く的確に行なうことができるようになりますので、技術者の労力負担の削減、作業生産性の向上に大きく寄与します。

それでは次項から、組込みソフトウェア開発に用いるSoCのバーチャルプラットフォームをどのような点に気を配り開発すればよいのか、その要点についてお話しを進めていきます。

2. バーチャルプラットフォームの抽象レベル

SoCのバーチャルプラットフォームを開発する際に最も大切な決断は、最適な抽象レベルを選択することです。

抽象レベルの選択は、ハードウェアの機能とタイミング精度をどの程度モデル化するかを決定づけることになりますが、その判断基準となるのはバーチャルプラットフォームの用途です。バーチャルプラットフォームは、組込みソフトウェアの開発、RTL検証、アーキテクチャ探索、パフォーマンス解析など様々な用途に利用できますが、今回は高い抽象レベルのバーチャルプラットフォームを必要とする組込みソフトウェア開発に議論を絞ります。

下図１のダイアグラムは、組込みソフトウェアのユーズケースと対応したバーチャルプラットフォームの様々な抽象レベルを示しています。水色のブロックはバーチャルモデルを、緑のブロックはそれらバーチャルモデルを使って開発、検証を行なうソフトウェアを示しています。図で示す３つのケースについて以降に説明します。

Programmers View

図１左端のProgrammers Viewモデルに含まれているのは、プロセッサの命令セットシミュレータ (ISS) とペリフェラルのレジスタ精度のトランザクションレベルモデルで、HAL(Hardware Abstraction Layer) やデバイスドライバを開発するソフトウェア開発チームでの使用に適しています。

もちろん、ミドルウェアやアプリケーション開発にも使用できますし、レイヤ構造を取らず直接ペリフェラルのレジスタをプログラムしハードウェア機能にアクセスするような小さな組込みアプリケーションの開発に使用する場合もあります。

HALやデバイスドライバはハードウェア毎に固有に開発するものです。ハードウェアとの関わりが密接ですのでデバイスドライバから見えるすべてのレジスタと、これらレジスタに関連する機能は正確にモデリングするべきです。

Programmers Viewモデルを開発する上で必要なものは、

　・SoCの仕様書

　・組込みソフトウェアをクロスコンパイルするためのターゲットSoCのツールチェーン

組込みソフトウェア開発のためのSystemCモデルという場合、業界で最も一般的に使われる抽象レベルはこのProgrammers Viewです。トランザクションレベルモデリングの標準化作業の多くもこの抽象レベルで行なわれています。

この抽象レベルでIPモデルを開発するにはOSCI TLM2.0基本プロトコルのLTメソドロジ、またはOCP-IP TL4が適しています。

Algorithmic View

Algorithmic Viewモデルは単なるハードウェアモデルではなく、ハードウェア＋ソフトウェアのモデル、すなわちひとつの電子機器製品全体です。Algorithmic Viewモデルは、ソフトウェアスタックのどのレイヤがモデルに含まれているか、このモデルを使ってどのソフトウェアスタックを開発／検証するか、によって異なるタイプのモデルがあります。

図１中央のAlgorithmic View (AV1)は、SoCの機能とHALやデバイスドライバ・レイヤを一体にしてシミュレーションするタイプのバーチャルプラットフォームです。実際のデバイスドライバ・レイヤと同じAPIインターフェイスを備えているので、汎用ミドルウェアなど高いソフトウェアレイヤを開発する用途に適しています。

ミドルウェア・レイヤは一般に汎用性があり特定のハードウェアに依存しません。そのようなレイヤを開発するためのバーチャルプラットフォームでは、低いレベルのハードウェア機能の大部分は抽象化できるので、ハードウェアの詳細をモデル化する必要がありません。

プロセッサモデルは命令セットは必要なく、C, C++で書いた演算機能のセットでかまいません。ペリフェラルモデルに関してもレジスタ精度は不要で、C / C++ファンクションで実装したトランザクションモデルでかまいません。TLM2.0インターフェイスは必要ありません。この抽象レベルで開発するモデルに標準のTLMインターフェイス定義はありません。

SystemCを使う必要があるのは、並列性のある動作のモデリングやイベントを使って適当なシーケンスを維持する必要があるときに限られます。デバイスドライバ・レイヤでは、実際のデバイスドライバが行なうようなレジスタのプログラミングは実装しません。ファンクションコールを介してペリフェラルを単純にアクセスするダミーレイヤで代用します。

Algorithmic View (AV1)を開発するのに必要なものは、

　・SoCの仕様書

　・HAL 、デバイスドライバのAPIインターフェイス仕様書（デバイスドライバを使いミドルウェアレイヤを開発するエンジニアが参照する仕様書）

図１右端のAlgorithmic View (AV2)は、SoCの機能とHALやデバイスドライバ、さらにミドルウェアを一体にしてシミュレーションするタイプのバーチャルプラットフォームです。ミドルウェアレイヤと同じAPIインターフェイスを備えており、組込みアプリケーションを開発、実行する場合の使用に適しています。

組込みアプリケーションソフトウェア開発に使うモデルの中で最も高い抽象レベルであるのがこのプラットフォームです。他の特徴は先に説明したAlgorithmic View (AV1)の抽象レベルと同様です。

Algorithmic View (AV2)を開発するのに必要なものは、

　・SoCの仕様書

　・ミドルウェアレイヤのAPIインターフェイス仕様書（組込みアプリケーションを開発するチームが参照する仕様書）

3. バーチャルプラットフォームの設計要素

図２は典型的なバーチャルプラットフォームの事例です。

SoCのバーチャルプラットフォームを開発する取り掛かりとしては、何らかの標準アーキテクチャ用の既存バーチャルプラットフォームを使うとよいでしょう。多くのバーチャルプラットフォーム・ツールベンダはリファレンスボードのプラットフォームを提供していますので、それを土台にするのが近道です。

組込みソフトウェア開発のためのバーチャルプラットフォームを開発するにあたっては、次に上げる設計要素についてそれぞれ設計方針の検討が必要です。

　1. システムIPモデル

　2. メモリモデル

　3. プロセッサモデル

　4. 通信モデル

　5. 外部デバイスへのアクセス

　6. デバッグインターフェイス

以降に、これらの設計要素をモデリングするにあたっての考え方、留意点、アイデアなどを順に述べます。

3.1 システムIPモデル

すべてのSoCは何らかのIPを含んでおり、それらが互いに通信をしています。これらIPブロックのレジスタ精度のモデルはSystemCとTLM2.0で作成します。

モデルはSTARC TLMガイドラインに沿って開発することを推奨します。すなわちコアの計算機能とインターフェイスは分離させることになりますが、これにより抽象レベルが変わってもコアを再利用しやすくなります。IPモデルを搭載するプラットフォームの環境ごとに外部とのインターフェイスが変わっても、コアの機能には影響を与えずにインターフェイスだけを変更することができます。

IPモデルとシステムバスとの接続にはOSCI TLM2.0インターフェイスを用います。OSCI TLM2.0はモデル間の相互運用性を考慮した標準規格です。異なる供給元から供給されたモデル間をプラットフォーム上でシームレスに結合します。また、ほとんど全ての商用バーチャルプラットフォーム・ツールはTLM2.0をサポートしていますので、TLM2.0標準に沿って開発したモデルは基本的にどの商用ツールにも搭載できます。

一方で、モデルとESLツールとの相互運用性を考慮する場合には注意が必要です。現状はツール毎にモデルの解析やデバッグのためのモニター方法が異なっているため、モデル開発者はツール毎に異なるアクセス手段を供給することを要求されます。現在OSCI CCI ワーキンググループではこの状況を改善し、モデルとツールとの相互運用性を向上させるため、モデルの構成やアクセスの容易性、可視化の標準メカニズムを定義する作業を進めています。OSCI CCI がベースにしているのはGreenSocsが提供するオープンソースのメカニズム GreenConfigです。GreenSocsは異なるベンダツールへのプラグインも提供していますので、 GreenConfigで作ったモデルはどのツールでも観測できます。

残念ながら、OSCI CCIは未だリリースされておりませんので、それまではモデル開発にGreenConfigを使うことをお勧めします。Greensocs はオープンソースのライブラリを提供しており、ウェブサイトから無償で入手できます。 (www.greensocs.com).

各システムIPモデル内部は基本的に以下の４つのコンポーネントで構成します。IPのモデリングを行なう際にはこれらコンポーネントを互いに独立させることが大切です。

では、それぞれについて説明します。

A. 通信機能

IPと外部との通信機能を記述します。'3.4　通信モデル'で詳しく説明します。

B. 計算機能ブロック

IPの機能を記述するブロック。計算処理やステートマシン。

C. レジスタ・インターフェイス

IPのレジスタセットは他のコンポーネントとは切り分けて、chars, int, short int などのC++ データタイプ、または SystemCデータタイプのフィールドから成るレジスタを実装したC++ class またはSystemCモジュールとして独立して定義できます。サイズ、フィールド、read only / write only、マスクなどを可変にした共通のレジスタ・インターフェイスを作っておき、リード／ライトのオペレーションが起きたときにイベントやコールバックを付加できるようにしておくと便利です。レジスタ・インターフェイスは計算機能ブロックと相互にやりとりできるようにしておかなければなりませんし、計算機能ブロックもレジスタへのリード／ライトアクセスができなければなりません。SystemCモデルにレジスタを実装するための標準規格はなく、ベンダ毎に異なったメカニズムでサポートしているのが現状です。参考までにGreensocsはオープンソースの実装モデルGreenregを提供しています。

D. タイミング

IPモデルの抽象レベルはタイミング精度と密接な関わりがあります。抽象レベルを変更する際にリファインメントしやすいよう、タイミングは切り分けてモデリングすることが肝要です。以下に、Untimed / Loosely timed / Timedの３つのタイミングモデルについてその特徴と違いを説明します。

Untimed Model

時間概念のないレジスタ精度のモデルで、モデリングの際は、TLM2.0 のブロッキングインターフェイスで作成し、ゼロアノテートタイミングディレイでTLM2.0トランスポートコールを使います。IPの機能ブロックもタイミング詳細を与えずにモデリングします。

このタイプのモデルは、実デバイスの並列処理をエミュレートするSystemC スレッドを使わずにモデリングできます。IPモデルにスレッドがないとシステム全体を非常に高速に実行できます。なぜならスレッドのコンテクスト切り替えがないことと、すべてのオペレーションがひとつのスレッドで実行されるからです。このタイプのモデルは組込みソフトウェア開発のためのバーチャルプラットフォームに最適です。しかしIPの何らかの動作タイミングに依存するようなソフトウェアコンポーネントはフェイルします。たとえばソフトウェア開発者が、レジスタの更新をもってIPが即座に発行する割り込みではなく、割り込みタイミングを想定していたとすると、ソフトウェアは割り込みを正しく捉えることができません。

Loosely timed model

IP機能に組込みソフトウェアの実行に必要な最低限のタイミングを実装したモデルで、TLM2.0のアノテートタイミングを含んだブロッキングトランスポートコールを使います。

このモデルはSystemC スレッドをまったく使わずに、もしくは最低限の使用でモデリングできます。 IPモデルはwait のコールやタイムド・イベントにセンシティブなスレッドを使うことにより遅延を認識します。遅延がレジスタアクセスや、レジスタアクセスに関わる機能であれば、遅延を明示する代わりにブロッキングトランスポートコールのアノテートタイミング・アーギュメントを更新することによりIPモデルからイニシエータに遅延情報を送り返すことができます。

複数のスレッドが存在するとコンテクストスイッチングによりシミュレーション速度を低下させますが、テンポラルデカップリングを使うとスレッド間のコンテクストスイッチングの回数を減らしシステムスピードを改善できます。テンポラルデカップリングはローカル変数を通して時間の経過を追いながらシミュレーションの現在時間に先行してスレッドを実行することができ、クオンタムに到達したらシミュレーションカーネルと同期します。

Timed model

時間精度の一番高いモデルで、TLM2.0のノン・ブロッキングインターフェイスを使います。OSCIのATメソドロジを使うか、もしくはより多くのタイミングポイントを扱うには基本プロトコルを拡張します。IPの機能もタイミング詳細を含んでモデリングできます。このタイプのIPモデルは実際のハードウェアで行なわれる並列処理をタイミングを含めて表現するため複数のSystemCスレッドで作ります。組込みソフトウェアの開発用には適しているとは言えません。

3.2 メモリモデル

メモリはSoCの大変重要な構成要素です。SoCの通信トラフィックの大きな要因はメモリのリードやライトです。従って速いバーチャルプラットフォームを開発するにはリード／ライトアクセスに関して十分に最適化したメモリモデルを使用することが大切です。

メモリモデルはOSCI TLM2.0に準拠していなければなりません。コアのトランスポートインターフェイスに加え、OSCI TLM2.0で定義されているDMIインターフェイスの実装も必要です。デフォルトではメモリのリード／ライトにはISSがブロッキングトランスポートファンクションをコールしますが、メモリアクセス頻度が高くなるとトランスポートコールが非常に多くなり、これがシミュレーションスピードに影響を与えます。DMIインターフェイスを用いることにより、メモリデータのポインタをISSマスターモデルに渡し、ISSはトランスポートファンクションコールを作らずダイレクトにメモリにアクセスすることができます。

また、個々のリード／ライトのコールにおいては、その度にメモリモデルがwaitをコールしてリード／ライト処理遅延を与えるべきではありません。waitを頻繁にコールするとシミュレーション速度に多大な悪影響を与えます。遅延そのものを与える代わりに、トランスポートコールのアーギュメントを介してイニシエータにアノテートディレイを送ることを推奨します。この方法を使うとイニシエータがテンポラルデカップリングを使うことができ、複数のトランスポートコールを処理した後で同期更新すればよいからです。

3.3プロセッサモデル

SoCバーチャルプラットフォームを作るには、プロセッサコアのソフトウェアモデルも必要です。

モデルはプロセッサを開発・販売している企業やバーチャルプラットフォームのツールベンダから入手することができます。またはOVPやQemuなどオープンソースのプロセッサモデルもあります。これらの企業では大抵、C / C++をつかった独自の技術でプロセッサモデルを社内開発しており、このモデルにTLM 2.0 ラッパを作ることでTLM2.0 に準拠した他のIPブロックのモデルとバーチャルプラットフォーム上で接続できるようにしています。

バーチャルプラットフォームに用いるプロセッサモデルは一般的にはプロセッサABI準拠の命令セットシミュレータ (ISS)です。ISS は正確なタイミング詳細を含めたサイクル精度のモデルであることもありますし、より抽象レベルが高く、組込みソフトウェア開発用のバーチャルプラットフォームに使うUntimedモデルの場合もあります。

バーチャルプラットフォーム上で実行する組込みソフトウェアはターゲットプロセッサのツールチェーンでコンパイルします。ISSはターゲットCPUの命令を読み、バーチャルプラットフォーム上でターゲット命令をシミュレーションするためのホスト命令を生成します。またプロセッサの内部ステートを保持します。実行中に命令毎にコードの変換を行なうのでシミュレーション速度はISSの処理速度に支配されることになります。そこでISSではシミュレーション速度を上げるため様々な最適化の技術が使われています。例えばQemuではいくつかの命令をまとめて最適化しホスト命令を生成することにより高速化を図っています。

3.4 通信モデル

SoCで行なわれる通信は２つのカテゴリに分類できます。SoC内部のIPブロック間の通信であるオンチップ通信と、SoCと外部デバイスとの通信である外部インターフェイスです。

オンチップ通信：

SoCには１つないし複数のプロセッサコアと他にいくつかのIPブロックが搭載されています。これらすべてのブロックは互いにブロックのピンを通して配線でつながっており、このピンと配線を通してデータをやり取りすることにより通信をしています。高い抽象レベルでモデルを作成するときにはピンレベルのインターフェイスを作る必要はなく、高いレベルのファンクションコールでデータ転送を行ないます。これがトランザクションレベルモデリングです。トランザクションレベルのモデルはピンレベルのモデルに比べ非常に高速にシミュレーションが行なえます。

大抵のSoCでは何らかのメモリバスプロトコルを使い、これを介してプロセッサコア（マスタ）がその他全てのIP（スレーブ）と通信しています。OSCI TLM2.0はメモリマップド・バスプロトコル用の標準トランザクションレベルインターフェイスを用意しています。AMBA, PLBなど一般によく使われるSoCバスはいくつかありますが、プロトコル定義やタイミング詳細は各々異なります。しかし高い抽象レベルで考えたときには、これら低レベルでの機能とタイミングの詳細はモデリングする必要がないのです。OSCI TLM2.0は高い抽象レベルでメモリマップドバスを表現できる基本プロトコルを提供しています。

IPにはメモリマップ通信に関連するピンのほかにも通信のためのピンがあります。例えば割り込みコントローラの割り込みライン、タイマのゲート入力などです。これらは単独に機能するピンなので通信プロトコルのように他のピンと一緒にまとめてしまうことができません。このようなピンをモデル化するひとつの方法はsc_in, sc_outのような標準SystemC ポートを使うことです。

このSystemC ポートを介した通信はイベントに連動しており、SystemC スケジューラのサイクルを更新するのでシミュレーション速度に影響を与えます。このような信号がSoC内に多く存在するとシミュレーション速度の低下が懸念されます。そこで高い抽象レベルでモデルを作る際には、通信にはピンを使わずファンクションコールを使うことを推奨します。TLMインターフェイスを定義して、ペイロード変数を介し信号の値を伝播させます。または汎用ペイロードをカスタムペイロードと置き換えることにより新しいプロトコルを定義するOSCI TLM2.0の拡張のメカニズムでも対応できます。この場合信号毎に新しいTLMプロトコルを定義しなければならず、接続はイニシエータとターゲットとの１対１のソケット接続で行なわれます。

他の方法としては、SoC内におけるそのような単独信号全てについて共通のTLMプロトコルを定義することです。各信号はペイロード拡張としてペイロードデータメンバーに加えます。この場合イニシエータからターゲットへの接続にはバスを使います。IPの全てのイニシエータソケットはバスのターゲットソケットに、IPの全てのターゲットソケットはバスのイニシエータソケットに接続します。１対１接続ではなくバスを使うことはパフォーマンス面での利点はありませんが、接続を形成する際に便利です。しかしその利便性は、より複雑なTLMプロトコルを定義したり、追加のコンポーネントやバスをモデリングする際には障害となります。よってSOC上にそのような信号が多数あるときにだけ有効な手法です。

外部インターフェイス：

SoCは外部デバイスと通信するためのインターフェイスも備えています。例えばUSB, Ethernet, WLAN, CAN, UART, I2C, SPI, SATA などです。高い抽象レベルでは実物のデバイスのようにビット単位での精度やサイクル精度での伝送プロトコルをモデリングする必要はありません。ファンクションコールやアノテートタイミングでパケット全体を送信する方法を取ります。そのような処理を行なうため通信プロトコルごとにTLMプロトコルを定義します。モデル化するIPブロックがこれらの通信プロトコルで通信する場合には、ピン精度のモデルを作る必要はありません。通信に関わる全てのIPのピンはTLMソケットにより抽象化されます。

OSCI TLM2.0はメモリマップドバスについては標準TLMインターフェイスとバスプロトコルを定めていますが、USB, Ethernet, WLAN, CAN, UART, I2C, SPI, SATAなどの非メモリマップドバスに関してはそのような標準のTLMインターフェイスやプロトコルは定義していません。高い抽象レベルでモデル化するには、それらの各通信バスに関してTLMプロトコルを新たに定義しなければなりません。OSCI TLM2.0は基本プロトコルを拡張するメカニズムをそなえていますので、その機能を使い非メモリマップドバス用の新しいTLMプロトコルを定義することができます。

本稿で主眼としているのは組込みソフトウェア開発を目的とした高い抽象レベルでのバーチャルプラットフォームですが、その用途にはOSCI TLM2.0のブロッキングインターフェイスを使ったUntimedまたはLoosely timedのモデルを作ることが必要ですので、非メモリマップドバスをモデル化するためのTLM2.0の拡張にはブロッキングインターフェイスを使用します。この拡張にはバスごとに固有の新しいペイロードを定義する必要があります。ペイロードはTLMコマンドに対応した変数 (基本プロトコルのリードやライトに似ています)、送信するデータ、コマンドと関連したハンドシェイクプロトコルのためのコントロール信号を持ちます。

一方、AT,CAなど低い抽象レベルで、よりタイミング精度の高いモデルを作りたい場合にはTLM2.0のノンブロッキングインターフェイスを使います。その際にはトランザクションのタイミングポイントに対応したフェーズも定義します。フェーズの数はトランザクションのタイミングポイントの数に依ります。タイミング精度を上げれば上げるほどトランザクションのタイミングポイントは増えフェーズも増加します。

ところで非メモリマップドバスのモデリングにはOSCI TLM2.0を拡張することが唯一の方法ではありません。非メモリマップドバスごとにそれぞれインターフェイス（ファンクションコール）とプロトコルを定義することでモデリングすることもできます。

TLM2.0の拡張は相互運用性を保証するものではありません。なぜなら同じ非メモリマップドバスであっても開発者が異なれば違ったペイロードを定義するであろうからです。にもかかわらずTLM2.0の拡張は、独自のインターフェイスを定める方法と比べ次のような利点があります：

・sockets, memory manager, PEQ, quantum keeperなど TLM2.0で提供される共通インフラやユーティリティが共用できます。

・LT, AT, タイミングアノテーション、テンポラルデカップリングなど異なるモデリング概念に対し標準インターフェイス(b_transport, nb_transport)や、標準用語を使うことができます。これらの概念はメモリマップドバスのみならず、どのような通信バスにも適用できます。バスごとに異なる用語を定義するのではなく、汎用的な概念には一貫した用語を使うことが望ましいと考えます。

・TLM2.0で定義している拡張メカニズムは、同じ通信バスの異なるバリエーションについて、または同じバスでも抽象レベルが異なるモデルのTLMプロトコルを表現することができる標準メカニズムを提供しています。

しかし、先に述べたように非メモリマップドバスのためのTLM2.0の拡張は相互運用性を保証するものではありません。同じバスであっても供給元が違えば異なる拡張をするでしょう。異なるベンダから提供されたモデル同士は接続できないことが多々あります。接続には何らかのアダプタが必要になるのです。業界は一般的な非メモリマップドバスについて標準TLMプロトコルを定義するよう標準化のイニシアチブをとるべきです。

特定の非メモリマップドインターフェイスを持つ SoC は、インターフェイスに対応したコントローラIPを備えています。例えばSoCがイーサネットインターフェイスを持っていればイーサネットコントローラIPを搭載しています。同様にUSBインターフェイスがあればUSBホスト/デバイスコントローラIPがあります。これらのコントローラIPモデルの片側には、プロセッサがこのIPのレジスタにアクセスするためのTLM2.0ソケットを備えています。そしてコントローラIPのもう一方の側には、Ethernet-TLM、 USB-TLMなど各インターフェイス固有のTLMソケットを備えています。このインターフェイス固有ソケットは、外部デバイスとの接続に使います。そのため外部デバイスも同じTLMプロトコルを理解しなければなりません。

このようなIPのモデルを作る場合には、外部デバイスのためにインターフェイス固有のTLM通信を取り扱う汎用バックエンドが必要です。外部デバイスのモデルはこの汎用バックエンドコンポーネントを使いデバイス固有の機能を実装することができます。複数接続が可能な外部バスインターフェイスであれば、インターフェイス固有のTLMソケットを介して複数デバイスを接続することができる仮想バスモデル（ルータ）も作ります。そのようなレイヤードアプローチを用いると、バーチャルプラットフォームを外部デバイスの仮想モデル、ホストコンピュータの物理インターフェイス、外部デバイスのRTLモデルなど様々なバックエンドと接続することができます。

3.5 外部デバイスへのアクセス

SoCは外部デバイスと接続するためのインターフェイスを備えています。SoC上で動作する組込みソフトウェアはこれらインターフェイスを通して外部デバイスにアクセスします。SoCのバーチャルプラットフォームを開発する際の課題のひとつはこれら外部インターフェイスをどのようにテストするかということです。

ひとつの方法は外部デバイスのSystemC モデルを作り、これを外部インターフェイスに相当するTLMソケットを介してSoCと接続するやり方です。バーチャルプラットフォーム上で動作する組込みソフトウェアは、外部デバイスのソフトウェアモデルにアクセスすることになります。

しかしこの方法は実際のソフトウェアをテストする方法として最適ではありません。最適な方法は実物の外部デバイスを使うことです。バーチャルプラットフォームを実行しているホストコンピュータにはUSB, Ethernetなどの汎用インターフェイスが備え付けられています。これら実際に物理的に存在するホストコンピュータのインターフェイスをバーチャルプラットフォームからアクセスできれば、その上で動作するソフトウェアは現実世界のデバイスと通信できるわけです。この仕掛けは組込みソフトウェアのテストを行なう上で非常に強力なバーチャル環境となりえます。

次の図３はバーチャルプラットフォーム内部からどのようにホストコンピュータのUSBポートをアクセスするかを表しています。

USBホストコントローラモデル：バーチャルプラットフォーム上にはUSBホストコントローラのレジスタ精度のモデルがあります。このモデルはSoCで使われることを想定して作られたUSBホストコントローラIPの仕様に基づいて作られています。EHCI, UHCIなど標準ホストコントローラでもかまいませんし、ベンダ独自のコントローラでも構いません。バーチャルプラットフォームで動作するゲストOSの標準USBドライバが、実際のホストコントローラハードウェアで動作するのと同じようにこのモデルでも問題なく動作するでしょう。モデルのバックエンド側にはUSB伝送用のトランザクションレベルAPI(USB-TLM1)を備えています。

USBバックエンド：ホストコントローラモデルからのUSB-TLM1通信を処理し、仮想USBバスモデルを介してUSBデバイスと接続するレイヤです。図の例ではUSBデバイスはソフトウェアモデル、またはUSBバックエンドドライバと考えてください。

USBバックエンドドライバ：ユーザが使用しているホストコンピュータのUSBアプリケーションとして振舞います。一方の側ではホストコンピュータのUSBポートにアクセスするため、ホストコンピュータのUSBスタックと相互にやりとりします。もう一方ではバックエンドモデルにUSBデータを引き渡し、USBバックエンドは USB-TLM1 APIを介してUSBホストコントローラモデルに渡します。バックエンドドライバはホストOSごとに開発する必要があります(Linux / Windows)。バーチャルプラットフォーム上で動作するゲストOSとは無関係です。USBスタックへのユーザ空間APIアクセスを提供するlibusb のようにプラットフォームに依存しないライブラリは使用することができます。

Ethernet, WLAN, Printer, Speaker, Microphone, LCD screen, Cameraなどホストコンピュータで使用可能な他のインターフェイスについても同様の手法でアクセスすることができます。

3.6 デバッグインターフェイス

組込みソフトウェア開発にFPGA ボードではなくバーチャルプラットフォームを使うことの利点のひとつは、バーチャルプラットフォームが強力なデバッグ機能を提供できることです。マルチコアシステムが増えるに従い、実機でのマルチコアシステムのデバッグやバグの再現は非常に困難になりつつあります。バーチャルプラットフォームを使うことによりデバッグ用のアプリケーションが作りやすくなります。ハードウェア／ソフトウェア双方をシミュレーション実行中に同時に観測することも容易になります。バーチャルプラットフォームでは次のようなデバッグ機能が必須です。

・バイナリコードをシミュレーションメモリまたはフラッシュデバイスにロードする機能

・デバッガを接続するインターフェイスが提供されていること (GDB Stub / OCD interface export)。デバッガはバーチャルプラットフォームで実行する組込みソフトウェアのデバッグに使います。

・バーチャルシステムの実行・停止など状態をコントロールできること

・内部ステートレジスタやSoC / IPモデルの変数を参照、設定する機能

・バーチャルプラットフォームのシミュレーションステートをいつでもセーブ／リストアできること

・IP-IP間やバックエンドモデルとのトランザクションをランタイムにトレースできること

バーチャルプラットフォーム用に最新のデバッグツールが開発されています。例えばSystemC対応デバッガでは、ハードウェアのスレッドと組込みソフトウェアを同時にデバッグできます。

４. まとめ

SoCバーチャルプラットフォームは、用途に適した抽象レベルを選択し運用することで大きな効果を発揮します。ソフトウェアによるバーチャルな環境ならではのデバッグ機能を活用することで、組込みソフトウェア開発の生産性を大いに高めることができます。そのためには、ハードウェアの機能を俯瞰し、何をモデリングすればよいのかを見極めるとともに、それを表現する設計技術としてのSystemC/TLM2.0の特徴をよく理解して使いこなすことが肝要です。

５．参考資料

[1] OSCI TLM2.0 Language Reference Manual

[2] OCP-IP Modeling Kit

[3] OSCI CCI: Requirement specification for Configuration Interfaces

[4] GreenSocs: Open source infrastructure for SoC modeling (www.greensocs.com)

[5] Zeeshan Anwar, Reusable Device Simulation Models for Embedded System Virtual Platforms

[6] STARC compliant demo SystemC models (http://www.circuitsutra.com/downloads.php)

筆者

CircuitSutra Technologies社　（サーキットストラ　テクノロジーズ社）

CEO, Umesh Sisodia

本記事に関する国内お問い合せ先：

sales-jp@circuitsutra.com