Embed Size (px)
Citation preview
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が採用
シミュレータにロック
シミュレータとハンドシェイク
バーチャル・プラットフォームとハンドシェイク
低い 高い
kHz
MH
z
協調シミュレーション シミュレータから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
&A
検証
編S
upport Q&
Aフ
ィジ
カル
編S
upport Q&
A論
理合
成編
New
s Release
ニュ
ース
リリ
ース
オー
トモ
ーテ
ィブ
ソリ
ュー
ショ
ン
98
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].
void MasterXactor<A,D>::send (const TLMRequest<A,D> & request,
bool discardResponse = false)
Where argument A is address width [32|64] and argument D is data
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
&A
検証編
Support Q
&A
フィジカル編
Support Q
&A
論理合成編
New
s Release
ニュースリリース
オートモーティブ
ソリューション
次ページに続く
98
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].
void MasterXactor<A,D>::send (const TLMRequest<A,D> & request,
bool discardResponse = false)
Where argument A is address width [32|64] and argument D is data
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
&A
検証編
Support Q
&A
フィジカル編
Support Q
&A
論理合成編
New
s Release
ニュースリリース
オートモーティブ
ソリューション
次ページに続く
1110
前ページより続く
設計フローまとめ
VDKで提供されるシステムレベルのソフトウェア・デバッグ機能の例を図3に示します。このVirtual Platform AnalyzerのGUIパネルには、バーチャル・プラットフォームの各構成要素（メモリー・コントローラ、GPIO、CPU）、逆アセンブルしたマイクロコード命令、グローバル・ブレークポイント、各コンポーネント当たりの消費電力のトレースが表示されます。プラットフォーム・コンポーネントに対して高い可視性と可制御性を提供するこのツールは、ソフトウェア・プログラマの使い慣れた伝統的なIDEと同期して併用できます。 図4は、マルチコア・システムの高度な解析機能の例を示したものです。ここでは、シノプシスのVirtualizerで生成したVDK+を使ってスマートフォンに搭載されたARM big.LITTLEシステムの各プロセッサ当たりの消費電力をプロットしています。OSブート、ユーザー・メニュー操作、地図アプリケーションとジオ・ロケーション・タスクの実行、4Gネットワークからの通話着信、Webブラウザの使用といった主な動作フェーズで各プロセッサがソフトウェア・タスクを実行した時の消費電力をプロットしています。
ハイブリッド・プロトタイプをインプリメントするには、ホスト・システムをターゲットにした言語コンパイラと各種ライブラリ・リソースが必要です。図5は、シノプシスのFPGAプロトタイピング用EDAツールとハードウェア・システムを使用した設計フローの概略を示したものです。まず、チームが設定したプロジェクト目標に基づいて、SoCデザインのソース・ブロックを2つのプロトタイピング環境に分割します。デザインをどのように分割するかは、システム・パフォーマンス、モデル入手性、デバッグ可視性、I/O忠実度などの条件を必要に応じて考慮して決定します。バーチャル・ドメインに割り当てるブロックは、SystemC/C++ソースからバーチャル・プロトタイピング・フローを開始します。FPGAベース・プロトタイプに割り当てられたSoCブロックとの接続を参照するため、トランザクタ・ライブラリAPI
にはAMBAバス・チャネル通信用のsend、receiveメソッドとcallback関数、そして汎用I/O通信用のset、get、callbackメソッドの両方が用意されています。この高位インターフェイスは、物理的ハードウェアおよびユーザーのホスト・ワークステーションと、シノプシスHAPS-60シリーズ・システムの通信のインプリメンテーションの細部を隠蔽します。Virtualizer（またはC++コンパイラ）からは、高位モデルとトランザクタを組み込んだバーチャル・プラットフォームが生成されます。ハードウェア・ドメインに割り当てられたブロックは、HDLソースからハードウェア・プロトタイピング・フローを開始します。バーチャル・プロトタイプに割り当てられたAMBAマスタまたはスレーブ・ブロックは、RTLデザインの他のコンポーネントのインスタンスと同様にインスタンシエートされます。シノプシス Certifyはトランザクタ・ライブラリ・ロジックをマージし、HAPS-60シリーズ・システムのFPGA、メモリー、アクセサリをターゲットにしてFPGAプログラミング・ファイルとシステム・コンフィギュレーションを出力します。これをハードウェア・システムにダウンロードすると動作可能な状態になります。オートメーション・ソフトウェアを使用するとハイブリッド・プロトタイプの構築と動作が容易に行え、トランザクタを最大限にシームレスに組み込めます。
SoCプロジェクトのバリデーションでプロトタイプを使用する場合、これまではSystemCベースのバーチャル・モデルを使用したプロトタイピングと、FPGAベースのASICプロトタイプとPCBシステムを使用したプロトタイピングは別々に行われていました。しかしTLMドメインとRTL/ハードウェア・ドメインを接続すると、容易に入手可能なモデルを利用することでより現実に即した高性能なシステムを早期段階でモデリングできるなど、開発チームにとっての柔軟性が向上します。最新のSystemC/TLMモデル環境では、ハードウェアとソフトウェアの動作を一元的に確認することにより、これまで以上に効果的にシステム・パフォーマンスを解析できます。
図3. シノプシスVirtualizerで提供される仮想プラットフォームのデバッグ機能
FPGAベース・プロトタイピング・メソドロジ・マニュアル（FPMM）: DFP（Design-For-Prototyping）のベスト・プラクティス（www.synopsys.com/Systems/FPGABasedPrototyping/FPMM）シノプシスのハイブリッド・プロトタイピング・ソリューション
（www.synopsys.com/Systems/FPGABasedPrototyping/Pages/hybrid-prototyping.aspx）シノプシスのバーチャル・プロトタイピング・ソリューション
（www.synopsys.com/Systems/VirtualPrototyping）
関連リンク
図4. シノプシスVirtualizerでマルチコア・プロセッサ・システムの消費電力を解析
図5. バーチャル・プロトタイプとFPGAベース・ハードウェア・プロトタイプにトランザクタを使用した設計フローの例
SoCデザイン
Cortex-A15のプロセス当たりの電力
Cortex-A7のプロセス当たりの電力
big.LITTLE全体の電力
Cortex-A15で動作するソフトウェア: パフォーマンス優先の最適化
Cortex-A7で動作するソフトウェア: 電力効率優先の最適化
ブート メニュー マップ 通話 ブラウザ
シノプシスHAPS-60シリーズ・システム
AMBA向けシノプシストランザクタ・ライブラリ
ハイブリッドプロトタイプ
ユーザー・ホスト・ワークステーション
バーチャルプロトタイピング・フロー
ハードウェアプロトタイピング・フロー
バーチャル・プラットフォーム（ユーザー・アプリケーション/バイナリ）
FPGAベースハードウェア・プロトタイプ
AMBAバス・トランザクション
SystemCまたはC++ソース
シノプシスVirtualizerまたはC++コンパイラ シノプシスCertify
HDLソース
Technology UpdateFPGA ベース・ハードウェア・プロトタイプとバーチャル・プロトタイプのリンクによりハードウェア / ソフトウェア・バリデーションの負担を軽減
Technology Update
最新
技術
情報
Technology Update
最新
技術
情報
Support Q
&A
検証
編S
upport Q&
Aフ
ィジ
カル
編S
upport Q&
A論
理合
成編
New
s Release
ニュ
ース
リリ
ース
オー
トモ
ーテ
ィブ
ソリ
ュー
ショ
ン
1110
前ページより続く
設計フローまとめ
VDKで提供されるシステムレベルのソフトウェア・デバッグ機能の例を図3に示します。このVirtual Platform AnalyzerのGUIパネルには、バーチャル・プラットフォームの各構成要素（メモリー・コントローラ、GPIO、CPU）、逆アセンブルしたマイクロコード命令、グローバル・ブレークポイント、各コンポーネント当たりの消費電力のトレースが表示されます。プラットフォーム・コンポーネントに対して高い可視性と可制御性を提供するこのツールは、ソフトウェア・プログラマの使い慣れた伝統的なIDEと同期して併用できます。 図4は、マルチコア・システムの高度な解析機能の例を示したものです。ここでは、シノプシスのVirtualizerで生成したVDK+を使ってスマートフォンに搭載されたARM big.LITTLEシステムの各プロセッサ当たりの消費電力をプロットしています。OSブート、ユーザー・メニュー操作、地図アプリケーションとジオ・ロケーション・タスクの実行、4Gネットワークからの通話着信、Webブラウザの使用といった主な動作フェーズで各プロセッサがソフトウェア・タスクを実行した時の消費電力をプロットしています。
ハイブリッド・プロトタイプをインプリメントするには、ホスト・システムをターゲットにした言語コンパイラと各種ライブラリ・リソースが必要です。図5は、シノプシスのFPGAプロトタイピング用EDAツールとハードウェア・システムを使用した設計フローの概略を示したものです。まず、チームが設定したプロジェクト目標に基づいて、SoCデザインのソース・ブロックを2つのプロトタイピング環境に分割します。デザインをどのように分割するかは、システム・パフォーマンス、モデル入手性、デバッグ可視性、I/O忠実度などの条件を必要に応じて考慮して決定します。バーチャル・ドメインに割り当てるブロックは、SystemC/C++ソースからバーチャル・プロトタイピング・フローを開始します。FPGAベース・プロトタイプに割り当てられたSoCブロックとの接続を参照するため、トランザクタ・ライブラリAPI
にはAMBAバス・チャネル通信用のsend、receiveメソッドとcallback関数、そして汎用I/O通信用のset、get、callbackメソッドの両方が用意されています。この高位インターフェイスは、物理的ハードウェアおよびユーザーのホスト・ワークステーションと、シノプシスHAPS-60シリーズ・システムの通信のインプリメンテーションの細部を隠蔽します。Virtualizer（またはC++コンパイラ）からは、高位モデルとトランザクタを組み込んだバーチャル・プラットフォームが生成されます。ハードウェア・ドメインに割り当てられたブロックは、HDLソースからハードウェア・プロトタイピング・フローを開始します。バーチャル・プロトタイプに割り当てられたAMBAマスタまたはスレーブ・ブロックは、RTLデザインの他のコンポーネントのインスタンスと同様にインスタンシエートされます。シノプシス Certifyはトランザクタ・ライブラリ・ロジックをマージし、HAPS-60シリーズ・システムのFPGA、メモリー、アクセサリをターゲットにしてFPGAプログラミング・ファイルとシステム・コンフィギュレーションを出力します。これをハードウェア・システムにダウンロードすると動作可能な状態になります。オートメーション・ソフトウェアを使用するとハイブリッド・プロトタイプの構築と動作が容易に行え、トランザクタを最大限にシームレスに組み込めます。
SoCプロジェクトのバリデーションでプロトタイプを使用する場合、これまではSystemCベースのバーチャル・モデルを使用したプロトタイピングと、FPGAベースのASICプロトタイプとPCBシステムを使用したプロトタイピングは別々に行われていました。しかしTLMドメインとRTL/ハードウェア・ドメインを接続すると、容易に入手可能なモデルを利用することでより現実に即した高性能なシステムを早期段階でモデリングできるなど、開発チームにとっての柔軟性が向上します。最新のSystemC/TLMモデル環境では、ハードウェアとソフトウェアの動作を一元的に確認することにより、これまで以上に効果的にシステム・パフォーマンスを解析できます。
図3. シノプシスVirtualizerで提供される仮想プラットフォームのデバッグ機能
FPGAベース・プロトタイピング・メソドロジ・マニュアル（FPMM）: DFP（Design-For-Prototyping）のベスト・プラクティス（www.synopsys.com/Systems/FPGABasedPrototyping/FPMM）シノプシスのハイブリッド・プロトタイピング・ソリューション
（www.synopsys.com/Systems/FPGABasedPrototyping/Pages/hybrid-prototyping.aspx）シノプシスのバーチャル・プロトタイピング・ソリューション
（www.synopsys.com/Systems/VirtualPrototyping）
関連リンク
図4. シノプシスVirtualizerでマルチコア・プロセッサ・システムの消費電力を解析
図5. バーチャル・プロトタイプとFPGAベース・ハードウェア・プロトタイプにトランザクタを使用した設計フローの例
SoCデザイン
Cortex-A15のプロセス当たりの電力
Cortex-A7のプロセス当たりの電力
big.LITTLE全体の電力
Cortex-A15で動作するソフトウェア: パフォーマンス優先の最適化
Cortex-A7で動作するソフトウェア: 電力効率優先の最適化
ブート メニュー マップ 通話 ブラウザ
シノプシスHAPS-60シリーズ・システム
AMBA向けシノプシストランザクタ・ライブラリ
ハイブリッドプロトタイプ
ユーザー・ホスト・ワークステーション
バーチャルプロトタイピング・フロー
ハードウェアプロトタイピング・フロー
バーチャル・プラットフォーム（ユーザー・アプリケーション/バイナリ）
FPGAベースハードウェア・プロトタイプ
AMBAバス・トランザクション
SystemCまたはC++ソース
シノプシスVirtualizerまたはC++コンパイラ シノプシスCertify
HDLソース
Technology UpdateFPGA ベース・ハードウェア・プロトタイプとバーチャル・プロトタイプのリンクによりハードウェア / ソフトウェア・バリデーションの負担を軽減
Technology Update
最新
技術
情報
Technology Update
最新
技術
情報
Support Q
&A
検証
編S
upport Q&
Aフ
ィジ
カル
編S
upport Q&
A論
理合
成編
New
s Release
ニュ
ース
リリ
ース
オー
トモ
ーテ
ィブ
ソリ
ュー
ショ
ン
