インテル®高位合成 (HLS) コンパイラー プロ・エディション: ベスト・プラクティス・ガイド

ダウンロード PDF
ID 683152
日付 12/16/2019
Public
ドキュメント目次
ドキュメント目次 x
1. インテル®HLSコンパイラー プロ・エディション ベスト・プラクティス・ガイド 2. コンポーネントのコーディングおよびコンパイルのベスト・プラクティス 3. インターフェイスのベスト・プラクティス 4. ループのベスト・プラクティス 5. メモリー・アーキテクチャーのベスト・プラクティス 6. タスクのシステム 7. データ型のベスト・プラクティス 8. 高度なトラブルシューティング A. インテル®HLSコンパイラー プロ・エディション ベスト・プラクティス・ガイド B. インテル®HLSコンパイラー プロ・エディション ベスト・プラクティス・ガイドの改訂履歴
3. インターフェイスのベスト・プラクティス x
3.1. コンポーネントに適したインターフェイスの選択 3.2. 可変遅延MMマスター・インターフェイスのLSUの制御 3.3. ポインター・エイリアシングの回避
3.1. コンポーネントに適したインターフェイスの選択 x
3.1.1. ポインター・インターフェイス 3.1.2. Avalon® Memory Mappedマスター・インターフェイス 3.1.3. Avalon® Memory Mappedスレーブ・インターフェイス 3.1.4. Avalon® Streaming インターフェイス 3.1.5. 値渡しインターフェイス
4. ループのベスト・プラクティス x
4.1. ループでの呼び出しによるハードウェアの再利用 4.2. ループの並列化 4.3. 整形式ループの構造 4.4. ループ搬送依存関係の最小化 4.5. 複雑なループ終了条件の回避 4.6. ネスト化ループから単一ループへの変換 4.7. 可能な限り最も深いスコープでの変数宣言
4.2. ループの並列化 x
4.2.1. ループのパイプライン処理 4.2.2. ループの展開 4.2.3. 例 : ループのパイプライン処理および展開
5. メモリー・アーキテクチャーのベスト・プラクティス x
5.1. 例 : 結合メモリー・アーキテクチャーのオーバーライド 5.2. 例 : バンク・メモリー・アーキテクチャーのオーバーライド 5.3. 領域削減のためのメモリーのマージ 5.4. 例 : ローカル・メモリー・アドレスのバンク選択ビットの指定
5.3. 領域削減のためのメモリーのマージ x
5.3.1. 例 : 深さ方向へのメモリーのマージ 5.3.2. 例 : メモリーの幅方向のマージ
6. タスクのシステム x
6.1. 複数ループの並列実行 6.2. 負荷のかかる計算ブロックの共有 6.3. 階層デザインの実装 6.4. 潜在的なパフォーマンスの落とし穴の回避
7. データ型のベスト・プラクティス x
7.1. 暗黙的データ型変換の回避 7.2. ac_int データ型使用時の負のビットシフトの回避
8. 高度なトラブルシューティング x
8.1. コンポーネントがコ・シミュレーションでのみ失敗する場合 8.2. コンポーネントの結果の品質が悪い
1. インテル®HLSコンパイラー プロ・エディション ベスト・プラクティス・ガイド
2. コンポーネントのコーディングおよびコンパイルのベスト・プラクティス
3. インターフェイスのベスト・プラクティス
4. ループのベスト・プラクティス
5. メモリー・アーキテクチャーのベスト・プラクティス
6. タスクのシステム
7. データ型のベスト・プラクティス
8. 高度なトラブルシューティング
A. インテル®HLSコンパイラー プロ・エディション ベスト・プラクティス・ガイド
B. インテル®HLSコンパイラー プロ・エディション ベスト・プラクティス・ガイドの改訂履歴

8.2. コンポーネントの結果の品質が悪い

デザインの品質の結果 (QoR) が悪くなる理由は数多くありますが、不適切なメモリー・コンフィグレーションが重要な要素であることがよくあります。High Level Design ReportのFunction Memory Viewerレポートを確認し、ストール可能なアービトレーション・ノードと予期しないRAM使用率を探します。

この項内の情報で説明しているのは、ストール可能なアービトレーション・ノードまたは過剰なRAM使用率の一般的なソースについてです。

コンポーネントで予想以上のFPGAリソースを使用する

デフォルトで インテル®HLSコンパイラー プロ・エディションでは、コンポーネントを最適化して最大限のスループットを得るために、最大動作周波数 (fMAX) を最大化しようとします。

領域の消費を削減する方法の1つは、fMAX 要件の緩和です。そのためには、ターゲットfMAX 値の設定を -clock i++コマンドオプションまたは hls_scheduler_target_fmax_mhz コンポーネント属性を使用して行います。HLSコンパイラーでは、多くの場合、指定値よりも高いfMAX を達成します。そのため、ターゲットfMAX rの設定を必要な値よりも低くしても、デザインでは、許容可能なfMAX 値を達成し、消費面積を小さくすることができる場合があります。

fMAX ターゲット値制御の動作について詳しくは、次のチュートリアルを参照してください。 <quartus_installdir>/hls/examples/tutorials/best_practices/set_component_target_fmax

誤ったバンクビット

配列の一部に並列アクセスする場合 (一次元または多次元配列)、メモリーバンクの選択ビットのコンフィグレーションが必要になることがあります。

効率的なメモリーシステムのコンフィグレーション方法について詳しくは、メモリー・アーキテクチャーのベスト・プラクティス を参照してください。

struct 変数の異なる2つの配列にアクセスする条件演算子

場合によっては、struct 変数の異なる配列にアクセスを条件演算子を使用してしようとすると、 インテル®HLSコンパイラー プロ・エディションでは、配列を同じRAMブロックにマージします。Function Memory Viewerには、ストール可能なアービトレーションが表示される場合があります。これは、メモリーシステムに十分なロード/ストアサイトがないためです。

例えば、次のサンプルコードで示すのは、struct 変数の配列、ストール可能なアービトレーションをもたらす条件演算子、およびストール可能なアービトレーションの回避策です。 
struct MyStruct {
  float a;
  float b;
}

MyStruct array1[64];
MyStruct array2[64];
次の条件演算子は、struct 変数の配列を使用しており、ストール可能な調停を引き起こします。 
MyStruct value = (shouldChooseArray1) ? array1[idx] : array2[idx];
ここで条件演算子が引き起こすストール可能なアービトレーションを回避するには、演算子を削除し、代わりに明示的な if ステートメントを使用します。 
MyStruct value;
if (shouldChooseArray1)
{
    value = array1[idx];
} else
{
    value = array2[idx];
}

クラスターロジック

デザインで消費するRAMブロックは、予想より多くなることがあります。これは、多くの配列変数を大きなレジスターに格納する場合は特にそうです。ハイレベルのデザインレポート ( report.html ) のArea Analysis of Systemレポートは、この問題の発見に役立ちます。

3つのマトリックスは、意図的にRAMブロックに格納されます。しかしながら、マトリックスのRAMブロックが占めるRAMブロックは、コンポーネントで消費するRAMブロックの半分未満です。

レポートのさらに下を見ると、多くのRAMブロックが、Cluster logicまたはState変数によって消費されていることがわかります。また、レジスターに格納する予定の配列値の一部が、代わりに多数のRAMブロックに格納されていることもわかります。

Cluster LogicおよびStateによって消費されるRAMブロックの数に注意してください。

場合によっては、このRAMブロックの使用率を削減するために次の手法を使用します。
  • ループをパイプライン処理する (ループは展開しない)
  • ローカル変数をローカルRAMブロック (hls_memory メモリー属性) に格納 (大きなレジスター (hls_register メモリー属性) には格納しない)
レベル 2 の表題