Technology Update › content › dam › synopsys › japan › ...1988/07/11 · 8 9 Technology...

76 次ページに続く

前ページより続く最新技術情報Technology Update

まとめ

FPGAベース・プロトタイプの通信リンクとトランザクタ・テクノロジ

FPGAベース・ハードウェア・プロトタイプのROIを向上

シナリオ再生機能

VDKのハードウェア/ソフトウェア・デバッグ・ツールに含まれる「アクティブCPUステータス」ウィンドウには、その時点で実行されているソフトウェア・タスクがCortex-A15とCortex-A7のどちらのプロセッサで動作しているかが表示されます（図3）。 VDKのマルチコア・トレース解析ツールを使うと、Cortex-A15やCortex-A7プロセッサで実行されているソフトウェアを詳細に観測でき、インテグレーション・エラーのデバッグに役立ちます。

また、このVDKをARM社やLauterbach社のソフトウェア・デバッガなどサードパーティ製のデバッガと組み合わせて使用し、ソースコードを表示してバグの箇所にもズームインできます。このVDKは最新のARM Development Studio 5（DS-5™）デバッガをサポートしています。DS-5はARM社製プロセッサ・ベース・システム向けのLinuxとAndroidネイティブ・アプリケーションの開発を簡略化するソフトウェア開発ツール・スイートです。

このユースケースからも分かるように、ソフトウェア・モデル、デバッガ、タスク・マイグレーション・ソフトウェア・スタックを組み合わせたVDKを利用することにより、ソフトウェア開発者は早期段階でタスクの解析と最適化に着手し、ビッグとリトルの2つのプロセッサ・クラスタをきめ細かく切り替えてサブシステムのパフォーマンスと電力効率を最大限に高められます。

実際のハードウェアを使ってデバッグを行う際、設計チームにとって難しいのは、複雑なシナリオで発生するバグをいかにして再現するかという点です。ハードウェアのタイミングがわずかに変わるだけで、一度発生したバグが次のテストでは発生しない場合があります。

VDKにはシナリオ再生機能があり、ユーザーは様々な動作モードを正確に再現したり、アーキテクチャの各種オプションが消費電力とパフォーマンスに与える影響を調べたりできます。

図 3. マルチクラスタ / マルチ CPU システムのデバッグ

この再生機能を使うと、たとえばユーザーがゲームをプレイ中に通話着信があった場合など、異なる動作モードの相互作用も詳しく調べられます。このようなタイプのユーザー・シナリオは、確定的で繰り返し可能な環境がなければ詳しく調べるのが困難ですが、それが可能なのもバーチャル・プロトタイプの大きな利点の1つです。

VDKではあらゆる動作をスクリプトで記述できるため、一連のイベント・シーケンスを記録して再生することも容易に行えます。このため、同じポイントに対するイベントをデバッグしたり、リグレッション・テスト用のシナリオを作成したりできます。

「次世代のパフォーマンスと電力効率を両立したスマートなインターネット接続デバイスを開発するため、ARMのbig.LITTLEプロセッシングを採用する企業が増えています。こうした中、ARMとパートナー各社は強力なエコシステムの整備を含めた開発支援環境づくりを進めてきました。Cortex-A15プロセッサとbig.LITTLEプロセッシングをサポートしたシノプシス社のARM Cortexプロセッサ向けVDKファミリーはソフトウェアの早期開発を可能にする非常に効果的なソリューションで、パートナー・エコシステムにおけるイノベーションをさらに加速させます」（ARM社、プロセッサ部門マーケティング担当副社長、Jim Nicholas氏）。

ARM big.LITTLEプロセッシングは、演算負荷が大きく変動する高性能アプリケーションで、独自のアプローチでパフォーマンスと電力効率の最適なバランスを実現します。

ARM社のプロセッサとシノプシスのVDKを組み合わせれば、ソフトウェア開発者は高い可制御性と可観測性を活かしながらソフトウェアのブリングアップとデバッグを短期間で完了し、ハードウェアが完成する最大12 ヶ月前からソフトウェアの開発をスタートできます。

FPGAベース・ハードウェア・プロトタイプは、数MHzの処理性能、実機環境に即したI/O接続、そしてソフトウェア開発やフィールド・テストのためのプロトタイプ配布が容易な可搬性など、SoC開発チームに高い価値をもたらします。FPGAベース・プロトタイプは、組込みソフトウェア開発やハードウェア/ソフトウェア・バリデーションに必要十分なシステム動作速度を備えています。FPGAベース・プロトタイプを導入すればハードウェア/ソフトウェアのコンカレント・エンジニアリングが可能になり、多くの設計チームがスケジュールを数ヶ月単位で短縮することに成功しています。一方で、システムの可能性を最大限に引き出し、プロトタイピング・システムの投資利益率（ROI）を最大化するため、最近ではFPGAベース・プロトタイプとホスト・ワークステーションを接続し、シミュレータなどのEDAツール、ユーザー・アプリケーション、バーチャル・プロトタイプなどとの通信リンクを活用するチームが増えています。

FPGAプロトタイプはASICのRTLデザインに基づいて作成されるため、膨大な機能検証を完了しないと作成できません。しかしRTLより抽象度の高いSoCデザインに接続して種類の異なるモデル・ソリューションを組み合わせるようにすれば、機能検証用システムの早期活用、深いソフトウェア・スタックのMIPSスループット向上、現実に即したインターフェイスへのアクセスによる通信プロトコルのコンプライアンス・テストなど、さまざまなプロトタイプ・プロジェクトの目標を達成できます。

FPGAベース・ハードウェア・プロトタイプとバーチャル・プロトタイプのリンクによりハードウェア/ソフトウェア・バリデーションの負担を軽減

フリーラン

図 1. プロトタイプの各種接続方法の比較

FPGAプロトタイプと他のモデル環境の間で通信を行うための技術は主に2つあります。1つはサイクル・レベル実行に対応した信号レベル・リンク、そしてもう1つはハンドシェイクの頻度を減らしてパフォーマンスを高めたトランザクションレベル・リンクです。次のグラフは、プロトタイプの各種接続方法をパフォーマンスと自律性の観点から分類したものです。ここでは、信号レベル・リンクによる協調シミュレーション、トランザクションレベル・リンクによるトランザクション・ベース検証、トランザクタ・ベース・バリデーション、完全自律型のインサーキット・プロトタイピングの4つを示しています。協調シミュレーションのシナリオでは、FPGAプロトタイプはAPIによってシミュレータにロックされ、シミュレータがハードウェア内部のDUT（Device Under Test）を制御します。パフォーマンスは制約されますが、シミュレータのテストベンチを再利用するには理想的なアプローチです。また、シミュレータからFPGAプロトタイプへRTLをインクリメンタルに橋渡しすると、活用も容易になります。トランザクション・ベース検証のシナリオでは、ハードウェア内のDUTとシミュレータ（またはASICエミュレータ）がメッセージ・パッシング・トランザクションを利用して通信します。このトランザクションは抽象度が高く頻繁には発生しないため、全体的なパフォーマンスが向上します。設計者も使い慣れたインターフェイスを利用できます。CPUベースのバーチャル・プロトタイプを作成する業界標準言語としてはSystemCが採用

シミュレータにロック

シミュレータとハンドシェイク

バーチャル・プラットフォームとハンドシェイク

低い高い

協調シミュレーション　シミュレータからFPGAプロト　タイプへの信号レベル・リンク

　シミュレータのAPIを使用

　シミュレーション・テストベンチ　を再利用

　早期ブリングアップに効果的

トランザクション・ベース検証　シミュレータからFPGAプロト　タイプへのトランザクション　レベル・リンク

　SCE-MI準拠が可能

　システムレベル・テストベンチ　を再利用

トランザクタ・ベースバリデーション　バーチャル・プロトタイプと　FPGAプロトタイプを　TLMリンクで接続

　SCE-MI準拠が可能

　クロック・ドメイン間の非同期　動作をサポート

インサーキットプロトタイピング　ワークステーションとのリンクなし

　現実に即したスティミュラスと

　インターフェイス

　テストベンチ不要

　HW/SWバリデーションに効果的

パフォーマンス

自律性

・・

シノプシスのVDKツール

ARM DS-5

big.LITTLEソフトウェア制御

タスクマイグレーション

ポリシー

アクティブCPUステータス

big.LITTLEボード

システム可視性

テスト/デバッグ用スクリプト

Technology Update ARM 社の big.LITTLE プロセッシング向けソフトウェアの早期開発開始を支援

Technology Update

最新

技術

情報

Technology Update

最新

技術

情報

Support Q

検証

upport Q&

ィジ

カル

upport Q&

理合

成編

s Release

ニュ

ース

リリ

ース

オー

トモ

ーテ

ィブ

ソリ

ュー

ショ

Technology Update

前ページより続く

パフォーマンスに関する考察

ハイブリッド・プロトタイプの利用シナリオ

マルチコア・プロセッサ・システムのデバッグと解析

されているため、SystemCベースのトランザクタ・モデルを使用してLT（Loosely Timed）とFPGA プロトタイプなどサイクル・レベルのハードウェア・デザインを接続します。トランザクタ・ベース・バリデーションのシナリオでは、バーチャル・プロトタイプとハードウェア・プロトタイプの間にバッファリング・ロジックと非同期モード通信を利用すれば、パフォーマンスや自律性はさらに向上します。SystemCトランザクションレベル・モデリング規格（TLM-2.0）に基づいたトランザクタは、信号（ピン・レベル）インターフェイスとプロシージャ・インターフェイスの中間レイヤとして動作します。これにより、ユーザー・アプリケーションのファンクション・コールを利用してシステム・メモリーの特定の番地にデータを書き込み、バス・リクエスト・ピン、アドレスおよびデータ・バスにスティミュラスを生成できます。同様に、読み出しを実行してバス・クロックまたはバス・グラント信号を取得できます。

SystemC/C++とFPGAハードウェアで構成されたシステム（ハイブリッド・プロトタイプ）では、トランザクタ・ライブラリが言語コンパイラ用のライブラリ・リソースとターゲットFPGAシステムの合成可能ロジックの両方をサポートしなければなりません。SoCデザインをバーチャル・ドメインとハードウェア・ドメインに分割する場所は任意に決められますが、通常はオンチップ・バスで分割するのが一般的です。この場合、トランザクタ・ライブラリはAMBA®やOCPなどの一般的なSoCバス・プロトコルをサポートしていなければなりません。

システム内では各コンポーネントのデータ・レートがさまざまに異なるため、トランザクタに何らかのバッファリングやハンドシェイクの仕組みを用意して、これら2つのプロトタイプ環境がなるべく独立して動作できるようにするのが理想です。シノプシスのAMBAバス・プロトコル用トランザクタ・ライブラリは、ソフトウェア（バーチャル）ベースとハードウェア・ベース・プロトタイプの両方にFIFOとバッファをインプリメントしています。バーチャル・プロトタイプ内のメッセージは送信/受信ソフトウェア・バッファにキューイングされます。メモリー消費量が増えすぎないようにバッファのサイズは制限されており、これを超えると送信リクエストはブロックまたは拒否されます。ハードウェア・プロトタイプでは、FPGAプロトタイプ内のメッセージは2,048個の32ビット・ワード入力ポートと出力ポートFIFOを使用し、これによりホストから大きなパケットを送信できるようにしています。ホストによってFIFOオーバーランが発生しないようにクレジット・ベースのプロトコルを使用しています。

ハイブリッド・プロトタイプのパフォーマンスは、ホスト・ワークステーションのメモリーおよび処理スループットや、FPGAハードウェア・コンテクストにおけるクロック・レートの上限など、数多くの要因によって左右されます。事実、バーチャル・ホストは数GHzの動作速度が可能ですが、クライアントFPGAはせいぜい数十MHzにすぎません。バーチャル・モデルとFPGAの通信帯域幅を最大化する手法としては主に、非同期トランザクタ通信を利用する方法と、なるべく大きなデータ・パケットを送信して転送コストを分散させる方法の2つがあります。前者では高速トランザクタ・デザインが必要になり、後者では設計中のユーザー・アプリケーションの動作効率をなるべく高める必要があります。非同期通信方式をインプリメントするには、バス・マスタ・トランザクタが送信リクエストと受信レスポンスを分離する必要があります。これを実現するには、送信と受信に別々のループを使用する、書き込みリクエストのレスポンスを破棄する、リクエストとレスポンスに別々のスレッドを使用する、コールバック通知を使用してレスポンスを処理するなどの方法があります。また、転送コストを複数のトランザクションに分散させて通信帯域幅を拡大するには、バス・プロトコルで規定されているバースト・モードをユーザー・アプリケーションで最大限に活用し、1つのコマンドで複数のリクエストまたはレスポンスを通信リンクに転送するようにします。高速トランザクションのインプリメンテーションを支援するため、シノプシスのAMBA用トランザクタ・ライブラリにはマスタ・トランザクタとスレーブ・トランザクタを同期/非同期モードのSystemC/C++メソッドに分離する機能があります。

次に示すシノプシスのAMBA対応トランザクタ・ライブラリの使用例では、同期または非同期モード・トランザクタへのソフトウェア通信APIを示してい

ます。メソッドは、TLMリクエスト・オブジェクトを送信するマスタ・トランザクタとTLMレスポンス・オブジェクトを受信するマスタ・トランザクタにグループ化されます。

トランザクタを組み込んだハイブリッド・プロトタイプは、次のようにさまざまなハードウェア/ソフトウェア・バリデーションのシナリオで使用されます。

ここでは、IPプロバイダから提供されたバーチャル・モデルを最新のCPUとサブシステムに採用した場合を例にとって考えます。このモデルは機能的にはリリース・バージョンと同等ですが、RTLと物理的IPはまだSoC開発者に提供されていないため、ソフトウェア開発をただちにスタートさせるにはバーチャル・プラットフォームを利用するしかありません。このデザインにはもう1つの重要なSoCブロックとして、HDビデオ・コーデックがありますが、このブロックにはSystemC TLMがありません。コーデックはソフトウェア開発の初期段階ではそれほど重要ではありませんが、新しいディスプレイ・パネルを選定するにはソフトウェア・スタックの高次の機能が関係してきます。品質チームはリフレッシュ・レートやランドスケープ/ポートレイトの回転速度などを評価する必要があるため、このチームは過去のコーデック・デザインのRTLを再利用し、FPGAにインプリメントすることにより、精度とパフォーマンスの両立を図ることにします。

プロトタイプ担当チームが設定したプロジェクトの目標は次のとおりです。

実際、ラピッド・プロトタイプ開発プロジェクトや複雑なバリデーション・テストではこれらの目標が設定されることが少なくありません。

実際のシステムをSystemCモデルとFPGAに分割した場合のパフォーマンス特性と準備にかかる工数を見積もるため、シノプシスは1つのケース・スタディとして、ARM Cortex-A9 CPU（x2）を利用したバーチャルARM Versatile ExpressマイクロATXボード（SystemC/TLMとしてインプリメント）と、USB 3.0デバイス・モード・コントローラ（RTLソースからHAPS-60シリーズのFPGAベース・プロトタイピング・システムへインプリメント）で構成したハイブリッド・プロトタイプを開発しました。ホスト・ワークステーションのバーチャル・モデルとHAPSハードウェア・マザーボードの物理的な接続には、シノプシスのUMRBus（Universal Multi-Resource Bus）ハードウェア・インターフェイス・ポッド、ケーブル、PCI Expressプラグイン・ボードを使用して、低レイテンシの通信レイヤを確立しています。シノプシスのAMBA向けトランザクタ・ライブラリには、SystemC/TLM用のソフトウェアAPI、およびHAPS-60シリーズ・システムのXilinx® Virtex®-6 FPGAへのインプリメンテーション用の合成可能なVerilog HDLが付属しています。このほかの物理システム・コンポーネントとしては、USB PHYデバイスを搭載したHapsTrakドーターボードを使用しています。バーチャルVersatile Expressボードは、USBデバイス・ドライバ、Linux OS、ファイル・ストレージ・ガジェット・アプリケーションで構成されるソフトウェア・スタックを提供します。バーチャル・プロトタイプとFPGAプロトタイプのドメイン間接続には、バス接続に1つのマスタとスレーブAXI 3トランザクタを使用し、割り込みにはGPIOトランザクタを使用しています。

バーチャル・プロトタイプ・プロジェクトの開始に当たり、開発チームはまず、シノプシスのARM Cortexプロセッサ向けVDK（Virtualizer Development Kit）ファミリーに含まれるVersatile ExpressマイクロATXボード相当の既存リファレンス・デザインを使用しました。次に、シノプシスVirtualizerのプラットフォーム・エディタ・インターフェイスを利用して、USB 3.0ブロックのTLM-2.0モデルをAMBA AXIトランザクタで置き換えました。USB 3.0にはイニシエータとターゲットという2つのインターフェイスがあるため、AXIマスタとスレーブ両方のトランザクタを挿入しました。USB 3.0デバイス・コントローラからの割り込み出力はGPIOトランザクタで置き換えました。プラットフォームのメモリー・マップとトランザクタのパラメータは、プロトコルの細部を反映するように設定しました。この開発には、プラットフォームのアセンブリに1日、コンフィギュレーションのトラブル・シューティングに1日を要しました。

FPGAベース・プロトタイプは、USB 3.0デバイス・コントローラ・ブロックのホストとして約1800万ASICゲート容量のHAPS-62システムを使用し、USB PHYインターフェイスICと物理コネクタを搭載したHAPSドーターボードを追加しました。バーチャル・プロトタイプを実行するホスト・ワークステーションへの接続にはUMRBusインターフェイス・キットを使用しました。FPGAベース・プロトタイプの開発は、まずシノプシスのcoreConsultantを使ってDesignWare USB 3.0コントローラのコンフィギュレーションを生成し、これをDMAアクセス用にはAXIマスター・ポートとインスタンシエートし、コンフィギュレーション・インターフェイス用にはAXIスレーブ・ポートとインスタンシエートします。割り込み処理用にはGPIOトランザクタ・コンポーネントをインスタンシエートします。論理合成やHAPS-62のFPGAへのインプリメンテーションの前に動作確認を行うため、coreConsultantから出力したテストベンチを使用してシノプシスのVCSでバーチャル・モデルの協調シミュレーションを実行し、USB PHYとの連携動作を確認します。次に、シノプシス Certifyのインターフェイスを利用して、HAPS-62ハードウェア・リソースをターゲットにしてロジックを分割し、論理合成とFPGA配置配線をカプセル化します。ハードウェア・フローの準備作業には、プラットフォームのアセンブリに3～5日、コンフィギュレーションのトラブル・シューティングに1日を要しました。このチームはVirtualizerとHAPSシステムを使い慣れていたため、システムの構築は2週間以内で完了しました。

実際のバリデーション・シナリオをデモンストレーションするため、このハイブリッド・プロトタイプをUSB 3.0ホスト・ポート搭載のWindows 7ノートブックPCに接続しました。新しいUSBデバイスはWindows OSによって自動検出され、エクスプローラに新規ボリュームとして表示されます。Windows 7

PC上でDiskBenchアプリケーションを実行し、USB3.0読み出し/書き込みベンチマークを実行したところ、読み出しは0.515MB/s、書き込みは0.500MB/sという結果でした。Linux OSがUSB 3.0マス・ストレージ・デバイスのファイル・マウントにかかった時間は約1秒でした。パフォーマンスに関しては、60MBのMP4動画をWindowsノートブックPC上でリアルタイム再生できました。

次世代のワイヤレス、コンシューマ、車載向け機器では、マルチコア・プロセッサ・システムを利用することによって高度なエンドユーザー・アプリケーションの実行に必要な容量とパフォーマンス、そしてリアルタイム動作をサポートするために必要な省電力モードをバランスよく実現しています。バーチャル・プロトタイプを開発し導入するには、シノプシスVirtualizerのようなSystemC/TLMモデル環境を利用します。Virtualizer環境では、サードパーティ製のソフトウェア・デバッガやIDEと同期しながら、高度な解析ツールを利用してシステムレベルのマルチコア対応ソフトウェアのデバッグやパフォーマンス解析が行えます。

高度な解析機能を備えたプラットフォームの配布例として、シノプシスのVDK（Virtualizer Development Kit）があります。VDKには、従来のデバッグ環境にはなかったシステムレベルのハードウェア解析とSystemC/TLMデバッグ機能があります。Virtualizerのプラットフォーム編集、アセンブリ、パッケージング・ツールを利用すれば、ソフトウェア開発チームへの配布が容易なVDKを作成できます。開発者は、各VDKを使ってハードウェアとソフトウェアの動作を一元的に確認できます。この結果、ハードウェア設計チームとソフトウェア開発チーム間のコンカレント・エンジニアリングとコミュニケーションが改善され、仕様定義やインプリメンテーションのミスが少なくなります。

USBホストへのケーブル接続

シノプシスのトランザクタ・ライブラリに含まれる同期MasterXactor Sendメソッド。リクエストを送信した後、レスポンスを受信するまでブロックする

void MasterXactor<A,D>::send (const TLMRequest<A,D> & request,

TLMResponse<D> & response)

Where argument A is address width [32|64] and argument D is data

width [8|16|32… 1024].

bool discardResponse = false)

width [8|16|32… 1024].

コード1

シノプシスのトランザクタ・ライブラリに含まれる非同期MasterXactor Sendメソッド。高速メソッドからトランザクタへリクエストを送信。ソフトウェア・キューの容量を超えると、このコールはブロック

コード2

1ヶ月以内に完全に動作するプロトタイプを開発する

実際に即したストリーミングI/Oに接続し、一般的なベンチマーク・ツールを利用してSoC IPのストレス・テストを実行する

新規ソフトウェア・ドライバのバリデーションには実際のSoC IPを使用する

プロトタイプのパフォーマンスはソフトウェア開発に必要十分なレベルを達成する

・・

過去のプロジェクトからの既存IPまたは商用IPと、開発期間の非常に短いバーチャル・モデルまたはユーザー・アプリケーションを組み合わせ、プロトタイプの早期作成を達成する

複雑なプロセッサ・サブシステムにはバーチャル・モデルを使用し、ペリフェラルはFPGAに割り当てることにより、LTモデルによる優れたMIPSスループットと実際のハードウェアI/Oに対する高い忠実度とサイクル精度を両立する

新規SoCのモデリングを完全にバーチャル・ドメインで開始し、HDLが完成したサブシステムから順にRTLに置き換える

・図 2. SoC におけるバーチャル・プロトタイプと FPGA ベース・プロトタイプの分割

Linux OS

USBデバイス・ドライバ（デバイスとマスストレージ・ドライブ）

Versatile Expressボード

AXIバス

Cortex-A<x> CPU

バーチャル・プロトタイプ

Verilogトランザクタ

AXIまたはAHBバス

USB 3.0デバイス

FPGベース・プロトタイプ

SystemCTLM-2.0トランザクタ

USB 3.0PHY

FPGA ベース・ハードウェア・プロトタイプとバーチャル・プロトタイプのリンクによりハードウェア / ソフトウェア・バリデーションの負担を軽減

Technology Update

最新技術情報

Technology Update

最新技術情報

Support Q

検証編

Support Q

フィジカル編

Support Q

論理合成編

s Release

ニュースリリース

オートモーティブ

ソリューション

次ページに続く