合成サマリ - 2023.2 日本語

Vitis 高位合成ユーザー ガイド (UG1399)

Document ID
UG1399
Release Date
2023-12-18
Version
2023.2 日本語

合成が完了すると、Vitis HLS で最上位関数の合成レポートが生成され、情報エリアに表示されます。

Synthesis Summary ビューには、次のセクションがあります。

General Information

結果が生成された日時、使用されたツール バージョン、プロジェクト名、ソリューション名、ターゲット フロー、およびデバイスの詳細を示します。

図 1. 合成サマリ レポート

[Timing Estimate]

ソリューションで指定されたタイミングのクイック見積りを表示します (クロック周波数の指定 を参照)。これには、指定された Target クロック周期と Uncertainty (ばらつき) の周期が含まれます。クロック周期からばらつきを差し引いた値が Estimated クロック周期になります。

ヒント: これらの値は、HLS ツールの見積もりにすぎません。より正確なタイミング見積もりは、インプリメンテーションの実行 で説明されるように、Vivado 合成とインプリメンテーションを実行すると算出できます。

[Performance & Resource Estimates]

最上位関数および最上位にインスタンシエートされているサブブロックのタイミング スラック、レイテンシおよび開始間隔 (II) をレポートします。C/C++ ソースのこのレベルで呼び出される各サブ関数は、INLINE プラグマまたは指示子を使用して最上位にインライン展開するかまたは自動的にインライン展開されていなければ、生成された RTL ブロックのインスタンスになります。

Slack 列は、インプリメンテーションのタイミング問題を表示します。

2 つの Latency 列は、出力を生成するのにかかるサイクル数とレイテンシ (ns) を示します。

Iteration Latency は、ループの 1 反復のレイテンシです。

Initiation Interval 列は、新しい入力が適用されるまでのクロック サイクル数を示します。PIPELINE 指示子がない場合、レイテンシは開始間隔 (II) よりも 1 サイクル短くなります (次の入力は前の出力が書き込まれた後に読み出される)。

ヒント: レイテンシ値が ? と表示されている場合は、ループ反復回数を決定できなかったことを意味します。デザインのレイテンシまたはスループットが変数インデックスのループによって異なる場合、HLS コンパイラではそのループのレイテンシが不明とレポートされます。この場合は、LOOP_TRIPCOUNT プラグマまたは指示子を使用して、ループ反復数を手動で指定します。LOOP_TRIPCOUNT 値は、生成されたレポートに意味のあるレイテンシおよび開始間隔の範囲を表示するためだけに使用され、合成結果には影響しません。

Trip Count 列は、インプリメントされたハードウェアでのループの反復回数を示します。これは、ハードウェアでのループの展開を反映します。

リソース見積もりの列は、RTL コードにソフトウェア関数をインプリメントするのに必要なリソース数の見積もりをレポートします。BRAM、DSP、FF、および LUT の見積もり数が示されます。

ハードウェア インターフェイス

合成中に生成されたハードウェア インターフェイスの表を示します。ツールで生成されるハードウェア インターフェイスのタイプは、ソリューションで指定されたフロー ターゲットおよびコードに適用された INTERFACE プラグマまたは指示子によって決まります。次の図では、ソリューションは Vitis カーネル フローをターゲットとしているので、AXI インターフェイスが生成されます。

図 2. ハードウェア インターフェイス

これらの表は、次のようになっています。

  • インターフェイスごとに個別の表があります。
  • 表の列は、インターフェイスのプロパティを示します。M_AXI インターフェイスの表には、ポート幅の自動変更 が実行されたか、実行された場合はどの程度かを示す Data Width および Max Widen Bitwidth 列が含まれます。上の図の例では、ポート幅がソフトウェアで指定された 16 ビットから 512 ビットに拡張されています。
  • Latency 列はインターフェイスのレイテンシを示します。
    • ap_memory インターフェイスでは、この列はインターフェイスを起動する RAM リソースの読み出しレイテンシを示します。
    • m_axi インターフェイスでは、この列は AXI4 インターフェイスの見積もりレイテンシを示します。バス要求は、読み出しまたは書き込みのこのサイクル数 (レイテンシ) 前に開始できます。
  • Bundle 列は、INTERFACE プラグマまたは指示で指定されているバンドル名を示します。
  • 追加の列は、M_AXI インターフェイスのバーストおよび読み出しと書き込みのプロパティを示します (INTERFACE プラグマまたは指示子を参照)。
  • Bit Fields 列には、s_axilite インターフェイスのレジスタで使用されるビットが表示されます。

[SW I/O Information]

C/C++ ソースの関数引数と生成された RTL コードでのポート名の対応を示します。次の図に示すように、ソフトウェア ポートとハードウェア ポートの追加の詳細も示されます。1 つのソフトウェア引数が複数のハードウェア インターフェイスにマップされていることに注意してください。たとえば、input 引数は m_axi のデータと s_axi_lite の制御信号にマップされています。

図 3. [SW I/O Information]

[M_AXI Burst Information]

[M_AXI Burst Information] セクションの Burst Summary 表は、正常に実行されたバースト転送と、対応するソース コードへのリンクを示します。レポートされるバースト長は max_read_burst_length またはmax_write_burst_length で、バースト転送で読み出し/書き込みされたデータ数を示します。たとえば、入力のデータ型が整数 (32 ビット) の場合、インターフェイスの幅 512 ビットに拡張され、各バーストで 1024 個の整数が転送されます。幅が拡張されたインターフェイスは一度に 16 個の整数を転送できるので、64 ビート バーストになります。Burst Missed 表は、バースト転送が正しく実行されなかった場合に、その理由と解決に役立つガイダンス メッセージへのリンクを示します。

図 4. [M_AXI Burst Information]

プラグマ レポート

デザイン内のプラグマ (valid、ignored、inferred) を表示します。このレポートは問題をまとめたもので、ログ ファイルにも含まれます。これにより、デザインで使用されるプラグマの問題を迅速に特定し、どのプラグマが指定どおりに使用されていないかを確認できます。有効なプラグマは個別にレポートされるため、デザインで使用されているすべてのプラグマを確認できます。

ヒント: ソース コード中のプラグマのディレクトリへのリンクが提供されます。リンクをクリックしてソース コードを表示します。
図 5. プラグマ レポート

Bind Op および Bind Storage レポート

Bind Op レポートと Bind Storage レポートが合成サマリ レポートに追加されます。どちらのレポートも、操作をリソースにマップする際の HLS コンパイラでの選択を理解するのに役立ちます。ツールは、適切なレイテンシで適切なリソースに操作をマップします。このプロセスに影響を与えるには、BIND_OP プラグマまたは指示子を使用し、特定のリソース マップとレイテンシを要求します。Bind Op レポートには、プラグマを使用して実行されたマップと比較して、自動的に実行されたマップが表示されます。同様に、Bind Storage レポートには、BRAM/LUTRAM/URAM のようなプラットフォーム上のメモリ リソースへの配列のマップが表示されます。

Bind Op レポートには、カーネルまたは IP のインプリメンテーションの詳細が表示されます。最上位関数の階層が表示され、変数が適用された HLS プラグマまたは指示子、定義された操作、HLS ツールで使用されたインプリメンテーション、適用されたレイテンシと共にリストされます。

このレポートは、RTL デザインで指定されたプログラマブル ロジック インプリメンテーションの詳細を調べるのに役立ちます。

図 6. 合成サマリ

上記のように、Bind Op レポートではデザインの特定の重要な特性がハイライトされます。現在のところ、デザインで使用される DSP 数が、デザインでこれらの DSP が使用される階層で表示されるようになっています。また、ユーザー指定のプラグマのために特定のリソース割り当てがされたかどうかもハイライトされ、割り当てられている場合は [Pragma] 列に Yes と表示されます。[Pragma] 列に何も表示されない場合は、リソースが自動的に推論されたことを意味します。表には、ユーザーのデザインで各モジュールに割り当てられたリソースの RTL 名も表示されます。階層を下ってさまざまなリソースを表示することもできます。

推論されたすべてのリソースが表示されるわけではなく、四則演算、浮動小数点、DSP などの関心のあるリソースを表示します。ファブリック (LUT を使用してインプリメント) または DSP といった特定のインプリメンテーション選択肢も示されます。最後に、リソースのレイテンシも表示されます。これは、パイプライン段階をデザインに追加する必要がある場合に、リソースのレイテンシを理解して増加するのに役立ちます。これは、インプリメンテーション中にタイミング問題を解決する際に長い組み合わせパスを分割しようとする場合に非常に便利です。

各リソース割り当ては、対応する op が推論されたソース コードの行に関連付けられます。リソースを右クリックして [Goto Source] オプションを選択すると、この関係を確認できます。最後に、Bind Op レポートの下の 2 つ目の表は、ツールで使用されるグローバル コンフィギュレーション設定で、ツールで使用されるリソース割り当てアルゴリズムを変更することもできます。上記の例では、dadd (倍精度浮動小数点加算) 演算のインプリメンテーションの選択肢が fulldsp インプリメンテーションに固定されています。同様に、ddiv 演算の遅延が 2 に固定されています。

BIND_OP プラグマと同様、BIND_STORAGE プラグマを使用すると、特定のメモリ タイプ (シングル ポートやデュアル ポートなど) や特定のメモリ インプリメンテーション (BRAM/LUTRAM/URAM/SRL など)、およびレイテンシ値を選択できます。Bind Storage レポートでは、デザインで使用されるストレージ マップがハイライトされます。現在のところ、デザインで使用されている BRAM および URAM の数が示されるようになっています。また、ユーザー指定のプラグマのために特定のストレージ リソース割り当てがされたかどうかもハイライトされ、割り当てられている場合は [Pragma] 列に Yes と表示されます。[Pragma] 列に何も表示されない場合は、ストレージ リソースが自動的に推論されたことを意味します。特定のストレージ タイプとインプリメンテーションの選択も、変数名とレイテンシと共に表示されます。

この情報を使用して、デザイン内のストレージ リソースの割り当てを確認し、リソースが使用可能かどうかに基づいて最終的なストレージ インプリメンテーションを変更できます。最後に、Bind Storage レポートの下の 2 つ目の表は、ストレージの設定 で説明されるグローバル設定がある場合はそれを示します。この設定により、ツールで使用されるストレージ リソース割り当てアルゴリズムを変更することもできます。