SDSoC 環境デバッグガイド · トストリームを含む完全なハードウェアシステムを生成します。すべてのハードウェア関数呼び出しで元の動作が保

SDSoC 環境デバッグガイドUG1282 (v2018.3) 2019 年 1 月 24 日

この資料は表記のバージョンの英語版を翻訳したもので、内容に相違が生じる場合には原文を優先します。資料によっては英語版の更新に対応していないものがあります。日本語版は参考用としてご使用の上、最新情報につきましては、必ず最新英語版をご参照ください。

https://www.xilinx.com

改訂履歴次の表に、この文書の改訂履歴を示します。

セクション改訂内容2019 年 1 月 24 日バージョン 2018.3

資料全体編集上のアップデート。2018 年 12 月 5 日バージョン 2018.3



全体的なアップデート初版。

改訂履歴

UG1282 (v2018.3) 2019 年 1 月 24 日 japan.xilinx.comSDSoC デバッグガイド 2

https://japan.xilinx.com

https://japan.xilinx.com/about/feedback.html?docType=User_Guides&docId=UG1282&Title=SDSoC%20%26%2312487%3B%26%2312496%3B%26%2312483%3B%26%2312464%3B%20%26%2312460%3B%26%2312452%3B%26%2312489%3B&releaseVersion=2018.3&docPage=2

目次改訂履歴....................................................................................................................................................................2

第 1 章: SDSoC のデバッグの概要........................................................................................................... 4SDSoC 環境の概要.....................................................................................................................................................4SDSoC デバッグフローの概要................................................................................................................................10

第 2 章: SDSoC のデバッグ機能...............................................................................................................15SDx 環境デバッグツール........................................................................................................................................ 15システムエミュレーション.....................................................................................................................................23すべてのプラットフォームで使用可能なハードウェア実行機能............................................................................ 28ハードウェア/ソフトウェアイベントのトレース................................................................................................... 38

第 3 章: デバッグ手法..................................................................................................................................... 41システムのハングとランタイムエラーのデバッグ.................................................................................................42IP レジスタの監視および変更................................................................................................................................. 47イベントトレース................................................................................................................................................... 48ソフトウェア/ハードウェアのクロスプローブのデバッグ..................................................................................... 51パフォーマンスのデバッグに関するヒント............................................................................................................ 52コンパイル時およびリンク時のエラーのトラブルシューティング........................................................................ 53パフォーマンス問題のトラブルシューティング..................................................................................................... 54

付録 A: SDSoC 環境でのトラブルシューティング...................................................................... 56

付録 B: その他のリソースおよび法的通知....................................................................................... 57Documentation Navigator およびデザインハブ................................................................................................... 57参考資料.................................................................................................................................................................. 57トレーニングリソース............................................................................................................................................ 58お読みください: 重要な法的通知............................................................................................................................ 58




第 1 章

SDSoC のデバッグの概要SDSoC™ 環境は、ヘテロジニアスエンベデッドシステムをインプリメントするための Eclipse ベースの統合設計環境(IDE) です。SDSoC では、Zynq®-7000 SoC および Zynq® UltraScale+™ MPSoC デバイスを使用した Arm® Cortex™ ベースのアプリケーションと、ザイリンクス SoC および FPGA 上の MicroBlaze™ プロセッサベースのアプリケーションがサポートされます。この資料では、SDSoC 環境のデバッグ機能について説明し、SDSoC フローで発生した問題を解析する方法を詳細に示します。注記: パフォーマンスの問題については説明しません。ツールの問題がなく、デザインが正しく機能している場合は、

『SDSoC 環境プロファイリングおよび最適化ガイド』 (UG1235) を参照して、デザインのパフォーマンスに改善の余地があるかどうかを調べてみてください。

SDSoC 環境の概要SDSoC 環境には、選択した関数をプログラマブルロジック (PL) にコンパイルし、C/C++ プログラムを完全なハードウェア/ソフトウェアシステムに変換するシステムコンパイラが含まれます。SDSoC のシステムコンパイラは、プログラムを解析してソフトウェア関数とハードウェア関数間のデータフローを判断し、プログラムを実現するアプリケーション特定のシステムオンチップ (SoC) を生成します。高パフォーマンスを達成するため、各ハードウェア関数は独立したスレッドとして実行されます。システムコンパイラは、ハードウェアコンポーネントおよびソフトウェアコンポーネントを生成してハードウェアスレッドとソフトウェアスレッド間が同期するようにし、パイプライン計算および通信もイネーブルにできます。アプリケーションコードには、多数のハードウェア関数、特定のハードウェア関数の複数のインスタンス、プログラムの異なる部分からのハードウェア関数呼び出しなどを含めることができます。SDSoC 統合開発環境 (IDE) では、プロファイリング、コンパイル、リンク、システムパフォーマンス解析、デバッグを含むソフトウェア開発ワークフローがサポートされています。また、高速なパフォーマンス見積もり機能があり、ハードウェアの完全なコンパイルを実行する前に、さままなハードウェア/ソフトウェアインターフェイスを試すことが可能です。SDSoC システムコンパイラは、ベースプラットフォームをターゲットとし、Vivado® 高位合成 (HLS) ツールを起動して合成可能な C/C++ 関数をプログラマブルロジックにコンパイルします。その後 Vivado Design Suite ツールを起動して、システムコンパイラで DMA、インターコネクト、ハードウェアバッファー、その他の IP、および FPGA ビットストリームを含む完全なハードウェアシステムを生成します。すべてのハードウェア関数呼び出しで元の動作が保持されるようにするため、SDSoC システムコンパイラはシステム特定のソフトウェアスタブおよびコンフィギュレーションデータを生成します。このプログラムには、生成された IP ブロックを使用するのに必要なドライバーへの関数呼び出しが含まれています。アプリケーションおよび生成されたソフトウェアは、標準の GNU ツールチェーンを使用してコンパイルおよびリンクされます。システムコンパイラでは、1 つのソースから完全なアプリケーションを生成することにより、プログラムレベルでデザインおよびアーキテクチャを繰り返し変更できるので、ターゲットプラットフォームで実行可能なプログラムを達成するまでの時間を短縮できます。

第 1 章: SDSoC のデバッグの概要


https://japan.xilinx.com/cgi-bin/docs/rdoc?v=2018.3;d=ug1235-sdsoc-optimization-guide.pdf



用語次の用語は、SDSoC 環境での設計に関する内容でよく使用されます。用語とその説明は次のとおりです。• アクセラレータ: FPGA 汎用インターコネクトのハードウェアにインプリメントされるアプリケーションコードの

部分。「ハードウェア関数」とも呼ばれます。• データムーバー: データムーバーは、アクセラレータ間、およびプロセッシングシステム (PS) とアクセラレータ

の間でデータを転送します。SDSoC 環境では、転送されるデータの特性とサイズに基づいてさまざまなタイプのデータムーバーを生成できます。

• パイプライン処理: パイプライン処理は、アルゴリズムのハードウェアインプリメンテーションで命令レベルの並列処理を増加させる手法で、演算または関数の独立した段をオーバーラップさせます。等価の機能が得られるように元のソフトウェアインプリメンテーションのデータ依存性は保持されますが、必要な回路は独立した段のチェーンに分割されます。チェーンのすべての段は、同じクロックサイクルで並列実行されます。唯一の違いは各段のデータのソースで、計算の各段は、前のクロックサイクルで前の段で計算された結果からデータ値を受信します。

• プラグマ: システムコンパイラに指示を与えるためにソースコードに挿入可能な特別な指示子。SDSoC 環境では、通信と計算のバランスが取られるようにハードウェア関数およびハードウェア関数への呼び出しを構成し、システムコンパイラに指示を与えるプラグマをソースコードに挿入することにより、システム生成プロセスを制御します。

• プロセッサ: SDSoC 環境では、プロセッサとは MicroBlaze プロセッサなどのソフトプロセッサまたは Zynq-7000SoC および Zynq UltraScale+ MPSoC などの Arm プロセッサを意味します。

• システムポート: システムポートは、データムーバーを PS に接続します。システムポートとしては、Zynq のACP、AFI (ハイパフォーマンスポートに対応)、MIG (PL ベースの DDR メモリコントローラーに対応)、またはストリームポートを使用できます。

SDSoC のエレメントSDSoC 環境には、次の機能が含まれます。• 完全なハードウェア/ソフトウェアシステムを生成する sds++ システムコンパイラ。sds++ システムコンパイ

ラでは、Vivado 高位合成 (HLS)、Vivado IP インテグレーター、データ移動およびインターコネクト用の IP ライブラリ、RTL 合成、配置、配線、ビットストリーム生成用のツールを含む Vivado Design Suite System Edition からの機能が使用されます。

• アプリケーションプロジェクトおよびワークフローを作成および管理する Eclipse ベースの統合開発環境 (IDE)。• ハードウェア/ソフトウェアインターフェイスで異なるシナリオを試すためのシステムパフォーマンス見積もり。SDSoC 環境は、Zynq-7000 SoC および Zynq UltraScale+ MPSoC 用の GNU ツールチェーン、標準ライブラリ (glibc など)、エンベデッドプロセッサターゲットとの通信に使用される TCF (Target Communication Framework) を含むザイリンクスソフトウェア開発キット (SDK) などの多数のツールも継承しています。Eclipse/CDT ベースの IDE には、パフォーマンス解析パースペクティブも含まれます。sds++ システムコンパイラでは、ターゲットプラットフォームをカスタマイズしてアプリケーションのシステムオンチップが生成されます。この環境には、アプリケーション開発用の多数の標準ベースプラットフォームのほか、サードパーティパートナーや SDSoC 設計チームの開発したプラットフォームも含まれます。『SDSoC 環境プラットフォーム開発ガイド』 (UG1146) に、Vivado Design Suite を使用したプラットフォームデザインの作成方法、プラットフォームインターフェイスの設定方法、プラットフォームを構築するソフトウェアランタイム環境を定義して SDSoC環境で使用できるようにする方法などが説明されています。



https://japan.xilinx.com/cgi-bin/docs/rdoc?v=2018.3;d=ug1146-sdsoc-platform-development.pdf



SDx™ IDE では、アプリケーション特定のハードウェアアクセラレータおよびアクセラレータをプラットフォームに接続するデータモーションネットワークを使用して、ターゲットプラットフォームをカスタマイズします。次に、メモリアクセスポートとハードウェアアクセラレータを含む簡略化した Zynq と DDR コンフィギュレーションを示します。

図 1: メモリアクセスポートとメモリを示した Zynq + DDR の簡略図

Zynq Programmable Logic (PL)

ARM A9Processor

L2 CacheMemory

MemoryController

DMA1 DMA2

HardwareFunction1

HardwareFunction2

DDRMemory

GPx ACP HPx/AFI

Zynq Processing System (PS)

X14709-061518

SDSoC アプリケーションの実行モデルSDSoC 環境アプリケーションの実行モデルは、プラットフォームのブート後にターゲット CPU で実行される C++ プログラムの通常実行を考えると理解できます。C++ バイナリの実行ファイルがハードウェアとどのようにインターフェイスするかを理解しておくと有益です。プログラム内で宣言されたハードウェア関数はハードウェアアクセラレータにコンパイルされ、標準 C ランタイムでこれらの関数への呼び出しによりアクセスされます。各ハードウェア関数呼び出しがタスクとしてアクセラレータを起動し、関数への各引数が CPU とアクセラレータ間で転送されて、アクセラレータタスクの完了後にプログラムでアクセスできるようになります。メモリとアクセラレータ間のデータ転送には、DMA エンジンなどのデータムーバーが使用され、zero_copy などのユーザーデータムーバープラグマを考慮して、sds++ システムコンパイラにより自動的に挿入されます。





図 2: SDSoC システムのアーキテクチャ

SDSoC プラットフォーム

DDR バンク

Zynq

エンベデッドプロセッサ (PS 領域) オペレーティングシステム

ドライバーアプリケーションコード

ペリフェラル(ビジョン、グラフィック、測定...)

プログラマブルロジック (PL 領域)ハードウェア関数アクセラレータデータムーバー

ダイレクト I/O アクセス

X21358-082418

プログラムが正しく機能するようにするため、システムコンパイラはハードウェア関数への各呼び出しをインターセプトし、シグネチャが同じで派生した名前が付けられたスタブ関数への呼び出しに置き換えます。スタブ関数はすべてのデータ移動とアクセラレータの演算を制御し、ハードウェア関数呼び出しの終了時にソフトウェアとアクセラレータハードウェアを同期化します。スタブ内では、すべてのアクセラレータとデータムーバーは sds_lib ライブラリに含まれる送信および受信 API により制御されます。ハードウェア関数呼び出し間のプログラムデータフローに、プログラム内で関数呼び出し (デストラクターまたはfree() 呼び出し以外) が実行された後にアクセスされない配列引数が関係する場合、およびハードウェアアクセラレータをストリームを使用して接続できる場合、メモリへの往復がインプリメントされるのではなく、1 つのハードウェアアクセラレータから直接ハードウェアストリーム接続を介して次のハードウェアアクセラレータにデータが転送されます。この最適化により、パフォーマンスが大幅に向上し、ハードウェアリソースを削減できます。プログラムの SDSoC プログラム実行モデルの大まかな手順は次のとおりです。1. プログラムのコンストラクターが main() に入る前に sds_lib ライブラリが初期化されます。2. プログラム内で、ハードウェア関数への各呼び出しが、元の関数と関数シグネチャが同じ (名前は異なる) のスタ

ブ関数への関数呼び出しによりインターセプトされます。スタブ関数内では、次の手順が実行されます。a. 同期アクセラレータタスク制御コマンドがハードウェアに送信されます。b. ハードウェア関数への各引数に対して、非同期データ転送要求が関連付けられた wait() ハンドルと共に適

切なデータムーバーに送信されます。void 以外の戻り値は、出力スカラー引数として扱われます。





c. 各転送要求に対して、バリア wait() が発行されます。アクセラレータ間のデータ転送がダイレクトハードウェアストリームとしてインプリメントされる場合、この転送のバリア wait() は、この引数のアクセラレータ関数チェーンの最後のアクセラレータ関数に対するスタブ関数で発生します。

3. プログラムのデストラクターが main() を終了するときに、sds_lib ライブラリがクリーンアップされます。ヒント: 手順 2a ～ 2c は、アクセラレータパイプラインの開始および終了時にプログラムを正しく保ち、それと同時にパイプライン内での同時実行を可能にします。場合によっては、システムコンパイラで自動的には推論できないアクセラレータタスクの同時実行の可能性を、プログラマが認識していることもあります。sds++ システムコンパイラでは #pragma SDS async(ID) プラグマがサポートされており、このような場合にハードウェア関数への呼び出しの直前に挿入できます。このプラグマを指定すると、データ転送に対してバリア wait() 呼び出しなしでスタブ関数が生成されます。その結果、すべての転送要求を発行した後に制御がプログラムに戻り、アクセラレータの実行中にプログラムの同時実行が可能になります。この場合、プログラム内の適切な同期ポイントに #pragma SDS wait(ID) を挿入してください。このプラグマはsds_wait(ID) API 呼び出しとなり、ハードウェアアクセラレータ、その暗示的なデータムーバー、および CPU が正しく同期化されます。重要: 各 async(ID) プラグマには、対応する wait(ID) プラグマが必要です。

SDSoC のビルドプロセスSDSoC 環境のビルドプロセスでは、標準のコンパイルおよびリンクプロセスが使用されます。g++ と同様に、sds++ システムコンパイラはサブプロセスを呼び出してコンパイルおよびリンクを実行します。次の図に示すように、コンパイル段階では、CPU で実行されるオブジェクトコードのコンパイルだけでなく、Vivado高位合成 (HLS) ツールを使用したハードウェア関数の IP ブロックへのコンパイルおよびリンク、およびターゲットCPU ツールチェーンを使用した標準オブジェクトファイル (.o) の作成も実行されます。システムのリンク段階では、すべてのハードウェア関数における呼び出し元/呼び出し先の関係のプログラム解析、各ハードウェア関数呼び出しをインプリメントするアプリケーション特定のハードウェア/ソフトウェアネットワークの生成が実行されます。sds++ システムコンパイラは、Vivado HLS (関数コンパイラ)、生成されたハードウェアシステムをインプリメントする Vivado Design Suite、CPU で実行されるアプリケーションバリアを作成する Arm コンパイラおよびリンカーなど必要なすべてのツールを呼び出して、SD カード用の完全なブート可能イメージを出力することにより、各ハードウェア関数用のアクセラレータ (スタブ) を呼び出します。





図 3: SDSoC のビルドプロセス

エンベデッドプロセスアプリケーション

ハードウェア関数

SDS++コンパイル

HLS 関数のコンパイル

GNU Arm ツールチェーン

SDS++リンク

Vivado Design Suite

ソフトウェアイメージの

アップデート

C/C++

Arm のビルド手順

アプリケーションの実行ファイル

(.elf)

RTL、C/C++

プログラマブルロジックのビルド手順

FPGA バイナリ (ビットストリーム)

ブート可能システムイメージ

エンベデッドシステムのソースコード

X21126-082318

コンパイルプロセスには、次のタスクが含まれます。• コードが解析され、Arm コアの main アプリケーションがコンパイルされ、各ハードウェアアクセラレータに対し

て個別にコンパイルが実行されます。• 標準 GNU Arm コンパイルツールでアプリケーションがコンパイルされ、最終出力としてオブジェクトファイル

(.o) が生成されます。• ハードウェアでアクセラレーションされる関数が HLS ツールで実行され、カスタムハードウェア作成プロセスが

開始し、出力としてオブジェクトファイル (.o) が生成されます。コンパイル後のリンクプロセスには、次のタスクが含まれます。• デザイン内のデータ移動が解析され、ハードウェアプラットフォームがアクセラレータを受け入れるよう変更さ

れます。• Vivado Design Suite で合成およびインプリメンテーションが実行されてハードウェアアクセラレータがプログラ

マブルロジック (PL) 領域にインプリメントされ、デバイス用のビットストリームが生成されます。• エンベデッドプロセッサアプリケーションからハードウェア関数を呼び出すため、ソフトウェアイメージがハー

ドウェアアクセス API でアップデートされます。• ボードを ELF (Executable and Linkable Format) ファイルのアプリケーションでブートする統合 SD カードイメー

ジが生成されます。





SDSoC デバッグフローの概要SDSoC 環境で生成されるシステムは、ハードウェアコンポーネントおよびソフトウェアコンポーネントで構成される高性能で複雑なシステムです。ソフトウェアの一部がプロセッサで実行され、ハードウェアアクセラレータがプログラマブルファブリックで実行され、それらの間でデータ転送が同時に多数実行されるこのようなシステムでは、アプリケーションの実行を理解するのが困難なことがあります。SDSoC 環境では、ザイリンクスソフトウェアデバッガー (XSDB) を使用してプロジェクトを作成およびデバッグできます。高度なハードウェア/ソフトウェアイベントトレースが提供されており、ドライバーソフトウェア設定およびハードウェアでの実行を含むアクセラレータタスクとデータ転送の統合タイムラインビューがあります。コマンドラインまたはスクリプトオプションを使用すると、SDx 統合開発環境 (IDE) 外でプロジェクトをデバッグできます。SDSoC 開発環境では、コンパイルおよびリンクコマンドのビルドプロセスのターゲットをシステムエミュレーションターゲットまたは指定のプラットフォームのハードウェアターゲットに指定できます。完全なシステムをビルドする代わりに、ターゲットとアプリケーションバイナリを含むエミュレーションモデルを作成できます。エミュレーションターゲットに対しては、sds++ システムコンパイラによりクセラレータ関数のソースファイルを使用してシミュレーションモデルが作成されます。システムエミュレーションは SDSoC 環境で最も有効なデバッグ機能の 1 つで、論理的な問題をデバッグしたり、アプリケーションがハングする原因を突き止めたりするのに役立ちます。この機能は、ザイリンクスベースプラットフォーム ZC702、ZC706、ZCU102、ZCU104、ZCU106、および ZedBoard ベースのプラットフォームでのみ使用可能です。ハードウェア関数を特定したら、システムエミュレーションを使用してロジックをすばやくコンパイルし、システム全体を検証できます。これによりクイックエミュレーター (QEMU) ベースエミュレーターでクロスコンパイルされた Arm コードを実行し、Vivado シミュレータで実行しているハードウェアアクセラレータと通信できます。RTL シミュレータでは波形を表示できますが、波形を表示せずに高速にシミュレーションを実行することもできます。エミュレーターは SDx IDE 内またはコマンドライン (sdsoc_emulator) で実行でき、システムをビットストリームにコンパイルしてボード上のデバイスにプログラムせずに、最終的なハードウェアインプリメンテーションを正確に表示できます。





図 4: システムエミュレーションフローソフトウェア

アプリケーションコード

エミュレーションでのデバッグ

機能は正しいか?

プラットフォームは

ザイリンクスかカスタムか?

エミュレーション用にハードウェア関数あり/

なしでソフトウェアアプリケーションを

ビルド


標準ソフトウェアデバッグ

Yes

ザイリンクス

ハードウェアでビルド、イベントのトレース、

プロファイリングおよび適化



カスタム

YesNo

No

X21984-112018

ハードウェアプラットフォームをターゲットとする場合、ハードウェアおよびソフトウェアイベントトレースを使用して、イベントの実行を解析したり、問題を見つけたりすることもできます (ハードウェア/ソフトウェアイベントのトレースを参照)。ハードウェアデザイン自体に問題がある場合は、SDSoC 環境にインプリメントされたハードウェア関数にデバッグコアを挿入して、Vivado Lab Edition でハードウェアデバッグを使用できます。次の図に、典型的なハードウェアのビルドおよびデバッグプロセスを示します。





図 5: ハードウェアのビルドおよびデバッグフロー

ハードウェアビルドは正常に

完了したか?

ハードウェアで実行


パフォーマンスは満たされたか?

デバッグ終了

SDSoC 環境のトラブルシューティングは

UG1027 を参照



パフォーマンスおよび適化については

UG1235 を参照

No

Yes

Yes

ザイリンクスプラットフォームに切り替えて

さらにデバッグ

ChipScope を使用して

ハードウェアをデバッグ

Noアプリケーションのハング

ボードのハング

アプリケーションの

クラッシュ

無効なデータ

No

エミュレーションが問題なく完了

ソフトウェアアプリケーション

コード


コード


コード


コード

エラーを分類して修正

Yes

X21658-100818

ザイリンクスベースプラットフォームでは、システムエミュレーションおよびハードウェアターゲットビルドの両方がサポートされます。カスタムプラットフォームおよびサードパーティプラットフォームでは、ハードウェアビルドおよびデバッグフローのみがサポートされます。

関連情報システムのハングとランタイムエラーのデバッグ

システムエミュレーションザイリンクスベースプラットフォームでは、システムエミュレーションを使用してシステム全体 (PS および PL) のRTL レベルのトランザクションをデバッグできます。SDSoC エミュレーター (sdsoc_emulator) でアプリケーションを実行すると、デバッガーでデータ転送を可視化できます。これによりシステムハングプの問題をデバッグでき、シミュレーション波形ビューで関連するデータ転送調べて、そのデータ転送に関係するハードウェアブロックの信号を表示できます。





ハードウェア実行フローハードウェア実行では、実際のハードウェアプラットフォームを使用してアクセラレーションされたアプリケーションを実行できます。System Integrated Logic Analyzer (System ILA)、Virtual Input/Output (VIO) デバッグコア、AXI パフォーマンスモニターなどの特別なデバッグロジックをアクセラレータに含むハードウェアのデバッグコンフィギュレーションを作成できます。SDSoC 環境には Vivado ハードウェアマネージャーを使用したハードウェアデバッグ機能が含まれており、波形解析、カーネルアクティビティレポート、およびメモリアクセス解析を実行してハードウェアのクリティカルな問題を可視化できます。インシステムデバッグを使用すると、ターゲットハードウェアでデザインをリアルタイムにデバッグできます。これは、デザインを完成させるために必須の手順です。シミュレータでは再現するのが困難な状況もあるので、実行中のハードウェアで問題をデバッグすることが必要です。この手順では、デザインにデバッグコアを配置して、デザインを監視および制御できるようにします。デバッグプロセスが終了したら、パフォーマンスを向上してデバイスのリソース使用率を削減するため、デバッグコアを削除できます。SDx 統合開発環境 (IDE) およびコマンドラインオプションを使用して、デザインをデバッグ用にインストルメント化できます。--dk コンパイラオプションは、ハードウェア関数のインターフェイスに ILA デバッグコアを追加します。アプリケーションコードで使用される C 呼び出し可能な IP をデバッグするには、IP を C 呼び出し可能な IP としてパッケージする前に、IP の RTL コードにデバッグコアをインスタンシエートする必要があります。重要: SDSoC プラットフォームハードウェア上でハードウェア関数をデバッグするには、ハードウェアモデル全体に追加のロジックを組み込む必要があります。つまり、ハードウェアデバッグを有効にすると、ザイリンクスデバイスのリソース使用率およびハードウェア関数のパフォーマンスに影響します。

ハードウェアへの接続ボード接続の要件は、オペレーティングシステム (スタンドアロン、FreeRTOS、または Linux) によって多少異なります。• スタンドアロンおよび FreeRTOS の場合、USB/JTAG インターフェイスを使用して ELF ファイルをボードにダウン

ロードする必要があります。トレースデータも同じ USB/JTAG インターフェイスを介して読み出されます。• Linux では、SDSoC 環境で OS が SD カードから起動されると想定されます。その後 SDx 環境は .elf ファイルを

コピーし、ボードとホスト PC 間のイーサネット接続を介して、Linux で実行される TCP/TCF エージェントを使用して実行します。トレースデータは、USB/JTAG インターフェイスを介して読み出されます。このため、Linux アプリケーションのトレースには、USB/JTAG インターフェイスおよび TCP/TCF エージェントインターフェイスの両方が必要です。

次の図に、必要な接続を示します。





図 6: 異なるオペレーティングシステムでトレースを使用した場合に必要な接続

Linux

Standalone/FreeRTOS

Host PC Board

Ethernet Ethernet

USB JTAG

Zynq-7000SoC

Host PC Board

Ethernet Ethernet

USB JTAG

Zynq-7000 SoC

X16744-010419

イベントトレースSDSoC 環境のイベントトレース機能を使用すると、アプリケーション実行中にシステムで何が起こっているかを詳細に表示できます。トレースイベントが生成されてタイムラインビューに収集され、実行中のアプリケーションに関する情報が表示されます。この詳細な表示により、ワークロードを与えたときのアプリケーションのパフォーマンス、ハードウェア/ソフトウェアの分割、およびシステムデザインの選択肢などが理解しやすくなります。この表示を使用すると、プロセッサで実行されているソフトウェアと、システム内のハードウェアアクセラレータおよびデータ転送リンクのイベントトレースが可能になります。このような情報は、問題の特定、システムインプリメンテーションの最適化、システムインプリメンテーションの向上に役立ちます。アプリケーションをトレースすると、システム実行に関する情報を記録するログが生成されます。イベントトレースでは、イベントログとは異なり、特定の時間の瞬間的なイベントが表示されるのではなく、イベント期間中のイベント間の関係が表示されます。トレースの目標は、どのイベントがいつ発生するか、イベントにどれくらい時間がかかるかなどを監視し、デバッグを実行しやすくすることです。これは、パフォーマンスを解析し、アプリケーションのハングが発生するかどうかを調べるの最適です。





第 2 章

SDSoC のデバッグ機能このセクションでは、SDx™ 環境で Vivado® Design Suite IDE またはコマンドラインを使用してデバッグを実行する方法について詳しく説明します。

SDx 環境デバッグツールSDx 環境には、SDSoC 環境デザインをデバッグするためにザイリンクスシステムデバッガー (XSDB) が含まれます。

ザイリンクスシステムデバッガー (XSDB)ザイリンクスシステムデバッガー (XSDB) では、ザイリンクス hw_server がデバッグエンジンとして使用されます。ザイリンクスソフトウェア開発キット (SDK) は各ユーザーインターフェイス操作を一連の TCF (TargetCommunication Framework) コマンドに変換し、システムデバッガーからの出力を処理して、デバッグされているプログラムの現在のステートを表示します。ハードウェア上のプロセッサとの通信には、ザイリンクス hw_server が使用されます。システムデバッガーの 1 つのデバッグコンフィギュレーションで複数のプロセッサを同時にデバッグできます。これが、SDx 環境デザインに推奨されるデバッグエンジンです。システムデバッガーは、ハードウェアまたは QEMU エンジンで起動できます。




.elf

SDK のデバッグパースペクティブ

hw_server

ハードウェアまたは ISS で実行中の

プログラム

デバッグコンフィギュレーションの作成

hw_server の詳細を指定

X21076-120218

ワークフローは、次の要素で構成されます。• ELF ファイル: ユーザーアプリケーションをデバッグするには、デバッグ用にコンパイルされた ELF ファイルを使

用する必要があります。デバッグ ELF ファイルには、デバッガーへの追加のデバッグ情報が含まれ、ソースコードとその元のソースから生成された 2 進数間が直接関連付けられます。詳細は、ビルドコンフィギュレーションを参照してください。

• デバッグコンフィギュレーション: デバッグセッションを開始するには、SDx 環境でデバッグコンフィギュレーションを作成する必要があります。このコンフィギュレーションには、実行ファイル名、デバッグするプロセッサターゲットなど、デバッグセッションを開始するのに必要な情報が含まれます。詳細は、デバッグコンフィギュレーションの設定を参照してください。

• SDx の [Debug] パースペクティブ: [Debug] パースペクティブを使用すると、SDx ワークベンチでプログラムのデバッグまたは実行を管理できます。ブレークポイントを設定、実行中のプログラムを一時停止、コードをステップ実行、変数の内容を確認するなど、プログラムの実行を制御できます。

SDx 環境で、コードの修正、実行ファイルの構築、プログラムのデバッグというサイクルを繰り返すことができます。注記: コンパイル後にソースを編集すると、デバッグ情報がそのソースに直接関連付けられているため、その行番号はステップ実行されなくなります。同様に、最適化されたバイナリをデバッグすると、実行トレース中に予期しないジャンプが発生することがあります。

第 2 章: SDSoC のデバッグ機能


https://japan.xilinx.com/html_docs/xilinx2018_3/SDK_Doc/SDK_concepts/concept_sdk_build_configurations.html



デバッグコンフィギュレーションの設定アプリケーションをデバッグ、実行、およびプロファイリングするには、アプリケーション実行およびデバッグの設定を保存するデバッグコンフィギュレーションを作成する必要があります。デバッグコンフィギュレーションを作成するには、[Assistant] ビューで [Debug] ビルドコンフィギュレーションを右クリックし、[Debug] → [DebugConfigurations] をクリックします。または、メインメニューから [Run] → [Debug Configurations] をクリックします。次の図に示す [Debug Configurations] ダイアログボックスが開きます。ヒント: アプリケーションプロジェクトの OS とシステム設定、およびデバッグするアプリケーションのタイプによって、[Debug Configurations] ダイアログボックスに含まれるタブは異なります。ここで説明するタブおよびオプションが実際に表示されるものと異なる場合があります。

図 7: [Debug Configurations] ダイアログボックス

[Debug Configurations] ダイアログボックスの左側のペインで、[Xilinx SDx Application Debugger] を選択してプロジェクトのデバッグコンフィギュレーションを作成します。アプリケーションプロジェクトに新しいデバッグコンフィギュレーションが作成され、コンフィギュレーションを管理する複数のタブが表示されます。[Main] タブ[Main] タブのオプションは、現在のアプリケーションプロジェクトのデバッグおよび接続のタイプに応じて自動的に設定されます。たとえば Linux アプリケーションは、Linux デバッグタイプを使用し、アプリケーションへの接続には Linux エージェントを使用します。





ヒント: ここでデバッグタイプを変更できますが、それによりデバッグコンフィギュレーションに関連付けられているアプリケーションプロジェクトもリセットされます。

図 8: [Debug Configurations] ダイアログボックス: [Main] タブ

[Application] タブ[Application] タブには、プロセッサにダウンロードして実行するコンパイル済みアプリケーション ELF ファイルが表示されます。





図 9: [Debug Configurations] ダイアログボックス: [Application] タブ

[Target Setup] タブLinux アプリケーションでは、[Target Setup] タブは空白です。スタンドアロンアプリケーションでは、ハードウェアプラットフォームと、初期化に FSBL (第 1 段階ブートローダー) フローを使用するかどうか (プラットフォームのデバイスを初期化する必要がある場合) を指定できます。[Arguments] タブ[Arguments] タブでは、デバッグセッションを起動するのに必要な変数を指定できます。[Variables] をクリックして[Select Variable] ダイアログボックスを表示します。





[Environment] タブ[Environment] タブでは、デバッグコンフィギュレーションの環境変数を設定します。





図 10: 環境変数の追加、設定、および編集

デバッグコンフィギュレーションに新しい環境変数を追加するには、[New] をクリックして値を指定します。[Select]をクリックすると、デバッグコンフィギュレーションに追加可能な既存の環境変数が表示され、値を変更および設定できます。

[Target Connections] ビュー[Target Connections] ビューでは、複数のリモートターゲットを設定できます。接続されているターゲットが表示され、ターゲット接続を追加または削除するオプションがあります。SDx 環境では、ターゲット接続はハードウェアサーバーエージェントを介して確立されます。リモートターゲットに接続するには、ターゲットに接続されたリモートホスト上でハードウェアサーバーエージェントが実行されている必要があります。

詳細は、ハードウェアへの接続を参照してください。





SDSoC IDE での Linux アプリケーションのデバッグSDSoC 統合開発環境 (IDE) でアプリケーションをデバッグするには、次の手順を使用します。ボードが JTAG デバッグコネクタを使用してホストコンピューターに接続されていることを確認します。ボードとホスト PC 間にはイーサネット接続があります。1. 選択した SDSoC プラットフォームのユーザーガイドに従って、SD カードから起動するアプリケーションを設定

します。2. [SDx Application Project Settings] で、[Target] を [Hardware] に設定し、[Generate SD card image] チェックボック

スをオンにします。3. [Assistant] ビューで [Debug] ビルドコンフィギュレーションを右クリックし、[Set Active] をクリックします。4. [Assistant] ビューまたはメインメニューで [Build] ( ) コマンドをクリックし、デバッグコンフィギュレーショ

ンをビルドします。5. ファイルブラウザーまたはコマンドシェルで、Debug/sd_card フォルダーの内容を SD カードにコピーしま

す。6. SD カードをプラットフォームのカードリーダーに挿入し、カードをブートします。7. ボードがネットワークに接続されていることを確認し、UART を介してボードと通信するターミナルを使用して、

コマンドプロンプトでボードに対して ifconfig eth0 を実行するなどして、IP アドレスを記録します。8. [Assistant] ビューで [Debug] ビルドコンフィギュレーションを右クリックし、[Debug] → [Debug Configurations]

をクリックして新しいビルドコンフィギュレーションを作成します。ボードの IP アドレスを入力します。9. SDSoC 環境の [Debug] パースペクティブに切り替え、デバッグの開始、停止、ステップ実行、ブレークポイント

の設定、変数およびメモリの検証などのデバッグ操作を実行します。SDSoC IDE でのスタンドアロンまたは FreeRTOS アプリケーションのデバッグスタンドアロン (ベアメタル) または FreeRTOS OS で実行中のアプリケーションをデバッグするには、ボードが JTAGデバッグコネクタを使用してホストコンピューターに接続されていることを確認し、ボードが JTAG から起動するように設定します。1. [Assistant] ビューで [Debug] ビルドコンフィギュレーションを右クリックし、[Set Active] をクリックします。2. [Assistant] ビューまたはメインメニューで [Build] ( ) コマンドをクリックし、デバッグコンフィギュレーショ

ンをビルドします。3. [Assistant] ビューで [Debug] ビルドコンフィギュレーションを右クリックし、[Debug] → [Debug Configurations]

をクリックして新しいビルドコンフィギュレーションを作成します。4. オプション: SDSoC 環境の [Debug] パースペクティブに切り替え、デバッグの開始、停止、ステップ実行、ブレー

クポイントの設定、変数およびメモリの検証などのデバッグ操作を実行します。5. オプション: SDSoC IDE ツールバーで [Debug] をクリックすると、上記の手順を一気に実行できます。

XSCT (ザイリンクスソフトウェアコマンドラインツール)SDx 環境などのグラフィカル開発環境は、新規プロセッサの開発を高速化するのに有益です。初心者でも使用できるように、よく使用される関数のほとんどが抽象化され、論理的なウィザードにまとめられています。スクリプトを記述して実行できる機能も重要であり、ツールでの処理を拡張する柔軟性が提供されます。スクリプトは、毎晩実行する回帰テストを開発する際や、開発者がよく使用するコマンドセットを実行する際に特に便利です。XSCT (ザイリンクスソフトウェアコマンドラインツール) は、SDx 環境のインタラクティブでスクリプト記述可能なコマンドラインインターフェイスです。XSCT のスクリプト言語は、その他のザイリンクスツールと同様、Tcl (ツールコマンド言語) に基づきます。XSCT コマンドはインタラクティブに実行でき、またコマンドをスクリプトに記述して自動化することもできます。XSCT では、次の操作を実行できます。• ハードウェア、ボードサポートパッケージ (BSP)、およびアプリケーションプロジェクトを作成。





• リポジトリを管理。• チェーンプリファレンスを設定。• BSP/アプリケーションをコンフィギュレーションおよびビルド。• ハードウェアターゲットにアプリケーションをダウンロードして実行。• Bootgen および program_flash ツールを実行してブートイメージを作成およびフラッシュ。XSCT コマンドの詳細は、『ザイリンクスソフトウェアコマンドラインツール (XSCT) リファレンスガイド』(UG1208) を参照してください。

システムエミュレーションシステムエミュレーションは、システムデバッガー上で TCF (Target Communications Framework) サーバーを使用して実行できます。注記: 現在のところ、カスタムプラットフォームでのエミュレーションはサポートされていません。エミュレーションはザイリンクスが提供するベースプラットフォームでのみサポートされます。

IDE からのシステムエミュレーションの実行システムエミュレーションでは、システムをビットストリームにコンパイルしてボード上にデバイスをプログラムしなくても、最終的なインプリメンテーションと同レベルの精度で検証できます。システムエミュレーションを使用すると、実際のハードウェアを使用せずにアプリケーションをデバッグできます。パフォーマンスのボトルネックも特定できます。

システムエミュレーションの有効化システムエミュレーションを有効にするには、[Application Project Settings] ウィンドウで次を実行します。1. [Active build configuration] を [Debug] に設定します。2. [Target] を [Emulation] に設定します。3. エミュレーションモデルを設定します。2 つのエミュレーションモデルモードがあります。

• [Debug]: RTL 生成およびハードウェア関数を含む IP インテグレーターブロックデザインからシステムを構築し、デザインのビヘイビアーシミュレーションを実行して、結果を解析しやすいように波形ビューアーに表示します。Vivado Design Suite で Vivado シミュレータを使用して波形を解析します。

• [Optimized]: バッチモードでビヘイビアーシミュレーションを実行し、波形データなしの結果を返します。[Optimized] モデルの方が高速ですが、[Debug] モデルよりも表示される情報は少なくなります。

ハードウェアデバッグ情報を取り込まずに、エミュレーションを高速に実行するには、[Optimized] オプションを選択します。システムのハング問題をデバッグする場合は、[Debug] モードを使用して Vivado シミュレータの波形ビューアーで異なる信号のステートを確認します。アプリケーションのみをデバッグする場合は、[Optimized] エミュレーションモデルを使用できます。



https://japan.xilinx.com/cgi-bin/docs/rdoc?v=2018.3;d=ug1208-xsct-reference-guide.pdf



エミュレーションではシステム全体をコンパイルする必要はないので、実行時間を短縮するために [Generate SDcard image] はデフォルトでオフになっています。システムエミュレーションを使用すると、全ビットストリームコンパイルと同レベルの精度でシステムを検証およびデバッグできます。

4. エミュレーションモデルを指定した後、[Build] ボタン ( ) を使用してシステムをエミュレーション用にコンパイルします。ビルドプロセスには、アプリケーションコード、ハードウェア関数のサイズ、選択したオプションによって時間がかかることがあります。ハードウェア関数をコンパイルするため、ツールスタックには SDx 環境、Vivado 高位合成 (HLS) ツール、および Vivado Design Suite が含まれます。

システムエミュレーターの実行1. エミュレーションターゲットを作成したら、[Xilinx] → [Start/Stop Emulator] をクリックしてシステムエミュレー

ターを実行します。または、[Assistant] ビューでアプリケーションを右クリックし、[Start/Stop Emulator] をクリックします。

2. [Start/Stop Emulator] ダイアログボックスが開いたら、エミュレーションモードを指定します。• [Debug] を選択すると、波形を表示するかしないかを指定してエミュレーションを実行できます。• [Optimized] を選択すると、[Show Waveform] チェックボックスボックスは無効になります。





[Start/Stop Emulator] ダイアログボックスには、[Project] (プロジェクト名)、[Configuration] (ビルドコンフィギュレーション)、[Show Waveform] (波形表示) オプションが含まれます。[Show Waveform] をオフにすると、ソースコードの print 文の結果も含め、すべてのシステムメッセージが [Emulation Console] ビューに表示されます。この中には、ハードウェア関数で送受信される値や、アプリケーションが問題なく実行されたことを示すメッセージが表示され、PL で実行されるソースコードと PS で実行されるコンパイル済みハードウェア関数が論理的に問題なかったかどうかを確認できます。[Show Waveform] オプションをオンにすると、コンソールウィンドウで波形ウィンドウと同じ機能が使用できるようになり、RTL のビヘイビアーシミュレーションも実行できます。RTL 波形ウィンドウには、時間の経過に応じたハードウェア関数の信号値が表示されます。[Show Waveform] をオンにする場合、エミュレーションの開始前に信号を手動で波形ウィンドウに追加しておく必要があります。

3. [Scope] ウィンドウでデザイン階層を確認します。4. [Object] ウィンドウで監視する信号を右クリックして、その信号を波形ウィンドウに追加します。5. [Run All] ツールバーボタンをクリックして、波形ウィンドウのアップデートを開始します。Vivado シミュレータ

の波形ウィンドウの詳細は、『Vivado Design Suite ユーザーガイド: ロジックシミュレーション』 (UG900) を参照してください。

注記: RTL 波形を表示して実行すると、実行時間は長くなりますが、ハードウェア関数の動作を詳細に解析できます。ヒント:

システムエミュレーションは、[Project Explorer] ビューでアクティブプロジェクトを右クリックし、次のコマンドをクリックしても開始できます。• [Run As] → [Launch on Hardware]

• [Debug As] → [Launch on Hardware]

エミュレーターを [Debug As] メニューから起動すると、パースペクティブが [Debug] パースペクティブに変更され、ウィンドウおよびビューがプロジェクトのデバッグに適した配置になります。

エミュレーション出力の表示1. システムエミュレーターを実行すると、コンソールウィンドウにプログラム出力が表示されます。[Show

Waveform] オプションを選択した場合は、Vivado 統合開発環境 (IDE) でシミュレータが起動します。必要に応じて波形ウィンドウに波形を追加します。[Run All] をクリックしてシミュレーションを開始します。



https://japan.xilinx.com/cgi-bin/docs/rdoc?v=2018.3;d=ug900-vivado-logic-simulation.pdf



2. エミュレーターを実行してデバッグセッションを起動するには、[Assistant] ビューでデバッグコンフィギュレーションを右クリックして [Debug As] → [Launch on Emulator (SDx Application Debugger)] をクリックします。

3. [Confirm Perspective Switch] ダイアログボックスが表示されます。[Yes] をクリックして [Debug] パースペクティブに切り替えます。

4. [Debug] パースペクティブでアプリケーションが起動し、プログラムの実行が main 関数で停止します。アプリケーションコードの実行を再開するには、[Resume] をクリックします。

アプリケーションコードの実行が開始します。次の図に示すように、[Emulation Console] にアプリケーションコードの出力が表示されます。





Vivado 波形ウィンドウにさまざまな信号のステータスが表示されます。ハードウェア関数の適切な応答も RTL波形に表示されます。コードの実行中の一時停止でも、ボードで実行される FPGA と同様、RTL 波形は続けて実行されてアップデートされます。

5. エミュレーションを停止するには、[Xilinx] → [Start/Stop Emulator] をクリックして [Stop] をクリックします。ヒント: エミュレーションのデモのサンプルプロジェクトを参照するには、[Emulation Example] テンプレートを使用して新しい SDx 環境プロジェクトを作成します。プロジェクトの README.txt ファイルには、SDx IDE およびコマンドラインの両方でエミュレーションを実行する手順が含まれています。





コマンドラインからのシステムエミュレーションの実行SDx 統合開発環境 (IDE) を使用せずにデザインを作成するには、一般的なコマンドラインフローで個別の SDx コマンドを使用してプロジェクトを構築およびコンパイルするか、makefile フローを使用します。次のスクリプト例では、TARGET でエミュレーション用にコンパイルするよう定義しています。# FPGA Board Platform (Default ~ zcu102)PLATFORM := zcu102# Run Target:# hw - Compile for hardware# emu - Compile for emulation (Default)TARGET := emu

エミュレーションモードでは、次のスクリプト例に示すように、次の 2 つのオプションのいずれかを選択できます。• debug: 確認およびデバッグ用 PL ハードウェアエミュレーションから波形データを取り込みます。• optimized: ハードウェアデバッグ情報を取り込まずに、エミュレーションを高速に実行します。# Target OS:# linux (Default), standaloneTARGET_OS := linux# Emulation Mode:# debug - Include debug data# optimized - Exclude debug data (Default)EMU_MODE := optimized

コマンドプロンプトに「make」と入力してプログラムをビルドします。波形をシミュレータで表示するには、_sdsディレクトリを含むレベルに移動し、「sdsoc_emulator -graphic-xsim」と入力します。これにより、次の図に示すように Vivado シミュレータが起動します。

すべてのプラットフォームで使用可能なハードウェア実行機能システムエミュレーションは、ザイリンクスベースのプラットフォームで実行されているアプリケーションプロジェクトでしか使用できませんが、ハードウェア実行フローは SDSoC プロジェクトのターゲットであるどのプラットフォームでも実行できます。ハードウェア実行フローとは、ハードウェアプラットフォーム上で協調実行されるエンベデッドプロセッサオペレーティングシステム、アプリケーションコード、およびハードウェア関数です。ハードウェアで実行可能なデバッグには、次のタイプがあります。





• ザイリンクスシステムデバッガー (XSDB) を使用した完全なソフトウェアデバッグ• ザイリンクスシステムデバッガー (XSDB) を使用したハードウェアおよびソフトウェアの協調デバッグ• イベントトレース注記: ハードウェアデバッグには、Vivado ハードウェアマネージャーで信号の解析用にハードウェアをインストルメント化することも含まれます。ハードウェアをインストルメント化するため、アプリケーションを特別の命令を含めてビルドする必要があります。

ChipScope を使用した SDSoC でのハードウェアデバッグ最終的なシステムイメージを生成して SDSoC 環境で実行したら、エンベデッドプロセッサ OS、アプリケーションコード、およびアクセラレーションされたハードウェア関数を含むシステム全体が実際のハードウェア上で正しく実行されるかを検証し、必要なデバッグ操作を実行できます。ChipScope は、Vivado IDE を使用してハードウェアでデザインをデバッグするために使用します。ハードウェアとソフトウェアのクロスプローブには、SDx 環境および Vivadoツールスイートの詳細な知識が必要です。このデバッグ手順を使用すると、ターゲットプラットフォームへの接続、プロセッサの接続、プロセッサのブート、およびハードウェアのシステムイメージでのプログラムに関連する問題を発見できます。また、アプリケーションコードとハードウェア関数間のデータのやり取り (プロトコル違反)、複数のハードウェア関数とアプリケーションコードとの検証に関する問題を検出できる可能性があります。さらに、システムパフォーマンスメトリクスも取得でき、その結果作業の焦点がデバッグからパフォーマンスの調整に移行する場合もあります。SDx ツールでは、ハードウェアアクセラレータおよびアダプターのインターフェイスでのトランザクションを解析するため、ハードウェアをインストルメント化できます。また、デザインのハードウェア部分もデバッグできます。

--dk を使用したアクセラレーションされた関数のデバッグのイネーブルデザインの実行を視覚的に表示することは、アプリケーションがハングするような困難な問題をデバッグするために重要です。System Integrated Logic Analyzer (System ILA) デバッグコアを使用すると、トランザクションレベルでアクセラレーションされたカーネルやハードウェアで実行される関数などを表示できます。ILA コアを使用すると、特定の AXI トラフィックをキャプチャして表示することも可能です。ILA コアは、既存の SDSoC 環境デザインのハードウェア全体にインスタンシエートしてそのデザイン内でデバッグ機能をイネーブルにするか、コンパイラで自動的に挿入されるようにできます。sds++ コンパイラには、デバッグおよびパフォーマンス監視用に System ILA コアをインターフェイスでハードウェア関数に接続するための -–dk オプションがあります。-–dk オプションを使用して ILA IP コアの挿入をイネーブルにします。 --dk arg <[protocol|chipscope|list_ports]:<compute_unit_name>:<interface_name>>

次に、-–dk オプションを使用する例を示します。sds++ -c --dk chipscope:vadd_cu0:s_axi_control --dk chipscope:vadd_cu0:m_axi_gmem

次に、デバッグコアを挿入する makefile の例を示します。APPSOURCES = main.cpp mmult.cpp madd.cppEXECUTABLE = mmultadd.elfPLATFORM = zc702CLKID =





DMCLKID = SDSFLAGS = -sds-pf ${PLATFORM} ${DMCLKID} \ -sds-hw mmult mmult.cpp ${CLKID} -sds-end \ -sds-hw madd madd.cpp ${CLKID} -sds-end \ -debug-port mmult:A \ -debug-port madd:C \ --dk chipscope:madd_1:A \ --dk chipscope:madd_1_if:ap_ctrl CC = sds++ ${SDSFLAGS}CFLAGS = -O3 -cCFLAGS += -MMD -MP -MF"$(@:%.o=%.d)"LFLAGS = -O3OBJECTS := $(APPSOURCES:.cpp=.o)DEPS := $(OBJECTS:.o=.d).PHONY: all clean ultracleanall: ${EXECUTABLE}${EXECUTABLE}: ${OBJECTS} ${CC} ${LFLAGS} $^ -o $@ -include ${DEPS}%.o: %.cpp ${CC} ${CFLAGS} $^ -o $@clean: ${RM} ${EXECUTABLE} ${OBJECTS} ${DEPS}ultraclean: clean ${RM} ${EXECUTABLE}.bit ${RM} -rf _sds sd_card

–debug-port オプションは、アクセラレータの System ILA を挿入する関数名と引数名を指定します。下位レベルの--dk オプションは、ブロックデザインインスタンスとポート名を再作成するために使用する Tcl ファイルを指定します。次に例を示します。• -debug-port mmult:A は --dk chipscope:mmult_1:A と同じですが、sds++ コマンドではブロックデザイ

ンの再作成に使用される Tcl ファイルに含まれるインスタンスとポート名が判断されます。注記: Tcl ファイルは、Vivado Design Suite のアクセラレータを含むハードウェアプラットフォームのブロックデザインを再作成するために SDx 環境で使用されます。• --xp param:compiler.userPostSysLinkTcl=<user_tcl_file> を使用して <user_tcl_file> に IP イ

ンテグレーターの Tcl コマンドを指定すると、システムのリンク後、合成前にブロック図の System ILA の後処理を実行できます。

注記: 上級ユーザーは、ILA 設定を Tcl コマンドを使用して変更できます。通常、必要に応じて ILA で追加のプローブおよびインターフェイスを有効にして、同じクロックドメインのほかの信号をデバッグできます。このようにすると、FPGA のロジックリソースを削減できます。また、この機能を使用して ILA のチェーンをクロストリガーすることも可能です。• --dk は、アクセラレータおよびアダプターポート用に System ILA を挿入する場合に使用できます。このオプシ

ョンを使用すると、アダプターポートを確認できます。デザインをビルドしたら、『Vivado Design Suite ユーザーガイド: プログラムおよびデバッグ』 (UG908) に説明するように、Vivado ハードウェアマネージャーを使用してデザインをデバッグできます。



https://japan.xilinx.com/cgi-bin/docs/rdoc?v=2018.3;d=ug908-vivado-programming-debugging.pdf



ビルド設定へのフラグの追加SDSoC IDE で作業している場合は、次に示すように、ビルド設定で前述のシステムオプションを追加できます。1. [Assistant] ビューで [Debug] または [Release] ビルドコンフィギュレーションを右クリックし、[Settings] をクリ

ックします。2. [Build Configuration Settings] ダイアログボックスで [Edit Toolchain Settings] リンクをクリックします。3. [Properties for <application_name>] ダイアログボックスの [Tool Settings] タブで、[SDS++ Linker] →

[Miscellaneous] をクリックします。4. [Linker Flags] フィールドに必要なデバッグフラグを追加します。

ヒント: [Tool Settings] タブの上部に [Configuration] フィールドがあり、設定を適用するビルド ([Debug]、[Release]、または [All]) を選択できます。

コンパイラおよびリンカーオプションの詳細は、『SDx コマンドおよびユーティリティリファレンスガイド』(UG1279) を参照してください。

ハードウェアデザインの解析適切な ILA (Integrated Logic Analyzer) インスタンスを含めてデザインをビルドしたら、次の手順を実行して Vivado デザインを開いて解析できます。1. デバッグ可能な信号を確認するには、[Project Explorer] ビューで [Debug/Release] → [_sds] → [p0] → [vivado] →

[prj] フォルダーに移動します。



https://japan.xilinx.com/cgi-bin/docs/rdoc?v=2018.3;d=ug1279-sdx-command-utility-reference-guide.pdf



2. prj.xpr をダブルクリックします。デザインが Vivado IDE で開きます。3. Vivado IDE で、Flow Navigator の [IP インテグレーター] → [Open Block Design] をクリックします。





4. [Designs] ウィンドウで system_ila_x のインスタンスを見つけます。

5. [Design] ウィンドウで ILA インスタンスを選択し、ブロックデザインでハイライトします。





6. ILA に接続されているインターフェイスネットを選択し、SDx IDE で指定したインターフェイスに接続されていることを確認します。

Vivado ハードウェアマネージャーを使用したデザインのデバッグSDx 環境アプリケーションにデバッグコアを挿入したら、Vivado ハードウェアマネージャーに接続して ILA(Integrated Logic Analyzer) コアのトランザクションを確認します。ハードウェアマネージャーを使用してターゲットボードに接続するには、次の手順を実行します。1. Vivado Design Suite を起動します。2. [Tasks] セクションで [Open Hardware Manager] をクリックします。





または、Vivado を起動してプロジェクト (<appication_project_name>/Debug/_sds/p0/vivado/prj/prj.xpr) を開き、Flow Navigator で [Program and Debug] → [Open Hardware Manager] → [Open Target] →[Open New Target] をクリックします。

3. Open New Hardware Target ウィザードが開きます。[Next] をクリックします。





4. [Hardware Server Settings] ページで [Connect to] ドロップダウンリストから [Remote server] または [Localserver] を選択します。[Remote Server] を選択した場合は、[Host name] にホスト名を入力して [Port] に正しいポート番号を入力します。この例では、[Local server] を選択します。

5. [Next] をクリックします。[Select Hardware Target] ページが開き、ボードに存在するターゲットがリストされます。

6. [Next] をクリックします。[Open Hardware Target Summary] ページが開き、サーバー名、接続するポート、ターゲット、および動作周波数が表示されます。





7. [Finish] をクリックします。次の図に示すように Hardware Manager 環境が開きます。

8. これで、Vivado ハードウェアマネージャーを使用してデザインで実行中の Integrated Logic Analyzer (ILA) に接続できるようになります。ツールの詳細は、『Vivado Design Suite ユーザーガイド: プログラムおよびデバッグ』(UG908) を参照してください。



https://japan.xilinx.com/cgi-bin/docs/rdoc?v=2018.3;d=ug908-vivado-programming-debugging.pdf



ハードウェア/ソフトウェアイベントのトレースイベントトレースを使用すると、アクセラレータおよびデータ転送のソフトウェア設定、アクセラレータおよびデータ転送のハードウェア実行など、各フェーズを視覚的に確認できます。アプリケーションをトレースすると、ある期間におけるイベント間の関連を記録するログが生成されます。トレースの目標は、どのイベントがいつ発生するか、イベントにどれくらい時間がかかるかなどを監視し、デバッグを実行しやすくすることです。ソフトウェアイベントトレースでは、ハードウェア関数に自動的にスタブが挿入され、ハードウェア関数呼び出しに関連するソフトウェア制御イベントが検出されます。記録されたイベントタイプには、ハードウェアアクセラレータ、データ転送、およびハードウェア/ソフトウェア同期イベントの設定と初期化が含まれます。AXI4-Stream 接続を介するデータ転送を使用したアクセラレータのハードウェアイベントトレースは、sdscc/sds++ システムコンパイラの -trace オプションを使用してイネーブルにすることもできます。リンカーを -trace オプションを指定して起動すると、ハードウェア関数の RTL インプリメンテーションにハードウェアモニター IP コアが挿入され、アクセラレータの開始と停止、およびデータ転送期間が監視されます。ハードウェアデバッグと同様、ハードウェアへの接続で説明しているように、イベントトレースには SDSoC 環境プラットフォームをホストコンピューターに接続する必要があります。イベントトレースを実行するには、[Debug] または [Release] ビルドコンフィギュレーションを使用してホストから SDSoC IDE でアプリケーションを実行します。

ハードウェア/ソフトウェアシステムのランタイム操作SDSoC 環境のシステムコンパイラでは、ハードウェア関数を Vivado 高位合成 (HLS) ツールを使用して IP にクロスコンパイルするか、『SDSoC 環境プラットフォーム開発ガイド』 (UG1146) で説明するように C 呼び出し可能 IP としてリンクすることにより、ハードウェア関数がインプリメントされます。各ハードウェア関数の呼び出しサイトは、ハードウェアアクセラレータの実行を管理するスタブ関数を呼び出すように書き換えられます。次の図に、ハードウェア関数を書き換えた例を示します。左側が元のコード、右側が新しい関数名で書き換えられたハードウェア関数呼び出しです。

図 11: ハードウェア関数呼び出しサイトの書き換え

X16743-040516

スタブ関数は、ハードウェアアクセラレータを初期化し、関数引数に必要なデータ転送を開始して、アクセラレータと関連のデータ転送がすべて完了するまでプログラム内の適切なポイントで待機することによりハードウェアとソフトウェアを同期します。たとえば、ハードウェア関数 foo() が foo.cpp で定義されている場合書き換えられたコードはそのプロジェクトのビルド設定の _sds/swstubs/foo.cpp に生成されます。次のスタブコードでは、ハードウェア用にマークされたユーザー関数を置き換えています。この関数はアクセラレータを開始し、アクセラレータからのデータの送受信を開始し、転送が終了するまで待機します。void _p0_mmult0(float *A, float *B, float *C) { switch_to_next_partition(0); int start_seq[3]; start_seq[0] = 0x00000f00; start_seq[1] = 0x00010100;






start_seq[2] = 0x00020000; cf_send_i(cmd_addr,start_seq,cmd_handle); cf_wait(cmd_handle); cf_send_i(A_addr, A, A_handle); cf_send_i(B_addr, B, B_handle); cf_receive_i(C_addr, C, C_handle); cf_wait(A_handle); cf_wait(B_handle); cf_wait(C_handle);

イベントトレースを使用すると、アクセラレータおよびデータ転送のソフトウェア設定、アクセラレータおよびデータ転送のハードウェア実行など、各フェーズを視覚的に確認できます。たとえば、次のスタブコードはトレース用に記述されています。アクセラレータを開始し、転送を開始し、転送が終了するまで待機するコマンドが記述されています。void_p0_mmult_0(float *A, float *B, float *C) { switch_to_next_partition(0); int start_seq[3]; start_seq[0] = 0x00000f00; start_seq[1] = 0x00010100; start_seq[2] = 0x00020000; sds_trace(EVENT_START); cf_send_i(cmd_addr,start_seq,cmd_handle); sds_trace(EVENT_STOP); sds_trace(EVENT_START); cf_wait(cmd_handle); sds_trace(EVENT_STOP); sds_trace(EVENT_START); cf_send_i(A_addr, A, A_handle); sds_trace(EVENT_STOP); sds_trace(EVENT_START); cf_send_i(B_addr, B, B_handle); sds_trace(EVENT_STOP); sds_trace(EVENT_START); cf_receive_i(C_addr, C, C_handle); sds_trace(EVENT_STOP); sds_trace(EVENT_START); cf_wait(A_handle); sds_trace(EVENT_STOP); sds_trace(EVENT_START); cf_wait(B_handle); sds_trace(EVENT_STOP); sds_trace(EVENT_START); cf_wait(C_handle); sds_trace(EVENT_STOP);

ソフトウェアトレースイベントトレースでは、スタブ関数が自動的に挿入され、ハードウェア関数呼び出しのインプリメンテーションに関連するソフトウェア制御イベントがキャプチャされます。イベントには、次のようなタイプがあります。• アクセラレータの設定および開始• データ転送設定• ハードウェア/ソフトウェア同期バリア (イベントを待つ)

これらのイベントはそれぞれ個別にトレースされ、プログラマブルロジックへの 1 つの AXI4-Lite 書き込みとなり、ハードウェアイベントと同じグローバルタイマーからのタイムスタンプが付きます。





ハードウェアトレースSDSoC 環境では、Vivado 高位合成 (HLS) でクロスコンパイルされたアクセラレータのハードウェアイベントトレースと、AXI4-Stream 接続を介したデータ転送がサポートされます。sds++ を -trace オプションを使用して起動すると、ハードウェアモニター IP コアが生成されたシステムに自動的に挿入され、次のイベントタイプが記録されます。• ap_start および ap_done 信号で定義されたアクセラレータの開始および停止。• AXI4-Stream ハンドシェイク信号および TLAST 信号で定義されたデータ転送。これらのイベントはそれぞれ個別に監視され、ソフトウェアイベントで使用されたのと同じグローバルタイマーからのタイムスタンプが付けられます。ハードウェア関数で次のプラグマを使用して明示的に AXI4-Lite 制御インターフェイスが宣言されている場合は、ap_start および ap_done 信号は IP インターフェイスの一部ではないので、トレースできません。#pragma HLS interface s_axilite port=foo

これらのデバッグコアでハードウェアリソースがいくらか使用されますが、ZC706 ボードでは 0.1% 未満です。AXI4-Stream モニターコアには、basic と statistics の 2 つのモードがあります。basic モードでは、開始/停止トレースイベントの生成のみが実行されます。statistics モードでは、AXI4-Lite インターフェイスが 2 つの 32 ビットレジスタに対して有効になります。オフセット 0x0 のレジスタには現在または今後の転送のワードカウントが、オフセット0x4 のレジスタには前の転送のワードカウントが示されます。転送が完了するとすぐに、現在のカウントが前のレジスタに移動されます。デフォルトでは、AXI4-Stream コアは basic モードに設定されます。ハードウェアトレースモニターコアに加え、出力トレースイベント信号が 1 つのインテグレーションコアによりまとめられます。このコアでは、ポート数を 1 ～ 63 に設定できるので、最大で 63 個のモニターコア (アクセラレータまたは AXI4-Stream) がサポートされます。このコアのリソース使用率は、イネーブルになったポートの数、つまり挿入されるモニターコアの数によります。ZC706 プラットフォームでは、使用可能なハードウェアリソースの約 0.1 ～ 1.0% が使用され、インテグレーションロジックを含めて約 10% までのメモリが使用されます。

インプリメンテーションフローインプリメンテーションフロー中にトレースがオンになっていると、トレースインストルメンテーションがソフトウェアコードに、ハードウェアモニターがハードウェアシステムに自動的に挿入されます。この後、ハードウェアシステムが (モニターコアも含めて) 合成およびインプリメントされ、ビットストリームが生成されます。ソフトウェアトレースは、通常のユーザープログラムにコンパイルされます。ハードウェアおよびソフトウェアトレースはハードウェアでタイムスタンプが付けられて 1 つのトレースストリームにまとめられ、プログラマブルロジックのバッファーに格納されます。





第 3 章

デバッグ手法この章では、SDSoC™ 環境デザインで使用可能な異なるデバッグ手法について説明します。ソフトウェアベースのデバッグおよびハードウェア重視の異なる手法を示します。ソフトウェアベースの方法では、FPGA でのデザインのインプリメンテーションを完全に理解する必要はありません。ただし、この概念が適用できるのはあるレベルの詳細度までで、それ以上はハードウェアベースの詳細な解析を実行する必要があります。ソフトウェアのみのデバッグ手法を強調することは、この資料の意図ではありません。SDSoC アプリケーションのデバッグでは、標準 C/C++ をデバッグするのと同じ手法を使用できます。ほとんどのSDSoC アプリケーションには、ハードウェアアクセラレーション用にマークされた関数と、それを含む標準 C/C++コードが含まれます。デバッグホストマシンに接続されたボードを使用して SDSoC アプリケーションをデバッグするには、[Assistant] ビューでビルドコンフィギュレーションを右クリックし、[Debug] → [Launch on Hardware] をクリックしてデバッグセッションを開始します。オプションをデフォルト設定から変更する場合は、[Debug] → [Debug Configurations] をクリックして新しいビルドコンフィギュレーションを作成します。デバッグ環境は初期化されるので、ザイリンクスでは [Debug] パースペクティブに切り替えることをお勧めします。[Debug] パースペクティブには、コードのシングルステップ、ブレークポイントの設定と削除、変数の表示、レジスタのダンプ、メモリの表示、run until および jump to などのデバッグ指示子を使用したコードフローの制御など、アプリケーションの標準 C/C++ 部分をデバッグする機能が含まれます。関数呼び出しの前後に入力および出力を監視でき、動作が正しいかを判断できます。ハードウェアアクセラレーションされたアプリケーションがリアルタイムの要件を満たすかどうかを判断するには、ハードウェアアクセラレーションされた関数の直前および直後にカウンターを開始および停止するデバッグ文を記述します。SDx™ 環境には、通常ハードウェアアクセラレーションされた関数の経過時間を計算するのに使用されるsds_clock_counter() 関数が含まれています。プロジェクトをエミュレーション用に SDx ビルドすると、デバッグホストに接続されたターゲットボードがなくてもデバッグを実行できます。エミュレーション中は、前述のように [Debug] パースペクティブでソフトウェアおよびデータを制御および確認できますが、Vivado® シミュレータの波形ビューアーを使用してもハードウェアアクセラレーションされた関数を表示できます。アクセラレータの信号で Accelerator start、Accelerator done などの条件を確認したり、入力および出力のデータバスを監視したりできます。プロジェクトをエミュレーション用にビルドすると、FPGA ビットストリームを生成するための時間のかかる Vivado インプリメンテーション段階を回避することもできます。SDx IDE でインタラクティブなデバッガーを使用する方法については、『SDSoC 環境デバッグガイド』 (UG1282) を参照してください。


https://japan.xilinx.com/cgi-bin/docs/rdoc?v=2018.3;d=ug1282-sdsoc-debugging-guide.pdf



システムのハングとランタイムエラーのデバッグsds++ を使用してコンパイルされたプログラムは、SDSoC 環境または Vivado SDK 環境で提供される標準デバッガーを使用してデバッグできます。間違った結果、プログラムの早期終了、プログラムのハングなどが典型的なランタイムエラーとして挙げられます。最初の 2 つのエラーは、デバッガーでコードをステップスルーすることによりデバッグできます。注記: アプリケーションがボードでの実行中にハングすることがあります。アプリケーションのハングは通常、プロデューサーとコンシューマーのデータサイズが一致していないことが原因で発生します。プログラムのハングは、#pragma SDS data access_pattern(A:SEQUENTIAL) を使用して作成したストリーミング接続を介して転送するデータ量の間違った指定、Vivado 高位合成 (HLS) ツールにおける合成可能な関数へのストリーミングインターフェイスの指定、またはストリーミングハードウェアインターフェイスを含むビルド済みライブラリの C 呼び出し可能なハードウェア関数が原因で発生するランタイムエラーです。プログラムは、ストリームのコンシューマーがプロデューサーから送信されるデータを待機しているときに、プロデューサーがデータの送信を停止するとハングします。ハードウェア関数からのストリーミング入力および出力となる次のようなコードがあるとします。#pragma SDS data access_pattern(in_a:SEQENTIAL, out_b:SEQUENTIAL)void f1(int in_a[20], int out_b[20]); // declarationvoid f1(int in_a[20], int out_b[20]) { // definition int i; for (i=0; i < 19; i++) { out_b[i] = in_a[i]; }}

In_a[] には 20 個の要素がありますが、ループでは 19 個しか読み出されません。f1 への呼び出しは、f1 が最後の要素を消費するまで無期限に待機することになるので、ハングしているように見えます。プログラムのハングの原因となるプログラムエラーは、システムエミュレーションを使用して関連するプロトコル信号 TREADY、TLAST、ap_ready、ap_done などを監視し、データ信号がスタティックであるかどうかを確認すると検出できます。または、非順次アクセスや関数内の間違ったアクセスカウントなどのストリーミングアクセスエラーがフラグされるようコードをインストルメント化してもプログラムのハングの原因となるプログラムエラーを検出できます。ストリーミングアクセスの問題は、通常ログファイルに警告 (improper streaming access) として示され、これらが実際にエラーであるかをユーザーが確認できます。SDSoC エミュレーターでアプリケーションを実行することは、デバッガーを使用してデータ転送を可視化するのに良い方法です。システムがソフトウェアのどこでハングしているか (ほとんどの場合 cf_wait() 呼び出し内) がわかるので、シミュレーション波形ビューで関連するデータ転送を、関連するハードウェアブロックの信号を表示することにより調べることができます。

システムハングのデバッグ例別の例として、ハードウェア関数からのストリーミング入力および出力となる次のようなコードがあるとします。#pragma SDS data access_pattern(in:SEQUENTIAL, out:SEQUENTIAL)#pragma SDS data copy(in[0:large], out[0:small])void too_large_copy(int* in, int* out, int small, int large){ for(int i = 0; i < small; i++) {out[i] = in[i];}}

int main(){

第 3 章: デバッグ手法




int* temp_var1 = new int[1024 * 1024]; int* temp_var2 = new int[1024 * 1024]; too_large_copy(temp_var1, temp_var2, 1024, 1024 * 1024); //hangs because the input DMA continues to try to feed data to a halted HLS core}

この場合、ダイレクトメモリアクセス (DMA) はデータを継続してハードウェア関数に送信しようとしますが、ハードウェア関数は既に終了しており、データを受信しません。これにより、システムがハングします。1. このような問題をデバッグするには、ベースプラットフォーム上にエミュレーション用のコードをビルドしま

す。アプリケーションをコンパイルしたら、[Xilinx] → [Start/Stop Emulator] をクリックしてエミュレーターを起動します。または、次の図に示すように [Assistant] ビューからエミュレーターを起動することもできます。アプリケーションのアクティブなビルドコンフィギュレーションを右クリックし、[Start/Stop Emulator] をクリックします。

2. [Emulation] ダイアログボックスで、[Show Waveform (Programmable Logic only)] チェックボックスをオンにします。これにより Vivado シミュレータが起動し、異なるインターフェイスのステートが波形ウィンドウに表示されます。ハードウェア関数のインターフェイスを監視するには、関数を右クリックして [Add to Wave window] をクリックします。これにより選択した関数のすべての I/O ポートが波形ウィンドウに追加されます。

3. シミュレータを開始するには、ツールバーの [Run All] をクリックします。4. SDx 統合設計環境 (IDE) に戻り、デバッガーでアプリケーションを起動します。これには、デバッグするアプリ

ケーションを選択して右クリックし、[Launch on Emulator (SDx Application Debugger)] をクリックします。

[Confirm Perspective Switch] ダイアログボックスで [Yes] をクリックします。[Debug] パースペクティブが開き、ハードウェアでアプリケーションが実行されている状態になります。コードの実行は main プログラム入力で停止します。

5. ツールバーの [Resume] ボタンをクリックしてアプリケーションを実行します。





アプリケーションが停滞します。つまり、システムハングが発生します。

6. システムハングの原因を調べるには、Vivado Design Suite に戻ります。関数の ap_done、ap_start、ap_idle、および ap_ready 信号のステートを確認します。インスタンスでトランザクションが開始すると ap_start 信号が High になり、トランザクションが終了すると ap_done 信号が Low になります。ap_ready およびap_idle 信号は、関数のレディーおよびアイドル状態を示します。





同じ時点での DMA のステートを解析すると、ハードウェア関数がデータの受信を終了したのに、M00_AXIS_tready および M00_AXIS_tvalid に示されるように、DMA はまだ書き込みを実行しています。





これでシステムハングの原因がわかったので、ハードウェア関数のコードに戻って問題を修正します。

システムハングの原因システムのハングは、ほかにも次のような状況で発生します。1. Ctrl + C キーを押してアプリケーションから抜け出せる場合は、アクセラレータから十分な情報がないことが考え

られます。Arm® プロセッサにアクセラレータが送信しているよりも多くのデータが必要です。プロデューサーからコンシューマーまでに複数のパスがある場合は、レイテンシを確認します。デザインに 2 つのアクセラレータ間のレイテンシが同じ複数のパスがある場合 (A → B ... → Z と直接の A → Z があるなど) は、分岐が均等になるように、デザインレベルで修正する必要があります。

2. Ctrl + C キーが機能しないがボードに ping または ssh を発行できる場合は、スキャッターギャザー DMA(SGDMA) 操作に十分なデータがありません。データムーバー (copy または zero-copy) とアクセスパターンを確認してください。

3. ボードに ping を発行できず、ハードロックアップ状態で電源を切って入れ直さないとその状態を抜け出せない場合は、次のものの間のデータ転送が問題であるのが一般的です。a. SDSoC 環境デザインとプラットフォーム上の IP。ChipScope を使用して peeking および poking レジスタを

デバッグします (ChipScope を使用した SDSoC でのハードウェアデバッグおよび IP レジスタの監視および変更を参照)。





b. SDSoC 環境デザインと C 呼び出し可能な IP ライブラリ。ChipScope を使用して peeking および poking レジスタをデバッグします (ChipScope を使用した SDSoC でのハードウェアデバッグおよび IP レジスタの監視および変更を参照)。

c. SDSoC フローで生成された RTL またはソフトウェアドライバー。Vivado Design Suite または C ドライバーの使用に慣れている場合は、デバッグできると思われますザイリンクスが、そうでない場合はザイリンクスフォーラムを活用してください。

ランタイムエラーの原因次に、ランタイムエラーのその他の原因を示します。• wait() 文を不適切に配置すると、次の問題が発生することがあります。

○ ハードウェアアクセラレータで正しい値が書き込まれる前にソフトウェアが無効なデータを読み出す。○ 関連するアクセラレータよりも前にブロッキング wait() が呼び出されて、システムがハングする。

• メモリに一貫性を持たせる SDS data mem_attribute プラグマの使用に一貫性がないと、結果が正しくなくなることがある。

予期しないデータ値アプリケーションの実行中、予期しないデータが受信されることがあります。ハードウェア関数で予測されるデータが返されないか、予測されるデータが間違った時間に返されている可能性があります。この問題の原因は、ハードウェアまたはソフトウェアの問題のどちらである可能性もあります。ハードウェアが原因であると考えられる場合は、必要に応じて ChipScope を使用してボードへのデータ入力を確認します。ソフトウェアが原因であると考えられる場合は、次の手順を実行します。1. ソフトウェアデバッグに戻ってソフトウェアに問題がないことを確認します。2. ソフトウェアデバッグで問題がない場合は、コードを目で確認します。予期しないデータが受信される場合、

#SDS data または #SDS zero copy プラグマの使用が一般的な原因です。3. #SDS data プラグマを使用している場合は、ユーザーが書き込む内容がツールで信頼されるので、コードのデ

ータアクセスパターンがプラグマで指定されているデータアクセスパターンに一致していることを確認します。

4. #SDS zero copy のサイズが適切でない (通常は大きすぎる) と、キャッシュから無効なデータが読み出されることがあります。これはハードウェアで検出されます。ソフトウェアにはキャッシュコントローラーがないので、エミュレーションでは通常検出されません。

IP レジスタの監視および変更ザイリンクスシステムデバッガーツール (XSDB) は、プラットフォームに含まれる IP ブロックやさまざまな C 呼び出し可能な IP を理解するのに便利なツールです。ザイリンクスソフトウェアコマンドラインツール (XCST) のコンソールから、統合デザインのさまざまな IP ブロック内のレジスタを読み出しおよび書き込みできます。レジスタを読み出すには、メモリ読み出しコマンド mrd を使用します。デザインの IP の書き込み可能なレジスタに書き込むには、XSCT コンソールで mwr コマンドを使用します。コマンドのヘルプを表示するには、「<command> -help」と入力します。



https://forums.xilinx.com

https://forums.xilinx.com



デザインの IP ブロックのレジスタに対して読み出しおよび書き込みを実行するには、レジスタのメモリマップを理解しておく必要があります。この情報は、Vivado プロジェクトを開いて [Address Editor] ウィンドウを確認します。Vivado プロジェクトは、<project_name>/<Debug or Release>/_sds/p0/vivado/prj/prj.xpr にあります。prj.xpr をダブルクリックすると Vivado でプロジェクトが開きます。Vivado IDE で、Flow Navigator の [IPIntegrator] → [Open Block Design] をクリックします。[Address Editor] ウィンドウをクリックしてメモリマップ情報を表示します。

XSDB の詳細は、SDK ヘルプ (UG782) を参照してください。注意: マップされていないアドレスにアクセスしようとすると、バスエラーが発生します。アドレスがマップされていても適切な補足がない場合は、システムがハングします。

イベントトレースこのセクションでは、トレースの収集方法と SDSoC 環境での表示方法について説明します。

ランタイムトレースの収集ソフトウェアトレースは、ハードウェアトレースと同じストレージパスに挿入され、タイムスタンプにはハードウェアトレースと同じタイマー/カウンターが使用されます。この 1 つのトレースデータストリームはハードウェアシステム内のバッファーに格納され、ホスト PC から JTAG を介してアクセスされます。SDSoC 環境では、トレースはプログラムの実行中継続して読み出され、ハードウェアバッファーをできるだけすぐに空にしてバッファーがオーバーフローしないようにします。ただし、トレースデータはアプリケーションが終了したときにのみ表示されます。トレースデータは、ハードウェア上で実行中にリアルタイムで収集されます。ハードウェアへの接続については、ハードウェアへの接続を参照してください。



https://japan.xilinx.com/html_docs/xilinx2018_3/SDK_Doc/index.html



トレースの可視化SDSoC 環境には、ハードウェアおよびソフトウェアトレースストリームがグラフィカルに表示されます。ユーザーアプリケーションの各トレースポイントに固有の名前が指定され、タイムラインの軸が示されます。コードの同じブロックがループで実行されたり、アクセラレータが複数回起動される場合など、アプリケーションの実行中にトレースポイントは通常複数のトレースイベントを作成できます。

図 12: さまざまなイベントタイプを示すトレースのタイムライン表示例

X22041-112718

トレースイベントには、名前、タイプ、開始時間、終了時間、期間などの属性があります。このデータは、カーソルをビュー内のイベントの 1 つの上に置くとツールヒントとして表示されます。

図 13: 各イベントの詳細な情報を示すトレースのタイムライン表示例

X22041-112718





図 14: イベント名とユーザープログラムとの関係を示すトレースのタイムライン表示例

X22040-112718

トラブルシューティングこのセクションでは、イベントのトレース時に発生するさまざまな状況をトラブルシューティングするのに役立つ一般情報を示します。• インクリメンタルビルドフロー: SDSoC 環境ではトレース機能を使用したインクリメンタルビルドフローはサポ

ートされていません。アプリケーションが正しくビルドされ、トレースが正しく収集されるようにするには、まずプロジェクトをクリーンアップして、ソースコードを変更した後ビルドします。ソースコードの変更がハードウェア用にマークされた関数には関係ない場合や影響のない場合でも、正しい結果にならないことがあります。

• プログラムおよびビットストリーム: トレース機能は、1 回完結型の解析です。イベントのタイムスタンプに使用されたタイマーは、最初のイベントが発生するまで開始せず、その後恒久的に実行されます。ビットストリームをプログラムした後にソフトウェアアプリケーションを 1 回実行すると、プログラムの実行が終了した後にタイマーが不明な状態になります。ソフトウェアを 2 回目に実行すると、イベントのタイムスタンプが間違ったものになります。まずビットストリームをプログラムしてから、アプリケーションを実行するたびにソフトウェアアプリケーションをダウンロードして、トレース機能を利用できるようにしてください。アプリケーションは 2 回目も正しく実行はされますが、トレースデータは正しくありません。Linux では、ビットストリームが U-Boot によるブート時に読み込まれるので、再起動する必要があります。

• トレースのバッファリング: SDSoC 環境では、アプリケーションの実行中にトレースがバッファーに格納され、リアルタイムで読み出されますが (デバイス上で作成されるよりは低速)、アプリケーションが終了するまでは表示されません。そのため、ホスト PC でトレースを読み出すことができるようになるまでトレースを格納するのに十分なバッファー容量が必要です。デフォルトでは、1024 個のトレースを保存するのに十分なバッファー容量があります。バッファーがフルになると、その後生成されるトレースは破棄されて失われます。バッファーがオーバーフローする場合のエラー条件が設定されています。バッファーのオーバーフロー後に作成されたトレースは収集されず、オーバーフロー直前のトレースの表示されることがあります。

• エラー: SDSoC 環境では、トレースがハードウェアのバッファーに格納されてから、ホスト PC から JTAG を介して読み出されます。トレースが消費されるよりも速く生成される場合は、バッファーオーバーフローイベントが発生する可能性があります。トレース構造によりこれが認識され、エラーフラグが設定されて、ホスト PC での収集中に検出されます。トレースデータの収集中にエラーフラグが検出されると、収集が停止し、正しく読み出されたトレースデータが表示用に準備されますが、バッファーオーバーフローが発生する直前に正しく読み出されたデータが、正しく表示されないことがあります。





オーバーフローが発生すると、<build_config>/_sds/trace ディレクトリにarchive_DAY_MON_DD_HH_MM_SS_-GMT_YEAR_ERROR という名前のエラーファイルが作成されます。アプリケーションを実行してトレースデータを再収集する前に、デバイスをプログラムし直す (Linux を再起動するなど) 必要があります。デザインのトレースハードウェアをリセットするには、プログラムし直すしかありません。

ソフトウェア/ハードウェアのクロスプローブのデバッグSDx 環境アプリケーションを作成し、関数をハードウェアアクセラレーション用にマークしたら、適切な設定でデザインをビルドし、ターゲットボードに接続する必要があります (ハードウェアへの接続を参照)。

デバッグコンフィギュレーションの設定1. [Project Explorer] ビューで Debug フォルダーの ELF (.elf) ファイルを選択します。2. ツールバーで [Debug] をクリックするか、[Debug] のプルダウンリストから [Debug As] → [Launch on Hardware

(SDx Application Debugger)] をクリックします。3. または、プロジェクトを右クリックし、[Debug As] → [Launch on Hardware (SDx Application Debugger)] をクリッ

クします。[Confirm Perspective Switch] ダイアログボックスが表示されます。4. プロジェクトをデバッグする前にボードのスイッチがオンになっていることを確認します。[Yes] をクリックし

て [Debug] パースペクティブに切り替えます。これで、SDx IDE が [Debug] パースペクティブになりました。注記: デバッガーによりシステムがリセットされ、デバイスがプログラムおよび初期化され、main 関数で停止します。ソースコードが中央のパネルに表示され、ローカル変数は右上のパネルに表示されます。右下の SDx 環境ログには、デバッグコンフィギュレーションログが表示されます。

アプリケーションを実行する前に、シリアルターミナルをボードに接続して、プログラムからの出力が表示されるようにします。たとえば、次の設定を使用できます。• [Connection Type]: Serial

• [Port]: COM<n>

• [Baud Rate]: 115200

アプリケーションの実行[Resume] をクリックしてアプリケーションを実行し、出力をターミナルウィンドウで確認します。ソースコードウィンドウに _exit 関数が表示され、[Terminal] タブにアプリケーションからの出力が表示されます。





図 15: [Debug] パースペクティブ

コードの実行が main 関数で停止します。コードの特定の位置にブレークポイントを追加して、その位置でコードの実行を停止できます。コードの行番号の横にある青色のバーをダブルクリックすると、ブレークポイントのイネーブル/ディスエーブルを切り替えることができます。コードの実行を再開するには、ツールバーの [Resume] ボタンをクリックします。

パフォーマンスのデバッグに関するヒントSDSoC 環境では、次の関数を使用して基本的なパフォーマンス監視機能が提供されています。• sds_clock_counter(): アクセラレーションされるコードとされないコードなど、コードセクション間の実行

時間の差を調べるのに使用します。• sds_clock_frequency(): 1 秒ごとの CPU サイクル数を返します。Vivado Design Suite 高位合成 (HLS) ツールのレポートファイル (_sds/vhls/…/*.rpt または IDE の [Reports] →[HLS Report]) のレイテンシ値を見ると、実際のハードウェアアクセラレーション時間を見積もることができます。アクセラレータクロックサイクルのレイテンシは、X * (processor_clock_freq/accelerator_clock_freq)processor clock cycles と等しくなります。実際の関数呼び出しにかかる時間とこの時間を比較すると、設定およびデータ転送のオーバーヘッドがわかります。パフォーマンスを最大限に向上するには、アクセラレーションされる関数の実行に必要な時間が元のソフトウェア関数の実行に必要な時間よりも大幅に短縮されることが必要です。そうならない場合は、sds++ コマンドラインで別のclkid を選択して、アクセラレータをより高速の周波数で実行してみてください。この方法で改善が見られない場合は、データ転送のオーバーヘッドがアクセラレーションされる関数の実行時間に影響していないかを確認し、このオーバーヘッドを減らす必要があります。デフォルトの clkid はすべてのプラットフォームで 100 MHz です。特定のプラットフォームの clkid 値の詳細は、-sds-pf-info <path>/<platform_name> を実行すると取得できます。データ転送のオーバーヘッドが大きい場合は、次を変更すると改善される可能性があります。





• 計算時間が増加するようにアクセラレーションされる関数に移動するコードを増やし、計算時間とデータ転送にかかる時間の比率を向上させます。

• コードを変更するかプラグマを使用して必要なデータのみを転送するようにし、転送するデータ量を減らします。• 無関係のランダムアクセスを連続して実行するよりも、バースト転送の方が効率的なので、アクセラレータコー

ドの視点からアクセスパターンを順次化します。• データ転送に転送されるデータのキャッシュ可能性に適したシステムポートが使用されるようにします。キャッ

シュフラッシュにはリソースが多く使用されるので、コヒーレントデータにアクセスするのにコヒーレントポート、非コヒーレントポートにアクセスするのに非コヒーレントポートを使用すると、結果が大きく改善します。可能であれば、malloc の代わりに、sds_alloc() を使用します。sds_alloc() によるメモリは物理的に隣接しており、コンフィギュレーションが高速で物理的に隣接したメモリを必要とするデータムーバーを使用できるようになります。また、malloc() データによるデータ転送に必要な仮想ページをピン留めにもかなりのコストがかかります。

コンパイル時およびリンク時のエラーのトラブルシューティング通常、コンパイル/リンク時のエラーは、make を実行したときにエラーメッセージとして示されます。さらに解析するには、SDSoC 環境で作成されたビルドディレクトリの _sds/reports サブディレクトリからログファイルと rptファイルを確認します。最後に生成されたログファイルには、該当する入力ファイルの構文エラーや、アクセラレータハードウェアまたはデータモーションネットワークの合成中にツールチェーンで生成されたエラーなど、エラーの原因が示されます。次に、SDSoC 環境に特定のエラーを解決するためのヒントおよびストラテジを示します。

SDSoC 開発チェーンのツールでレポートされたツールエラー次のトラブルシューティング手順を実行してみます。• 該当するコードが『SDSoC 環境プログラマガイド』 (UG1278) のコードガイドラインに従っているかどうかを確

認します。• プラグマの構文を確認します。詳細は、『SDx プラグマリファレンスガイド』 (UG1253) を参照してください。• プラグマにスペルミスがないかどうか確認します。これが原因で正しく適用されていない可能性があります。Vivado Design Suite 高位合成 (HLS) でタイミング要件を満たすことができない次のトラブルシューティング手順を実行してみます。• SDSoC IDE (または sdscc/sds++ コマンドラインパラメーター) でアクセラレータに対して低速のクロック周波

数を選択します。• HLS で高速のインプリメンテーションを生成できるようにコード構造を変更します。詳細は、『SDSoC 環境プロフ

ァイリングおよび最適化ガイド』 (UG1235) の「ハードウェア関数の並列処理の向上」を参照してください。Vivado ツールでタイミングを満たすことができない次のトラブルシューティング手順を実行してみます。



https://japan.xilinx.com/cgi-bin/docs/rdoc?v=2018.3;d=ug1278-sdsoc-programmers-guide.pdf

https://japan.xilinx.com/cgi-bin/docs/rdoc?v=2018.3;d=ug1253-sdx-pragma-reference.pdf




• SDSoC IDE でデータモーションネットワークまたはアクセラレータ (あるいはその両方) に対してより低速のクロック周波数を選択します (コマンドラインからの場合は sdscc/sds++ コマンドラインパラメーターを使用)。

• -xp オプションを使用して Vivado インプリメンテーションストラテジを適用し、結果を向上します。次に例を示します。-impl-strategy Performance_Explore

• ユーザーが HLS ブロックをより高速なクロック周波数に合成して合成/インプリメンテーションツールに余裕を持たせられるようにする例/リソースを提供ます。

• HLS に渡される C/C++ コードを変更するか、HLS 指示子を追加して、HLS ブロックが高速になるようにします。• リソース使用率が 80% を超えている場合に、デザインのサイズを削減します。_sds フォルダーの Vivado ツール

レポートを参照してください。デザインが大きすぎてフィットしない次のトラブルシューティング手順を実行してみます。• アクセラレーションする関数の数を減らします。• アクセラレータ関数のコーディングスタイルを、よりコンパクトなアクセラレータが生成されるように変更しま

す。並列処理の量を減らすには、『SDSoC 環境プロファイリングおよび最適化ガイド』 (UG1235) の「ハードウェア関数の並列処理の向上」を参照してください。

• アクセラレータの複数のインスタンスが作成される原因となっているプラグマとコーディングスタイル (パイプライン処理) を変更します。

• プラグマを使用して AXIDMA_SG の代わりに AXIFIFO のようなより小型のデータムーバーを選択します。• 入力および出力パラメーター/引数の数が少なくなるようハードウェア関数を記述し直します (特に、入力/出力が

データムーバーハードウェアを共有できない連続ストリーム (シーケンシャルアクセス配列引数) タイプの場合)。

パフォーマンス問題のトラブルシューティングSDSoC 環境では、sds_clock_counter() 関数により基本的なパフォーマンス監視機能が提供されています。この関数を使用すると、アクセラレーションされるコードとされないコードなど、コードセクション間における実行時間の差異を調べることができます。実際のハードウェアアクセラレーション時間を見積もるには、Vivado HLS レポートのレイテンシ値、アクセラレータのクロック周波数、および Arm CPU のクロック周波数が必要です。レイテンシ値を確認するために Vivado HLS レポートを開くには、[Assistant] ビューで [<Project Name>] → [<Build Configuration>] → [<Accelerator Name>] → [HLSreport] をクリックします。アクセラレータのクロック周波数を確認するには、[Project Settings] の [HardwareFunctions] セクションを見ます。[Project Settings] の [Platform] リンクをクリックし、[Platform Summary] ダイアログボックスを開きます。CPU の周波数は [Clock Frequencies] の下に表示されます。X アクセラレータクロックサイクルのレイテンシは、X * (<プロセッサのクロック周波数>/<アクセラレータのクロック周波数>) プロセッサクロックサイクルです。実際の関数呼び出しにかかる時間とこの時間を比較すると、データ転送のオーバーヘッドを確認できます。パフォーマンスを最大限に向上するには、アクセラレーションされる関数の実行に必要な時間が元のソフトウェア関数の実行に必要な時間よりも大幅に短縮されることが必要です。そうならない場合は、sdscc/sds++ コマンドラインで別の clkid を選択して、アクセラレータをより高速の周波数で実行してみてください。この方法で改善が見られない場合は、データ転送のオーバーヘッドがアクセラレーションされる関数の実行時間に影響していないかを確認し、このオーバーヘッドを減らす必要があります。






注記: 特定のプラットフォームの clkid 値の詳細は、次のコマンドを実行すると取得できます。sds++ -sds-pf-info

データ転送のオーバーヘッドが大きい場合は、次を変更すると改善される可能性があります。• 計算時間が増加するようにアクセラレーションされる関数に移動するコードを増やし、計算時間とデータ転送に

かかる時間の比率を向上させます。• コードを変更するかプラグマを使用して必要なデータのみを転送するようにし、転送するデータ量を減らします。





付録 A

SDSoC 環境でのトラブルシューティングSDSoC™ 環境を使用する際に発生する一般的な問題は、次のとおりです。• コンパイル/リンク時のエラーは、ソフトウェアコンパイラで検出される典型的なソフトウェア構文エラー、また

はデザインがターゲットプラットフォームには大きすぎるなどの SDSoC 環境フロー特有のエラーが原因で発生します。

• ランタイムエラーは、ヌルポインターアクセスなどの一般的なソフトウェアの問題、またはアクセラレータとの誤データ転送などの SDSoC 環境特有の問題が原因で発生します。

• アクセラレーションに使用したアルゴリズムの選択、アクセラレータとのデータの送受信にかかる時間、およびアクセラレータとデータモーションネットワークの実動作速度などが原因で、パフォーマンスの問題が発生する可能性があります。

• プログラムの動作の問題の原因は、アルゴリズムの目的をインプリメントできないコードの論理的なエラーである可能性があります。

付録 A: SDSoC 環境でのトラブルシューティング




付録 B

その他のリソースおよび法的通知

Documentation Navigator およびデザインハブザイリンクス Documentation Navigator (DocNav) では、ザイリンクスの資料、ビデオ、サポートリソースにアクセスでき、特定の情報を取得するためにフィルター機能や検索機能を利用できます。DocNav を開くには、次のいずれかを実行します。• Vivado® IDE で [Help] → [Documentation and Tutorials] をクリックします。• Windows で [スタート] → [すべてのプログラム] → [Xilinx Design Tools] → [DocNav] をクリックします。• Linux コマンドプロンプトに「docnav」と入力します。ザイリンクスデザインハブには、資料やビデオへのリンクがデザインタスクおよびトピックごとにまとめられており、これらを参照することでキーコンセプトを学び、よくある質問 (FAQ) を参考に問題を解決できます。デザインハブにアクセスするには、次のいずれかを実行します。• DocNav で [Design Hub View] タブをクリックします。• ザイリンクスウェブサイトでデザインハブページを参照します。注記: DocNav の詳細は、ザイリンクスウェブサイトの Documentation Navigator ページを参照してください。注意: DocNav からは、日本語版は参照できません。ウェブサイトのデザインハブページをご利用ください。

参考資料このガイドの補足情報は、次の資料を参照してください。日本語版のバージョンは、英語版より古い場合があります。1. 『SDSoC 環境リリースノート、インストール、およびライセンスガイド』 (UG1294)

2. 『SDSoC 環境ユーザーガイド』 (UG1027)

3. 『SDSoC 環境チュートリアル: 概要』 (UG1028: 英語版、日本語版)

4. 『SDSoC 環境チュートリアル: プラットフォームの作成』 (UG1236: 英語版、日本語版)

5. 『SDSoC 環境プラットフォーム開発ガイド』 (UG1146)

6. 『SDSoC 環境プロファイリングおよび最適化ガイド』 (UG1235)


https://japan.xilinx.com/cgi-bin/docs/ndoc?t=design+hubs

https://japan.xilinx.com/cgi-bin/docs/rdoc?t=docnav

https://japan.xilinx.com/cgi-bin/docs/rdoc?v=2018.3;d=ug1294-sdsoc-rnil.pdf

https://japan.xilinx.com/cgi-bin/docs/rdoc?v=2018.3;d=ug1027-sdsoc-user-guide.pdf

https://github.com/Xilinx/SDSoC-Tutorials/tree/master/getting-started-tutorial

https://github.com/Xilinx/SDSoC-Tutorials/tree/Japanese-master/getting-started-tutorial

https://github.com/Xilinx/SDSoC-Tutorials/tree/master/platform-creation-tutorial

https://github.com/Xilinx/SDSoC-Tutorials/tree/Japanese-master/platform-creation-tutorial





7. 『SDx コマンドおよびユーティリティリファレンスガイド』 (UG1279)

8. 『SDSoC 環境プログラマガイド』 (UG1278)

9. 『SDSoC 環境デバッグガイド』 (UG1282)

10. 『SDx プラグマリファレンスガイド』 (UG1253)

11. 『UltraFast エンベデッドデザイン設計手法ガイド』 (UG1046: 英語版、日本語版)

12. 『Zynq-7000 SoC ソフトウェア開発者向けガイド』 (UG821: 英語版、日本語版)

13. 『Zynq UltraScale+ MPSoC: ソフトウェア開発者向けガイド』 (UG1137: 英語版、日本語版)

14. 『Zynq-7000 XC7Z020 SoC 用 ZC702 評価ボードユーザーガイド』 (UG850)

15. 『ZCU102 評価ボードユーザーガイド』 (UG1182)

16. 『PetaLinux ツール資料: リファレンスガイド』 (UG1144)

17. 『Vivado Design Suite ユーザーガイド: 高位合成』 (UG902)

18. 『Vivado Design Suite ユーザーガイド: カスタム IP の作成とパッケージ』 (UG1118)

19. SDSoC 開発環境ウェブページ20. Vivado® Design Suite 資料

トレーニングリソース1. トレーニングコース: SDSoC 開発環境および設計手法2. トレーニングコース: アドバンス SDSoC 開発環境および設計手法

お読みください: 重要な法的通知本通知に基づいて貴殿または貴社 (本通知の被通知者が個人の場合には「貴殿」、法人その他の団体の場合には「貴社」。以下同じ) に開示される情報 (以下「本情報」といいます) は、ザイリンクスの製品を選択および使用することのためにのみ提供されます。適用される法律が許容する最大限の範囲で、(1) 本情報は「現状有姿」、およびすべて受領者の責任で (with all faults) という状態で提供され、ザイリンクスは、本通知をもって、明示、黙示、法定を問わず (商品性、非侵害、特定目的適合性の保証を含みますがこれらに限られません)、すべての保証および条件を負わない (否認する)ものとします。また、(2) ザイリンクスは、本情報 (貴殿または貴社による本情報の使用を含む) に関係し、起因し、関連する、いかなる種類・性質の損失または損害についても、責任を負わない (契約上、不法行為上 (過失の場合を含む)、その他のいかなる責任の法理によるかを問わない) ものとし、当該損失または損害には、直接、間接、特別、付随的、結果的な損失または損害 (第三者が起こした行為の結果被った、データ、利益、業務上の信用の損失、その他あらゆる種類の損失や損害を含みます) が含まれるものとし、それは、たとえ当該損害や損失が合理的に予見可能であったり、ザイリンクスがそれらの可能性について助言を受けていた場合であったとしても同様です。ザイリンクスは、本情報に含まれるいかなる誤りも訂正する義務を負わず、本情報または製品仕様のアップデートを貴殿または貴社に知らせる義務も負いません。事前の書面による同意のない限り、貴殿または貴社は本情報を再生産、変更、頒布、または公に展示してはなりません。一定の製品は、ザイリンクスの限定的保証の諸条件に従うこととなるので、https://japan.xilinx.com/legal.htm#tos で見られるザイリンクスの販売条件を参照してください。IP コアは、ザイリンクスが貴

付録 B: その他のリソースおよび法的通知


https://japan.xilinx.com/cgi-bin/docs/rdoc?v=2018.3;d=ug1279-sdx-command-utility-reference-guide.pdf

https://japan.xilinx.com/cgi-bin/docs/rdoc?v=2018.3;d=ug1278-sdsoc-programmers-guide.pdf

https://japan.xilinx.com/cgi-bin/docs/rdoc?v=2018.3;d=ug1282-sdsoc-debugging-guide.pdf

https://japan.xilinx.com/cgi-bin/docs/rdoc?v=2018.3;d=ug1253-sdx-pragma-reference.pdf

https://japan.xilinx.com/cgi-bin/docs/rdoc?d=ug1046-ultrafast-design-methodology-guide.pdf

https://japan.xilinx.com/cgi-bin/docs/rdoc?d=j_ug1046-ultrafast-design-methodology-guide.pdf

https://japan.xilinx.com/cgi-bin/docs/ndoc?t=user_guides;d=ug821-zynq-7000-swdev.pdf

https://japan.xilinx.com/cgi-bin/docs/ndoc?t=user_guides;d=ug821-zynq-7000-swdev.pdf

https://japan.xilinx.com/cgi-bin/docs/ndoc?t=user_guides;d=ug1137-zynq-ultrascale-mpsoc-swdev.pdf

https://japan.xilinx.com/cgi-bin/docs/ndoc?t=user_guides;d=j_ug1137-zynq-ultrascale-mpsoc-swdev.pdf

https://japan.xilinx.com/support/documentation/boards_and_kits/zc702_zvik/ug850-zc702-eval-bd.pdf

https://japan.xilinx.com/cgi-bin/docs/bkdoc?k=zcu102;d=ug1182-zcu102-eval-bd.pdf

https://japan.xilinx.com/cgi-bin/docs/rdoc?v=2018.3;d=ug1144-petalinux-tools-reference-guide.pdf

https://japan.xilinx.com/cgi-bin/docs/rdoc?v=2018.3;d=ug902-vivado-high-level-synthesis.pdf

https://japan.xilinx.com/cgi-bin/docs/rdoc?v=2018.3;d=ug1118-vivado-creating-packaging-custom-ip.pdf

https://japan.xilinx.com/products/design-tools/software-zone/sdsoc.html

https://japan.xilinx.com/cgi-bin/docs/rdoc?t=vivado+docs

https://japan.xilinx.com/training/courses/sdsoc-development-environment-method.html

https://japan.xilinx.com/training/courses/advanced-sdsoc-development-environment-methodology.html

https://japan.xilinx.com/legal.htm#tos




殿または貴社に付与したライセンスに含まれる保証と補助的条件に従うことになります。ザイリンクスの製品は、フェイルセーフとして、または、フェイルセーフの動作を要求するアプリケーションに使用するために、設計されたり意図されたりしていません。そのような重大なアプリケーションにザイリンクスの製品を使用する場合のリスクと責任は、貴殿または貴社が単独で負うものです。https://japan.xilinx.com/legal.htm#tos で見られるザイリンクスの販売条件を参照してください。

自動車用のアプリケーションの免責条項オートモーティブ製品 (製品番号に「XA」が含まれる) は、ISO 26262 自動車用機能安全規格に従った安全コンセプトまたは余剰性の機能 (「セーフティ設計」) がない限り、エアバッグの展開における使用または車両の制御に影響するアプリケーション (「セーフティアプリケーション」) における使用は保証されていません。顧客は、製品を組み込むすべてのシステムについて、その使用前または提供前に安全を目的として十分なテストを行うものとします。セーフティ設計なしにセーフティアプリケーションで製品を使用するリスクはすべて顧客が負い、製品の責任の制限を規定する適用法令および規則にのみ従うものとします。

著作権情報© Copyright 2018-2019 Xilinx, Inc. Xilinx、Xilinx のロゴ、Alveo、Artix、ISE、Kintex、Spartan、Versal、Virtex、Vivado、Zynq、およびこの文書に含まれるその他の指定されたブランドは、米国およびその他各国のザイリンクス社の商標です。OpenCL および OpenCL のロゴは Apple Inc. の商標であり、Khronos による許可を受けて使用されています。 HDMI、HDMI のロゴ、および High-Definition Multimedia Interface は、HDMI Licensing LLC の商標です。AMBA、AMBA Designer、Arm、ARM1176JZ-S、CoreSight、Cortex、PrimeCell、Mali、および MPCore は、EU およびその他各国の Arm Limited 社の商標です。すべてのその他の商標は、それぞれの保有者に帰属します。

この資料に関するフィードバックおよびリンクなどの問題につきましては、[email protected] まで、または各ページの右下にある [フィードバック送信] ボタンをクリックすると表示されるフォームからお知らせください。フィードバックは日本語で入力可能です。いただきましたご意見を参考に早急に対応させていただきます。なお、このメールアドレスへのお問い合わせは受け付けておりません。あらかじめご了承ください。

付録 B: その他のリソースおよび法的通知



mailto:[email protected]



Documents

SDSoC 環境デバッグ ガイド · トストリームを含む完全なハードウェア システムを生成します。すべてのハードウェア関数呼び出しで元の動作が保

SDSoC 環境デバッグガイド · トストリームを含む完全なハードウェアシステムを生成します。すべてのハードウェア関数呼び出しで元の動作が保