インテル^®HLS (高位合成) コンパイラーを使用すると、コンポーネントでは、基本的なワイヤーからAvalon StreamingおよびAvalon Memory-Mapped Masterインターフェイスまでのさまざまなインターフェイスが使用できます。インターフェイスのベスト・プラクティスは、コンポーネントに適切なインターフェイスの選択やコンフィグレーションに役立ちます。

インテル^®HLSコンパイラー プロ・エディションでサポートする各インターフェイスには、そのタイプによって異なる利点がああります。しかしながら、コンポーネントを囲むシステムによって、インターフェイスの選択が制限される場合があります。コンポーネントにとって最適なインターフェイスを決定する際には、ご自身の必要条件を念頭に置いてください。

<quartus_installdir>/hls/examples/tutorials

ロード・ストア・ユニット (LSU) は、 インテル^®HLSコンパイラー プロ・エディションによって可変レイテンシーMemory Mapped (MM) Masterインターフェイスとの対話に使用されます。LSUのタイプを制御すると、デザインの面積が節約できます。また、ロード/ストアと他のロード/ストア動作の静的結合をディスエーブルすると、デザインのパフォーマンスが向上する場合があります。

次のチュートリアルで、LSUの制御について確認してください。 <quartus_installdir>/hls/examples/tutorials/best_practices/lsu_control

LSU制御を使用する必要性を確認するには、コンポーネント、特にFunction Memory ViewerのHigh-Level Design Reportを確認します。その上で、メモリー・アクセス・パターン (およびその関連LSU) が、 インテル^®HLSコンパイラー プロ・エディションで予想するメモリー・アクセス・パターンと一致するかどうかを確認します。一致しない場合は、LSUタイプ、LSU結合、またはその両方の制御を検討してください。

component void
dut(mm_master<int, dwidth<128>, awidth<32>, aspace<4>, latency<0>> &Buff1,
    mm_master<int, dwidth<32>, awidth<32>, aspace<5>, latency<0>> &Buff2) {
  int Temp[SIZE];

  using pipelined = lsu<style<PIPELINED>>; 
  using burst_coalesced = lsu<style<BURST_COALESCED>>;

  for (int i = 0; i<SIZE; i++) {
    Temp[i] = burst_coalesced::load(&Buff1[i]); // Burst-Coalesced LSU
  }

  for (int i = 0; i<SIZE; i++) {
    pipelined::store(&Buff2[i], 2*Temp[i]); // Pipelined LSU
  }
}

component int
dut(mm_master<int, dwidth<256>, awidth<32>, aspace<1>, latency<0>> &Buff1,
    int i, bool Cond1, bool Cond2) {

  using no_coalescing = lsu<style<PIPELINED>, static_coalescing<false>>;
  int Val = 0;
  if (Cond1) {
    Val = no_coalescing::load(&Buff1[i]);
  }
  if (Cond2) {
    Val = no_coalescing::load(&Buff1[i + 1]);
  }
  return Val;
}

可能な場合は常に、制限型修飾子をポインター型に追加します。制限型修飾子ポインターを使用することにより、不要なメモリー依存関係が、非競合読み出し動作と書き込み動作との間に インテル^®HLSコンパイラー プロ・エディションによって作成されるのを防ぎます。

制限型修飾子は __restrict です。

ループでの各イタレーションによるデータの読み出しが、1つの配列から行われる場合について検討します。この場合、各イタレーションよるデータの書き込みは、同じ物理メモリー内の別の配列に対して行われます。制限型修飾子をこのポインター引数に追加しない場合、コンパイラーでは、2つの配列が重複していると仮定します。そうすると、コンパイラーでは、メモリーアクセスの元の順序を両方の配列に対して維持する必要があります。その結果、ループの最適化が不十分になったり、メモリーアクセスを含むループのパイプライン処理が失敗したりします。

<quartus_installdir>/hls/examples/tutorials/best_practices/parameter_aliasing

インテル^®HLSコンパイラー プロ・エディションでは、ループの最適化を妨げる依存関係があるかどうかを知らせます。コード内にそのような依存関係がある場合は、それを排除して、コンポーネントのパフォーマンスを最適化してください。さらに、追加のガイダンスをコンパイラーに対して提供することもできます。このためには、入手可能なループプラグマを使用します。

<quartus_installdir>/hls/examples/tutorials

ループは、ハードウェアを再利用する便利な方法です。コンポーネント関数で別の関数をコールすると、コールされた関数はトップレベルのコンポーネントになります。関数を複数回コールすると、ハードウェアが重複します。

int foo(int a)
{
    return 4 + sqrt(a) /
}

component
void myComponent()
{
  ...
  int x =
  x += foo(0);
  x += foo(1);
  x += foo(2);
  ...
}

component
void myComponent()
{
  ...
  int x = 0;
#pragma unroll 1
  for (int i = 0; i < 3; i++)
  {
    x += foo(i);
  }
  ...
}

component
void myComponent()
{
  ...
  int x = 0;
#pragma unroll 1
  for (int i = 0; i < 3; i++)
  {
     int val = 0;
     switch(i)
     {
     case 0:
         val = 3;
         break;
     case 1:
         val = 6;
         break;
     case 2:
         val = 1;
         break;
     }
     x += foo(val);
  }
  ...
}
H

ハードウェアの再利用とインラインの最小化ついては、リソース共有チュートリアルを参照してください。これは、次のウェブサイトで入手可能です。 <quartus_installdir>/hls/examples/tutorials/best_practices/resource_sharing_filter

空間計算構造を利用して、ループの高速化ができます。このためには、ループの複数のイタレーションを同時に実行します。ループの複数のイタレーションを同時に実行するには、可能であればループを展開し、また、ループの構成は、ループ・イタレーション間の依存関係が最小化されて、1クロックサイクル内で解決できるようにします。

このようなプラクティスで示しているのは、同じループの異なるイタレーションを並列化する方法です。異なる2つのループを並列化する場合は、タスクのシステムの使用を検討してください。詳細については、タスクのシステム を参照してください。

次の基本ループについて検討します。このループには、3ステージと3イタレーションがあります。ループステージとは、ループ内で1クロックサイクルの間に発生する動作です。

図 6. 基本ループ (3ステージと3イタレーション)

このループの各ステージの実行に1クロックサイクルかかる場合、このループのレイテンシーは、9サイクルです。

次の図で示すパイプライン処理は、図 6 のループのものです。

図 7. パイプライン化ループ (3ステージと4イタレーション)

パイプライン化ループのレイテンシーは、3イタレーションで5クロックサイクル (かつ、4イタレーションで6サイクル) ですが、領域トレードオフはありません。2回目のクロックサイクル中、パイプライン・ループのStage 1ではイタレーション2を処理し、Stage 2ではイタレーション1を処理し、Stage 3は非アクティブです。

このループのパイプライン処理では、ループの開始間隔 (II) の値は1です。II の値が1ということは、1クロックサイクルの遅延が、連続した各ループのイタレーションが開始する間に存在するという意味です。

The インテル^®HLSコンパイラー プロ・エディション では、デフォルトでループのパイプライン処理を試みます。ループのパイプライン処理は、ループの展開と同じ一定のイタレーション回数の制約は受けません。

すべてのループが、図 7 で示されるループと同じ様にパイプライン処理できるわけではありません。特に、各イタレーションの依存する値が、前のイタレーションで計算された値である場合はそうです。

例えば、Stage 1のループが、前のループ・イタレーションのStage 3の処理中に計算された値に依存するとします。このような場合、2回目 (オレンジ色) のイタレーションによる実行は、1回目 (青色) のイタレーションがステージ Stage 3に到達するまでは開始できません。このような依存関係は、ループ搬送依存関係 と呼ばれます。

この例では、ループのパイプライン処理は、II = 3で行われます。IIはループ・イタレーションのレイテンシーと同じであるため、ループは、実際にはパイプライン処理されません。ループの合計レイテンシーの見積もりは、次の数式ですることができます。

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

ここでは、${\mathrm{latency}}_{\mathrm{loop}}$ は、ループの実行にかかるサイクル数です。また、${\mathrm{latency}}_{\mathrm{body}}$ iは、1回のループ・イタレーションの実行にかかるサイクル数です。

インテル^®HLSコンパイラー プロ・エディション では、ネストされたループのパイプライン処理をサポートします。このとき内部ループは展開しません。ネストされたループのレイテンシーを計算するとき、この式を再帰的に適用します。この再帰が意味するのは、II>1を持つことによる問題は、外側のループに対してよりも内側のループに対することです。したがって、アルゴリズムは、ほとんどの作業をII=1の内側のループで行う場合は、外側のループがII>1であっても、引き続き良好に機能します。

次の基本ループについて検討します。このループには、3ステージと3イタレーションがあります。各ステージで表される動作は、ループで1クロックサイクル内に発生します。

図 8. 基本ループ (3ステージと3イタレーション)

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

次の図で示しているループは、図 8 のループが3回展開されたものです。

図 9. 展開されたループ (3ステージと3イタレーション)

ループの3イタレーションの完了は、3クロックサイクル内のみで可能ですが、3倍ものハードウェア・リソースが必要です。

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

#pragma unroll ディレクティブの使用例については、best_practices/resource_sharing_filter チュートリアルを参照してください。

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.	}

このコンポーネントのパフォーマンスを向上させるには、特定のカラムの各エントリーで繰り返されるループを展開します。ループ動作が独立している場合、コンパイラーでは、それを並列実行します。

浮動小数点演算を実行する順序は、通常、ソースコードで表現されているのと同じにして、数値精度を維持してください。ただし、--ffp-contract=fast コンパイラー・フラグを使用して、浮動小数点演算の順序を緩和することができます。浮動小数点演算の順序を緩和すると、このループ内のすべての乗算が並行して発生する場合があります。詳細については、次のチュートリアルを確認してください。 <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: }

これで j ループが完全に展開されました。依存関係がないため、4イタレーションすべてが同時に実行されます。

詳しくは、resource_sharing_filter チュートリアルを参照してください。このチュートリアルの場所は次のとおりです。 <quartus_installdir>/hls/examples/tutorials/best_practices/resource_sharing_filter

続行して、ループの展開を10行目ですることもできますが、このループを展開すると、面積が再び増加します。コンパイラーで、このループを展開するのではなく、パイプライン処理できるようにすると、面積の増加が回避でき、さらに使うのは約4クロックサイクルのみになります ( i ループのIIが1のみの場合)。ハイレベルのデザインレポートのLoops Analysis (report.html ) の詳細ペインには、この改善方法のヒントが表示されます。

整形式ループの終了条件では、整数境界との比較ができます。また整形式ループでは、各イタレーションごとにシンプルな誘導インクリメントを1つ備えています。 インテル^®HLSコンパイラー プロ・エディションでは、整形式ループの解析を効率的に行うことができます。これにより、コンポーネントのパフォーマンスが向上します。

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

また、整形式のネスト化ループは、コンポーネントのパフォーマンスを最大にするのに役立ちます。

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

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

speculated_iterations プラグマを使用して、ループ終了条件の計算に必要なサイクル数を指定します。

パフォーマンスを最大限に高めるには、可能な限りネスト化ループを結合して単一ループにします。ループの制御フローでは、ロジックで必要なオーバーヘッドと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 プラグマ) を参照してください。

次のチュートリアルでも確認できます。 <quartus_installdir>/hls/examples/tutorials/best_practices/loop_coalesce

変数の実装に必要なFPGAハードウェア・リソースを低減するためには、変数の宣言は、ループでの使用直前に行います。変数の宣言を可能な限り最も深いスコープで行うと、データ依存関係とFPGAハードウェア使用率が最小限に抑えられます。これは、 インテル^®HLSコンパイラー プロ・エディションによる変数データの保持は、変数を使用しないループでは必要がないためです。

次の例を検討します。

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/component_memories

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

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

• hls_bankwidth(N)
• hls_numbanks(N)
• hls_singlepump
• hls_max_replicates(N)

元のコードによって2つのメモリーアクセスが結合し、結果として、深さ256の位置、64ビット幅 (256x64ビット) のメモリーシステム (2つのオンチップ・メモリー・ブロック) になります。

component unsigned int mem_coalesce_default(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;
}

次の画像で示すのは、このコードサンプルの256x64ビットメモリーの構造と、ハイレベルのデザインレポート ( report.html ) でのコンポーネント・メモリー構造の表示方法です。

図 10.  mem_coalesce_default 用に生成されたメモリー構造

変更されたコードによって実装されるのは、512のワード深さ、32ビット幅で、ストール可能なアービトレーションを備えたオンチップ・メモリー・ブロックです。

component unsigned int mem_coalesce_override(unsigned int raddr,
                                             unsigned int waddr,
                                             unsigned int wdata){
    //Attributes that stop memory coalescing
    hls_bankwidth(4) hls_numbanks(1)
    //Attributes that specify a single-pumped single-replicate memory
    hls_singlepump hls_max_replicates(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;
} 

次の画像で示すのは、このコードサンプルのストール可能なアービトレーションを備えた512x32ビットメモリーの構造と、ハイレベルのデザインレポート ( report.html ) でのコンポーネント・メモリー構造の表示方法です。

図 11.  mem_coalesce_default 用に生成されたメモリー構造

ハードウェア領域の節約は、コンポーネントに必要なRAMブロック数の削減によってできるように見えますが、ストール可能なアービトレーションの導入により、コンポーネントの実装に必要なハードウェアの量が増えます。次の表では、コンポーネントに必要なALMとFFの数の比較ができます。

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

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

• hls_bankwidth(N)
• hls_numbanks(N)
• hls_singlepump
• hls_doublepump

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

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;
}

バンクメモリーの節約のために、ダブルパンプ32ビット幅オンチップ・メモリー・ブロックのバンクを1つ実装します。このためには、次の属性の追加を data[1024] の宣言前に行います。この属性によって、半分使用したメモリーバンク2つを折りたたんで、完全に使用したメモリーバンク (ダブルパンプ済み) 1つにします。これにより、半分使用したメモリーバンク2つと同じ速さでのアクセスが可能になります。

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

あるいは、ダブルパンプされたメモリーのダブルクロック要件を回避するために、シングルパンプ・オンチップ・メモリー・ブロックのバンクを1つ実装します。このためには、次の属性の追加を data[1024] の宣言前に行います。ただし、この例では、この属性によってストール可能なアービトレーションがコンポーネント・メモリーに追加され、コンポーネントのパフォーマンスが低下します。

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

場合によっては、FPGAメモリーブロックを節約するために、コンポーネント・メモリーをマージします。これにより、消費するメモリー・ブロックが少なくなり、コンポーネントで使用する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;
}

このコードによる インテル^®HLSコンパイラー プロ・エディションへの指示によって、ローカルメモリー a および b の実装をそれぞれ独自のロード/ストア命令を備えた 2つのオンチップ・メモリーブロックとして行います。

ローカルメモリー 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コンパイラー プロ・エディションでは、メモリーシステムをダブルパンプし、すべてのアクセスに十分なポートを提供する可能性があります。それ以外の場合、アクセスにはポートを共有してください。これによって、ストールフリーのアクセスを防止します。

hls_merge("<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;
}

(b ₀ , b ₁ , ... ,b _n ) 引数では、ローカル・メモリー・アドレスのビット位置を参照します。 インテル^®HLSコンパイラー プロ・エディションでは、このビット位置をバンク選択ビットに使用します。hls_bankbits(b ₀, b ₁ , ..., b _n) 属性の指定は、バンクの数が 2 ^{number of bank bits} に等しいことを意味します。

hls_bankbits 属性の実装例

次のコンポーネントコードの例を検討します。

¹

component int bank_arbitration (int raddr,
                                int waddr,
                                int wdata) {

  #define DIM_SIZE 4

  // Adjust memory geometry by preventing coalescing
  hls_numbanks(1)
  hls_bankwidth(sizeof(int)*DIM_SIZE)

  // Force each memory bank to have 2 ports for read/write
  hls_singlepump
  hls_max_replicates(1) 

  int a[DIM_SIZE][DIM_SIZE][DIM_SIZE];
  // initialize array a…
  int result = 0; 
 
  #pragma unroll
  for (int dim1 = 0; dim1 < DIM_SIZE; dim1++)
    #pragma unroll
    for (int dim3 = 0; dim3 < DIM_SIZE; dim3++)
      a[dim1][waddr&(DIM_SIZE-1)][dim3] = wdata;

  #pragma unroll
  for (int dim1 = 0; dim1 < DIM_SIZE; dim1++)
    #pragma unroll
    for (int dim3 = 0; dim3 < DIM_SIZE; dim3++)
      result += a[dim1][raddr&(DIM_SIZE-1)][dim3];

  return result;
}

次の図で示すとおり、このコード例によって複数のロード/ストアユニット (LSU) が生成され、それによって、複数のロードおよびストア命令がハードウェアに生成されます。メモリーシステムが複数のバンクに分割されていない場合、メモリーアクセス命令よりもポート数が少なくなり、アービトレーションされたアクセスにつながります。このアービトレーションにより、ループ開始間隔 (II) の値が高くなります。アービトレーションは、可能な限り避けてください。これは、アービトレーションによってコンポーネントのFPGAエリアの使用率が増加し、コンポーネントのパフォーマンスが低下するためです。

図 18. コンポーネント bank_arbitration のローカルメモリーaへのアクセス

デフォルトでは、 インテル^®HLSコンパイラー プロ・エディションでは、分割がコンポーネントのパフォーマンスに有益であると判断した場合、メモリーをバンクに分割します。コンパイラーでは、アクセス間で一定のビットが残っているかどうかを確認し、バンク選択ビットを自動的に推測します。

次のコンポーネントコードの例を検討します。

component int bank_no_arbitration (int raddr, 
                                   int waddr, 
                                   int wdata) {
  #define DIM_SIZE 4

  // Adjust memory geometry by preventing coalescing and splitting memory
  hls_bankbits(4, 5)
  hls_bankwidth(sizeof(int)*DIM_SIZE)

  // Force each memory bank to have 2 ports for read/write
  hls_singlepump
  hls_max_replicates(1)
 
  int a[DIM_SIZE][DIM_SIZE][DIM_SIZE];

  // initialize array a…
  int result = 0; 
 
  #pragma unroll
  for (int dim1 = 0; dim1 < DIM_SIZE; dim1++)
    #pragma unroll
    for (int dim3 = 0; dim3 < DIM_SIZE; dim3++)
      a[dim1][waddr&(DIM_SIZE-1)][dim3] = wdata;

  #pragma unroll
  for (int dim1 = 0; dim1 < DIM_SIZE; dim1++)
    #pragma unroll
    for (int dim3 = 0; dim3 < DIM_SIZE; dim3++)
      result += a[dim1][raddr&(DIM_SIZE-1)][dim3];

  return result;
}

次の図で示しているとおり、このサンプルコードによって作成されるメモリー・コンフィグレーションには4つのバンクが備わっています。ビット4および5をバンク選択ビットとして使用すると、各ロード/ストアアクセスは、確実にそれ自体のメモリーバンクに送られます。

図 19. コンポーネント bank_no_arbitration のローカルメモリーaへのアクセス

このコード例では、hls_bankbits(4,5) ではなく hls_numbanks(4) を設定すると、同じメモリー・コンフィグレーション結果になります。これは、 インテル^®HLSコンパイラー プロ・エディションでは、最適なバンク選択ビットを自動的に推測するためです。

Function Memory Viewer (High-Level Design Report内) では、 Address bit information によって表示されるバンク選択ビットは、b6 および b7 です。b4 および b5 ではありません。

この違いが発生する理由は、Function Memory Viewerで報告されるアドレスビットが、要素アドレスではなくバイトアドレスに基づいているためです。配列 a のすべての要素のサイズは4バイトであるため、要素アドレスビットのビット b4 および b5 の対応先は、バイトアドレス指定のビット b6 および b7 になります。

component void foo() {
  // first loop
  for (int i = 0; i < n; i++) {
    // Do something
  }
  // second loop
  for (int i = 0; i < m; i++) {
    // Do something else
  }
}

void offloaded_work() {
  // first loop
  for (int i = 0; i < n; i++) {
    // Do something
  }
}

component void foo() {
  ihc::launch(offloaded_work);
  // second loop
  for (int i = 0; i < m; i++) {
    // Do something else
  }
  ihc::collect(offloaded_work);
}

チュートリアル <quartus_installdir>/hls/examples/tutorials/system_of_tasks/parallel_loop で 、複数ループの並列実行方法についての詳細を参照してください。

複数の場所からタスクへのコールを許可するには、 インテル^®HLSコンパイラー プロ・エディションでは、アービトレーション・ロジックの生成をコールされたタスク関数に対して行います。このアービトレーション・ロジックによって、コンポーネントの領域使用率を高めることができます。共有ロジックが大きい場合は、トレードオフによりFPGAリソースの節約ができます。この節約が特に顕著になるのは、コンポーネントの大きな計算ブロックが、常にアクティブではない場合です。

チュートリアル <quartus_installdir>/hls/examples/tutorials/system_of_tasks/resource_sharing で、計算ブロックをコンポーネントで共有する方法の簡単な例を参照してください。

タスクのシステムを使用しない場合、HLSコンポーネントの関数コールはインライン化され、呼び出しコードとともに最適化されます。これは状況によっては有害な場合があります。タスクのシステムを使用して、デザインの小さなブロックがシステムの他の部分の影響を受けないようにします。

通常、このパフォーマンスの問題の原因は、ihc::launch および ihc::collect 呼び出しを使用してタスク関数を呼び出す関数のデータパスの容量不足です。このような場合、システムのスループットを改善するには、明示的なストリームにバッファーを追加して、タスク関数のレイテンシーを考慮します。

インテル^®HLSコンパイラー プロ・エディションのエミュレーターでは、ストリームに接続されたバッファーのサイズをモデル化します。ただし、エミュレーターでは、ハードウェアのレイテンシーを完全には考慮しておらず、こういったケースではシミュレーションとエミュレーションの間で異なる動作を示す場合があります。

デザインのアルゴリズムのボトルネックを最適化した後、コンポーネント内の一部のデータ型を微調整することができます。このためには、任意の精度のデータ型を使用して、データ幅を縮小します。 インテル^®HLSコンパイラー プロ・エディションのデバッグ機能では、任意の精度データ型のオーバーフローを簡単に検出することができます。

C++では、short や char などの小さいデータ型を32ビットに自動昇格させ、加算やビットシフトなどの操作に使用します。このため、コンポーネント内に狭いデータパスを作成する場合は、任意の精度のデータ型を使用してください。

<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);
}