抽象レベルが異なるSystemC モデル間を接続するアダプタの活用 CircuitSutra Technologies
抽象レベルが異なるSystemC モデル間を接続するアダプタの活用
CircuitSutra Technologies
本稿では、抽象レベルが異なるSystemCモデル間を接続するアダプタの有効性についてご紹介します。
SoCのバーチャルプラットフォームをSystemCで構築する際の懸案の一つに、SoC上で使用している各IPのSystemCモデルをどう用意すればよいのか？という問題が挙げられます。既存のSystemCモデルの設計資産は抽象レベルが様々であるのが実情ですが、それらを再利用するのも問題解決のひとつの手段となります。その際に有効なのが抽象レベルの異なるモデル間を接続するアダプタです。アダプタの活用で１つのバーチャルプラットフォーム上に抽象レベルの異なるSystemCモデルを混在することができ、バーチャルプラットフォームの早期構築を図ることができます。
ではアダプタはどのような働きをするのか、具体例を交えてご紹介しましょう。
■IPモデルの構成
まず単体のIPモデル構造から見ていきましょう。IPのSystemC機能モデルは３つのコンポーネントで構成することが推奨されています：
・動作義部 -- IPの計算機能を定義する
・通信機能部 -- IPと外部との通信機能を定義する
・タイミング
これら３つのコンポーネントは互いに独立させ別々にモデリングすることが重要です。そうすることによりモデルの再利用性、相互運用性を高めることができます。
さて実際にモデルを新規に開発する時には、モデルの用途に応じてある特定の抽象レベルを選び設計することになります。
■抽象レベル
抽象レベルは主に２つの事項に依存します。 タイミング精度とデータ粒度です。抽象レベルの定義は標準化団体によっていくつか提唱されていますが、ここではOCP-IP TLM kitでの定義を用いて説明します。図１に抽象レベルの定義とその比較を示します。
この表で示す抽象レベルが高いほどシミュレーション速度は高速になり、タイミング精度とデータ粒度は粗くなります。
図1 SystemCモデルの抽象レベルとその比較
・抽象ベルが最も高いのがTL4です。Programmer's Viewに近く、TLM2.0 ベースのプロトコルではLoosely Timed methodology(LT)に相当します。
・TL3はArchitect's Viewに近く、TLM2.0ではApproximately Timed methodology(AT)に相当します。
・TL2もArchitect's ViewのユースケースですがTLM2.0のATを拡張して定義されています。 TL3 とTL2の大きな違いは、TL3はインターバースト・タイミング、TL2はイントラバースト・タイミングをサポートするということです。TL2ではバースト転送の各ビートは分けてモデリングできます。
・TL1は完全にサイクル精度で、やはりTLM2.0を拡張して実装しています。クロックサイクル同期と組み合わせ回路パスをサポートしています。その代表的な使われ方からVerification Viewとも言われています。TL1は様々な面でRTL modelに似ていますが、トランザクションレベルであり、ピンレベルのインターフェイスではありません。
・TL0がRTLに最もよく似ています。シグナルやピンをモデリングしています。
■アダプタ
このように抽象レベルの幅は広くタイミング精度やデータ粒度も異なります。様々な抽象レベルでモデリングしてある個々のＩＰモデルをひとつのプラットフォーム上で接続したい、そのときに活躍するのがアダプタです。
例えば組込みソフトウェア開発のためTL4レベルでプラットフォームをつくろうとしているとします。しかし必要な全てのＩＰをそのレベルでそろえることができず、今から開発する時間もない。そこでEDAツールを使ってRTLからTL0レベルのモデルを 起こすことにしました。このような時、このTL0レベルのモデルをTL4レベルのプラットフォームにプラグインするために、アダプタを用います。シミュレーション速度が低下するのは明らかですが、当座はこのモデルを使用し、いつでも準備ができた段階でTL0モデルをTL4モデルと置き換えればよいのです。
また別の事例として、ある企業ではすでに何段階かの抽象レベルでモデルを取り揃えていましたが、新たに開発するバーチャルプラットフォームはそれらとは違う抽象レベルで作ることになりました。モデルをゼロから作ることはせず既存モデルはそのまま再利用することにし、接続にアダプタを使うことにしました。さらにアダプタやトランザクタの組み合わせを使うことにより、SystemC環境にRTLをも結合させ協調検証も実現しています。
図２は抽象レベルが混在したシステムの構成図です。プラットフォーム全体はTL4で構成しています。マスタとバスがTL4です。スレーブIP1はTL4なのでアダプタ無しでダイレクトにバスに接続しています。TL1で出来ているスレーブIP2と、TL0のスレーブIP3はそれぞれにアダプタが必要です。そしてさらにアダプタとSystemC-Verilogトランザクタを使ってRTL ブロックを接続しています。まずRTLをTL0に、そしてTL4でシステムに結合しています。
図2 抽象レベルが混在したシステム
これらのアダプタは双方向に使用することができます。ここでマスタのほうが抽象レベルが高くスレーブ側が低い場合、 このアダプタをダウンストリーム・アダプタ、逆にマスタの抽象レベルが低くスレーブ側が高い場合、 このアダプタをアップストリーム・アダプタと呼ぶことにします。
高い抽象レベルではタイミング精度は粗くタイミングポイントも少ないですが、低い抽象レベルではより細かいタイミング精度となり、トランザクション内には多くのタイミングポイントが存在します。これらの違いを変換、吸収するのがアダプタの役割です。
ダウンストリーム・アダプタでは、スレーブで必要となるタイミングポイントをアダプタが挿入します。一方アップストリーム・アダプタでは、アダプタがタイミングポイントを取り除き抽象レベルを上げます。
同様に各タイミングポイントでシステムの状態を保持するデータ変数についても考慮が必要です。低い抽象レベルではタイミングポイントが多いのでデータ変数もより多く必要です。アダプタはこれら変数も管理します。ダウンストリーム・アダプタではアダプタが拡張を実施し、逆にアップストリーム・アダプタでは、アダプタがこれらの拡張を取り除きます。
図３はTL2のマスタとTL3のスレーブがアダプタを介して接続しています。アップストリームです。TL2はイントラバーストタイミングをサポートしているので、バースト転送のビートは個別にモデリングすることができます。しかしTL3はインターバーストです。全バーストはひとつのトランザクションになります。
OCP-IP TLM kit はTL2,TL1など低い抽象レベルについてOSCI TLM2.0を拡張し 'begin data'という新たなフェーズを導入しており、TL2マスタ側はバースト転送の最初のビートでこのフェーズ 'Beg_Data' を送っています。この例ではバーストに２ビートありますので２回目にも 'Beg_Data' フェーズを送ります。アダプタはバーストの全バイトを受け取るまでTL3スレーブに対するリクエストを発行しません。全データを受け取って初めて'begin request'をTL3スレーブに送ります。そしてTL3 スレーブからのレスポンスを待って TL2マスタにレスポンスを返します。このようにしてタイミングポイントを取り除くのです。
図３ タイミング精度のハンドリング：タイミングポイントの挿入と削除
TL2マスタとTL1スレーブのダウンストリームでも似たような処理が考えられます。 TL1はサイクル精度なので各ワードを個別にモデリングしますが、TL2ではバーストのビート単位でモデリングします。TL2マスタは２つのワードに対してひとつのリクエストしか送出しません。しかしアダプタは２つのリクエストを出す必要があります。TL1スレーブの各ワード毎に１つです。つまりアダプタがタイミングポイントを作り出すのです。
■アダプタ事例２・・トランザクションの順序を把握する
図４はTL4マスタとTL3スレーブがアダプタを介して接続している様子を表しています。この TL4マスタには複数のスレッドがあり、複数のブロッキングコールを送出することができます。アダプタはこれらトランザクションのオーダーを管理していなければなりません。スレッドA1が生成したトランザクションが終了する前にスレッドA2 が別のトランザクションを開始しました。アダプタは内部変数を用いてそれらの順序を保存し双方のトランザクションのステートを保持します。
図４ トランザクションのオーダーをハンドリング
■アダプタ事例３・・アウトオブオーダー・トランザクションを処理する
図５ではTL2マスタとTL4スレーブがアダプタを介して接続しています。TL2マスタはアウトオブオーダーで複数のトランザクションを生成します--すなわち先のトランザクションが終了するのを待たずに次のトランザクションを生成することができます。 この事例では低い抽象レベルから高い抽象レベルへのトラフィックなので、タイミングポイントを取り除きます。アダプタは各トランザクションについて、データフェーズをすべて受け取るまでTL4スレーブへのブロッキングコールを発行しません。Tran1の'Begin_Req'を先に受け取りましたが、Tran2のデータフェーズが先にすべて届いたので、b_transport(Tran2)を先に発行しました。このようにアダプタは並列に動作する２つのトランザクションに対応しています。
図５ アウトオブオーダー・トランザクションのハンドリング
■まとめ
このようにアダプタがタイミング精度やデータ粒度を適切に処理することによって、抽象レベルが異なるモデルが混在したバーチャルプラットフォーム構築が可能となります。実際のアダプタ開発には、ハードウェアIPモデルやバス仕様に関する理解とともに、SystemC 抽象レベル定義の深い知識・理解が不可欠であり、早期開発のためにはCircuitSutra Technologies社のようにSystemC に特化した技術専門家集団の活用が有効です。
筆者
CEO, Umesh Sisodia
本稿はCircuitSutra Technologies社が2010年にNASCUG(North American SystemC User Group)で行なった講演の要約です。
本記事に関する国内お問い合せ先：
sales-jp@circuitsutra.com