C/C ++ カーネル

任意精度の整数型は、ヘッダー ファイル ap_int.h で符号付き整数の場合は ap_int、符号なし整数の場合は ap_uint で定義されます。任意精度整数型を使用するには、次の手順に従います。

• ソース コードにヘッダー ファイル ap_int.h を追加します。
• ビット型を、ap_int<N> または ap_uint<N> (N はビット サイズを表す 1 ～ 1024 の値) に変更します。

次の例に、ヘッダー ファイルの追加方法と、2 つの変数を 9 ビット整数および 10 ビットの符号なし整数を使用してインプリメントする方法を示します。

#include "ap_int.h" 
ap_int<9> var1 // 9 bit signed integer
ap_uint<10> var2 // 10 bit unsigned integer

既存のアプリケーションには、ほかのハードウェア アーキテクチャ用に記述されているために、浮動小数点型が使用されているものもあります。ただし、浮動小数点型は終了するのに多くのクロック サイクルを必要とするので、固定小数点型の方が適している場合もあります。アプリケーションおよびアクセラレータの算術演算に浮動小数点を使用するか固定小数点を使用するかを選択する際は、消費電力、コスト、生産性、精度のトレードオフを注意深く評価する必要があります。

『浮動小数点から固定小数点への変換による消費電力およびコストの削減』 (WP491: 英語版、日本語版) で説明するように、機械学習のようなアプリケーションに浮動小数点ではなく固定小数点演算を使用すると、消費電力効率が上がり、必要な消費電力合計を削減できます。浮動小数点型の範囲がすべて必要な場合を除き、固定小数点型で同じ精度をインプリメントでき、より小型で高速なハードウェアにできることがよくあります。

固定小数点型では、データが整数ビットおよび小数ビットとして記述されます。固定小数点型には、ap_fixed ヘッダーが必要で、符号付きと符号なしの両方がサポートされます。

ヘッダー ファイル

ap_fixed.h

符号付き固定小数点

ap_fixed<W,I,Q,O,N>

符号なし固定小数点

ap_ufixed<W,I,Q,O,N>

• W = 合計幅 < 1024 ビット
• I = 整数ビット幅。I の値は幅 (W) と等しいかそれ以下である必要があります。小数部を表すためのビット数は W から I を差し引いた値です。整数幅を指定するには、定数の整数式のみを使用します。
• Q = 量子化モード。Q の指定には、あらかじめ定義されている列挙値のみを使用できます。使用できる値は、次のとおりです。
  • AP_RND: 正の無限大への丸め。
  • AP_RND_ZERO: 0 への丸め。
  • AP_RND_MIN_INF: 負の無限大への丸め。
  • AP_RND_INF: 無限大への丸め。
  • AP_RND_CONV: 収束丸め。
  • AP_TRN: 切り捨て。Q を指定しない場合、これがデフォルト値です。
  • AP_TRN_ZERO: 0 への切り捨て。
• O = オーバーフロー モード。Q の指定には、あらかじめ定義されている列挙値のみを使用できます。使用できる値は、次のとおりです。
  • AP_SAT: 飽和。
  • AP_SAT_ZERO: 0 への飽和。
  • AP_SAT_SYM: 対称飽和。
  • AP_WRAP: 折り返し。O を指定しない場合、これがデフォルト値です。
  • AP_WRAP_SM: 符号絶対値の折り返し。
• N = オーバーフロー WRAP モードでの飽和ビット数。このパラメーター値には定数の整数式のみを使用します。デフォルト値は 0 です。

次のコード例では、ap_fixed 型を使用して、符号付き 18 ビット変数 (6 ビットが 2 進小数点より上位の整数部で、12 ビットが 2 進小数点より下位の小数部) を定義しています。量子化モードは正の無限大 (AP_RND) へ丸めらるように設定されています。オーバーフロー モードと飽和ビットが指定されていないので、デフォルトの AP_WRAP と 0 が使用されます。

#include <ap_fixed.h>
...
  ap_fixed<18,6,AP_RND> my_type;
...

変数に異なるビット数 (W) や精度 (I) が含まれるような計算を実行する場合は、2 進小数点が自動的に揃えられます。固定小数点データ型の詳細は、『Vitis 高位合成ユーザー ガイド』 (UG1399) の「C++ の任意精度固定小数点型」を参照してください。

メモリ マップド インターフェイスは、ポインター パラメーターから推論されます。このインターフェイスでは、カーネルがグローバル メモリのデータを読み出し/書き込みでき、グローバル メモリはカーネルとホスト アプリケーションで共有されます。そのため、メモリ マップド インターフェイスはアクセラレーション アプリケーションの異なるエレメント間でデータを共有するのに便利な方法ですが、カーネル実行モード に説明されているように、シーケンシャルおよびパイプライン カーネル実行モードでのみ使用可能です。

コンパイル中に Vitis ツールで割り当てられるデフォルトのインターフェイスをカスタマイズするには、INTERFACE プラグマを使用できます。ザイリンクスでは、最大のパフォーマンスを得るため、AXI プロトコルの転送ごとの上限である 4 KB までのバースト転送をお勧めします。

データのアクセスが順次である場合は、ストリーミング インターフェイスを使用できます。このインターフェイスでは、グローバル メモリを介さずに、ホストからカーネル、カーネルからホストへのデータの直接ストリーミングが可能です。ストリーミング インターフェイスは、1 つのカーネルがデータをストリーミングするプロデューサーで、もう 1 つのカーネルがコンシューマーである場合にも、これらのカーネル間で使用できます。この転送も、グローバル メモリを使用せずに直接実行されます。詳細は、ストリーミング データ転送 を参照してください。

デフォルトでは、ループの反復は前の反復が終了してから開始されます。たとえば次に示すループの例では、ループの 1 回の反復で 2 つの変数が加算され、結果が 3 つ目の変数に格納されます。ハードウェアでこのループの 1 回の反復を終了するのに 3 サイクルかかるとします。また、ループの変数 len は 20 だとします (カーネルで vadd ループが 20 回反復実行される)。このループのすべての演算を終了するには、合計 60 クロックサイクル (20 反復 * 3 サイクル) かかります。

vadd: for(int i = 0; i < len; i++) {
  c[i] = a[i] + b[i];
}

vadd: for(int i = 0; i < len; i++) {
  #pragma HLS PIPELINE
  c[i] = a[i] + b[i];
}

上記の例では、ループの各反復 (読み込み、追加、書き出し) に 3 サイクルかかっていました。パイプライン処理なしの場合、ループの後続の反復は 3 サイクルごとに開始します。パイプライン処理すると、ループの後続の反復が 2 サイクルごと、または各サイクルで開始するようにできます。

ループの次の反復を開始するまでにかかるサイクル数は、パイプライン ループの開始間隔 (II) と呼ばれます。II=2 はループの連続する反復が 2 サイクルごとに開始され、II=1 (理想的) はループの各反復が各サイクルで開始されることを意味します。pragma HLS PIPELINE を使用すると、コンパイラは常に II=1 のパフォーマンスを達成しようとします。

次の図は、パイプライン処理ありとなしのループの違いを示しています。この図の (A) はデフォルトの順次演算を示しています。各入力は 3 クロック サイクルごとに処理され (II=3)、最後の出力が書き出されるまでに 8 クロック サイクルかかっています。

ループ内にデータ依存性がある場合、ループ依存性 で説明するように、II=1 を達成できず、開始間隔が 1 より大きな値になることがあります。

vadd: for(int i = 0; i < 20; i++) {
  #pragma HLS UNROLL
  c[i] = a[i] + b[i];
}

上記の例では、ループ本体に pragma HLS UNROLL が追加されており、コンパイラにループを完全に展開するよう指示しています。データの依存性で許容されれば、ループの 20 回の反復すべてが並列実行されます。

array_sum:for(int i=0;i<4;i++){
  #pragma HLS UNROLL factor=2
  sum += arr[i];
}

array_sum_unrolled:for(int i=0;i<4;i+=2){
  // Manual unroll by a factor 2
  sum += arr[i];
  sum += arr[i+1];
}

ループ内のデータ依存性は、ループのパイプライン処理またはループの展開結果に影響することがあります。これらのループ依存性は、ループの 1 回の反復内またはループ内の異なる反復間で発生します。ループ依存性を理解するには、極端な例を見てみるのとわかりやすいです。次のコード例では、ループの結果がそのループの継続/終了条件として使用されています。次のループを開始するには、前のループの各反復が終了する必要があります。

Minim_Loop: while (a != b) { 
  if (a > b) 
    a -= b; 
  else 
    b -= a;
}

このループはパイプライン処理できません。ループの前の反復が終了するまで次の反復を開始できないからです。

Vitis コンパイラを使用してさまざまなタイプの依存性を処理するには、コンパイラの結果を使用する高位合成について詳細に理解しておく必要があります。詳細は、『Vitis 高位合成ユーザー ガイド』 (UG1399) の「Vitis HLS での依存」を参照してください。

入れ子のループはコード記述で一般的に使用されます。必要なパフォーマンスを達成するには、入れ子のループ構造内のループがどのようにパイプライン処理されるかを理解することが重要です。

HLS PIPELINE プラグマを別のループ内に含まれるループに適用すると、v++ コンパイラはそのループを平坦化して 1 つのループを作成し、作成されたループに PIPELINE プラグマを適用します。ループを平坦化すると、カーネルのパフォーマンスが向上します。

コンパイラでは、次のタイプの入れ子のループを平坦化できます。

1. 完全入れ子ループ:
   • 内側のループのみにループ本体が含まれます。
   • ループ宣言間に指定されるロジックまたは演算はありません。
   • すべてのループ範囲は定数です。
2. 半完全入れ子ループ:
   • 内側のループのみにループ本体が含まれます。
   • ループ宣言の間にはロジックまたは演算は指定されません。
   • 内側のループ範囲は定数にする必要がありますが、外側のループ範囲は変数にできます。

次のコード例に、完全入れ子ループの構造を示します。

ROW_LOOP: for(int i=0; i< MAX_HEIGHT; i++) {
  COL_LOOP: For(int j=0; j< MAX_WIDTH; j++) {
    #pragma HLS PIPELINE
    // Main computation per pixel
  }
}

上記の例は、入力ピクセル データに対して計算を実行する 2 つのループを含む入れ子のループ構造を示します。ほとんどの場合、サイクルごとに 1 ピクセル処理するのが望ましいので、PIPELINE は入れ子のループの本体構造に適用されます。この例の場合は完全入れ子ループなので、コンパイラで入れ子ループ構造を平坦化できます。

上記の例の入れ子ループには、2 つのループ宣言の間にロジックは含まれていません。ROW_LOOP と COL_LOOP の間にロジックがないので、すべての処理ロジックが COL_LOOP に含まれます。また、両方のループの反復数は固定されています。これら 2 つの条件を満たすことが、v++ コンパイラでループを平坦化し、PIPELINE 制約を適用するのに役立ちます。

void adder(unsigned int *in, unsigned int *out, int inc, int size) {

  unsigned int in_internal[MAX_SIZE];
  unsigned int out_internal[MAX_SIZE];
  mem_rd: for (int i = 0 ; i < size ; i++){
    #pragma HLS PIPELINE
    // Reading from the input vector "in" and saving to internal variable
    in_internal[i] = in[i];
  }
  compute: for (int i=0; i<size; i++) {
  #pragma HLS PIPELINE
    out_internal[i] = in_internal[i] + inc;
  } 

  mem_wr: for(int i=0; i<size; i++) {
  #pragma HLS PIPELINE
    out[i] = out_internal[i];
  }
}

上記の例は、mem_rd、compute、および mem_wr の 3 つのシーケンシャル ループを示しています。

• mem_rd ループはメモリ インターフェイスから入力ベクター データを読み出し、内部ストレージに格納します。
• compute ループは、内部ストレージからデータを読み出してインクリメント演算を実行し、結果を別の内部ストレージに保存します。
• mem_wr ループは、内部ストレージからデータを読み出してメモリに書き込みます。

このコード例ではメモリの入力/出力インターフェイスに対する読み出しと書き込みに 2 つの個別のループを使用してバースト読み出し/書き込みを推論しています。

デフォルトでは、これらのループはオーバーラップせずに順に実行されます。mem_rd ループが入力データをすべて読み出すまで、compute ループの処理は開始しません。同様に、compute ループがデータを処理し終わってから mem_wr ループがデータの書き込みを開始します。ただし、これらのループの処理をオーバーラップさせて、mem_rd (または compute) ループがデータを処理し終えるまで待たずに、compute (または mem_wr) ループが処理を実行するのに十分なデータが使用可能になったらすぐに開始されるようにできます。

ループの実行は、データフロー最適化に示すように、データフロー最適化を使用してオーバーラップさせることができます。

データフローのコード例では、次の点に注目してください。

1. コンパイラでデータフロー最適化をイネーブルにするため、pragma HLS dataflow が適用されています。これは、PS と PL 間のインターフェイスであるデータ ムーバーではなく、データがアクセラレータを介してフローする方法を指定を示します。
2. データフロー領域内の各関数間のデータ転送チャネルとして stream クラスが使用されています。
   ヒント: stream クラスは、プログラマブルの FIFO メモリ回路を推論します。このメモリ回路はソフトウェア プログラミングのキューとして動作し、関数間をデータ レベルで同期化してパフォーマンスを向上します。

void compute_kernel(ap_int<256> *inx, ap_int<256> *outx, DTYPE alpha) {
  hls::stream<unsigned int>inFifo;
  #pragma HLS STREAM variable=inFifo depth=32
  hls::stream<unsigned int>outFifo; 
  #pragma HLS STREAM variable=outFifo depth=32

  #pragma HLS DATAFLOW
  read_data(inx, inFifo);
  // Do computation with the acquired data
  compute(inFifo, outFifo, alpha);
  write_data(outx, outFifo);
  return;
}

次のような場合、Vitis コンパイラでデータフロー最適化が実行されないことがあります。

1. シングル プロデューサー コンシューマー違反。
2. タスクのバイパス。
3. タスク間のフィードバック。
4. タスクの条件付き実行。
5. 複数の exit 条件またはループ内で定義された条件を持つループ。

これらのいずれかがデータフロー領域内で発生する場合は、データフロー最適化が問題なく実行されるようにするためにコードを記述し直す必要があることもあります。