最初の段階の目的は、デザインが機能的に正しく、ハードウェアで問題なく実行できるかどうかを判断することです。ここで結果を解析し、さらに次の段階でデバッグと解析を実行できます。
次の図に、この段階で使用可能なタスクおよび手法を示します。
この段階は、デザインおよびホスト アプリケーションがハードウェアで問題なく実行できるかどうかを判断するのに役立ちます。この段階では、ホスト アプリケーションの API を使用して、ハードウェア上で実行中のデザインをプロファイルし、デザインがスループット、レイテンシ、および帯域幅の目標を満たしているかどうかを調べることができます。さらに、デザインをハードウェアで実行したときに生成されたレポートを使用して、AI エンジンのストールとデッドロックのトラブルシューティングを実行できます。
次に、この段階で使用可能な手法を説明します。
ハードウェアでのホスト アプリケーションのエラー処理とレポート
Linux では、XRT にエラー レポート API が含まれています。これらの API をホスト アプリケーションで使用して、これらのエラーをレポートし、問題の根本的な原因を特定します。XRT のエラー レポート API の詳細は、AI エンジンのエラー レポート を参照してください。AI エンジン アレイによりレポートされたエラー メッセージを調べるには、dmesg ログをイネーブルにして確認します。AI エンジン アレイ特定のエラー処理の詳細は、AI エンジンのエラー イベント を参照してください。
次の段階: ホスト アプリケーションをさらにデバッグする必要がある場合は、段階 5 に進みます。
ハードウェアでのデザイン ストールの解析
Linux 上のハードウェアでデザインがストールした場合は、Linux 上の XRT XBUtil ユーティリティを使用して、デザイン内の AI エンジンおよび PL カーネルのステータスを調べます。ユーティリティを使用して現在のデザイン ステータスに関するレポートを生成し、Vitis IDE で結果を表示する方法の詳細は、ハードウェアでの AI エンジン ステータスの解析 を参照してください。
XSDB で手動でレポートを生成して結果を Vitis IDE で表示することもできます。詳細は、AI エンジン ステータスの生成 を参照してください。Vitis IDE で表示されるデッドロックの例は、xrz1645747295229.html#xrz1645747295229__fig_f23_n35_ctb および xrz1645747295229.html#xrz1645747295229__fig_h3j_hys_5sb を参照してください。
次の段階: デザインがストールしており、ストールの根本的な原因を特定するためにさらに詳細が必要な場合は、段階 2 に進みます。
ハードウェアでのデザイン スループット、レイテンシ、帯域幅のレポート
ホスト アプリケーションの API を使用してグラフの入力/出力をプロファイリングすることにより、AI エンジン グラフのスループット、レイテンシ、帯域幅を特定することもできます。ホストで API のプロファイリングを開始および停止するタイミングは、慎重に検討する必要があります。ホスト アプリケーションにおける API の使用方法の詳細は、グラフの入力および出力用のイベント プロファイル API を詳細してください。
次の段階: デザインのスループットまたはレイテンシが最適でない場合、デザインがパフォーマンス目標を満たしていない場合は、段階 2 に進みます。段階 2 では、パフォーマンスの低下に影響している可能性のあるカーネルまたは I/O を特定します。