Vitis HLS のプログラム

次のコードは、基本的な算術演算を実行します。

#include "types.h"

void apint_arith(dinA_t  inA, dinB_t  inB, dinC_t  inC, dinD_t  inD,
          dout1_t *out1, dout2_t *out2, dout3_t *out3, dout4_t *out4
  ) {

 // Basic arithmetic operations
 *out1 = inA * inB;
 *out2 = inB + inA;
 *out3 = inC / inA;
 *out4 = inD % inA;
}

dinA_t や dinB_t などのデータ型は、ヘッダー ファイル types.h で定義されます。types.h などのプロジェクト全体に適用されるヘッダー ファイルを使用すると、標準 C 型から任意精度型に簡単に移行でき、任意精度型を最適なサイズに調整できるようになります。

上記の例のデータ型は次のように定義されているとします。

typedef char dinA_t;
typedef short dinB_t;
typedef int dinC_t;
typedef long long dinD_t;
typedef int dout1_t;
typedef unsigned int dout2_t;
typedef int32_t dout3_t;
typedef int64_t dout4_t;

この場合、合成後の結果は次のようになります。

+ Timing (ns): 
    * Summary: 
    +---------+-------+----------+------------+
    |  Clock  | Target| Estimated| Uncertainty|
    +---------+-------+----------+------------+
    |default  |   4.00|      3.85|        0.50|
    +---------+-------+----------+------------+

+ Latency (clock cycles): 
    * Summary: 
    +-----+-----+-----+-----+---------+
    |  Latency  |  Interval | Pipeline|
    | min | max | min | max |   Type  |
    +-----+-----+-----+-----+---------+
    |   66|   66|   67|   67|   none  |
    +-----+-----+-----+-----+---------+
* Summary: 
+-----------------+---------+-------+--------+--------+
|       Name      | BRAM_18K| DSP48E|   FF   |   LUT  |
+-----------------+---------+-------+--------+--------+
|Expression       |        -|      -|       0|      17|
|FIFO             |        -|      -|       -|       -|
|Instance         |        -|      1|   17920|   17152|
|Memory           |        -|      -|       -|       -|
|Multiplexer      |        -|      -|       -|       -|
|Register         |        -|      -|       7|       -|
+-----------------+---------+-------+--------+--------+
|Total            |        0|      1|   17927|   17169|
+-----------------+---------+-------+--------+--------+
|Available        |      650|    600|  202800|  101400|
+-----------------+---------+-------+--------+--------+
|Utilization (%)  |        0|   ~0  |       8|      16|
+-----------------+---------+-------+--------+--------+

ただし、次のような例のように、データ幅をインプリメントするのに標準 C 型を使用する必要がなく、一部の幅は狭いが、次に小さい標準 C 型よりは広い場合があるとします。

typedef int6 dinA_t;
typedef int12 dinB_t;
typedef int22 dinC_t;
typedef int33 dinD_t;
typedef int18 dout1_t;
typedef uint13 dout2_t;
typedef int22 dout3_t;
typedef int6 dout4_t;

合成結果では、最大クロック周波数とレイテンシが改善し、エリア使用量が 75% 削減されています。

+ Timing (ns): 
    * Summary: 
    +---------+-------+----------+------------+
    |  Clock  | Target| Estimated| Uncertainty|
    +---------+-------+----------+------------+
    |default  |   4.00|      3.49|        0.50|
    +---------+-------+----------+------------+

+ Latency (clock cycles): 
    * Summary: 
    +-----+-----+-----+-----+---------+
    |  Latency  |  Interval | Pipeline|
    | min | max | min | max |   Type  |
    +-----+-----+-----+-----+---------+
    |   35|   35|   36|   36|   none  |
    +-----+-----+-----+-----+---------+
* Summary: 
+-----------------+---------+-------+--------+--------+
|       Name      | BRAM_18K| DSP48E|   FF   |   LUT  |
+-----------------+---------+-------+--------+--------+
|Expression       |        -|      -|       0|      13|
|FIFO             |        -|      -|       -|       -|
|Instance         |        -|      1|    4764|    4560|
|Memory           |        -|      -|       -|       -|
|Multiplexer      |        -|      -|       -|       -|
|Register         |        -|      -|       6|       -|
+-----------------+---------+-------+--------+--------+
|Total            |        0|      1|    4770|    4573|
+-----------------+---------+-------+--------+--------+
|Available        |      650|    600|  202800|  101400|
+-----------------+---------+-------+--------+--------+
|Utilization (%)  |        0|   ~0  |       2|       4|
+-----------------+---------+-------+--------+--------+

2 つのデザイン間でレイテンシが大きく異なるのは、除算および余りの計算に複数サイクルかかるからです。デザインを標準 C 型にフィットさせるよりも、AP 型を使用した方が、同じ精度でパフォーマンスが高く、リソース使用量の少ない高品質のハードウェア インプリメンテーションが得られます。

Vitis HLS では、C++ の整数および固定小数点の任意精度型が提供されています。

Vitis HLS には、任意精度型を定義するヘッダー ファイルもスタンドアロン パッケージとして含まれており、ソース コードで使用できるようになっています。xilinx_hls_lib_<release_number>.tgz パッケージは、Vitis HLS インストール ディレクトリの include ディレクトリに含まれます。パッケージには、ap_cint.h で定義された C 任意精度型は含まれません。これらのデータ型は、標準 C コンパイラとは一緒に使用できず、Vitis HLS でのみ使用できるようになっています。

#include "ap_int.h"

void foo_top (…) {

ap_int<9>  var1;           // 9-bit
ap_uint<10>  var2;           // 10-bit unsigned

#define AP_INT_MAX_W 4096 // Must be defined before next line
#include "ap_int.h"

ap_int<4096> very_wide_var;

固定小数点型では、データが整数ビットおよび小数ビットとして記述されます。次の例では、Vitis HLS の ap_fixed 型を使用して、18 ビット変数 (6 ビットが整数部、12 ビットが小数部) を定義しています。変数は、符号付きとして指定され、量子化モードは正の無限大の方向に丸めらるように設定されています。オーバーフロー モードは指定されていないので、オーバーフローにはデフォルトの折り返しモードが使用されます。

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

ビット数または精度が異なる変数を含む計算を実行する場合は、2 進小数点が自動的に揃えられます。

固定小数点を使用して実行された C++ シミュレーションの動作は、最終的なハードウェアと同じになります。これにより、ビット精度、量子化、およびオーバーフロー ビヘイビアーを高速の C レベル シミュレーションで解析できるようになります。

固定小数点型は、終了するのに多くのクロック サイクルを必要とする浮動小数点型の代わりに使用できます。浮動小数点型の範囲がすべて必要な場合を除き、固定小数点型で同じ精度をインプリメントでき、より小型で高速なハードウェアにできることがよくあります。

次の表に、ap_fixed 型の識別子を示します。

ap_[u]fixed 型に使用可能なデフォルトの最大幅は 1024 ビットです。このデフォルトは、ap_int.h ヘッダー ファイルを含める前に、32768 以下の正の整数値でマクロ AP_INT_MAX_W を定義すると上書きできます。

次に、AP_INT_MAX_W を上書きする例を示します。

#define AP_INT_MAX_W 4096 // Must be defined before next line
#include "ap_fixed.h"

ap_fixed<4096> very_wide_var;

Vitis HLS を使用する場合は、任意精度型の使用をお勧めします。前の例で示したように、任意精度型を使用すると、ハードウェア インプリメンテーションの質がかなり向上するという利点があります。

型修飾子は、高位合成で作成されるハードウェアに直接影響します。通常、修飾子は次に示すように合成結果に影響を与えますが (予測可能)、Vitis HLS は、修飾子の解釈によってのみ制限されます。これは、修飾子が関数の動作に影響を与え、最適化を実行してより最適なハードウェア デザインを作成できるからです。この例は、各修飾子の概要の後に示します。

垂直たたみ込みでは、FPGA 向けのストリーミング データ モデルを記述するのが困難です。データには列ごとにアクセスする必要がありますが、画像全体を格納するのは望ましくありません。ソリューションは、次の図に示すようにライン バッファーを使用することです。

サンプルはストリーミング方式で読み込まれますが、この場合は hls::stream hconv から読み込まれます。このアルゴリズムでは、最初のサンプルを処理するのに少なくとも K-1 行のデータが必要です。これより前に実行された計算はすべて削除されます。

ライン バッファーには、K-1 行のデータを格納できます。新しいサンプルが読み込まれるたびに、別のサンプルがライン バッファーから排出されます。つまり、最新のサンプルが計算に使用されると、そのサンプルがライン バッファーに格納され、古いサンプルが排出されます。この結果、キャッシュされる必要があるのは K 行ではなく、K-1 行のみになります。ライン バッファーにはローカルで格納するために複数行が必要ですが、たたみ込みのカーネル サイズ K はフル ビデオ画像の 1080 行よりもかなり小さくなります。

最初の計算は、K 行目にある最初のサンプルが読み込まれると実行されます。その後、最後のピクセルが読み込まれるまで値が出力されます。

// Vertical convolution 
VConvH:for(int col = 0; col < height; col++) {
 VConvW:for(int row = 0; row < vconv_xlim; row++) {
#pragma HLS DEPENDENCE variable=linebuf inter false
#pragma HLS PIPELINE
  T in_val = hconv.read();
  T out_val = 0;
  VConv:for(int i = 0; i < K; i++) {
     T vwin_val = i < K - 1 ? linebuf[i][row] : in_val;
     out_val += vwin_val * vcoeff[i];
     if (i > 0)
       linebuf[i - 1][row] = vwin_val;
  }
  if (col >= K - 1)
     vconv << out_val;
 }
}

上記のコードでは、デザインのサンプルがすべてストリーミング方式で処理されます。タスクは、継続して実行されます。hls::stream コンストラクトを使用すると、データがローカルにキャッシュされます。これは、FPGA をターゲットにする場合の理想的なストラテジです。

このアルゴリズムの最後には、エッジ ピクセルを境界領域に複製します。一定したフローまたはデータ/データ再利用を実現するには、アルゴリズムで hls::stream とキャッシュが使用されるようにします。

次の図に、境界サンプルがどのように画像に組み込まれるかを示します。

• 各サンプルが垂直たたみ込みからの vconv 出力から読み込まれます。
• 次に、サンプルが 4 つのピクセル タイプのいずれかとしてキャッシュに格納されます。
• サンプルが出力ストリームに書き出されます。

次は、境界ピクセルの位置を決定するコードです。

Border:for (int i = 0; i < height; i++) {
 for (int j = 0; j < width; j++) {
  T pix_in, l_edge_pix, r_edge_pix, pix_out;
#pragma HLS PIPELINE
 if (i == 0 || (i > border_width && i < height - border_width)) {
   if (j < width - (K - 1)) {
     pix_in = vconv.read();
     borderbuf[j] = pix_in;
   }
   if (j == 0) {
     l_edge_pix = pix_in;
   }
   if (j == width - K) {
     r_edge_pix = pix_in;
   }
 }
 if (j <= border_width) {
   pix_out = l_edge_pix;
 } else if (j >= width - border_width - 1) {
    pix_out = r_edge_pix;
 } else {
    pix_out = borderbuf[j - border_width];
 }
 dst << pix_out;
 }
 }
}

このコードの明らかな違いは、タスク内に条件文が多く使用されている点です。これにより、タスクはパイプラインされたら、データを続けて処理し、条件文の結果によりパイプラインの実行が影響を受けることはありません。結果は出力値には影響しますが、パイプラインは入力サンプルが使用できる限り、処理され続けます。

この FPGA に最適なアルゴリズムを含む最終的なコードには、次の最適化指示子が使用されます。

template<typename T, int K>
static void convolution_strm(
int width, 
int height,
hls::stream<T> &src, 
hls::stream<T> &dst,
const T *hcoeff, 
const T *vcoeff)
{
#pragma HLS DATAFLOW
#pragma HLS ARRAY_PARTITION variable=linebuf dim=1 complete

hls::stream<T> hconv("hconv");
hls::stream<T> vconv("vconv");
// These assertions let HLS know the upper bounds of loops
assert(height < MAX_IMG_ROWS);
assert(width < MAX_IMG_COLS);
assert(vconv_xlim < MAX_IMG_COLS - (K - 1));

// Horizontal convolution 
HConvH:for(int col = 0; col < height; col++) {
 HConvW:for(int row = 0; row < width; row++) {
#pragma HLS PIPELINE
   HConv:for(int i = 0; i < K; i++) {
 }
 }
}
// Vertical convolution 
VConvH:for(int col = 0; col < height; col++) {
 VConvW:for(int row = 0; row < vconv_xlim; row++) {
#pragma HLS PIPELINE
#pragma HLS DEPENDENCE variable=linebuf inter false
   VConv:for(int i = 0; i < K; i++) {
 }
}

Border:for (int i = 0; i < height; i++) {
 for (int j = 0; j < width; j++) {
#pragma HLS PIPELINE
 }
}

各タスクは、同レベルでパイプラインされます。ライン バッファーはレジスタに完全に分割され、ブロック RAM ポートの不足によって読み出しまたは書き込みが制限されることはありません。ライン バッファーには、依存指示子も必要です。すべてのタスクがデータフロー領域で実行され、タスクが同時処理されるようになります。hls::streams は 1 要素を含む FIFO として自動的にインプリメントされます。

データ入力の読み込みを最小限にします。データがブロックに読み込まれると、多くの並列パスに簡単に供給できますが、入力ポートがパフォーマンスのボトルネックになることがあります。データを読み込んだ後、再利用する必要がある場合は、ローカル キャッシュを使用します。

配列、特に大型の配列へのアクセスを最小限に抑えます。配列はブロック RAM にインプリメントされますが、ブロック RAM では I/O ポートと同様ポート数が限られるので、パフォーマンスのボトルネックになることがあります。配列は小型の配列および個別のレジスタに分割できますが、大型の配列を分割すると使用されるレジスタ数が多くなります。小型のローカル キャッシュを使用して累積などの結果を保持してから、最終結果を配列に書き出すようにします。

パイプライン処理されたタスクであっても、タスクを条件で実行するのではなく、パイプライン処理されたタスク内で条件分岐を実行するようにします。条件文は、パイプラインで別々のパスとしてインプリメントされます。データが 1 つのタスクから次のタスク内で実行される条件に流れるようにすると、システムのパフォーマンスが向上します。

入力の読み出しと同様に、ポートはボトルネックになるので、出力の書き込みも最低限にします。追加ポートを複製すると、単に問題がシステムに先送りになるだけです。

ストリーミング方式でデータを処理する C コードの場合、優れたコード記述になるので、hls::streams を使用することをお勧めします。なぜ FPGA が必要なパフォーマンスで動作しないのかデバッグするよりも、優れたパフォーマンスの FPGA インプリメンテーションになる C のアルゴリズムを設計する方が生産的です。

Vitis HLS でサポートされる AXI4 インターフェイスには、AXI4-Stream (axis)、AXI4-Lite (s_axilite)、および AXI4 マスター (m_axi) インターフェイスがあります。

タイミングおよびポートを含む AXI4 インターフェイスの詳細は、『Vivado Design Suite: AXI リファレンス ガイド』 (UG1037: 英語版、日本語版) を参照してください。この I/O プロトコルの機能すべてについては、AXI4 インターフェイスの使用を参照してください。

ap_none および ap_stable モードは、ポートに追加する I/O ポートがないことを指定します。これらのモードを指定すると、引数が関連信号のないデータ ポートとしてインプリメントされます。ap_none モードは、スカラー入力のデフォルトです。ap_stable モードは、デバイスがリセット モードのときにのみ変化するコンフィギュレーション入力用です。

インターフェイス モード ap_hs には、データ ポートの付いた 2 方向のハンドシェイク信号が含まれます。業界標準の有効 (valid) と承認 (acknowledge) ハンドシェイクに使用されます。ap_vld モードの場合は valid ポートしかなく、ap_ack モードの場合は acknowledge ポートしかありません。

入出力引数には、ap_ovld モードを使用します。入出力が入力ポートと出力ポートに分割される場合は、ap_none モードが入力ポートに、ap_vld モードが出力ポートに使用されます。これが、読み出しと書き込みの両方に使用されるポインター引数のデフォルトです。

ap_hs モードは、順に読み出しまたは書き込みが実行される配列に使用できます。Vitis HLS では読み出しまたは書き込みアクセスが順に実行されない場合はそれが検出され、エラー メッセージが表示されて合成が停止します。アクセス順序が決定できない場合は、Vitis HLS で警告メッセージが表示されます。

ap_hs (ap_ack、ap_vld、および ap_ovld)

ap_hs ポート レベル I/O プロトコルを使用すると、開発プロセス中の柔軟性が最大となり、ボトムアップおよびトップダウン デザイン フローの両方が可能になります。2 方向ハンドシェイクによりすべてのブロック間の通信が安全に実行されるので、正しい動作に手動の介入や想定は必要ありません。ap_hs ポート レベル I/O プロトコルには、次の信号が含まれます。

• データ ポート
• データが受信されたことを示す承認 (ACK) 信号。
• データが読み出されたことを示す Valid 信号。

次の図に、入力ポートと出力ポートでの ap_hs インターフェイスの動作を示します。この例では、入力ポート名は in、出力ポート名は out です。

注記: 制御信号名は、元のポート名に基づいています。たとえば、データ入力 in の valid ポートの名前は in_vld です。

入力では、次のようになります。

• ap_start が High になると、ブロックが通常の動作を開始します。
• デザインが入力データを読み出す準備ができても、valid 入力が Low の場合デザインは停止し、valid 入力が High になって新しい入力値が有効であることが示されるまで待機します。
  注記: 前の図は、この動作を示しています。この例では、デザインはクロック サイクル 4 でデータ入力を読み出す準備ができ、データを読み出す前に valid 入力を待ちます。
• valid 入力が High になると、承認出力が High になり、データが読み出されたことが示されます。

出力では、次のようになります。

• ap_start が High になると、ブロックが通常の動作を開始します。
• 出力ポートへの書き込みが実行されると、同時に valid 出力信号が High になり、ポートに valid データが存在することが示されます。
• in_ack 入力が Low の場合、デザインが停止し、in_ack 入力が High になるまで待機します。
• in_ack 入力が High になると、次のクロック エッジで valid 出力が Low になります。

配列引数は、デフォルトでは ap_memory インターフェイスとしてインプリメントされます。これは、データ ポート、アドレス ポート、チップイネーブル ポート、ライトイネーブル ポートを含む標準ブロック RAM インターフェイスです。

ap_memory インターフェイスは、デュアル ポート インターフェイスのシングル ポートとしてインプリメントされる可能性があります。Vitis HLS でデュアル ポート インターフェイスを使用することで開始間隔 (II) が削減されると判断された場合は、デュアル ポート インターフェイスが自動的にインプリメントされます。BIND_STORAGE プラグマまたは指示子を使用してメモリ リソースを指定し、シングル ポート ブロック RAM を含む配列に指定した場合は、シングル ポート インターフェイスがインプリメントされます。また、BIND_STORAGE プラグマでデュアル ポート インターフェイスを指定していても、このインターフェイスを使用しても利点がないと Vitis HLS で判断された場合は、シングル ポート インターフェイスが自動的にインプリメントされます。

bram インターフェイス モードは、ap_memory と機能的には同じですが、デザインが Vitis IP インテグレーターで使用される際のポートのインプリメント方法が異なります。

• ap_memory インターフェイスは複数の別々のポートとして表示されます。
• bram インターフェイスは 1 つのまとまったポートとして表示され、1 つのポイント ツー ポイント接続を使用してザイリンクス ブロック RAM に接続できます。

配列がシーケンシャルにアクセスされる場合は、ap_fifo インターフェイスを使用できます。ap_hs インターフェイスを使用した場合と同様、データ アクセスがシーケンシャルでないと判断されたら Vitis HLS が停止します。アクセスがシーケンシャルかどうか判別できなかった場合は警告メッセージが表示され、シーケンシャルであると判断された場合はメッセージは表示されません。ap_fifo は、読み出しまたは書き込みのいずれかにのみ使用可能で、両方には使用できません。

ap_memory、bram

ap_memory および bram インターフェイス ポート レベル I/O プロトコルは、配列引数をインプリメントするために使用されます。このタイプのポート レベル I/O プロトコルは、インプリメンテーションでメモリのアドレス ロケーションにランダム アクセスが必要な場合に、メモリ エレメント (RAM、ROM など) と通信するために使用されます。

注記: メモリ エレメントへの順次アクセスのみが必要な場合は、ap_fifo インターフェイスを使用してください。ap_fifo インターフェイスを使用すると、アドレス生成は実行されないので、ハードウェア オーバーヘッドが削減します。

ap_memory と bram インターフェイス ポート レベル I/O プロトコルは同じですが、Vivado IP インテグレーターでのブロックの表示方法だけが異なります。

• ap_memory インターフェイスは個別のポートとして表示される。
• bram インターフェイスは 1 つのポートとして表示される。IP インテグレーターでは、1 つの接続を使用して、すべてのポートへの接続を作成できます。

ap_memory インターフェイスを使用する場合は、BIND_STORAGE 指示子を使用して配列ターゲットを指定してください。配列に対してターゲットを指定しない場合は、Vitis HLS でシングル ポートまたはデュアル ポート RAM インターフェイスのいずれかが指定されます。

ヒント: 合成を実行する前に、配列引数が BIND_STORAGE プラグマを使用して正しいメモリ タイプをターゲットにしているかどうかを確認してください。変更されたメモリを使用して合成し直すと、スケジューリングおよび RTL の結果が異なることがあります。

次の図では、d という配列がシングル ポート ブロック RAM として指定されています。ポート名は、C 関数引数に基づいています。たとえば、C 関数が d の場合、チップ イネーブルは d_ce、入力データは BRAM の output/q ポートに基づいて d_q0 になります。

リセット後は、次にようになります。

• ap_start が High になると、ブロックが通常の動作を開始します。
• 出力信号 d_ce をアサートしたときに出力アドレス ポートにアドレスを供給することにより、読み出しが実行されます。
  注記: デフォルトのブロック RAM では、入力データ d_q0 が次のクロック サイクルで有効になると想定されます。BIND_STORAGE プラグマを使用すると、RAM の読み出しレイテンシを長くできます。
• 書き込み操作は、出力ポート d_ce と d_we がアサートされ、同時にアドレスと出力データ d_d0 が供給されると実行されます。

ap_fifo

出力ポートが書き込まれると、デザインがメモリ エレメントにアクセスする必要があり、そのアクセスが常に順番に実行される、つまりランダム アクセスが必要ない場合、ap_fifo に関連する出力 valid 信号インターフェイスを使用するのが最もハードウェア効率の良いアプローチです。ap_fifo ポート レベル I/O プロトコルでは、次がサポートされます。

• ポートを FIFO に接続できるようになる
• 完全な 2 方向の empty-full 通信を可能にする
• 配列、ポインター、参照渡し引数タイプに使用できる

注記: ap_fifo インターフェイスを使用可能な関数では、ポインターがよく使用され、同じ変数に複数回アクセスする可能性があります。マルチアクセス ポインター インターフェイス: ストリーミング データを参照し、このコーディング スタイルを使用する場合の volatile 修飾子の重要性を理解してください。

次の例では、in1 は現在のアドレスにアクセスし、その後現在のアドレスの上 2 つのアドレスにアクセスして、最後に 1 つ下のアドレスにアクセスするポインターです。

void foo(int* in1, ...) {
 int data1, data2, data3;  
       ...
 data1= *in1; 
 data2= *(in1+2);
 data3= *(in1-1);
 ...
}

in1 を ap_fifo インターフェイスとして指定すると、Vitis HLS でアクセスがチェックされ、アクセスが順次でない場合はエラー メッセージが表示され、停止します。順次アドレスではないアドレス位置から読み出すには、ap_memory または bram インターフェイスを使用します。

読み出しおよび書き込みの両方に使用される場合、引数に ap_fifo インターフェイスは指定できません。ap_fifo インターフェイスは、入力引数または出力引数にのみ指定可能です。入力引数 in、出力引数 out を ap_fifo インターフェイスとして指定したデザインは、次の図のように動作します。

入力では、次のようになります。

• ap_start が High になると、ブロックが通常の動作を開始します。
• 入力ポートで読み出し準備ができたのに FIFO が空の場合 (in_empty_n 入力ポートが Low)、デザインは停止し、データを読み出せるようになるまで待機します。
• in_empty_n 入力ポートが High になって FIFO にデータが含まれていることが示されると、出力 ACK の in_read が High にアサートされてデータがこのサイクルで読み出されたことが示されます。

出力では、次のようになります。

• ap_start が High になると、ブロックが通常の動作を開始します。
• 出力ポートで書き込み準備ができても、FIFO がフルの場合 (out_full_n が Low)、データは出力ポートに配置されますが、デザインは停止し、FIFO に書き込むスペースができるまで待機します。
• FIFO に書き込むスペースができると (out_full_n 入力が High)、出力 ACK 信号の out_write が High になり、出力データが valid であることが示されます。
• -rewind オプションで最上位関数または最上位ループがパイプライン処理されると、Vitis HLS では _lwr が接尾語に付いた追加の出力ポートが作成されます。FIFO インターフェイスへの最後の書き込みが終了すると、_lwr ポートがアクティブ High になります。

AXI4-Stream は、関数引数 ap_axis 型に AXI4 サイドチャネル エレメントが含まれない場合は、サイドチャネルなしで使用されます。この例では、両方のインターフェイスが AXI4-Stream を使用してインプリメントされます。

#include "ap_axi_sdata.h"
#include "hls_stream.h"
 
 
void example(hls::stream< ap_axis<32>> &A,
         hls::stream< ap_axis<32>> &B)
{
#pragma HLS INTERFACE axis port=A
#pragma HLS INTERFACE axis port=B
 
    ap_axis<32> tmp;
 
    A.read(tmp);
    tmp.data = tmp + 5;
    B.write(tmp);
}

合成後は、次の図に示すように、どちらの引数もデータ ポートと標準 AXI4-Stream の TVALID および TREADY ポートを使用してインプリメントされます。

構造体を使用して複数の変数を 1 つの AXI4-Stream インターフェイスにまとめることができ、Vitis HLS によりデフォルトで統合されます。構造体の要素を 1 つの幅の広いベクターに統合すると、構造体のすべての要素を同じ AXI4-Stream インターフェイスにインプリメントできます。

次の例は、サイドチャネルを C コードで直接使用する方法とインターフェイスへのインプリメント方法を示しています。このコードは、API 用に ap_axi_sdata.h インクルード ファイルを使用して、AXI4-Stream インターフェイスのサイドチャネルを処理します。この例の場合、符号付き 32 ビットのデータ型が使用されています。

#include "ap_axi_sdata.h"
#include "ap_int.h"
#include "hkls_stream.h"

#define DWIDTH 32

typedef ap_axiu<DWIDTH, 0, 0, 0> trans_pkt;

extern "C"{  
   void krnl_stream_vmult(hls::stream<trans+pkt> &b, hls::stream<trans_pkt> &output) {
   #pragma HLS INTERFACE axis port=b
   #pragma HLS INTERFACE axis port=output
   #pragma HLS INTERFACE s_axilite port=return bundle=control

   bool eos = false;
   vmult:
      do {
         #pragma HLS PIPLINE II=1
         trans_pkt t2 = b.read();

         //Patcket for Output
         trans_pkt t_out;

         // Reading data from input packet
         ap_uint<DWIDTH> in2 = t2.data;
         ap_uint<DWIDTH> tmpOut = in2 * 5;

         // Setting data and configuration to output packet
         t_out.data = tmpOut;
         t_out.last = t1.get_last();
         t_out.keep = -1; //Enabling all bytes

         //Writing packet to output stream
         output.write(t_out);

         if(t.get_last()) {
            eos = true;
         }
       } while (eos == false);
   }
}

合成後は、どちらの引数も、データ ポート、標準 AXI4-Stream の TVALID および TREADY プロトコル ポート、および構造体で記述されたオプションのポートすべてを使用してインプリメントされます。

AXI4-Stream インターフェイスと一緒に構造体を使用する場合は、デフォルトの合成動作が異なります。構造体のデフォルトの合成動作については、インターフェイス合成および構造体を参照してください。

サイドチャネルありまたはなしの AXI4-Stream インターフェイスを使用していて、関数引数が構造体の場合、Vitis HLS でその構造体のすべての要素が単一幅のデータ ベクターにまとめられます。インターフェイスは、関連する TVALID および TREADY 信号を使用して単一幅のデータ ベクターとしてインプリメントされます。

サイドチャネルありの AXI4-Stream インターフェイスを使用する場合、Vitis HLS ツールでは RGBPixel などの構造体を axis インターフェイスを介して送信できません。独自の構造体を定義するために ap_axiu 構造体をオーバーロードすることはできません。この制限を回避するには、構造体初期化関数を使用して意図する結果を取得します。

struct RGBPixel
{
    unsigned char r;
    unsigned char g;
    unsigned char b;
    unsigned char a;
 
    RGBPixel(ap_int<32> d) : r(d.range(7,0)), g(d.range(15,8)), b(d.range(23,16)), a(d.range(31,24)) {
#pragma HLS INLINE
    }
 
    operator ap_int<32>() {
#pragma HLS INLINE
        return (ap_int<8>(a), ap_int<8>(b), ap_int<8>(g), ap_int<8>(r));
    }
 
}__attribute__((aligned(4)));

デフォルトでは、Vitis HLS では AXI4-Lite インターフェイスと合成済みデザインに同じクロックが使用されます。また、Vitis HLS では、AXI4-Lite インターフェイスのすべてのレジスタが合成されたロジック (ap_clk) に使用されるクロックに接続されます。

INTERFACE 指示子に clock オプションを使用すると、AXI4-Lite ポートごとに別々のクロックを指定できます (オプション)。クロックを AXI4-Lite インターフェイスに接続する場合は、次のプロトコルを使用する必要があります。

• AXI4-Lite インターフェイス クロックは、合成されたロジック (ap_clk) に使用されるクロックと同期している必要があります。つまり、どちらのクロックも同じマスター ジェネレーター クロックから派生している必要があります。
• AXI4-Lite インターフェイス クロックの周波数は、合成されたロジック (ap_clk) に使用されるクロックの周波数以下にする必要があります。

インターフェイス指示子に clock オプションを使用する場合、clock オプションは各バンドルの 1 つの関数引数に指定するだけです。Vitis HLS では、バンドル内のその他すべての関数引数が同じクロックとリセットを使用してインプリメントされます。Vitis HLS では、リセット信号が ap_rst_ の後にクロック名が付いた名前で生成されます。生成されるリセット信号は、config_rtl コマンドとは関係なくアクティブ Low になります。

次の例では、Vitis HLS で関数引数 a および b が AXI_clk1 というクロックと関連するリセット ポートと一緒に AXI4-Lite ポートにまとめられるところを示しています。

// Default AXI-Lite interface implemented with independent clock called AXI_clk1
#pragma HLS interface s_axilite port=a clock=AXI_clk1
#pragma HLS interface s_axilite port=b 

次の例では、Vitis HLS で関数引数 c および d が CTRL1 というクロックと関連するリセット ポートを使用して AXI4-Lite ポートの AXI_clk2 にまとめられるところを示しています。

// CTRL1 AXI-Lite bundle implemented with a separate clock (called AXI_clk2)
#pragma HLS interface s_axilite port=c bundle=CTRL1 clock=AXI_clk2
#pragma HLS interface s_axilite port=d bundle=CTRL1

C ドライバー ファイルは、常にデータ転送に 32 ビット符号なし整数 (U32) を使用します。次の例では、関数で float 型の引数 a と r1 が使用されています。a の値が設定され、r1 の値が返されます。

float caculate(float a, float *r1)
{
#pragma HLS INTERFACE ap_vld register port=r1
#pragma HLS INTERFACE s_axilite port=a 
#pragma HLS INTERFACE s_axilite port=r1 
#pragma HLS INTERFACE s_axilite port=return 

 *r1 = 0.5f*a;
 return (a>0);
}

合成後、Vitis HLS ですべてのポートがデフォルトの AXI4-Lite インターフェイスにまとめられ、C ドライバー ファイルが作成されますが、次の図に示すように、ドライバー ファイルでは U32 型が使用されています。

// API to set the value of A
void XCaculate_SetA(XCaculate *InstancePtr, u32 Data) {
    Xil_AssertVoid(InstancePtr != NULL);
    Xil_AssertVoid(InstancePtr->IsReady == XIL_COMPONENT_IS_READY);
    XCaculate_WriteReg(InstancePtr->Hls_periph_bus_BaseAddress, 
XCACULATE_HLS_PERIPH_BUS_ADDR_A_DATA, Data);
}

// API to get the value of R1
u32 XCaculate_GetR1(XCaculate *InstancePtr) {
    u32 Data;

    Xil_AssertNonvoid(InstancePtr != NULL);
    Xil_AssertNonvoid(InstancePtr->IsReady == XIL_COMPONENT_IS_READY);

    Data = XCaculate_ReadReg(InstancePtr->Hls_periph_bus_BaseAddress, 
XCACULATE_HLS_PERIPH_BUS_ADDR_R1_DATA);
    return Data;
}

これらの関数が float 型で直接使用できる場合は、書き込み値および読み出し値が予測される float 型と一貫しません。これらの関数をソフトウェアで使用する場合は、次を使用して型を変換します。

float a=3.0f,r1;
u32 ua,ur1;

// cast float “a” to type U32
XCaculate_SetA(&calculate,*((u32*)&a));
ur1=XCaculate_GetR1(&caculate);

// cast return type U32 to float type for “r1”
r1=*((float*)&ur1);

ハードウェア ヘッダー ファイル (この例の場合 xexample_hw.h) には、AXI4-Lite スレーブ インターフェイスにまとめられたポートのメモリ マップド ロケーションのリストが含まれます。

// 0x00 : Control signals
//        bit 0  - ap_start (Read/Write/SC)
//        bit 1  - ap_done (Read/COR)
//        bit 2  - ap_idle (Read)
//        bit 3  - ap_ready (Read)
//        bit 7  - auto_restart (Read/Write)
//        others - reserved
// 0x04 : Global Interrupt Enable Register
//        bit 0  - Global Interrupt Enable (Read/Write)
//        others - reserved
// 0x08 : IP Interrupt Enable Register (Read/Write)
//        bit 0  - Channel 0 (ap_done)
//        bit 1  - Channel 1 (ap_ready)
// 0x0c : IP Interrupt Status Register (Read/TOW)
//        bit 0  - Channel 0 (ap_done)
//        others - reserved
// 0x10 : Data signal of a
//        bit 7~0 - a[7:0] (Read/Write)
//        others  - reserved
// 0x14 : reserved
// 0x18 : Data signal of b
//        bit 7~0 - b[7:0] (Read/Write)
//        others  - reserved
// 0x1c : reserved
// 0x20 : Data signal of c_i
//        bit 7~0 - c_i[7:0] (Read/Write)
//        others  - reserved
// 0x24 : reserved
// 0x28 : Data signal of c_o
//        bit 7~0 - c_o[7:0] (Read)
//        others  - reserved
// 0x2c : Control signal of c_o
//        bit 0  - c_o_ap_vld (Read/COR)
//        others - reserved
// (SC = Self Clear, COR = Clear on Read, TOW = Toggle on Write, COH = Clear on 
Handshake)

AXI4-Lite スレーブ インターフェイスのレジスタを正しくプログラムするには、ハードウェア ポートがどのように動作するのかを理解しておく必要があります。インターフェイス合成の I/O プロトコルで説明したように、ブロックは同じポート プロトコルで操作されます。

たとえば、ブロック操作を開始するには ap_start レジスタを 1 に設定する必要があります。次にデバイスがレジスタから AXI4-Lite スレーブ インターフェイスにまとめられた入力を読み出します。ブロックの演算が終了すると、ハードウェアの出力ポートにより ap_done、ap_idle、および ap_ready が設定され、AXI4-Lite スレーブ インターフェイスにまとめられた出力ポートの結果が適切なレジスタから読み出されます。

上記の例の関数引数 c のインプリメンテーションは、ハードウェア ポートの動作をある程度理解しておくことが重要であることも示しています。関数引数 c は読み出しおよび書き込みの両方に使用されるので、インターフェイス合成の概要に示すように、入力ポート c_i および出力ポート c_o として別々にインプリメントされます。

AXI4-Lite スレーブ インターフェイスをプログラムするのに最初に推奨されるフローは、関数を一度だけ実行するフローです。

• 割り込み関数を使用して、割り込みの動作方法を決定します。
• ブロックの入力ポートにレジスタ値を読み込みます。上記の例では、これは API 関数の XExample_Set_a、XExample_Set_b および XExample_Set_c_i を使用して実行されます。
• XExample_Start を使用して ap_start ビットを 1 に設定し、関数を開始します。このレジスタには、上記のヘッダー ファイルに記述されているように、セルフ クリーニング機能があります。トランザクションが 1 つ終了すると、ブロックは動作を一時停止します。
• 関数が実行されます。生成された割り込みが処理されます。
• 出力レジスタが読み出されます。上記の例では、これは API 関数の XExample_Get_c_o_vld (データが有効なことを確認) と XExample_Get_c_o を使用して実行されます。
  注記: AXI4-Lite スレーブ インターフェイスのレジスタは、ポートと同じ I/O プロトコルに従います。この場合、出力 valid がロジック 1 に設定されて、データが有効かどうかが示されます。
• 次のトランザクションでも繰り返します。

2 つ目に推奨されるフローは、ブロックの継続実行です。このモードの場合、AXI4-Lite スレーブ インターフェイスに含まれる入力ポートは、コンフィギュレーションを実行するポートのみであるべきです。ブロックは通常 CPU よりも速く実行される必要があります。ブロックが入力を待つ必要がある場合、ブロックはほとんどの時間を待機に費やすことになります。

• 割り込み関数を使用して、割り込みの動作方法を決定します。
• ブロックの入力ポートにレジスタ値を読み込みます。上記の例では、これは API 関数の XExample_Set_a、XExample_Set_a および XExample_Set_c_i を使用して実行されます。
• API XExample_EnableAutoRestart を使用して自動開始関数を設定します。
• 関数が実行されます。各ポートの I/O プロトコルにより、ブロックを介して処理されるデータが同期されます。
• 生成された割り込みが処理されます。出力レジスタにはこの操作中アクセスできますが、データが頻繁に変更される可能性があります。
• API 関数 XExample_DisableAutoRestart を使用して、これ以上実行されないようにします。
• 出力レジスタが読み出されます。上記の例では、これは API 関数の XExample_Get_c_o および XExample_Set_c_o_vld を使用して実行されます。

API 関数は、CPU で実行されるソフトウェアで使用すると、ハードウェア ブロックを制御できます。プロセスの概要は次のとおりです。

• ハードウェア インスタンスのインスタンスを作成
• デバイス コンフィギュレーションを検索
• デバイスを初期化
• HLS ブロックの入力パラメーターを設定
• デバイスを開始して結果を読み出し

このプロセスを抽象化すると、次のようになります。ソフトウェア制御のすべての例は、Zynq-7000 SoC のチュートリアルに含まれます。

#include "xexample.h"    // Device driver for HLS HW block
#include "xparameters.h" 

// HLS HW instance
XExample HlsExample;
XExample_Config *ExamplePtr

int main() {
 int res_hw;

// Look Up the device configuration 
 ExamplePtr = XExample_LookupConfig(XPAR_XEXAMPLE_0_DEVICE_ID);
 if (!ExamplePtr) {
 print("ERROR: Lookup of accelerator configuration failed.\n\r");
 return XST_FAILURE;
 }

// Initialize the Device
 status = XExample_CfgInitialize(&HlsExample, ExamplePtr);
 if (status != XST_SUCCESS) {
 print("ERROR: Could not initialize accelerator.\n\r");
 exit(-1);
 }

//Set the input parameters of the HLS block
 XExample_Set_a(&HlsExample, 42);
 XExample_Set_b(&HlsExample, 12);
 XExample_Set_c_i(&HlsExample, 1);

// Start the device and read the results
 XExample_Start(&HlsExample);
 do {
 res_hw = XExample_Get_c_o(&HlsExample);
 } while (XExample_Get_c_o(&HlsExample) == 0); // wait for valid data output
 print("Detected HLS peripheral complete. Result received.\n\r");
}

AXI4-Lite スレーブ インターフェイスを使用した HLS の RTL デザインが Vitis IP インテグレーターのデザインに統合されると、ブロックをカスタマイズできるようになります。IP インテグレーターのブロック図で HLS ブロックを選択し、右クリックして Customize Block をクリックします。

アドレス幅はデフォルトで必要最小限のサイズに設定されます。これを変更して、アドレス サイズが 32 ビット未満のブロックに接続します。

Vitis HLS には、カーネル インターフェイス ポートのサイズを Vitis ツール フローでのバースト アクセス用に自動的に 512 に変更する機能があります。これはつまり、バースト可能なアクセスは 512 ビット幅にしか変更されないということです。バーストするには、バースト転送の最適化 で説明する前提条件にコードが従っている必要があります。Vitis HLS では、次の 2 つのコマンドを使用してポート幅の自動変更を制御できます。

• config_interface -m_axi_max_widen_bitwidth <N>: M-AXI インターフェイスのバーストを指定した幅まで自動的に広げます。<N> の値には、0 ～ 1024 の 2 のべき乗を指定する必要があります。バースト幅を広げる場合は、バーストだけでなく、強力なアライメント プロパティが必要となります。<N> のデフォルト値は 512 ビットです。
• config_interface -m_axi_alignment_byte_size <N>: M-AXI インターフェイスにマップされる最上位関数ポインターが少なくとも指定したバイト幅 (2 のべき乗) に揃えられるとします。これにより、自動バースト拡張が実行されやすくなります。デフォルトのアライメントは 64 バイトです。

自動最適化の場合、カーネルが次の前提条件を満たす必要があります。

• アクセスするメモリのロケーションおよび時間が単調に増加する必要があります。以前にアクセスされた 2 つのメモリ ロケーション間のメモリ ロケーションにアクセスすることはできません (オーバーラップなしということ)。
• バーストの前提条件は、すべてポート幅のサイズ変更にも適用されます。
• グローバル メモリからのアクセス パターンはシーケンシャル順で、次の追加要件に従っている必要があります。
  • シーケンシャル アクセスは、ベクター以外のタイプにする必要があります。
  • シーケンシャル アクセスの開始は、拡張されたワード サイズにアラインメントする必要があります。
  • シーケンシャル アクセスの長さはその拡張係数で割り切れるようにする必要があります。

次のコード例は、これを示しています。

vadd_pipeline:
  for (int i = 0; i < iterations; i++) {
#pragma HLS LOOP_TRIPCOUNT min = c_len/c_n max = c_len/c_n

  // Pipelining loops that access only one variable is the ideal way to
  // increase the global memory bandwidth.
  read_a:
    for (int x = 0; x < N; ++x) {
#pragma HLS LOOP_TRIPCOUNT min = c_n max = c_n
#pragma HLS PIPELINE II = 1
      result[x] = a[i * N + x];
    }

  read_b:
    for (int x = 0; x < N; ++x) {
#pragma HLS LOOP_TRIPCOUNT min = c_n max = c_n
#pragma HLS PIPELINE II = 1
      result[x] += b[i * N + x];
    }

  write_c:
    for (int x = 0; x < N; ++x) {
#pragma HLS LOOP_TRIPCOUNT min = c_n max = c_n
#pragma HLS PIPELINE II = 1
      c[i * N + x] = result[x];
    }
  }
}
}

上記のコードの自動最適化の幅は、次の 3 つの段階で実行されます。

1. まず、read_a ループのアクセス パターン数がチェックされます。1 つのループ反復中に 1 アクセスなので、最適化ではインターフェイスのビット幅が 32= 32 *1 (int 変数のビット幅 * アクセス) と決定されます。
2. 次の式の項を使用して、config_interface m_axi_max_widen_bitwidth 512 で指定されたデフォルトの最大値を到達しようとします。

   length = (ceil((loop-bound of index inner loops) * (loop-bound of index - outer loops)) * #(of access-patterns))

   • 上記のコードでは外側のループが不完全なループなので、外側のループのバースト転送はなくなります。このため、長さには内側のループのみが含まれるので、計算式は次のように短縮できます。

     length = (ceil((loop-bound of index inner loops)) * #(of access-patterns))

     または、長さ = ceil(128) *32 = 4096 となります。

3. 最後に、計算された長さが 2 のべき乗かどうか確認され、2 のべき乗の場合は長さが m_axi_max_widen_bitwidth で指定された幅に制限されます。

ポート幅の自動変更機能を使用する前に、その利点と問題点について考慮してください。この機能は、データ型サイズではなく大きなベクターを読み出すので、DDR からの読み出しレイテンシを改善します。大きなベクターをバッファリングして、データをデータパス サイズに合わせてシフトする必要があるので、リソースも増えます。ただし、自動ポート幅変更では標準 C データ型のみがサポートされ、ap_int、ap_uint、構造体、配列などの集合体でないデータ型はサポートされません。

最適な AXI4 インターフェイスとは、バスへのアクセス待機中にデザインが停止せず、バス アクセスが承認された後の読み出し/書き込み待機中にバスが停止しないようなインターフェイスです。最適な AXI4 インターフェイスを作成するには、INTERFACE プラグマまたは指示子に次のオプションを使用してバーストの動作を指定し、AXI4 インターフェイスの効率を最適化します。バースト転送の詳細は、バースト転送の最適化 を参照してください。

これらのオプションの中には、内部ストレージを使用してデータをバッファリングするため、エリアおよびリソースへの影響があるものもあります。

• latency: AXI4 インターフェイスのレイテンシを指定し、読み出しまたは書き込みの指定サイクル (レイテンシ) 前にバス要求を開始できるようにします。この値が小さすぎると、デザインが準備完了になるのが早すぎ、バスを待つために停止する可能性があります。この値が大きすぎると、バス アクセスが承認されても、デザインがアクセスを開始するのを待つためにバスが停止する可能性があります。
• max_read_burst_length: バースト転送中に読み出されるデータ値の最大数を指定します。
• num_read_outstanding: デザインが停止する前に、AXI4 バスに対して応答なしで送信できる読み出し要求の数を指定します。これにより、デザインの内部ストレージである FIFO のサイズ (num_read_outstanding*max_read_burst_length*word_size) が決まります。
• max_write_burst_length: バースト転送中に書き込まれるデータ値の最大数を指定します。
• num_write_outstanding: デザインが停止する前に、AXI4 バスに対して応答なしで送信できる書き込み要求の数を指定します。これにより、デザインの内部ストレージである FIFO のサイズ (num_read_outstanding*max_read_burst_length*word_size) が決まります。

次に、これらのオプションを使用した例を示します。

 #pragma HLS interface m_axi port=input offset=slave bundle=gmem0 
depth=1024*1024*16/(512/8) 
 latency=100 
 num_read_outstanding=32 
 num_write_outstanding=32 
 max_read_burst_length=16
 max_write_burst_length=16 

インターフェイスは、レイテンシ 100 になるように指定されています。Vitis HLS では、デザインが AXI4 バスにアクセスできるようになる 100 クロック サイクル前に、バースト アクセス要求をスケジューリングしようとします。バスの効率をさらに向上するには、num_write_outstanding および num_read_outstanding オプションを使用して、デザインに最大 32 個の読み出しおよび書き込みアクセスを格納できるバッファー容量が含まれるようにします。これで、バス要求が送信されるまでデザインの処理を続行できるようになります。最後に、max_read_burst_length および max_write_burst_length オプションを使用することで、最大バースト サイズが 16 になり、AXI4 インターフェイスがそれを超える時間バスを保持しないようにします。

これらのオプションを使用すると、AXI4 インターフェイスの動作をそれが実行されるシステム用に最適化できます。操作の効率は、これらの値が正しく設定されているかどうかによって異なります。

デフォルトでは、AXI4 マスター インターフェイスはすべての読み出しおよび書き込み操作をアドレス 0x00000000 から開始します。たとえば、次のコードの場合、50 個のアドレス値を表すアドレス 0x00000000 ～ 0x000000c7 (32 ビット ワード 50 個で 200 バイトを提供) からデータを読み出してから、同じアドレスにデータを再び書き込みます。

void example(volatile int *a){

#pragma HLS INTERFACE m_axi depth=50 port=a 
#pragma HLS INTERFACE s_axilite port=return bundle=AXILiteS

 int i;
 int buff[50];

 memcpy(buff,(const int*)a,50*sizeof(int));

 for(i=0; i < 50; i++){
 buff[i] = buff[i] + 100;
 }
 memcpy((int *)a,buff,50*sizeof(int));
}

アドレス オフセットを使用するには、INTERFACE 指示子に -offset を付けて、次のいずれかを指定します。

• off: オフセット アドレスは使用しません。これがデフォルトです。
• direct: デザインにアドレス オフセットを適用するための 32 ビット ポートが追加されます。
• slave: AXI4-Lite インターフェイス内にアドレス オフセットを適用するための 32 ビット レジスタが追加されます。

Vitis HLS では、最終的な RTL にアドレス オフセットは AXI4 マスター インターフェイスで生成される読み出しまたは書き込みアドレスに直接適用され、システムのアドレス位置にアクセスできるようになります。

AXI インターフェイスで slave オプションを使用する場合は、デザイン インターフェイスに AXI4-Lite ポートを使用する必要があります。ザイリンクスでは、次のプラグマを使用して AXI4-Lite インターフェイスをインプリメントすることを勧めしています。

#pragma HLS INTERFACE s_axilite port=return

また、slave オプションを使用する際に複数の AXI4-Lite インターフェイスを使用した場合は、AXI マスター ポートのオフセット レジスタが正しい AXI4-Lite インターフェイスにまとめられているようにする必要もあります。次の例では、a ポートが、オフセットと AXI4-Lite インターフェイス (AXI_Lite_1 および AXI_Lite_2) と一緒に AXI マスター インターフェイスとしてインプリメントされています。

#pragma HLS INTERFACE m_axi port=a depth=50 offset=slave 
#pragma HLS INTERFACE s_axilite port=return bundle=AXI_Lite_1
#pragma HLS INTERFACE s_axilite port=b bundle=AXI_Lite_2

a ポートのオフセット レジスタが AXI_Lite_1 という AXI4-Lite インターフェイスにまとめられるようにするには、次の INTERFACE 指示子が必要です。

#pragma HLS INTERFACE s_axilite port=a bundle=AXI_Lite_1

AXI4 マスター インターフェイスを使用した HLS の RTL デザインを Vivado IP インテグレーターのデザインに組み込む際には、ブロックをカスタマイズできます。IP インテグレーターのブロック図で HLS ブロックを選択し、右クリックして Customize Block をクリックし、設定をカスタマイズします。AXI4 パラメーターのすべての説明については、『Vivado Design Suite: AXI リファレンス ガイド』 (UG1037) のこのセクションを参照してください。

次の図は、次のデザインの [Re-Customise IP] ダイアログ ボックスを示しています。このデザインには、AXI4-Lite ポートが含まれています。

前の図に示す問題を回避するため、PIPELINE プラグマには rewind というオプションのコマンドがあります。このコマンドを使用すると、rewind ループが最上位関数またはデータフロー プロセスの一番外側で、データフロー領域が複数回呼び出される場合に、このループへの連続する呼び出しの反復をオーバーラップできます。

次の図に、ループをパイプラインする際に rewind オプションを使用した場合の動作を示します。ループは、ループ反復カウントが終了すると再実行されます。通常は直後に再実行されますが、遅延があることもあり、それは GUI で表示されるようになっています。

パイプライン処理は、データがパイプラインの入力に入ってくる限り実行され続けます。処理するデータがなければ、パイプラインは一時停止します。これを次の図に示します。入力データの valid 信号が Low になり、データがないことが示されています。処理するデータが新しく入ってくれば、パイプラインは動作を再開します。

場合によっては、空にできる (フラッシュできる) パイプラインが必要なこともあります。このために、flush オプションが提供されています。パイプラインをフラッシュすると、パイプラインの開始時にデータ valid 信号によりデータがないことが示されたときに、新しい入力の読み出しが停止し、最後の入力が処理されてパイプラインから出力されるまで、処理が継続されてその後の各パイプライン段が閉鎖されます。

Vitis HLS でインプリメントされるパイプラインのデフォルト スタイルは、config_compile -pipeline_style コマンドで定義されます。デザインで使用するパイプラインは、ストール パイプライン (stp) またはフリーランニング フラッシュ パイプライン (frp) に指定できます。enable_flush オプションを使用すると、3 つ目のタイプのフラッシュ可能パイプライン (flp) を PIPELINE プラグマまたは指示子を使用して定義することもできます。このオプションは、特定のスコープのプラグマまたは指示子にのみ適用され、config_compile で割り当てられたグローバル デフォルト設定は変更されません。

config_compile を使用すると、反復回数に基づくループの自動パイプライン処理をイネーブルにできます。この設定にアクセスするには、Solution → Solution Setting → General → Add → config_compile をクリックします。

反復回数は、pipeline_loops オプションで設定します。反復回数がこの設定値よりも少ないループは、すべて自動的にパイプライン処理されます。デフォルトは 0 で、ループの自動パイプライン処理は実行されません。

次のようなコードがあるとします。

for (y = 0; y < 480; y++) {
  for (x = 0; x < 640; x++) {
    for (i = 0; i < 5; i++) {
      // do something 5 times
 …     ...
    }
  }
}

pipeline_loops オプションを 6 に設定すると、上記のコードの最内 for ループは自動的にパイプライン処理されます。これは、次のコードと同じです。

for (y = 0; y < 480; y++) {
  for (x = 0; x < 640; x++) {
    for (i = 0; i < 5; i++) {
#pragma HLS PIPELINE II=1
      // do something 5 times
 …    ...
    }
  }
}

自動パイプライン処理を適用するべきでないループがデザインに含まれる場合は、そのループに PIPELINE 指示子を off 設定で適用します。この指示子を off に設定すると、ループの自動パイプライン処理は実行されなくなります。

関数がパイプライン処理されると、その階層内にあるすべてのループが自動的に展開されます。これはパイプライン処理のために必要です。ループに変数境界があると展開できず、関数がパイプライン処理されなくなります。

スタティック変数は、ループの反復間でデータを維持するために使用される変数で、最終的なインプリメンテーションでレジスタになることがよくあります。これがパイプライン処理された関数に使用されていると、Vitis HLS でデザインを十分に最適化できず、開始間隔 (II) が要件を超えることがあります。

次に、この状況の典型的な例を示します。

function_foo()
{
	static bool change = 0
	if (condition_xyz){ 
		change = x; // store 
	}
	y = change; // load
}

Vitis HLS でこのコードを最適化できない場合、ストア操作に 1 サイクル、ロード操作に 1 サイクル必要となります。この関数がパイプラインの一部である場合は、スタティック変更変数によりループ運搬依存が作成されるので、パイプラインを最小限の開始間隔である 2 を使用してインプリメントする必要があります。

これを回避する方法の 1 つは、コードを次のように書き直すことです。これにより、ループの反復ごとに read または write のみが存在するようになるので、デザインが II=1 でスケジュールできるようになります。

function_readstream()
{
	static bool change = 0
	bool change_temp = 0;
	if (condition_xyz)
	{ 
		change = x; // store 
		change_temp = x; 
	}
	else
	{ 
	change_temp = change; // load 
	}
	y = change_temp;
}

config_array_partition は、配列を要素数に基づいて自動的に分割する方法を指定します。この設定にアクセスするには、Solution → Solution Settings → General → Add → config_array_partition をクリックします。

throughput_driven オプションを使用すると、分割のしきい値を調整し、分割を完全に自動化できます。throughput_driven オプションを選択すると、指定したスループットを達成するために Vitis HLS で配列が自動的に分割されます。

Vitis HLS は、DATAFLOW 最適化を適用するために領域を変更します。ザイリンクスでは、正規形式を使用してこの領域内 (正規領域と呼ぶ) でコードを記述することをお勧めしています。データフロー最適化を適用するには、2 つの正規形式があります。

1. インライン展開されていない関数の正規形式。

   
   void dataflow(Input0, Input1, Output0, Output1) 
   {
    #pragma HLS dataflow
    UserDataType C0, C1, C2;
    func1(read Input0, read Input1, write C0, write C1);
    func2(read C0, read C1, write C2);
    func3(read C2, write Output0, write Output1);
   }
   

2. ループ本体内のデータフロー。

   ループ (関数内でインラインなし) の場合、積分ループ変数は次のように設定する必要があります。

   1. ループ ヘッダーで宣言され 0 に設定される初期値。
   2. ループ条件は正の定数または定数の関数引数。
   3. 1 ずつインクリメント。
   4. データフロー プラグマはループ内にある必要あり。

      
      void dataflow(Input0, Input1, Output0, Output1) 
      {
       for (int i = 0; i < N; i++) 
       {
       #pragma HLS dataflow
       UserDataType C0, C1, C2;
       func1(read Input0, read Input1, write C0, write C1);
       func2(read C0, read C0, read C1, write C2);
       func3(read C2, write Output0, write Output1);
       }
      }
      

正規領域内では、正規本体は次のガイドラインにしたがっている必要があります。

1. ローカルの非スタティック スカラーまたは配列/ポインター変数、もしくはローカルのスタティック ストリーム変数を使用します。ローカル変数は、関数本体内 (関数内のデータフローの場合) またはループ本体 (ループ内のデータフローの場合) で宣言します。
2. データをフィードバックなしで、1 つの関数から別の関数に後に渡される関数呼び出しシーケンスの条件は次のとおりです。
   1. 変数 (スカラー以外) に含めることができるのは、1 つの読み出しプロセスと 1 つの書き込みプロセスのみです。
   2. ローカル変数を使用する場合は write before read (受信前に送信) を使用します。
   3. 関数引数を使用する場合、read before write (送信前に受信) を使用します。本体内の反依存はデザインで保持される必要があります。
   4. 関数の戻り値型は void である必要があります。
   5. 変数を介した異なるプロセス間のループ キャリー依存はないようにします。
      • 正規ループ内 (1 つの反復で書き出されて次の反復で読み込まれる値など)。
      • 最上位関数への連続呼び出し内 (1 つの反復で書き出されて次の反復で読み込まれる入力引数など)。

Vitis HLS には、データフロー チェッカーが含まれており、オンにすると、コードが推奨される標準形式に従っているかどうかが確認され、問題があると、エラーや警告メッセージを表示します。デフォルトでは、このチェッカーは warning に設定されています。チェッカーは config_dataflow Tcl コマンドの strict モードで error に設定したり、off を選択してディスエーブルにしたりできます。

config_dataflow -strict_mode  (off | error | warning)

DATAFLOW 最適化では、タスク (関数およびループ) 間、および最大限のパフォーマンスを得るため理想的にはパイプライン処理された関数およびループ間のデータの流れが最適化されます。そのためタスクを順につなげる必要はありませんが、データの転送方法にいくつかの制限があります。

次のような条件下では、Vitis HLS で DATAFLOW 最適化が実行されなかったり、設定が重複してしまう可能性があります。

• シングル プロデューサー コンシューマー違反
• タスクのバイパス
• タスク間のフィードバック
• タスクの条件付き実行
• 複数の exit 条件を持つループ

void foo(int data_in[N< N; i++) {
 temp1[i] = data_in[i] * scale;
 temp2[i] = data_in[i] >> scale;
 }
 Loop2: for(int j = 0; j < N; j++) {
 temp3[j] = temp1[j] + 123;
 }
 Loop3: for(int k = 0; k < N; k++) {
 data_out[k] = temp2[k] + temp3[k];
 }
}

void Split (in[N], out1[N], out2[N]) {
// Duplicated data
 L1:for(int i=1;i<N;i++) {
 out1[i] = in[i]; 
 out2[i] = in[i];     
 }
}
void foo(int data_in[N], int scale, int data_out1[N], int data_out2[N]) {

 int temp1[N], temp2[N]. temp3[N]; 
 Loop1: for(int i = 0; i < N; i++) {
 temp1[i] = data_in[i] * scale;
 }
 Split(temp1, temp2, temp3);
 Loop2: for(int j = 0; j < N; j++) {
 data_out1[j] = temp2[j] * 123;
 }
 Loop3: for(int k = 0; k < N; k++) {
 data_out2[k] = temp3[k] * 456;
 }
}

void foo(int data_in[N], int scale, int data_out1[N], int data_out2[N]) {

 int temp1[N], temp2[N

#pragma HLS STREAM off variable=temp2 depth=3

void foo(int data_in1[N], int data_out[N], int sel) {

 int temp1[N], temp2[N];

 if (sel) {
 Loop1: for(int i = 0; i < N; i++) {
 temp1[i] = data_in[i] * 123;
 temp2[i] = data_in[i];
 }
 } else {
 Loop2: for(int j = 0; j < N; j++) {
 temp1[j] = data_in[j] * 321;
 temp2[j] = data_in[j];
 }
 }
 Loop3: for(int k = 0; k < N; k++) {
 data_out[k] = temp1[k] * temp2[k];
 }
}

void foo(int data_in[N], int data_out[N], int sel) {

 int temp1[N], temp2[N];

 Loop1: for(int i = 0; i < N; i++) {
 if (sel) {
 temp1[i] = data_in[i] * 123;
 } else {
 temp1[i] = data_in[i] * 321;
 }
 }
 Loop2: for(int j = 0; j < N; j++) {
 temp2[j] = data_in[j];
 }
 Loop3: for(int k = 0; k < N; k++) {
 data_out[k] = temp1[k] * temp2[k];
 }
}

void proc_1(std::complex<float> (&buffer)[50], const std::complex<float> *in);
void proc_2(hls::Stream<std::complex<float>> &fifo, const std::complex<float> (&buffer)[50], std::complex<float> &acc);
void proc_3(std::complex<float> *out, hls::Stream<std::complex<float>> &fifo, const std::complex<float> acc);

void top(std::complex<float> *out, const std::complex<float> *in) {
#pragma HLS DATAFLOW

  std::complex<float> acc __attribute((no_ctor)); // Here
  std::complex<float> buffer[50] __attribute__((no_ctor)); // Here
  hls::Stream<std::complex<float>, 5> fifo; // Not here

  proc_1(buffer, in);
  proc_2(fifo, buffer, acc);
  proc_3(out, fifo, acc);
} 

Vitis HLS では、タスク間のチャネルが、データのプロデューサーとコンシューマーのアクセス パターンによって、ピンポン バッファーまたは FIFO のいずれかでインプリメントされます。

• スカラー、ポインター、リファレンス パラメーターの場合、Vitis HLS はチャネルを FIFO としてインプリメントします。
• パラメーター (プロデューサーまたはコンシューマー) が配列の場合、Vitis HLS はチャネルをピンポン バッファーまたは FIFO としてインプリメントします。
  • Vitis HLS でデータが順番どおり (シーケンシャルに) アクセスされると決定されると、Vitis HLS はメモリ チャネルを深さ 2 の FIFO としてインプリメントします。
  • Vitis HLS でデータが順にアクセスされるかを判断できない場合、または任意の順序でアクセスされていると判断された場合、Vitis HLS はメモリ チャネルをピンポン バッファー (プロデューサーまたはコンシューマーの配列の最大サイズで定義された 2 つのブロック RAM) としてインプリメントします。
    注記: ピンポン バッファーが使用されると、チャネルに常に損失なしにサンプルすべてを維持できるようになりますが、場合によっては、これが控えめすぎる設定であることもあります。

タスク間で使用されるデフォルトのチャネルを明示的に指定するには、config_dataflow を使用します。これを使用すると、デザイン内のすべてのチャネルにデフォルト チャネルが設定されます。チャネルで使用されるメモリ サイズを削減し、反復内で重複できるようにするには、FIFO を使用します。FIFO 内の深さ (要素数) を明示的に設定する場合は、-fifo_depth オプションを使用します。

FIFO チャネルのサイズを指定すると、デフォルトの設定が上書きされます。デザイン内のタスクが指定した FIFO サイズよりも速いレートでサンプルを入力または出力する場合、FIFO が空またはフルになることがあります。この場合、読み出しまたは書き込みはできないので、デザインの動作が停止し、デッドロック状態になってしまうこともあります。

ザイリンクスでは、FIFO の深さを設定する場合は、最初は深さを転送されるデータの最大値 (タスク間で渡される配列のサイズ) に設定して C/RTL 協調シミュレーションで問題がないことを確認し、その後 FIFO のサイズを削減してそれでも問題がないことを C/RTL 協調シミュレーションで再度確認することを勧めします。RTL 協調シミュレーションがエラーになる場合は、FIFO のサイズが小さすぎて、停止やデッドロック状態を回避できなかった可能性があります。

RTL 協調シミュレーションの実行後に、Vitis HLS GUI に時間経過に伴う各 FIFO/PIPO バッファーの占有率のヒストグラムが表示されます。これは、各バッファーの最適な深さを判断するのに役立ちます。

デフォルトでは、ランダム アクセスを可能にするためすべての配列がピンポン バッファーとしてインプリメントされます。これらのバッファーは、必要に応じてサイズ指定可能です。たとえば、タスクをバイパスする場合など、パフォーマンスが落ちることがあります。パフォーマンスへの影響を少なくするには、次のように STREAM 指示子を使用してこれらのバッファーのサイズを増加し、プロデューサーとコンシューマーにスラックを追加します。

void top ( ... ) {
#pragma HLS dataflow
  int A[1024];
#pragma HLS stream off variable=A depth=3
 
  producer(A, B, …);  // producer writes A and B
  middle(B, C, ...);  // middle reads B and writes C
  consumer(A, C, …);  // consumer reads A and C	

最上位関数インターフェイスの配列を ap_fifo、axis、または ap_hs インターフェイス タイプに設定すると、自動的にストリーミングとして設定されます。

FIFO がインプリメンテーションに必要な場合は、STREAM 指示子を使用してデザイン内ですべての配列をストリーミングとして指定する必要があります。

STREAM 指示子を使用すると、config_dataflow コンフィギュレーションで指定したデフォルトのインプリメンテーションから DATAFLOW 領域の配列を変更することもできます。

• config_dataflow default_channel がピンポンとして設定される場合、配列に STREAM 指示子を適用すると、どの配列も FIFO としてインプリメントできます。
  注記: FIFO インプリメンテーションを使用するためには、配列はストリーミング手法でアクセスされる必要があります。
• config_dataflow default_channel が FIFO に設定されるか、Vitis HLS で DATAFLOW 領域のデータがストリーミング手法でアクセスされると自動的に判断された場合、STREAM 指示子に -off オプションを付けて配列に適用すると、どの配列もピンポン インプリメンテーションとしてインプリメントできます。

DATAFLOW 領域の配列がストリーミングとして指定され、FIFO としてインプリメントされる場合、FIFO に元の配列と同じ数の要素を含める必要は通常ありません。DATAFLOW 領域のタスクでは、各データ サンプルは使用可能になるとすぐに使用されます。config_dataflow コマンドに -fifo_depth オプションを指定するか、STREAM 指示子に -depth を指定すると、FIFO のサイズを最低限必要な要素数に設定して、データが一時停止しないようにできます。-off オプションを選択する場合は、-off オプションでピンポンの深さ (ブロック数) を設定します。深さは少なくとも 2 にする必要があります。

stable プラグマを使用すると、データフロー領域の入力または出力変数をマークして、それらの該当する同期を削除できます (ユーザーがこの削除を本当に正しいと確認した場合のみ)。

void dataflow_region(int A[...], ...
#pragma HLS stable variable=A
#pragma HLS dataflow
    proc1(...);
    proc2(A, ...);

stable プラグマがなく、A が proc2 で読み出される場合、proc2 は、それが含まれるデータフロー領域で (ap_start を使用して) 初期同期の一部になります。つまり、proc1 は proc2 も再開可能な状態になるまでは再開されないので、データフロー反復が重複されなくなり、パフォーマンスが落ちてしまうことがあります。stable プラグマは、この同期が必ずしも正確性を保持するわけではないことを示しています。

前の例では、stable プラグマがない場合、A が proc2 で読み出されるとすると、proc2 がタスクをバイパスするので、パフォーマンスが落ちます。

これは、データフロー領域がまだ開始していない場合や実行を終了していない場合にのみ、呼び出し元がこれらの変数をアップデートまたは読み出す場合によく使用されます。

ap_ctrl_none ブロックレベルの I/O プロトコルを使用すると、ap_ctrl_hs および ap_ctrl_chain プロトコルから設定される柔軟性の少ない同期スキームを使用せずにすみます。これらのプロトコルでは、領域内のプロセスすべてが同じ回数分実行され、その C ビヘイビアーとより一致するようになります。

ただし、たとえば、作業を複数のより遅い作業に分散させてより頻繁に実行することで、プロセスを速めることを目的とすることがあります。

#pragma HLS interface ap_ctrl_none port=return

これは、あくまでも次の条件が整った場合にのみ可能です。

• 含まれる領域とすべてのプロセスが FIFO (hls::stream、ストリーム配列、AXIS などのメモリ以外) を介してしか通信しない場合。

• その領域の親領域すべてが、最上位デザインまで、次の要件に従っている場合。
  • すべてがデータフロー領域 (ループ内のデータフロー以外) に含まれる。
  • すべてが ap_ctrl_none を指定する。

つまり、次のいずれも階層内の ap_ctrl_none を使用するデータフロー領域の親にはなりません。

• シーケンシャルまたはパイプライン FSM
• for ループ (ループ内のデータフロー) 内のデータフロー領域

このプラグマでは、その領域内のプロセスを同期するのに ap_ctrl_chain が使用されなくなります。これらは入力 FIFO のデータが使用できるかどうか、および出力 FIFO のスペースによって実行されたり、停止したりします。次に例を示します。

void region(...) {
#pragma HLS dataflow
#pragma HLS interface ap_ctrl_none port=return
    hls::stream<int> outStream1, outStream2;
    demux(inStream, outStream1, outStream2);
    worker1(outStream1, ...);
    worker2(outStream2, ....);

この例の場合、demux は worker1 および worker2 の 2 倍の頻度で実行できます。たとえば、II=1 の設定で、worker1 およ worker2 に II=2 を設定しても、グローバル II=1 を達成できます。

デフォルトでは Vitis HLS はまずパフォーマンスを最大限にしようとするため、場合によっては、明示的に演算子の数を制限してエリア削減する必要があります。デザインの演算子数を制限する方法はエリア削減には効率的な方法で、演算を共有させるとエリアが削減しやすくなりますが、パフォーマンスが落ちる可能性があります。

ALLOCATION 指示子を使用すると、デザインで使用される演算子の数を制限できます。たとえば、foo というデザインには 317 個の乗算が含まれるのに、FPGA には 256 個の乗算器リソース (DSP48) しかないとします。Vitis HLS では、次の ALLOCATION プラグマを使用すると、最大 256 個の乗算 (mul) 演算子を含むデザインが作成されます。

dout_t array_arith (dio_t d[317]) {
 static int acc;
 int i;
#pragma HLS ALLOCATION instances=mul limit=256 operation

 for (i=0;i<317;i++) {
#pragma HLS UNROLL
 acc += acc * d[i];
 }
 rerun acc;
}

type オプションを使用すると、ALLOCATION 指示子で演算、インプリメンテーション、または関数を制限するかどうかを指定できます。次の表に、ALLOCATION 指示子を使用して制御可能なすべての演算をリストします。