デバッグ手法

この章では、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 環境デバッグ ガイド を参照してください。

システムの停止とランタイム エラーのデバッグ

sds++ を使用してコンパイルされたプログラムは、SDx 環境または Vivado 環境で提供される標準デバッガーを使用してデバッグできます。間違った結果、プログラムの早期終了、プログラムのハングなどが典型的なランタイム エラーとして挙げられます。最初の 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]);     // declaration

void 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 が最後の要素を消費するまで無期限に待機することになるので、ハングしているように見えます。プログラムのハングの原因となるプログラム エラーは、システム エミュレーションを使用して関連するプロトコル信号 TREADYTLASTap_readyap_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()
{
	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_doneap_startap_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 を発行できず、ハード ロックアップ状態で電源を切って入れ直さないとその状態を抜け出せない場合は、次のものの間のデータ転送が問題であるのが一般的です。
    1. SDSoC 環境デザインとプラットフォーム上の IP。ChipScope™ を使用して peeking および poking レジスタをデバッグします (ChipScope を使用した SDSoC でのハードウェア デバッグ および IP レジスタの監視および変更 を参照)。
    2. SDSoC 環境デザインと C 呼び出し可能な IP ライブラリ。ChipScope を使用して peeking および poking レジスタをデバッグします (ChipScope を使用した SDSoC でのハードウェア デバッグ および IP レジスタの監視および変更 を参照)。
    3. 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」と入力します。

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

XSDB の詳細は、SDK ヘルプ (UG782) を参照してください。

注意:
マップされていないアドレスにアクセスしようとすると、バス エラーが発生します。アドレスがマップされていても適切な補足がない場合は、システムがハングします。

イベント トレース

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

ランタイム トレースの収集

ソフトウェア トレースは、ハードウェア トレースと同じストレージ パスに挿入され、タイムスタンプにはハードウェア トレースと同じタイマー/カウンターが使用されます。この 1 つのトレース データ ストリームはハードウェア システム内のバッファーに格納され、ホスト PC から JTAG を介してアクセスされます。

SDSoC 環境では、トレースはプログラムの実行中継続して読み出され、ハードウェア バッファーをできるだけすぐに空にしてバッファーがオーバーフローしないようにします。ただし、トレース データはアプリケーションが終了したときにのみ表示されます。

トレース データは、ハードウェア上で実行中にリアルタイムで収集されます。ハードウェアへの接続については、ハードウェアへの接続を参照してください。

トレースの表示

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

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

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

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

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

トラブルシューティング

このセクションでは、イベントのトレース時に発生するさまざまな状況をトラブルシューティングするのに役立つ一般情報を示します。

インクリメンタル ビルド フロー
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] タブにアプリケーションからの出力が表示されます。

図: [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 環境プログラマ ガイド のコード ガイドラインに従っているかどうかを確認します。
  • プラグマの構文を確認します。詳細は、 を参照してください。
  • プラグマにスペルミスがないかどうか確認します。これが原因で正しく適用されていない可能性があります。

Vivado Design Suite 高位合成 (HLS) でタイミング要件を満たすことができない

次のトラブルシューティング手順を実行してみます。
  • SDx IDE (または sdscc/sds++ コマンド ライン パラメーター) でアクセラレータに対して低速のクロック周波数を選択します。
  • HLS で高速のインプリメンテーションを生成できるようにコード構造を変更します。詳細は、SDSoC プロファイリングおよび最適化ガイド の「ハードウェア関数の並列処理の向上」を参照してください。

Vivado ツールでタイミングを満たすことができない

次のトラブルシューティング手順を実行してみます。
  • SDx IDE でデータ モーション ネットワークまたはアクセラレータ (あるいはその両方) に対してより低速のクロック周波数を選択します (コマンド ラインからの場合は sdscc/sds++ コマンド ライン パラメーターを使用)。
  • -xp オプションを使用して Vivado インプリメンテーション ストラテジを適用し、結果を向上します。次に例を示します。
    -impl-strategy Performance_Explore
  • ユーザーが HLS ブロックをより高速なクロック周波数に合成して合成/インプリメンテーション ツールに余裕を持たせられるようにする例/リソースを提供ます。
  • HLS に渡される C/C++ コードを変更するか、HLS 指示子をさらに追加して HLS ブロックが速くなるようにします。
  • リソース使用率が 80% を超えている場合に、デザインのサイズを削減します。_sds フォルダーの Vivado ツール レポートを参照してください。

デザインが大きすぎてフィットしない

次のトラブルシューティング手順を実行してみます。
  • アクセラレーションする関数の数を減らします。
  • アクセラレータ関数のコーディング スタイルを、よりコンパクトなアクセラレータが生成されるように変更します。並列処理の量を減らすには、SDSoC プロファイリングおよび最適化ガイド の「ハードウェア関数の並列処理の向上」を参照してください。
  • アクセラレータの複数のインスタンスが作成される原因となっているプラグマとコーディング スタイル (パイプライン処理) を変更します。
  • プラグマを使用して AXIDMA_SG の代わりに AXIFIFO のようなより小型のデータ ムーバーを選択します。
  • 入力および出力パラメーター/引数の数が少なくなるようハードウェア関数を記述し直します (特に、入力/出力がデータ ムーバー ハードウェアを共有できない連続ストリーム (シーケンシャル アクセス配列引数) タイプの場合)。

パフォーマンス問題のトラブルシューティング

SDSoC 環境では、sds_clock_counter() 関数により基本的なパフォーマンス監視機能が提供されています。この関数を使用すると、アクセラレーションされるコードとされないコードなど、コード セクション間における実行時間の差異を調べることができます。

実際のハードウェア アクセラレーション時間を見積もるには、Vivado HLS レポートのレイテンシ値、アクセラレータのクロック周波数、および Arm CPU のクロック周波数が必要です。レイテンシ値を確認するために Vivado HLS レポートを開くには、[Assistant] ビューで [<Project Name>] > [<Build Configuration>] > [<Accelerator Name>] > [HLS report] をクリックします。アクセラレータのクロック周波数を確認するには、[Project Settings] の [Hardware Functions] セクションを見ます。[Project Settings] の [Platform] リンクをクリックし、[Platform Summary] ダイアログ ボックスを開きます。CPU の周波数は [Clock Frequencies] の下に表示されます。X アクセラレータ クロック サイクルのレイテンシは、X * (<プロセッサのクロック周波数>/<アクセラレータのクロック周波数>) プロセッサ クロック サイクルです。実際の関数呼び出しにかかる時間とこの時間を比較すると、データ転送のオーバーヘッドを確認できます。

パフォーマンスを最大限に向上するには、アクセラレーションされる関数の実行に必要な時間が元のソフトウェア関数の実行に必要な時間よりも大幅に短縮されることが必要です。そうならない場合は、sdscc/sds++ コマンドラインで別の clkid を選択して、アクセラレータをより高速の周波数で実行してみてください。この方法で改善が見られない場合は、データ転送のオーバーヘッドがアクセラレーションされる関数の実行時間に影響していないかを確認し、このオーバーヘッドを減らす必要があります。

注記: 特定のプラットフォームの clkid 値の詳細は、次のコマンドを実行すると取得できます。
sds++ -sds-pf-info
データ転送のオーバーヘッドが大きい場合は、次を変更すると改善される可能性があります。
  • 計算時間が増加するようにアクセラレーションされる関数に移動するコードを増やし、計算時間とデータ転送にかかる時間の比率を向上させます。
  • コードを変更するかプラグマを使用して必要なデータのみを転送するようにし、転送するデータ量を減らします。