インテル^® HLS コンパイラーでは、コンポーネントは基本的な配線から Avalon ストリーミング・インターフェイスや Avalon Memory-Mapped マスター・インターフェイスまで、さまざまなインターフェイスが使用できます。インターフェイスのベストプラクティスでは、コンポーネントに最適なインターフェイスの選択とコンフィグレーションについて学びます。

インテル^® HLS コンパイラーがサポートする各インターフェイスのタイプには異なる利点があります。しかしながら、コンポーネントを囲むシステムによっては選択に制限があります。最適なコンポーネントのインターフェイスを決定する際には、制限事項に注意が必要です。

<quartus_installdir>/hls/examples/tutorials

可能な場合、restrict型修飾子をポインター型に適用します。restrict で修飾されたポインターを有することで、 インテル^® HLS コンパイラーは競合しないリード動作とライト動作間の不要なメモリー依存関係の生成を回避できます。

各反復が 1 つの配列からデータを読み出してからデータを同じ物理メモリー内の別の配列に書き込むループを考慮します。。これらのポインター引数にrestrict型修飾子を追加しない場合、コンパイラーは 2 つの配列間で依存関係があると見なし、結果的にパイプライン並列化をより少なく抽出する可能性があります。

インテル^® HLS コンパイラーは、ループの最適化を妨げる依存性があるかどうかを通知します。コード内のこれらの依存性を排除し、コンポーネントのパフォーマンスを最適化します。

また、使用可能なループプラグマを使用して、コンパイラーに追加のガイダンスを提供することもできます。

<quartus_installdir>/hls/examples/tutorials

空間計算構造を使用すると、可能な場合にループを展開して複数のループ反復を同時に実行し、ループをパイプライン化できるように独立したステージでループを構成することで、ループを高速化できます。

3 ステージと 3 反復ある基本ループを考察します。各ステージは、1 クロックサイクル内にループ内で発生する演算を表します。

図 6. 基本ループ ( 3 ステージと 3 反復 )

このループの各ステージが実行に 1 クロックサイクを要する場合、このループは 9 サイクルのレイテンシーとなります。

次の図は、図 6のループのパイプライン化のプロセスを示しています。

図 7. パイプライン化ループ ( 3 ステージと 4 反復 )

パイプライン化ループは 3 反復で 5 クロックサイクル ( かつ、4 反復で 6 サイクル ) のレイテンシーがありますが、エリア・スレッドオフはありません。2 番目のクロックサイクル中、パイプライン化ループのステージ 1 は 2 反復を処理し、ステージ 2 は1 反復を処理し、ステージ 3 は非アクティブです。

このループは、ループの開始間隔 (initiation interval) (II) の値が 1 (II = 1) でパイプライン処理されます。II の値が 1 とは、連続した各ループ反復が開始する間が 1 クロックサイクルの遅延であることを意味します。

インテル^® HLS コンパイラーはデフォルトでループをパイプライン化しようとし、ループのパイプライン化はループ展開と同じ定数の反復回数の制約の対象ではありません。

すべてのループがパイプライン化できるのではなく、図 7で示されるループと同様に、特に各反復のあるループは前の反復で計算された値に依存します。

例えば、ステージ 1 のループは前のループ反復のステージ 3 の処理中に計算された値に依存します。このような場合、2 番目 ( オレンジ色 ) の反復は 1 番目 ( 青色 ) の反復がステージ 3 に到達するまで処理を開始しません。このような依存性をループ伝搬依存性といいます。

ループ伝搬依存性のあるループは II = 1 でパイプライン化できません。

この例では、ループは II = 3 でパイプライン化される可能性があります。II はループ反復のレイテンシーと同じであるため、ループは実際にはパイプライン化されません。次の等式でループのレイテンシー全体を見積ることができます。

${\mathrm{latency}}_{\mathrm{loop}}=(\mathrm{iterations}-1)*\mathrm{II}+{\mathrm{latency}}_{\mathrm{body}}$

ここでの ${\mathrm{latency}}_{\mathrm{loop}}$ はループのレイテンシー全体を、${\mathrm{latency}}_{\mathrm{body}}$ はループ内のコードのレイテンシーを指します。

ネスト化ループでは、この式を再帰的に適用する必要があります。この再帰は、 II>1 が内側ループが外側ループよりも問題が多いことを意味します。したがって、外側ループが II>1 であっても、II=1 の内側ループで作業の大部分を行うアルゴリズムは良好のまま実行します。

3 ステージと 3 反復の基本ループを考察します。各ステージは、1 クロックサイクル内にループ内で発生する演算を表します。

図 8. 基本ループ ( 3 ステージと 3 反復 )

このループの各ステージが実行に 1 クロックを要する場合、このループは 9 サイクルのレイテンシーとなります。

次の図は、3 回展開されたループ(図 8)を示しています。

図 9. 3 ステージと 3 反復で展開されたループ

3 回のループ反復は 3 クロックサイクルのみで終了が可能ですが、3 倍も多くのハードウェア・リソースを必要とします。

#pragma unrollディレクティブを使用してコンパイラーがループを展開する方法を制御でますが、このディレクティブは、コンパイラーがループのトリップ数を把握している場合、または展開係数を指定した場合にのみ機能します。ハードウェアの複製に加え、コンパイラーは演算の入力が準備できるとすぐに各演算を実行するように回路を再スケジュールします。

1.	#define ROWS 4
2.	#define COLS 4
3.	
4.	component void dut(...) {
5.		float a_matrix[COLS][ROWS]; // store in column-major format
6.		float r_matrix[ROWS][COLS]; // store in row-major format
7.	
8.		// setup...
9.	
10.		for (int i = 0; i < COLS; i++) {
11.			for (int j = i + 1; j < COLS; j++) {
12.	
13.				float dotProduct = 0;
14.				for (int mRow = 0; mRow < ROWS; mRow++) {
15.					dotProduct += a_matrix[i][mRow] * a_matrix[j][mRow];
16.				}
17.				r_matrix[i][j] = dotProduct;
18.			}
19.		}
20.	 	
21.	 // continue...
22.		
23.	}

このコンポーネントのパフォーマンスを向上させるには、特定のカラムの各エントリーを反復するループを展開します。

ループの演算が独立している場合、コンパイラーはそれらを並列に実行します。--fp-relaxedコンパイラー・フラグを浮動小数点演算の順序の緩和のために使用する場合、このループ内のすべての乗算が並列して発生し、蓄積機能は加算器ツリーとして実装されます。詳しくは、チュートリアルを参照してください。 <quartus_installdir>/hls/examples/ tutorials/best_practices/ floating_point_ops

コンパイラーはループ展開がパフォーマンスの向上に有効だと判断するとループ展開を試みます。例えば、ループの 14 行目は一定数の反復があるため自動的に展開され、かつ、それほど多くのハードウェアを消費しません (ROWS はコンパイル時に定義される定数で、このループが固定数の反復があることを保証しています )。

01: #define ROWS 4
02: #define COLS 4
03: 
04: component void dut(...) {
05: 	float a_matrix[COLS][ROWS]; // store in column-major format
06: 	float r_matrix[ROWS][COLS]; // store in row-major format
07: 
08: 	// setup...
09: 
10: 	for (int i = 0; i < COLS; i++) {
11: 
12: #pragma unroll
13: 			for (int j = 0; j < COLS; j++) {
14: 				float dotProduct = 0;
15: 
16: #pragma unroll

17: 				for (int mRow = 0; mRow < ROWS; mRow++) {
18: 					dotProduct += a_matrix[i][mRow] * a_matrix[j][mRow];
19: 				}
20: 
21: 				r_matrix[i][j] = (j > i) ? dotProduct : 0; // predication
22: 			}
23: 		}
24:  	}
25:  	
26: 	// continue...
27: 	
28: }

これらには依存性がなく、全 4 回の反復が同時に実行されるため、これでjループが完全に展開されます。

詳しくは、 <quartus_installdir>/hls/examples/tutorials/best_practices/resource_sharing_filterにあるresource_sharing_filterチュートリアルを参照してください。

10 行目でループを継続して展開できるかもしれませんが、このループを展開するとエリアが再び増加してしまいます。デフォルトでは、一定数の反復であっても、コンパイラーはこのループを展開しません。コンパイラーはこのループを展開するのではなくパイプライン化できるようにすることでエリアの増加を回避し、iループが II が 1 のみを有すると仮定して約 4 クロックサイクルを費やすことができます。II が 1 ではない場合、high level design レポート (report.html) の Loops analysis ページの Details ペインは改善方法を表示します。

整形式のループは整数境界と比較される終了条件があり、各反復ごとに 1 のシンプルな誘導インクリメントがあります。 インテル^® HLS コンパイラーは整形式のループを効率的に分析することができ、それによりコンポーネントのパフォーマンスが改善されます。

for(i=0; i < N; i++)
{
    //statements
}

また、整形式のネスト化ループはコンポーネントのパフォーマンスを最大にすることができます。

for(i=0; i < N; i++)
{
   //statements
   for(j=0; j < M; j++)
   {
      //statements
   }
}

コンポーネントのループに複雑な終了条件がある場合、条件を評価するためにメモリーアクセスまたは複雑な演算が必要な場合があります。ループの後続の反復は、評価が完了するまでループのパイプラインで起動できず、ループ全体のパフォーマンスが低下する可能性があります。

パフォーマンスを最大にするには、ネスト化ループを可能な限り単一ループに結合します。ループの制御フローは、ロジックで必要なオーバーヘッドと FPGA のハードウェア・フットプリントのオーバーヘッドの両方を追加します。ネスト化ループを単一ループに結合すると、これらの側面が緩和し、コンポーネントのパフォーマンスが向上します。

次のコード例はネスト化ルーから単一ループへの変換を示しています。

for (i = 0; i < N; i++)
{
    //statements
    for (j = 0; j < M; j++)
    {
        //statements          
    }
    //statements
} 

for (i = 0; i < N*M; i++)
{
    //statements
}

また、loop_coalesceプラグマを指定して、ループの機能に影響を与えずにネスト化ループを単一ループに結合できます。次のシンプルな例は、loop_coalesceプラグマを指定した際にコンパイラーが 2 つのループを単一ループに結合する方法を示しています。

#pragma loop_coalesce
          for (int i = 0; i < N; i++)
           for (int j = 0; j < M; j++)
           sum[i][j] += i+j;

int i = 0;
int j = 0;
while(i < N){

  sum[i][j] += i+j;
  j++;
  
  if (j == M){
    j = 0;
    i++;
  }
}

loop_coalesceプラグマについて詳しくは、 インテル^® HLS コンパイラー・リファレンス・マニュアルのループ結合 (loop_coalesceプグマ )を参照してください。

変数の実装に必要な FPGA ハードウェア・リソースを削減するには、ループで変数を使用する直前にそれを宣言します。可能な限り最も深いスコープで変数を宣言するる、 インテル^® HLS コンパイラーは変数を使用しないループ全体で変数データを保持する必要がないため、データの依存性と FPGA ハードウェア使用率を最小限に抑えます。

次の例を考察します。

int a[N];
for (int i = 0; i < m; ++i)
{
    int b[N];
    for (int j = 0; j < n; ++j)
	{
        // statements
    }
}

配列aは実装に配列bより多くのリソースを必要とします。ハードウェア使用率を削減するには、外側のループの反復によりデータを維持する必要がない限り、配列aを内側のループの外側に宣言します。

ほとんどの場合、アクセスパターンを変更することでメモリー・アーキテクチャーを最適化できますが、 インテル^® HLS コンパイラーはメモリー・アーキテクチャーでいくつかの手動制御を提供します。

<quartus_installdir>/hls/examples/tutorials

コードにさまざまな組み合わせのメモリー属性を使用することで、 インテル^® HLS コンパイラーはコンポーネントで推測されるメモリー・アーキテクチャーをオーバーライドすることができます。

以下のコード例は、次のメモリー属性を使用して結合メモリーをオーバーライドする方法を示しています。

• hls_bankwidth(n)
• hls_numbanks(n)
• hls_singlepump
• hls_numports_readonly_writeonly(m,n)

オリジナルコードは、64 ビット幅の 256 の深さ ( 256x64 ビット ) のメモリー、つまり、2 つのオンチップ・メモリーブロックを結合します。

component unsigned int mem_coalesce(unsigned int raddr,
                                    unsigned int waddr,
                                    unsigned int wdata){
    unsigned int data[512];
    data[2*waddr] = wdata;
    data[2*waddr + 1] = wdata + 1;
    unsigned int rdata = data[2*raddr] + data[2*raddr + 1];
    return rdata;
}

変更されたコードは、32 ビット幅の 512 の深さ ( 512×32 ビット ) で、ストール可能な調停を備えたシンプル・デュアルポート・オンチップ・メモリーブロックを実装しています。

component unsigned int mem_coalesce(unsigned int raddr,
                                    unsigned int waddr,
                                    unsigned int wdata){
    //Attributes that stop memory coalescing
    hls_bankwidth(4) hls_numbanks(1)
    //Attributes that specify a simple dual port
    hls_singlepump hls_numports_readonly_writeonly(1,1)
    unsigned int data[512];
    data[2*waddr] = wdata;
    data[2*waddr + 1] = wdata + 1;
    unsigned int rdata = data[2*raddr] + data[2*raddr + 1];
    return rdata;
} 

コードにさまざまな組み合わせのメモリー属性を使用することで、 インテル^® HLS コンパイラーがコンポーネントで推論するメモリー・アーキテクチャーをオーバーライドすることができます。

次のコード例は、下のメモリー属性を使用してバンクメモリーをオーバーライドして FPGA 上のメモリーブロックを節約する方法を示しています。

• hls_bankwidth(n)
• hls_numbanks(n)
• hls_singlepump
• hls_doublepump

オリジナルコードは、シングルパンプ・オンチップ・メモリーブロックのバンクを 2 つ、つまり 16 ビット幅を作成します。

component unsigned short mem_banked(unsigned short raddr,
                                    unsigned short waddr,
                                    unsigned short wdata){
    unsigned short data[1024];
    
    data[2*waddr] = wdata;
    data[2*waddr + 9] = wdata +1;

    unsigned short rdata = data[2*raddr] + data[2*raddr + 9];

    return rdata;
}

バンクメモリーの節約のために、data[1024] の宣言前に次の属性を追加することで、ダブルパンプされた 32 ビット幅のオンチップ・メモリーブロックのバンクを 1 つ実装するオプションがあります。

hls_bankwidth(2) hls_numbanks(1)hls_doublepump
unsigned short data[1024];

あるいは、data[1024] の宣言前に次の属性を追加することで、ストール可能な調停のシングルパンプ・オンチップ・メモリーブロックのバンク 1 つを実装によりダブルパンプされたメモリーのダブルクロック要件を回避できます。

hls_bankwidth(2) hls_numbanks(1)hls_singlepump
unsigned short data[1024];

場合によっては、コンポーネントメモリーをマージすることで FPGA メモリーブロックを節約できるため、少量の M20K メモリーブロックを消費して、コンポーネントが使用する FPGA エリアを削減できます。hls_merge属性を使用して、 インテル^® HLS コンパイラーに同じメモリーシステム内に異なる変数を実装させます。

メモリーをマージすると、複数のコンポーネント変数は同じメモリーブロックを共有します。幅 ( 幅方向のマージ ) または深さ ( 深さ方向のマージ ) でメモリーをマージできます。メモリー内のデータが異なるデータ型を有するメモリーをマージできます。

hls_merge("<mem_name>","depth") 属性を使用して インテル^® HLS コンパイラーに同じメモリーシステム内に変数を実装させ、深さによりこれらのメモリーをマージします。

これらのhls_merge属性に設定されている同じ <mem_name> ラベルのすべての変数がマージされます。

次のコンポーネント・コードを考察します。

component int depth_manual(bool use_a, int raddr, int waddr, int wdata) {
  int a[128];
  int b[128];

  int rdata;

  // mutually exclusive write
  if (use_a) {
    a[waddr] = wdata;
  } else {
    b[waddr] = wdata;
  }

  // mutually exclusive read
  if (use_a) {
    rdata = a[raddr];
  } else {
    rdata = b[raddr];
  }

  return rdata;
}

コードは、それぞれ独自のロード / ストアー命令を有する 2 つのオンチップ・メモリーブロックとして、 インテル^® HLS コンパイラーにローカルメモリーaとbを実装するように指示します。

ローカルメモリーaとbでのロード / ストアー命令は相互に排他的であるため、下のコード例で示されるようにアクセスをマージすることができ、これによりロード / ストアー命令の数が減り、オンチップ・メモリーブロックの数も半減します。

component int depth_manual(bool use_a, int raddr, int waddr, int wdata) {
  int a[128] hls_merge("mem","depth");
  int b[128] hls_merge("mem","depth");

  int rdata;

  // mutually exclusive write
  if (use_a) {
    a[waddr] = wdata;
  } else {
    b[waddr] = wdata;
  }

  // mutually exclusive read
  if (use_a) {
    rdata = a[raddr];
  } else {
    rdata = b[raddr];
  }

  return rdata;
}

深さに対してローカルメモリーをマージするとメモリーアクセスの効率が低下する場合があります。深さに対してローカルメモリーをマージするかどうかを決定する前に、HLD レポート(<result>.prj/reports/report.html) を参照し、予測されたロード / ストアー命令の数で予測されたメモリー構成を生成しているかを確認する必要があります。下の例では、各メモリーへのロード / ストアー命令は互いに排他的ではないため、 インテル^® HLS コンパイラーはローカルメモリーaとbへのアクセスをマージすべきではありません。

component int depth_manual(bool use_a, int raddr, int waddr, int wdata) {
  int a[128] hls_merge("mem","depth");
  int b[128] hls_merge("mem","depth");

  int rdata;

  // NOT mutually exclusive write

  a[waddr] = wdata;
  b[waddr] = wdata;
  
  // NOT mutually exclusive read

  rdata = a[raddr];
  rdata += b[raddr];
  
  return rdata;
}

この場合、 インテル^® HLS コンパイラーはメモリーシステムをダブルパンプし、すべてのアクセスに十分なポートを提供する可能性があります。それ以外の場合、アクセスはストールフリーのアクセスを防ぐポートを共有する必要があります。

merger("<mem_name>","width")属性を使用して インテル^® HLS コンパイラーに同じメモリーシステム内に変数を実装させ、幅によりこれらのメモリーをマージします。

これらのhls_merge属性に設定されている同じ <mem_name> ラベルのすべての変数がマージされます。

次のコンポーネントのコードを考察します。

component short width_manual (int raddr, int waddr, short wdata) {

  short a[256];
  short b[256];

  short rdata = 0;
  
  // Lock step write
  a[waddr] = wdata;
  b[waddr] = wdata;

  // Lock step read 
  rdata += a[raddr];
  rdata += b[raddr];

  return rdata;
}

この場合、ロード / ストアー命令が同じアドレスへのアクセスであるため、 インテル^® HLS コンパイラーはこれらをローカルメモリーaとbにマージすることができ、ロード / ストアー命令は次のように結合されます。

component short width_manual (int raddr, int waddr, short wdata) {

  short a[256] hls_merge("mem","width");
  short b[256] hls_merge("mem","width");

  short rdata = 0;
  
  // Lock step write
  a[waddr] = wdata;
  b[waddr] = wdata;

  // Lock step read 
  rdata += a[raddr];
  rdata += b[raddr];

  return rdata;
}

{b0, b1, ... ,bn} 引数は インテル^® HLS コンパイラーがバンク選択ビットで使用すべきワードアドレス・ビットを参照します。hls_bankbits(b0, b1, ..., bn) 属性を指定することは、バンク数が 2^( バンクビット数 ) と等しいことを意味します。

component int bank_arb_consecutive_multidim (int raddr, int waddr, int wdata, int upperdim) {

  int a[2][4][128];

  #pragma unroll
  for (int i = 0; i < 4; i++) {
    a[upperdim][i][(waddr & 0x7f)] = wdata + i;
  }

  int rdata = 0;

  #pragma unroll
  for (int i = 0; i < 4; i++) {
    rdata += a[upperdim][i][(raddr & 0x7f)];
  }

  return rdata;
}

component int bank_arb_consecutive_multidim (int raddr, int waddr, int wdata, int upperdim) {

  int a[2][4][128] hls_bankbits(8,7);

  #pragma unroll
  for (int i = 0; i < 4; i++) {
    a[upperdim][i][(waddr & 0x7f)] = wdata + i;
  }

  int rdata = 0;

  #pragma unroll
  for (int i = 0; i < 4; i++) {
    rdata += a[upperdim][i][(raddr & 0x7f)];
  }

  return rdata;
}

component int bank_arb_consecutive_multidim (int raddr,
                                             int waddr,
                                             int wdata,
                                             int upperdim){

  int a[2][4][128] hls_bankbits(5,4);

  #pragma unroll
  for (int i = 0; i < 4; i++) {
    a[upperdim][i][(waddr & 0x7f)] = wdata + i;
  }

  int rdata = 0;

  #pragma unroll
  for (int i = 0; i < 4; i++) {
    rdata += a[upperdim][i][(raddr & 0x7f)];
  }

  return rdata;
}

任意高精度のデータ型を使用してデータ幅を縮小することで、コンポーネント内のいくつかのデータ型が微調整でき、FPGA エリア使用率が低下します。 インテル^® HLS コンパイラーはデバック機能を提供しおり、任意高精度のデータ型のオーバーフローが容易に検出できます。

<quartus_installdir>/hls/examples/tutorials

ac_intデータ型は C および Verilog を含め、他の言語とはビットシフトが異なります。デフォルトでは、シフト量が符号付きデータ型ac_intの場合、負のシフトを許容します。

ハードウェアでは、この負のシフトは左シフトと右シフトの両方の実装をもたらします。下のコード例はシフト量が符号付きデータ型であることを示しています。

int14 shift_left(int14 a, int14 b) {
    return (a << b);
} 

シフトが常に一方向にあるとわかっている場合、効率的なシフト演算子を実装するには、次のようにシフト量を符号なしのデータ型として宣言します。

int14 efficient_left_only_shift(int14 a, uint14 b) {
    return (a << b);
}