SDx プラグマリファレンスガイド (UG1253SDx プラグマリファレンスガイド UG1253 (v2017.2) 2017 年 8 月 16 日この資料は表記のバージョンの英語版を翻訳したもので、内容に相違が生じる場合には原文を優先します。資

SDx プラグマ

リファレンスガイド

UG1253 (v2017.2) 2017 年 8 月 16 日

この資料は表記のバージョンの英語版を翻訳したもので、内容に相違が生じる場合には原文を優先します。資料によっては英語版の更新に対応していないものがあります。日本語版は参考用としてご使用の上、最新情報につきましては、必ず最新英語版をご参照ください。

改訂履歴改訂履歴

次の表に、この文書の改訂履歴を示します。

日付バージョン改訂内容

2017 年 8 月 16 日 2017.2 マイナーな編集。

2017 年 6 月 20 日 2017.1 初版。

SDx プラグマリファレンスガイド

UG1253 (v2017.2) 2017 年 8 月 16 日 japan.xilinx.com

2

https://japan.xilinx.com/about/feedback.html?docType=Reference_Guide&docId=UG1253&Title=SDx%20%26%2312503%3B%26%2312521%3B%26%2312464%3B%26%2312510%3B%20%26%2312522%3B%26%2312501%3B%26%2312449%3B%26%2312524%3B%26%2312531%3B%26%2312473%3B%20%26%2312460%3B%26%2312452%3B%26%2312489%3B&releaseVersion=2017.2&docPage=2

https://japan.xilinx.com

目次

概要概要

OpenCL 属性OpenCL 属性

always_inline.......................................................................................................................................................................... 8

opencl_unroll_hint................................................................................................................................................................ 9

reqd_work_group_size ......................................................................................................................................................11

vec_type_hint ......................................................................................................................................................................13

work_group_size_hint........................................................................................................................................................15

xcl_array_partition.............................................................................................................................................................17

xcl_data_pack......................................................................................................................................................................20

xcl_dataflow.........................................................................................................................................................................22

xcl_dependence .................................................................................................................................................................24

xcl_max_work_group_size ................................................................................................................................................27

xcl_pipeline_loop ................................................................................................................................................................29

xcl_pipeline_workitems ....................................................................................................................................................30

xcl_reqd_pipe_depth..........................................................................................................................................................32

SDS プラグマSDS プラグマ

pragma SDS async ..........................................................................................................................................................36

pragma SDS data access_pattern .............................................................................................................................38

pragma SDS data buffer_depth...................................................................................................................................40

pragma SDS data copy ..................................................................................................................................................42

pragma SDS data data_mover.....................................................................................................................................46

pragma SDS data mem_attribute ...............................................................................................................................48

pragma SDS data sys_port ...........................................................................................................................................50

pragma SDS partition .....................................................................................................................................................52

pragma SDS resource ....................................................................................................................................................54

pragma SDS wait ..............................................................................................................................................................55

pragma SDS data zero_copy........................................................................................................................................56



3



HLS プラグマHLS プラグマ

pragma HLS allocation ...................................................................................................................................................59

pragma HLS array_map ..................................................................................................................................................61

pragma HLS array_partition..........................................................................................................................................64

pragma HLS array_reshape ..........................................................................................................................................66

pragma HLS clock............................................................................................................................................................69

pragma HLS data_pack...................................................................................................................................................71

pragma HLS dataflow .....................................................................................................................................................74

pragma HLS dependence ..............................................................................................................................................77

pragma HLS expression_balance................................................................................................................................80

pragma HLS function_instantiate...............................................................................................................................82

pragma HLS inline ............................................................................................................................................................84

pragma HLS interface ....................................................................................................................................................87

pragma HLS latency........................................................................................................................................................93

pragma HLS loop_flatten ...............................................................................................................................................95

pragma HLS loop_merge ................................................................................................................................................97

pragma HLS loop_tripcount ..........................................................................................................................................99

pragma HLS occurrence ............................................................................................................................................ 101

pragma HLS pipeline .................................................................................................................................................... 103

pragma HLS protocol................................................................................................................................................... 105

pragma HLS reset......................................................................................................................................................... 107

pragma HLS resource.................................................................................................................................................. 109

pragma HLS stream ..................................................................................................................................................... 111

pragma HLS top............................................................................................................................................................. 113

pragma HLS unroll ........................................................................................................................................................ 114

その他のリソースおよび法的通知その他のリソースおよび法的通知

参考資料 .......................................................................................................................................................................... 117

お読みください: 重要な法的通知........................................................................................................................... 118



4



概要概要

ザイリンクス SDx ツール (SDAccel™ 環境、SDSoC™ 環境、および Vivado® HLS を含む) は、ソフトウェ

アアプリケーションの要素を分割してその一部を FPGA ベースのハードウェアカーネルで実行し、ハ

ードウェアがプロセッサまたはエンベデッドプロセッサで実行されるアプリケーションとスムーズに機能す

るようにすることができるツールです。デフォルトの状態でも多くのアプリケーションで十分な結果が得ら

れますが、ハードウェアパーティションで最高の QoR (結果の品質) を引き出し、カーネルのパフォーマ

ンスおよびデータスループットを向上し、レイテンシおよびカーネルで使用されるリソースを削減するに

は、ハードウェアロジックの最適化が必要な場合もあります。それには、ハードウェアカーネルのコンパ

イルおよび合成に指示を与えたり、プロセッサとハードウェアロジック間のデータムーバーの機能を最

適化したりするため、特定の属性、指示子、またはプラグマを使用できます。

このガイドでは、SDx 開発環境でシステムレベルのアプリケーションの OpenCL™ C 言語または標準

C/C++ 言語定義に使用可能なプラグマの形式とタイプを説明します。

• OpenCL の属性は OpenCL 言語規格で定義され、ハードウェアカーネルに最適化が適用されま

す。

• ザイリンクスでは追加の OpenCL 属性を提供しています。これらの属性には、名前の冒頭に xcl_

が付いています。

• SDS プラグマは C または C++ 言語で定義され、SDSoC デザインプロジェクトのインターフェイス、

データムーバー、およびハードウェアカーネルに適用されます。

• HLS プラグマは C または C++ 言語で定義され、Vivado HLS のハードウェアカーネルに最適化

を適用するために SDx フローで使用できます。

• 指示子は Vivado HLS Tcl コマンドで、HLS プラグマのようにハードウェアパーティションに適用で

きますが、ここでは詳細は説明しません。詳細は、『Vivado Design Suite ユーザーガイド: 高位合

成』 (UG902) を参照してください。

カーネル最適化は、カーネルインターフェイスにデータが到達したらすぐにすべてのデータを消費でき

るプロセッシングロジックを作成することを目的として実行されます。これは通常、関数のパイプライン処

理、ループ展開、配列分割、データフローなどの手法を使用してデータパスを一致させるようにプロセッ

シングコードを展開することによって達成されます。このガイドでは、最適化を支援するため、属性およ

びプラグマについて説明します。

第 1 章



5

https://japan.xilinx.com/cgi-bin/docs/rdoc?v=2017.2;d=ug902-vivado-high-level-synthesis.pdf



最適化プラグマおよび属性は、次のオブジェクトおよびスコープに適用できます。

• インターフェイス: プラグマをインターフェイスに適用すると、インターフェイスは最上位関数に含ま

れるので、プラグマは最上位関数に適用されます。

• 関数: プラグマを関数に適用すると、関数のスコープ内のすべてのオブジェクトにプラグマが適用さ

れます。プラグマの効果は、関数の次の階層レベルで停止します。ただし、階層のループを繰り返

し展開する PIPELINE プラグマなど -recursive オプションをサポートまたは使用するプラグマは例

外です。

• ループ: プラグマをループに適用すると、ループのスコープ内のすべてのオブジェクトにプラグマが

適用されます。たとえば、LOOP_MERGE プラグマをループに適用すると、そのループ自体ではな

く、ループ内の下位ループに適用されます。

• 配列: プラグマを配列に適用すると、その配列を含むスコープに適用されます。

• 領域: プラグマを領域に適用すると、その領域のスコープ全体に適用されます。領域は、{ } で囲ま

れたエリアのことです。次に例を示します。

{the scope between these braces is a region}

ヒント: 最適化は、関数およびループに適用するのと同じように領域に適用できます。

• ループおよび領域にラベルを付けて、コードで検索したりプラグマを設定しやすくすることができま

す。次に、ラベル付きとラベルなしのループおよび領域の例を示します。

// Example of a loop with a labelMy_For_Loop:for(i=0; i<3;i++ {printf(“This loop has the label My_For_Loop \n”);}

// Example of an region with no label{printf(“The scope between these braces has NO label”);}

// Example of a NAMED regionMy_Region:{printf(“The scope between these braces HAS the label My_Region”);}

第 1 章: 概要



6



OpenCL 属性OpenCL 属性

OpenCL での最適化OpenCL での最適化

このセクションでは、SDAccel コンパイラ xocc、SDSoC システムコンパイラ sdscc および sds++、

Vivado HLS 合成でのシステム最適化を支援するためにソースコードに追加可能な OpenCL 属性につ

いて説明します。

SDx では、コードをデータの動きとカーネルパフォーマンスで最適化する OpenCL 属性が提供されて

います。データの動きの最適化は、インターフェイス帯域幅および DDR 帯域幅の最大限に活用するこ

とにより、システムレベルのデータスループットを最大にすることを目的として実行されます。カーネル

計算最適化は、カーネルインターフェイスにデータが到達したらすぐにすべてのデータを消費できるプ

ロセッシングロジックを作成することを目的として実行されます。これは通常、関数のインライン展開とパ

イプライン処理、ループ展開、配列分割、データフローなどの手法を使用してデータパスを一致させるよ

うにプロセッシングコードを展開することによって達成されます。

OpenCL 属性には、次のタイプがあります。

表 1: OpenCL 属性 (タイプ別)

タイプ属性

カーネルサイズ • reqd_work_group_size

• vec_type_hint

• work_group_size_hint

• xcl_max_work_group_size

関数のインライン展開 • always_inline

タスクレベルのパイプライン処理 • xcl_dataflow

• xcl_reqd_pipe_depth

パイプライン処理 • xcl_pipeline_loop

• xcl_pipeline_workitems

ループ展開 • opencl_unroll_hint

• xcl_dependence

配列最適化 • xcl_array_partition

構造体 (struct) のパッキング • xcl_data_pack

第 2 章



7



always_inlinealways_inline

説明説明

always_inline 属性は、関数をインライン展開する必要があることを示します。この属性は GCC の標

準機能であり、SDx コンパイラの標準機能でもあります。

この属性は、関数を呼び出し関数内でインライン展開するコンパイラ最適化をイネーブルにします。イン

ライン展開された関数は、RTL で別の階層としては表示されなくなります。

関数をインライン展開すると、関数内の演算が共有され、呼び出し関数の周辺の演算と効率よく最適化

されることがあります。ただし、インライン展開された関数はほかの関数と共有できなくなるので、インライ

ン展開された関数とその関数の別のインスタンス (より広く共有可能) でロジックが複製される可能性が

あります。これによりパフォーマンスを向上できますが、RTL をインプリメントするのに必要なエリアが増

加します。

場合によっては、コンパイラにより always_inline 属性が無視され、関数がインライン展開されないこ

とがあります。

デフォルトでは、インライン展開は関数階層のすぐ下の階層でのみ実行され、サブ関数では実行されま

せん。

構文構文

OpenCL ソースで関数の前に記述し、その関数が呼び出すたびに常にインライン展開されるようにしま

す。

__attribute__((always_inline))

例例

次の例では、関数 foo に always_inline 属性を追加しています。

__attribute__((always_inline))void foo ( a, b, c, d ) {...

}

関連項目関連項目

• https://gcc.gnu.org

• 『SDAccel 環境最適化ガイド』 (UG1207)

第 2 章: OpenCL 属性



8

https://gcc.gnu.org/

https://japan.xilinx.com/cgi-bin/docs/rdoc?v=2017.2;d=ug1207-sdaccel-optimization-guide.pdf



opencl_unroll_hintopencl_unroll_hint

説明説明

重要: これはコンパイラヒントであり、コンパイラにより無視される可能性があります。

ループ展開は、SDAccel で使用可能な最初の最適化手法です。ループ展開最適化は、コンパイラで同

時処理が認識されるようにするために実行されます。認識された新たな同時処理により、レイテンシが削

減され、パフォーマンスが向上しますが、より多くの FPGA ファブリックリソースを使用します。

opencl_unroll_hint 属性は OpenCL 言語仕様の一部であり、OpenCL コンパイラでループ (for、

while、do) が展開されるよう指定します。詳細は、『SDAccel 環境最適化ガイド』 (UG1207) の「ループ

展開」を参照してください。

opencl_unroll_hint 属性修飾子は、適用するループの直前に記述する必要があります。この属性

では、ループの完全な展開、指定した量の部分展開、またはループ展開のディスエーブルを指定でき

ます。

構文構文

OpenCL ソースのループ定義の前に配置します。

__attribute__((opencl_unroll_hint(n)))

説明:

• n: オプションのループ展開係数。正の整数またはコンパイル時定数表現で指定します。1 にする

と、ループ展開がディスエーブルになります。

ヒント: n を指定しない場合、ループの展開係数はコンパイラにより自動的に決定されます。

例 1例 1

次の例では、for ループを係数 2 で展開しています。この結果、計算ユニットの 4 つの順次反復では

なく、2 つの並列ループ反復が生成されます。

__attribute__((opencl_unroll_hint(2)))for(int i = 0; i < LENGTH; i++) {bufc[i] = bufa[i] * bufb[i];}




9




上記のループは、コンパイラにより次のコードに変換されます。

for(int i = 0; i < LENGTH; i+=2) {bufc[i] = bufa[i] * bufb[i];bufc[i+1] = bufa[i+1] * bufb[i+1];}



• https://www.khronos.org/

• OpenCL C 仕様




10


https://www.khronos.org/

https://www.khronos.org/registry/OpenCL/specs/opencl-2.0-openclc.pdf



reqd_work_group_sizereqd_work_group_size

説明説明

OpenCL カーネルが OpenCL デバイスでの実行用に投稿されると、ND 範囲 (1、2、または 3 次元) と

呼ばれるインデックス空間内で実行されます。これは、OpenCL API ではグローバルサイズと呼ばれま

す。ワークグループサイズは、カーネル計算ユニットの 1 回の起動で処理可能な ND 範囲の量を定義

します。ワークグループサイズは、OpenCL API ではローカルサイズとも呼ばれます。OpenCL コンパ

イラでは、カーネルおよび選択されたデバイスのプロパティに基づいてワークグループサイズを決定で

きます。ワークグループサイズ (ローカルサイズ) が決定されたら、ND 範囲 (グローバルサイズ) が自

動的にワークグループに分割され、デバイス上で実行するためにワークグループがスケジューリングさ

れます。

OpenCL コンパイラでワークグループサイズを定義できますが、カーネルの FPGA インプリメンテーシ

ョンでは、カーネルの reqd_work_group_size 属性でワークグループサイズを定義することをお勧

めします。この属性は、カーネルのカスタムロジックの生成中にパフォーマンスを最適化するのに推奨

されます。詳細は、『SDAccel 環境最適化ガイド』 (UG1207) の「OpenCL Execution Model」 (OpenCL

実行モデル) を参照してください。

ヒント: FPGA インプリメンテーションの場合は、reqd_work_group_size 属性をカーネルのカスタムロジックの生

成中にパフォーマンスを最適化するために使用できるので、この属性を指定することをお勧めします。

OpenCL カーネル関数は、ND 範囲インデックス空間の各点に対して 1 回のみ実行されます。ND 範囲

の各点に対するこの処理ユニットは、ワークアイテムと呼ばれます。ワークアイテムは、計算ユニットにス

ケジューリングされるワークユニットであるワークグループにまとめられます。オプションの

reqd_work_group_size は、clEnqueueNDRangeKernel の local_work_size 引数として使用さ

れる必要のある計算ユニットのワークグループサイズを定義します。これにより、生成されたコードがこ

のカーネル用に適切に最適化されます。

構文構文

カーネル定義の前、またはそのカーネル用に指定されたプライマリ関数の前に配置します。

__attribute__((reqd_work_group_size(X, Y, Z)))

説明:

• X、Y、Z: カーネルの ND 範囲を指定します。カーネルのワークグループのサイズを指定する 3 次

元行列の各次元を表します。




11




例例

次の OpenCL API C カーネルコードはベクトル加法デザインを記述したもので、2 つの配列のデータ

の和が 3 つ目の配列に挿入されます。ワークグループに必要なサイズは 16x1x1 です。このカーネル

は 16 回実行され、有効な結果が生成されます。

#include <clc.h>// For VHLS OpenCL C kernels, the full work group is synthesized__attribute__ ((reqd_work_group_size(16, 1, 1)))__kernel voidvadd(__global int* a,__global int* b,__global int* c){int idx = get_global_id(0);c[idx] = a[idx] + b[idx];}




• OpenCL C 仕様




12






vec_type_hintvec_type_hint

説明説明


オプションの __attribute__((vec_type_hint(<type>))) は OpenCL 言語仕様の一部であり、カ

ーネルの計算幅を表す OpenCL コンパイラへのヒントです。この設定は、コンパイラでコードを自動ベク

ター化しようとするときにプロセッサ帯域幅の使用率を計算する際のベースとなります。

デフォルトでは、カーネルに __attribute__((vec_type_hint(int))) 修飾子があるとして処理さ

れます。これにより、異なるベクター化タイプを指定できます。

自動ベクター化では、コンパイラでワークアイテムが結合または分離される状況に対応するため、カー

ネルから呼び出されたライブラリはランタイム時に再コンパイル可能であると想定されます。つまり、ライ

ブラリはハードコードされたバイナリではないか、ハードコードされたバイナリの場合はソースまたはリタ

ーゲット可能な中間表記も提供されていることが必要です。これが、コードセキュリティの問題となる可

能性もあります。

構文構文


__attribute__((vec_type_hint(<type>)))

説明:

• <type>: 次の表にリストされたビルトインベクターのいずれか、または構成スカラー要素のデータ

型。

注記: 指定しない場合は、INT 型であると想定されます。

表 2: ベクター型

型説明

charn n 個の 8 ビット符号付き 2 の補数整数値のベクター。

ucharn n 個の 8 ビット符号なし整数値のベクター。

shortn n 個の 16 ビット符号付き 2 の補数整数値のベクター。

ushortn n 個の 16 ビット符号なし整数値のベクター。

intn n 個の 32 ビット符号付き 2 の補数整数値のベクター。




13



型説明

uintn n 個の 32 ビット符号なし整数値のベクター。

longn n 個の 64 ビット符号付き 2 の補数整数値のベクター。

ulongn n 個の 64 ビット符号なし整数値のベクター。

floatn n 個の 32 ビット浮動小数点値のベクター。

doublen n 個の 64 ビット浮動小数点値のベクター。

注記: n を指定しない場合は、1 と想定されます。上記のベクターデータ型名で n が 2、3、4、8、および 16 以外

の値のものも、予約されています。つまり、n は 2、3、4、8、および 16 のみに指定できます。

例例

次の例では、基本計算幅が 2 倍幅整数であると想定して自動ベクター化を実行しています。

#include <clc.h>// For VHLS OpenCL C kernels, the full work group is synthesized__attribute__((vec_type_hint(double)))__attribute__ ((reqd_work_group_size(16, 1, 1)))__kernel void...




• OpenCL C 仕様




14






work_group_size_hintwork_group_size_hint

説明説明


OpenCL 規格のワークグループサイズは、カーネル計算ユニットの 1 回の起動で処理可能な ND 範

囲のサイズを定義します。OpenCL カーネルが OpenCL デバイスでの実行用に投稿すると、ND 範囲

(1、2、または 3 次元) と呼ばれるインデックス空間内で実行されます。詳細は、『SDAccel 環境最適化ガ

イド』 (UG1207) の「OpenCL Execution Model」 (OpenCL 実行モデル) を参照してください。

OpenCL カーネル関数は、ND 範囲インデックス空間の各点に対して 1 回のみ実行されます。ND 範囲

の各点に対するこの処理ユニットは、ワークアイテムと呼ばれます。ループ反復が順番どおりに順次実

行される C の for ループとは異なり、OpenCL ランタイムおよびデバイスではワークアイテムを並列に

任意の順序で実行できます。

ワークアイテムは、計算ユニットにスケジューリングされるワークユニットであるワークグループにまとめ

られます。オプションの work_group_size_hint 属性は OpenCL 言語仕様の一部であり、ほとんどの

場合に clEnqueueNDRangeKernel への local_work_size 引数により指定されるワークグループ

サイズ値を示す OpenCL コンパイラへのヒントです。これにより、生成されたコードが指定した値に従っ

て最適化されます。

ヒント: FPGA インプリメンテーションの場合は、reqd_work_group_size 属性をカーネルのカスタムロジックの生

成中にパフォーマンスを最適化するために使用できるので、work_group_size_hint の代わりにこの属性を指

定することをお勧めします。

構文構文


__attribute__((work_group_size_hint(X, Y, Z)))

説明:



例例

次の例では、カーネルがほとんどの場合にワークグループサイズ 1 で実行されることをコンパイラにヒ

ントとして指定しています。

__attribute__((work_group_size_hint(1, 1, 1)))




15




__kernel void...




• OpenCL C 仕様




16






xcl_array_partitionxcl_array_partition

説明説明

重要: 現在のところ、この属性で分割できるのは 1 次元配列のみです。

OpenCL™ プログラマのほかの計算デバイスと比較した場合の FPGA の利点は、システム全体のメモリ

アーキテクチャをカスタマイズし、計算ユニットに挿入できることです。デフォルトでは、SDAccel™ コンパ

イラにより、カーネルコードのスタティックコード解析に基づいてローカルおよびプライベートメモリの帯

域幅を最大限にする計算ユニット内にメモリアーキテクチャが生成されます。これらのメモリはカーネル

ソースコードの属性に基づいてさらに最適化することが可能であり、ローカルおよびプライベートメモリ

の物理的なレイアウトおよびインプリメンテーションを指定するのに使用できます。計算ユニットのメモリ

の物理的なレイアウトを制御する SDAccel コンパイラの属性は array_partition です。

1 次元配列の場合、array_partition 属性により、カーネルコード内で宣言された配列が 1 つの物

理メモリではなく複数の物理メモリにインプリメントされます。どの分割方法を使用するかは、アプリケー

ションおよびパフォーマンス要件によって異なります。SDAccel コンパイラで使用可能な配列の分割方

法は、cyclic、block、および complete です。

構文構文

この属性は、配列変数の定義に配置します。

__attribute__((xcl_array_partition(<partition_type>, <partition_factor>,<array_dimension>)))

説明:

• <partition_type>: 次のいずれかの分割タイプを指定します。

◦ cyclic: 循環分割では、配列が計算ユニットのロジックにより同時にアクセス可能な複数の小

型の物理メモリとしてインプリメントされます。各メモリに要素が 1 つずつ配置され、すべての

配列に配置されたら最初の配列に戻って、配列が完全に分割されるまでそれが繰り返されま

す。

◦ block: ブロック分割では、配列が計算ユニットのロジックにより同時にアクセス可能な複数の

小型メモリとしてインプリメントされます。メモリブロックに配列からの要素がフルになるまで配

置され、次のメモリブロックに移動してそれが繰り返されます。

◦ complete: 完全分割では、配列が個々の要素に分割されます。1 次元配列の場合は、メモリ

が個々のレジスタに分割されます。

◦ デフォルトの <partition_type> は complete です。




17



• <partition_factor>: 循環分割では、カーネルコードの元の配列をいくつの物理メモリに分割

するかを指定します。ブロック分割では、元の配列から各物理メモリに配置する要素の数を指定し

ます。

重要: 完全分割では指定しません。

• <array_dimension>: 分割する次元を指定します。1 ～ N の整数値を指定します。SDAccel では

N 次元の配列がサポートされ、配列をどの 1 つの次元でも分割できます。

例 1例 1

次のような配列宣言があるとします。

int buffer[16];

buffer という名前の整数配列には、32 ビット幅の値が 16 個格納されています。この配列に、次の宣言

を使用して循環分割を適用します。

int buffer[16] __attribute__((xcl_array_partition(cyclic,4,1)));

この例では、<partition_type> に cyclic が指定されており、配列の内容が 4 つの物理メモリに分割

されます。この属性により、配列 buffer へのアクセスに使用可能なメモリ帯域幅が 4 倍になります。

SDAccel では、計算ユニット内のすべての配列で最高 2 つの同時アクセスを保持できます。コードの元

の配列を 4 つの物理メモリに分割することにより、計算ユニットで配列 buffer に対する最高 8 つの同時

アクセスを保持できます。

例 2例 2

例 1 と同じ整数配列に、次の宣言を使用してブロック分割を適用します。

int buffer[16] __attribute__((xcl_array_partition(block,4,1)));

ブロックのサイズは 4 なので、SDAccel で 4 つの物理メモリが生成され、各メモリに配列からのデータが

順に配置されます。

例 3例 3

例 1 と同じ整数配列に、次の宣言を使用して完全分割を適用します。

int buffer[16] __attribute__((xcl_array_partition(complete, 1)));

この例では、配列がカーネルのプログラマブルロジックの分散 RAM または 16 個のレジスタに完全に

分割されます。完全分割がデフォルトなので、次の宣言を使用しても同じ結果が得られます。

int buffer[16] __attribute__((xcl_array_partition));




18



これによりメモリ帯域幅が最大のインプリメンテーションが作成されますが、すべてのアプリケーションに

適しているわけではありません。カーネルコードによる定数またはデータ依存インデックスを介したデー

タへのアクセス方法によって、元のコードと同等の機能を確実にするために SDx で各レジスタの周辺に

構築する必要のあるサポートロジックの量が異なります。SDx での一般的なベストプラクティスガイドラ

インとして、完全分割は、少なくとも 1 つの次元が定数インデックスを介してアクセスされる配列に適して

います。


• pragma HLS array_partition


• 『Vivado Design Suite ユーザーガイド: 高位合成』 (UG902)




19





xcl_data_packxcl_data_pack

説明説明

構造体 (struct) のデータフィールドをワード幅が広い 1 つのスカラーにパックします。

xcl_data_pack 属性は、struct のすべての要素を 1 つの幅の広いベクターにパックして、変数に必

要なメモリを削減します。これにより、struct のすべてのメンバーを同時に読み込みおよび書き込みで

きます。生成されるワードのビットアライメントは、struct フィールドの宣言順から推論されます。最初の

フィールドはベクターの LSB で、struct の最後の要素がベクターの MSB に揃えられます。

ヒント: struct 内で宣言されている配列はすべて完全に分割され、幅の広いスカラーに再形成されて、ほかのス

カラーフィールドと共にパックされます。

struct に配列が含まれる場合は、これらの配列を xcl_array_partition 属性を使用して分割する

ことにより最適化できます。xcl_data_pack 属性は xcl_array_partition 属性の完全分割と同様

の処理を実行し、struct の要素を 1 つの幅の広いベクターに再形成します。

struct は、xcl_data_pack を使用して最適化すると同時に分割することはできません。

xcl_data_pack および xcl_array_partition 属性を同時に使用することはできません。

大きな配列を含む構造体に xcl_data_pack 最適化を使用する際には注意が必要です。配列に int

型の要素が 4096 個含まれる場合、ベクター (およびポート) の幅は 4096*32=131072 ビットになります。

SDx でこの RTL デザインは作成できますが、FPGA インプリメンテーション中に論理合成でこれが配線

できることはほとんどありません。

構文構文

struct 変数が定義されている領域内に配置します。

__attribute__((xcl_data_pack(<variable>, <name>)))

説明:

• <variable>: パックする変数を指定します。

• <name>: パック後の変数名を指定します。<name> を指定しない場合は、<variable> の名前が

使用されます。

例 1例 1

次の例では、関数 foo の 8 ビットフィールド 3 つを持つ構造体 (typedef struct {unsigned char R, G,

B;} pixel) の配列 AB[17] を 24 ビットの 17 要素の配列 1 つにパックしています。




20



typedef struct{unsigned char R, G, B;} pixel;

pixel AB[17] __attribute__((xcl_data_pack(AB)));


• pragma HLS data_pack





21




xcl_dataflowxcl_dataflow

説明説明

xcl_dataflow 属性は、タスクレベルのパイプライン処理をイネーブルにして関数およびループを重

複できるようにし、RTL インプリメンテーションでの同時実行性を増加してデザイン全体のスループットを

向上します。

C 記述では、すべての演算が順次に実行されます。Vivado HLS では、pragma HLS allocation な

どのリソースを制限する指示子がない場合は、レイテンシを最小限に押さえ、同時実行性を増加するこ

とが試みられます。ただし、データ依存性のためにこれが制限されることがあります。たとえば、配列にア

クセスする関数またはループは、完了する前に配列への読み出し/書き込みアクセスをすべて終了する

必要があります。そのため、そのデータを消費する次の関数またはループの演算を開始できません。デ

ータフロー最適化を使用すると、前の関数またはループがすべての演算を完了する前に、次の関数ま

たはループの演算を開始できるようになります。

データフロー最適化を指定した場合、Vivado HLS で順次関数またはループ間のデータフローが解析さ

れ、プロデューサー関数またはループが完了する前にコンシューマー関数またはループの演算を開始

できるように、ピンポン RAM または FIFO に基づいてチャネルが作成されます。これにより関数または

ループを並列実行でき、レイテンシが削減されて RTL のスループットが向上します。

開始間隔 (II) (関数またはループの開始から次の関数またはループの開始までのサイクル数) が指定さ

れていない場合は、Vivado HLS で開始間隔が最小になるようにし、データが使用可能になったらすぐ

に演算を開始できるようにすることが試みられます。

ヒント: Vivado HLS には、データフローコンフィギュレーション設定があります。config_dataflow コマンドは、デ

ータフロー最適化で使用されるデフォルトのメモリチャネルと FIFO の深さを指定します。詳細は、『Vivado Design

Suite ユーザーガイド: 高位合成』 (UG902) を参照してください。

DATAFLOW 最適化が機能するようにするには、デザイン内でデータが 1 つのタスクから次のタスクに

流れる必要があります。次のコーディングスタイルを使用すると、Vivado HLS で DATAFLOW 最適化

が実行されなくなります。詳細は、『Vivado Design Suite ユーザーガイド: 高位合成』 (UG902) を参照し

てください。

• シングルプロデューサーコンシューマー違反

• タスクのバイパス

• タスク間のフィードバック

• タスクの条件付き実行

• 複数の exit 条件を持つループ

重要: これらのコーディングスタイルのいずれかが使用されている場合、Vivado HLS でメッセージが表示され、

DATAFLOW 最適化は実行されません。

最後に、DATAFLOW 最適化には階層インプリメンテーションはありません。サブ関数またはループに

DATAFLOW 最適化が有益な可能性のあるタスクが含まれる場合、DATAFLOW 最適化をそのループ

またはサブ関数に適用するか、サブ関数をインライン展開する必要があります。




22



構文構文

dataflow 属性は、関数定義またはループ定義の前に指定します。

__attribute__((xcl_dataflow))

例例

次の例では、関数 foo 内にデータフロー最適化を指定しています。

#pragma HLS dataflow


• pragma HLS dataflow






23





xcl_dependencexcl_dependence

説明説明

xcl_dependence 属性は、ループ運搬依存を克服し、ループをパイプライン処理できるようにする (ま

たはより短い間隔でパイプラインできるようにする) ための追加情報を提供します。

Vivado HLS では、次の依存性が自動的に検出されます。

• ループ内 (ループ独立依存)。

• 同じループの反復間 (ループ運搬依存)。

こうした依存は、演算をスケジューリングするタイミング、特に関数およびループのパイプライン処理に影

響します。

• ループ独立依存: 同じ要素が同じループ反復でアクセスされます。

for (i=0;i<N;i++) {A[i]=x;y=A[i];

}

• ループ運搬依存: 同じ要素が異なるループ反復でアクセスされます。

for (i=0;i<N;i++) {A[i]=A[i-1]*2;

}

複雑な条件下では、自動依存性解析が保守的すぎ、偽依存性が除去されないことがあります。変数依

存の配列インデックスや、外部要件を満たす必要があるような状況 (2 つの入力が同じインデックスにな

らない場合など) では、依存解析が保守的すぎることがあります。xcl_dependence 属性を使用すると、

依存を明示的に指定し、偽依存を解決できます。

重要: 偽依存でないものを偽依存と指定すると、ハードウェアが正しく機能しなくなる可能性があります。依存性

(true または false) が正しいことを確認してから指定してください。

構文構文

変数の宣言で設定します。

__attribute__((xcl_dependence(<class> <type> <direction> distance=<int><dependent>)))




24



説明:

• <class>: 依存を明確にする必要がある変数のクラスを指定します。有効な値は array または

pointer です。

ヒント: <class> と variable= を同時に指定することはできません。変数または変数のクラスのいずれかの

みを指定できます。

• <type>: 有効な値は intra または inter です。依存のタイプを指定します。

◦ intra: 同じループ反復内の依存。<type> を intra、<dependent> を false に設定すると、

Vivado HLS によりループ内で演算を自由に移動でき、パフォーマンスまたはエリアを向上で

きる可能性が高くなります。<dependent> を true に設定すると、演算を指定の順序で実行す

る必要があります。

◦ inter: 異なるループ反復間の依存。これがデフォルトです。<type> を inter、

<dependent> を false に設定すると、関数またはループがパイプライン処理されているか、ル

ープが展開されていない場合または部分的に展開されている場合に、並列実行が可能にな

り、<dependent> を true に設定すると並列実行が不可能になります。

• <direction>: 有効な値は RAW、WAR、または WAW です。これはループ運搬依存にのみ関連し、

依存の方向を指定します。

◦ RAW (Read-After-Write - 真の依存): 書き込み命令により書き込まれた値が読み出し命令で


◦ WAR (Write-After-Read - 非依存): 読み出し命令により値が取得され、その値が書き込み命

令で上書きされます。

◦ WAW (Write-After-Write - 出力依存): 2 つの書き込み命令により、特定の順序で同じロケー

ションに書き込みが実行されます。

• distance=<int>: 配列アクセスの反復間隔を指定します。これは、依存が true に設定されてい

るループ運搬依存でのみ使用されます。

• <dependent>: 依存を適用する必要があるか (true)、削除するか (false) を指定します。デフォ

ルトは true です。




25



例 1例 1

次の例では、Vivado HLS では cols の値を認識する機能がないので、buff_A[1][col] への書き込

みと buff_A[1][col] の読み出し間に常に依存性があると想定されます。このようなアルゴリズムで

は、cols が 0 になることはほとんどありませんが、Vivado HLS ではデータ依存を想定できません。この

依存を解決するため、xcl_dependence 属性を使用して、ループ反復間 (この例の場合は buff_A と

buff_B の両方) に依存がないことを指定できます。

void foo(int rows, int cols, ...)for (row = 0; row < rows + 1; row++) {

for (col = 0; col < cols + 1; col++)__attribute__((xcl_pipeline_loop(II=1)))

{if (col < cols) {buff_A[2][col] = buff_A[1][col] __attribute__((xcl_dependence(inter

false))); // read from buff_Abuff_A[1][col] = buff_A[0][col]; // write to buff_Abuff_B[1][col] = buff_B[0][col] __attribute__((xcl_dependence(inter

false)));temp = buff_A[0][col];

}

例 2例 2

次の例では、関数 foo の loop_1 の同じ反復での Var1 の依存を削除しています。

__attribute__((xcl_dependence(intra false)));

例 3例 3

次の例では、関数 foo の loop_2 にあるすべての配列の依存を定義し、同じループ反復ではすべて

の読み出しが書き込みの後に実行される (RAW) ように設定しています。

__attribute__((xcl_dependence(array intra RAW true)));


• pragma HLS dependence






26





xcl_max_work_group_sizexcl_max_work_group_size

説明説明

4K サイズよりも大型のカーネルを指定する必要がある場合は、reqd_work_group_size ではなくこの

属性を使用してください。

この属性は、SDx で reqd_work_group_size 属性によりサポートされるデフォルトの最大ワークグル

ープサイズを拡大します。ザイリンクス属性 xcl_max_work_group_size を使用すると、SDx で 4096

より大型のワークサイズをサポートできます。

注記: 実際のワークグループサイズの制限は、プラットフォームに選択したザイリンクスデバイスによって異なりま

す。

構文構文


__attribute__((xcl_max_work_group_size(X, Y, Z)))

説明:



例 1例 1

次は、最適化されていない加算器のカーネルソースコード例です。このデザインでは、ワークサイズを

行列のサイズ (64x64) に設定している以外は、属性は指定されていません。つまり、ワークグループ全

体を実行すると、入力行列 a および b が完全に加算され、output に結果が出力されます。3 つはすべ

てグローバル整数ポインターであり、行列の各値は 4 バイトで、オフチップの DDR グローバルメモリに

格納されます。

#define RANK 64__kernel __attribute__ ((reqd_work_group_size(RANK, RANK, 1)))void madd(__global int* a, __global int* b, __global int* output) {int index = get_local_id(1)*get_local_size(0) + get_local_id(0);output[index] = a[index] + b[index];}

このローカルワークサイズ (64, 64, 1) は、グローバルワークサイズと同じです。この設定により、合計

ワークサイズ 4096 が作成されます。

注記: これは、標準の OpenCL 属性 reqd_work_group_size を使用した場合に SDAccel でサポートされる最大ワー

クサイズです。ザイリンクス属性 xcl_max_work_group_size を使用すると、SDAccel で 4096 より大型のワークサイ

ズをサポートできます。




27



64x64 より大型の行列では、ワークサイズを定義するのに 1 次元のみを使用する必要があります。つま

り、128x128 行列はワークサイズ (128, 1, 1) のカーネルで演算できます (各実行でデータの行全体ま

たは列全体を演算)。




• OpenCL C 仕様




28






xcl_pipeline_loopxcl_pipeline_loop

説明説明

ループをパイプライン処理してレイテンシおよびスループットを向上します。ループ展開により同時実行

性は増加しますが、カーネルデータパスのすべての要素を常にビジー状態に保持する問題は解決さ

れません。これは、カーネルのスループットおよびパフォーマンスを最大にするために必要です。ルー

プ展開されていても、ループ制御依存により順次実行となることがあります。演算が順次実行されると、

ハードウェアがアイドル状態となり、パフォーマンスが低下します。

ザイリンクスでは、この問題に対処するために、ループパイプライン処理の OpenCL 2.0 仕様にベンダ

ー拡張を導入しました。ループパイプライン処理用のザイリンクス属性は xcl_pipeline_loop です。

デフォルトでは、SDAccel™ コンパイラにより、トリップカウントが 64 を超える場合は最内ループ、トリップ

カウントが 64 以下の場合は親ループにこの属性が自動的に適用されます。

構文構文

OpenCL ソースのループ定義の前に配置します。

__attribute__((xcl_pipeline_loop))

例例

次の例では、関数 vaccum の LOOP_1 をパイプライン処理し、パフォーマンスを向上しています。

__kernel __attribute__ ((reqd_work_group_size(1, 1, 1)))void vaccum(__global const int* a, __global const int* b, __global int*result){int tmp = 0;__attribute__((xcl_pipeline_loop))LOOP_1: for (int i=0; i < 32; i++) {tmp += a[i] * b[i];}result[0] = tmp;}


• pragma HLS pipeline






29





xcl_pipeline_workitemsxcl_pipeline_workitems

説明説明

ワークアイテムをパイプライン処理してレイテンシおよびスループットを向上します。ワークアイテムのパ

イプライン処理は、カーネルのワークグループに対するループのパイプライン処理の拡張です。これ

は、カーネルのスループットおよびパフォーマンスを最大にするために必要です。

構文構文

OpenCL ソースのパイプライン処理する要素の前に配置します。

__attribute__((xcl_pipeline_workitems))

例 1例 1

次の例の reqd_work_group_size 属性を処理するため、SDAccel により ND 範囲 (3,1,1) の 3 次元

特性を処理するループネストが自動的に挿入されます。この追加のループネストのため、このカーネル

の実行プロファイルはパイプライン処理されていないループのようになります。

xcl_pipeline_workitems 属性を追加すると、同時実行性が追加され、コードのスループットが向上

します。

kernel__attribute__ ((reqd_work_group_size(3,1,1)))void foo(...){...__attribute__((xcl_pipeline_workitems)) {int tid = get_global_id(0);op_Read(tid);op_Compute(tid);op_Write(tid);}...}

例 2例 2

次の例では、カーネルの適切な要素にワークアイテムパイプライン処理を追加しています。

__kernel __attribute__ ((reqd_work_group_size(8, 8, 1)))void madd(__global int* a, __global int* b, __global int* output)




30



{int rank = get_local_size(0);__local unsigned int bufa[64];__local unsigned int bufb[64];__attribute__((xcl_pipeline_workitems)) {int x = get_local_id(0);int y = get_local_id(1);bufa[x*rank + y] = a[x*rank + y];bufb[x*rank + y] = b[x*rank + y];}barrier(CLK_LOCAL_MEM_FENCE);__attribute__((xcl_pipeline_workitems)) {int index = get_local_id(1)*rank + get_local_id(0);output[index] = bufa[index] + bufb[index];}}








31





xcl_reqd_pipe_depthxcl_reqd_pipe_depth

説明説明

OpenCL 2.0 仕様には、パイプと呼ばれる新しいメモリオブジェクトが導入されています。パイプには、

FIFO として構成されたデータが格納されます。パイプを使用すると、FPGA デバイス内の 1 つのカーネ

ルから別のカーネルにデータを外部メモリを使用せずにストリーミングでき、全体的なシステムレイテン

シを大幅に向上できます。

SDAccel 開発環境では、パイプはすべてのカーネル関数の外部にスタティックに定義する必要がありま

す。パイプの深さは、パイプ宣言内で xcl_reqd_pipe_depth 属性を使用して指定する必要がありま

す。

pipe int p0 __attribute__((xcl_reqd_pipe_depth(512)));

重要: 1 つのパイプは、異なるカーネル内に 1 つのプロデューサーおよびコンシューマーのみを持つことができま

す。

パイプは、ノンブロッキングモードの標準 OpenCL read_pipe() および write_pipe() ビルトイン関

数、またはブロッキングモードのザイリンクスの拡張 read_pipe_block() および

write_pipe_block() 関数を使用してのみアクセス可能です。パイプオブジェクトはホスト CPU から

はアクセスできません。パイプのステータスは、OpenCL get_pipe_num_packets() および

get_pipe_max_packets() ビルトイン関数を使用してクエリできます。これらのビルトイン関数の詳細

は、Khronos OpenCL Working Group からの『The OpenCL C Specification』を参照してください。

構文構文

パイプオブジェクトの宣言で設定します。

pipe int p0 __attribute__((xcl_reqd_pipe_depth(n)));

説明:

• n: パイプの深さを指定します。有効な値は 16、32、64、128、256、512、1024、2048、4096、8192、

16384、32768 です。

例例

次はザイリンクス GitHub からの dataflow_pipes_ocl 例で、パイプを使用してブロッキング

read_pipe_block() および write_pipe_block() 関数によりデータを 1 つの処理段階から次の処

理段階に渡しています。

pipe int p0 __attribute__((xcl_reqd_pipe_depth(32)));




32


https://github.com/Xilinx/SDAccel_Examples/tree/master/getting_started/dataflow



pipe int p1 __attribute__((xcl_reqd_pipe_depth(32)));// Input Stage Kernel : Read Data from Global Memory and write into Pipe P0kernel __attribute__ ((reqd_work_group_size(1, 1, 1)))void input_stage(__global int *input, int size){__attribute__((xcl_pipeline_loop))mem_rd: for (int i = 0 ; i < size ; i++){//blocking Write command to pipe P0write_pipe_block(p0, &input[i]);}}// Adder Stage Kernel: Read Input data from Pipe P0 and write the result// into Pipe P1kernel __attribute__ ((reqd_work_group_size(1, 1, 1)))void adder_stage(int inc, int size){__attribute__((xcl_pipeline_loop))execute: for(int i = 0 ; i < size ; i++){int input_data, output_data;//blocking read command to Pipe P0read_pipe_block(p0, &input_data);output_data = input_data + inc;//blocking write command to Pipe P1write_pipe_block(p1, &output_data);}}// Output Stage Kernel: Read result from Pipe P1 and write the result to// Global Memorykernel __attribute__ ((reqd_work_group_size(1, 1, 1)))void output_stage(__global int *output, int size){__attribute__((xcl_pipeline_loop))mem_wr: for (int i = 0 ; i < size ; i++){//blocking read command to Pipe P1read_pipe_block(p1, &output[i]);}}




• OpenCL C 仕様




33






SDS プラグマSDS プラグマ

SDSoC での最適化SDSoC での最適化

このセクションでは、システム最適化を支援するための SDSoC システムコンパイラ sdscc および

sds++ のプラグマについて説明します。

SDSoC システムコンパイラは、ベースプラットフォームをターゲットとし、Vivado® 高位合成 (HLS) ツー

ルを起動して合成可能な C/C++ 関数をプログラマブルロジックにコンパイルします。SDSoC IDE また

は sdscc/sds++ コマンドラインオプションを使用して、ソースプログラムからハードウェアで実行する関

数を選択し、アクセラレータおよびシステムクロックを指定して、データ転送のプロパティを設定します。

SDSoC 環境では、通信と計算のバランスが取られるようにハードウェア関数およびハードウェア関数へ

の呼び出しを構成し、システムコンパイラに指示を与えるプラグマをソースコードに挿入することにより、

システム生成プロセスを制御します。SDSoC コンパイラでは、データ転送に最適なシステムポートが自

動的に選択されますが、プラグマを使用してこの選択を変更することもできます。また、ハードウェア関

数引数に異なるデータムーバーを選択するプラグマを指定したり、ハードウェア関数から転送またはハ

ードウェア関数に転送されるデータ要素数をプラグマを使用して制御したりできます。

SDSoC 環境専用のすべてのプラグマには最初に #pragma SDS が付いており、C/C++ ソースコード

の関数宣言の直前に挿入するか、特定の関数呼び出しを最適化するために関数呼び出しサイトに挿入

する必要があります。

#pragma SDS data access_pattern(in_a:SEQENTIAL, out_b:SEQUENTIAL)void f1(int in_a[20], int out_b[20]);

第 3 章



34



SDS プラグマには、次のタイプがあります。

表 3: SDS プラグマ (タイプ別)

タイププラグマ

データアクセスパターン • pragma SDS data access_pattern

データ転送サイズ • pragma SDS data copy

• pragma SDS data zero_copy

メモリの属性 • pragma SDS data mem_attribute

データムーバーのタイプ • pragma SDS data data_mover

外部メモリへの SDSoC プラットフォームインターフェイス • pragma SDS data sys_port

ハードウェアバッファーのワード数 • pragma SDS data buffer_depth

関数の非同期実行 • pragma SDS async

• pragma SDS wait

リソースバインドの指定 • pragma SDS resource

パーティション仕様 • pragma SDS partition

第 3 章: SDS プラグマ



35



pragma SDS asyncpragma SDS async

説明説明

ASYNC プラグマは、ハードウェア関数の同期化の手動制御をサポートするため、WAIT プラグマと共に使

用する必要があります。

ASYNC プラグマはハードウェア関数呼び出しの直前に指定し、データフロー解析に基づいて wait を自

動的に生成しないようにコンパイラに指示します。WAIT プラグマは、プログラムの適切な位置に挿入し、

関連付けられている同じ ID の ASYNC 関数呼び出しが完了するまで CPU が待機するよう指示します。

ASYNC プラグマを使用すると、SDSoC システムコンパイラで関連する呼び出しに対してスタブ関数内に

sds_wait() は生成されません。プログラムには、CPU で実行されている制御スレッドとハードウェア関

数スレッドを同期させるために sds_wait(ID) または #pragma SDS wait(ID) を適切な位置に含め

る必要があります。sds_wait(ID) 関数呼び出しの代わりに #pragma SDS wait(ID) を使用すると、

gcc などの ASYNC または WAIT プラグマを解釈しない SDSoC コンパイラ以外のコンパイラでソースコ

ードをコンパイルできるという利点があります。

構文構文

C ソースの関数呼び出しの直前に配置します。

#pragma SDS async(<ID>)...#pragma SDS wait(ID)

説明:

• <ID>: ASYNC/WAIT ペアのユーザー定義 ID。コンパイル時の符号なし整数定数として指定しま

す。

例 1例 1

次の例では、このプラグマを異なる ID を使用して複数指定しています。

{#pragma SDS async(1)mmult(A, B, C);#pragma SDS async(2)mmult(D, E, F);...#pragma SDS wait(1)#pragma SDS wait(2)

}




36



ハードウェアで実行されるプログラムは、まず A と B を mmult ハードウェアに送信して、すぐに戻りま

す。次に D と E を mmult ハードウェアに送信して、すぐに戻ります。プログラムが #pragma SDSwait(1) まで実行されると、出力 C が準備できるまで待機し、#pragma SDS wait(2) まで実行される

と、出力 F が準備できるまで待機します。

例 2例 2

次のコード例では、同じ ID のプラグマを使用して、データ転送とアクセラレータの実行をパイプライン処

理しています。

for (int i = 0; i < pipeline_depth; i++) {#pragma SDS async(1)mmult_accel(A[i%NUM_MAT], B[i%NUM_MAT], C[i%NUM_MAT]);

}for (int i = pipeline_depth; i < NUM_TESTS-pipeline_depth; i++) {

#pragma SDS wait(1)#pragma SDS async(1)mmult_accel(A[i%NUM_MAT], B[i%NUM_MAT], C[i%NUM_MAT]);

}for (int i = 0; i < pipeline_depth; i++) {

#pragma SDS wait(1)}

上記の例では、最初のループにより深さ pipeline_depth でパイプラインを増加し、2 つ目のループ

でパイプラインを実行し、3 つ目のループでパイプラインを減少しています。ハードウェアバッファーの

深さ (pragma SDS data buffer_depth を参照) は、pipeline_depth と同じ値に設定する必要がありま

す。このパイプラインの目的は、現在の実行が進行中に、次の実行のためにデータをアクセラレータに

転送することです。詳細は、『SDSoC 環境ユーザーガイド』 (UG1027) の「システムでの並列処理および

同時処理の増加」を参照してください。


• 『SDSoC 環境最適化ガイド』 (UG1235)

• 『SDSoC 環境ユーザーガイド』 (UG1027)




37

https://japan.xilinx.com/cgi-bin/docs/rdoc?v=2017.2;d=ug1027-sdsoc-user-guide.pdf

https://japan.xilinx.com/cgi-bin/docs/rdoc?v=2017.2;d=ug1235-sdsoc-optimization-guide.pdf




pragma SDS data access_patternpragma SDS data access_pattern

説明説明

このプラグマは、関数宣言の直前か、関数宣言に指定された別の #pragma SDS の直前に指定する必

要があります。

このプラグマは、ハードウェア関数のデータアクセスパターンを指定します。SDSoC でこのプラグマの

値が確認され、合成するハードウェアインターフェイスが決定されます。アクセスパターンに

SEQUENTIAL が指定されている場合は、ap_fifo などのストリーミングインターフェイスが生成されま

す。RANDOM が指定されている場合は、RAM インターフェイスが生成されます。データモーションネット

ワークを生成する際にこのプラグマを使用する方法については、『SDSoC 環境ユーザーガイド』

(UG1027) の SDSoC でのデータモーションネットワークの生成」を参照してください。

構文構文

このプラグマの構文は、次のとおりです。

#pragma SDS data access_pattern(ArrayName:<pattern>)

説明:

• ArrayName: プラグマを設定する関数の仮引数のいずれかを指定します。

• <pattern>: SEQUENTIAL または RANDOM のいずれかに指定できます。デフォルトは RANDOM で

す。

例 1例 1

次のコード例では、配列引数 (A) に対してこのプラグマを使用しています。

#pragma SDS data access_pattern(A:SEQUENTIAL)void foo(int A[1024], int B[1024])

上記の例の場合、引数 A に対してストリーミングインターフェイスが、引数 B に対して RAM インターフ

ェイスが生成されます。引数 A のアクセスパターンは A[0], A[1], A[2], ..., A[1023] のようにし、すべて

の要素が 1 回のみアクセスされるようにする必要があります。一方、引数 B はランダムにアクセスできる

ので、各要素は 0 回でも何回でもアクセスできます。




38




例 2例 2

次のコード例では、ポインター引数に対してこのプラグマを使用しています。

#pragma SDS data access_pattern(A:SEQUENTIAL)#pragma SDS data copy(A[0:1024])void foo(int *A, int B[1024])

上記の例では、引数 A がストリーミングポートになる場合、これら 2 つのプラグマを適用する必要があり

ます。これらのプラグマがないと、SDSoC では引数 A がレジスタ (関数 foo で A がどのように使用され

るかによって、IN、OUT、または INPUT) として合成されます。

例 3例 3

次のコード例では、zero_copy プラグマと access_pattern プラグマを組み合わせて使用していま

す。

#pragma SDS data zero_copy(A)#pragma SDS data access_pattern(A:SEQUENTIAL)void foo(int A[1024], int B[1024])

上記の例では、access_pattern プラグマは無視されます。zero_copy プラグマが引数に適用された

後、AXI4 マスターインターフェイスがその引数に対して合成されます。詳細は、『SDSoC 環境ユーザー

ガイド』 (UG1027) の「zero_copy データムーバー」を参照してください。







39






pragma SDS data buffer_depthpragma SDS data buffer_depth

説明説明


要があり、その関数の呼び出し元すべてに適用されます。

ブロック RAM または FIFO インターフェイスにマップされている配列にのみ適用されます。ブロック

RAM にマップされている配列では、<BufferDepth> 値はハードウェアマルチバッファーの深さを指定

します。FIFO にマップされている配列では、<BufferDepth> 値は配列に割り当てられているハードウ

ェア FIFO の深さを指定します。このプラグマでは、次が満たされている必要があります。

• ブロック RAM: 1 ≤ <BufferDepth> ≤ 4、および 2 ≤ ArraySize ≤ 16384。

• FIFO: <BufferDepth> = 2n

(4 ≤ n ≤ 20)。

ヒント: このプラグマを指定しない場合、デフォルトの BUFFER_DEPTH は 1 です。

構文構文


#pragma SDS data buffer_depth(ArrayName:<BufferDepth>)

説明:


• <BufferDepth>: コンパイル時定数値を指定する必要があります。

• 1 つのプラグマで複数の配列をカンマで区切って指定できます。次に例を示します。

#pragma SDS data buffer_depth(ArrayName1:BufferDepth1,ArrayName2:BufferDepth2)

例 1例 1

次の例では、引数 a の RAM インターフェイスに使用されるサイズ 4 のマルチバッファーを指定してい

ます。

#pragma SDS data buffer_depth(a:4)void foo(int a[1024], b[1024);




40









41





pragma SDS data copypragma SDS data copy

説明説明

pragma SDS data copy | zero_copy は、関数宣言の直前か、関数宣言に指定された別の

#pragma SDS の直前に指定する必要があります。

重要: COPY プラグマおよび ZERO_COPY プラグマは、同じオブジェクトに同時に指定することはできません。

COPY プラグマを使用すると、データがホストプロセッサメモリからハードウェア関数にコピーされます。

最適なデータムーバーによりデータ転送が実行されます。詳細は、『SDSoC 環境ユーザーガイド』

(UG1027) の「システムパフォーマンスの向上」を参照してください。

ZERO_COPY プラグマを使用すると、ハードウェア関数が AXI4 マスターバスインターフェイスを介して

共有メモリからデータに直接アクセスします。

重要: SDSoC コンパイラでは、デフォルトでは配列引数に COPY プラグマが想定され、データがプロセッサからデ

ータムーバーを介してアクセラレータにコピーされます。

構文構文


#pragma SDS data copy|zero_copy(ArrayName[<offset>:<length>])

説明:

• ArrayName[<offset>:<length>]: プラグマを割り当てる関数パラメーターまたは引数と、配列の

次元およびデータ転送サイズを指定します。

• ArrayName: パラメーター名がオプションであるプロトタイプからではなく、関数定義からの仮引数

のいずれかを指定する必要があります。

• <offset>: 配列の最初の要素からの要素数を指定します (オプション)。コンパイル時定数として指

定する必要があります。

重要: <offset> 値は現在のところ無視されますが、0 に指定する必要があります。

• <length>: 指定した次元に対して配列から転送する要素数を指定します。演算式が関数内で実行

時に解決可能であれば、任意の演算式にできます。

ヒント: 下の例に示すように、<length> は同じ関数のほかのスカラー引数を含む C 演算式にできます。




42




• 多次元配列では、各次元を個別に指定する必要があります。たとえば、2 次元配列の場合は次を

使用します。

pragma SDS datacopy(ArrayName[offset_dim1:length1][offset_dim2:length2])

• 同じプラグマで複数の配列をカンマ (,) で区切って指定できます。次に例を示します。

pragma SDS data copy(ArrayName1[offset1:length1],ArrayName2[offset2:length2])

• [<offset>:<length>] はオプションで、配列のデータ転送サイズをコンパイル時に決定できない

場合にのみ必要です。これを指定しない場合、COPY または ZERO_COPY プラグマは、データムー

バーを介したメモリとアクセラレータ間のコピーか、アクセラレータからプロセッサメモリへの直接ア

クセスかを選択するためにのみ使用されます。配列サイズを判断するため、SDSoC コンパイラでア

クセラレータ関数の呼び出しコードが解析され、配列のメモリ割り当て API (malloc または

sds_alloc など) に基づいて転送サイズが決定されます。この解析で判断できない場合、引数タ

イプがチェックされ、引数タイプにコンパイル時配列サイズが指定されていて、そのサイズがデータ

転送サイズとして使用されているかどうかが確認されます。データ転送サイズを判断できない場合、

コンパイラでエラーメッセージが表示され、[<offset_dim>:<length>] を使用してデータサイズを

指定できます。データサイズが呼び出し元と呼び出し先で異なる場合や、複数の呼び出し元間で

異なる場合にもコンパイラからエラーメッセージが表示されるので、ソースコードを修正するか、こ

のプラグマを使用してコンパイラによる解析を無効にできます。

例 1例 1

次の例では、関数宣言の直前に、COPY プラグマをアクセラレータ関数 foo の引数 A および B に適用

しています。<length> オプションは size*size という式で指定されています。

#pragma SDS data copy(A[0:size*size], B[0:size*size])void foo(int *A, int *B, int size) {...}

SDSoC システムコンパイラにより、関数 foo の本体がアクセラレータ制御、データ転送、およびデータ

同期コードに置き換えられます。次のコードに、データ転送部分を示します。

void _p0_foo_0(int *A, int *B, int size){

...cf_send_i(&(_p0_swinst_foo_0.A), A, (size*size) * 4, &_p0_request_0);cf_receive_i(&(_p0_swinst_foo_0.B), B, (size*size) * 4, &_p0_request_1);...

}

オフセット値 size*size は、SDSoC に配列 A および B のランタイム時の要素数を通知するために使

用されます。

ヒント: cf_send_i および cf_receive_i 関数には転送するバイト数を指定する必要があるので、コンパイラによ

り <length> で指定された要素数と各要素のバイト数 (この場合は 4) が乗算されます。




43



例 2例 2

次のコード例では、上記の COPY プラグマの代わりに ZERO_COPY プラグマを適用しています。

#pragma SDS data zero_copy(A[0:size*size], B[0:size*size])void foo(int *A, int *B, int size)

関数 foo の本体は次のようになります。

void _p0_foo_0(int *A, int *B, int size){

...cf_send_ref_i(&(_p0_swinst_foo_0.A), A, (size*size) * 4,

&_p0_request_0);cf_receive_ref_i(&(_p0_swinst_foo_0.B), B, (size*size) * 4,

&_p0_request_1);...

}

cf_send_ref_i および cf_receive_ref_i 関数は配列の参照またはポインターのみをアクセラレー

タに転送し、アクセラレータは直接メモリにアクセスします。

例 3例 3

次の例では、複数の配列に ZERO_COPY プラグマを指定し、DDR を使用した直接メモリインターフェ

イスとハードウェア関数を生成しています。

#pragma SDS data zero_copy(in1[0:mat_dim*mat_dim], in2[0:mat_dim*mat_dim],out[0:mat_dim*mat_dim])void matmul_partition_accel(int *in1, // Read-Only Matrix 1

int *in2, // Read-Only Matrix 2int *out, // Output Resultint mat_dim); // Matrix Dim (assumed only

square matrix) {...}




44



例 4例 4

次のコード例では、関数宣言に関数定義で使用されたのとは異なる引数名を使用するよくあるミスを示

しています。

"foo.h"#pragma SDS data copy(in_A[0:1024])void foo(int *in_A, int *out_B)

"foo.cpp"#include "foo.h"void foo(int *A, int *B){...}

C/C++ 規格では関数宣言の引数名はオプションなので、C/C++ コンパイラで関数宣言の引数名が無

視され、関数定義の引数名のみが使用されます。プラグマを適用しようとしたときに、SDSoC コンパイラ

により警告メッセージが表示されます。

WARNING: [SDSoC 0-0] Cannot find argument in_A in accelerator functionfoo(int *A, int *B)







45





pragma SDS data data_moverpragma SDS data data_mover

説明説明

重要: このプラグマは、通常の使用にはお勧めしません。コンパイラで生成されるデータムーバーでデザイン要件

が満たされない場合のみに使用してください。


要があります。その関数の呼び出し元すべてに適用されます。

デフォルトでは、SDSoC コンパイラによりコードが解析され、データ型が自動的に選択されます。

data_mover プラグマは、コンパイラでのデフォルトを無効にするために使用できます。このプラグマ

は、配列引数を転送するのに使用されるハードウェア IP タイプ (DataMover) を指定します。

コンパイラにより、対応する配列の転送に使用されるデータムーバーハードウェア IP のインスタンスが

自動的に割り当てられます。:id を指定すると、関連の仮引数に特定のデータムーバーインスタンスを

割り当てることができます。3 つ以上の仮引数の DataMover および id が同じ場合、これらの仮関数で

同じデータムーバーハードウェア IP インスタンスが共有されます。

重要: AXIDMA_SIMPLE データムーバーを使用するには、対応する配列を sds_alloc() を使用して割り当てる

必要があるという追加要件があります。

構文構文


#pragma SDS data data_mover(ArrayName:DataMover[:id])

説明:


• DataMover: AXIFIFO、AXIDMA_SG、または AXIDMA_SIMPLE のいずれかを指定します。

• :id: オプション。正の整数値を指定します。

• 1 つのプラグマで複数の配列をカンマ (,) で区切って指定できます。次に例を示します。

#pragma SDS data data_mover(ArrayName1:DataMover[:id],ArrayName2:DataMover[:id])




46



例 1例 1

次のコード例では、プラグマにデータムーバー ID を指定しています。

#pragma SDS data data_mover(A:AXIDMA_SG:1, B:AXIDMA_SG:1)void foo(int A[1024], int B[1024])

上記のプラグマの場合、同じデータムーバー ID が指定されているため、同じ AXIDMA_SG IP インスタ

ンスが共有されて、引数 A および B のデータが転送されます。







47





pragma SDS data mem_attributepragma SDS data mem_attribute

説明説明


要があります。その関数の呼び出し元すべてに適用されます。

仮想メモリをサポートする Linux のようなオペレーティングシステムの場合、ユーザー空間の割り当てら

れたメモリがページ化されるために、システムパフォーマンスに影響が出ることがあります。SDSoC ラン

タイムには、物理的に隣接したメモリを割り当てるための API も含まれます。このセクションのプラグマを

使用すると、コンパイラにその引数が物理的に隣接したメモリに割り当てらているかどうかを伝えることが

できます。

構文構文


#pragma SDS data mem_attribute(ArrayName:contiguity)

説明:


• Contiguity: PHYSICAL_CONTIGUOUS または NON_PHYSICAL_CONTIGUOUS のいずれかを

指定します。デフォルトは NON_PHYSICAL_CONTIGUOUS です。

◦ PHYSICAL_CONTIGUOUS: 関連付けられている ArrayName に対応するすべてのメモリが

sds_alloc を使用して割り当てられています。

◦ NON_PHYSICAL_CONTIGUOUS: 関連付けられている ArrayName に対応するすべてのメモ

リが malloc を使用して、またはスタックの自由変数として割り当てられています。これは、

SDSoC コンパイラでの最適なデータムーバーの選択に有益です。

• 1 つのプラグマで複数の配列をカンマ (,) で区切って指定できます。次に例を示します。

#pragma SDS data mem_attribute(ArrayName:contiguity,ArrayName:contiguity)

例 1例 1

次のコード例では、contiguity 属性を指定しています。

#pragma SDS data mem_attribute(A:PHYSICAL_CONTIGUOUS)void foo(int A[1024], int B[1024])




48



上記の例の場合、物理的に隣接したメモリブロックに配列 A を割り当てることを SDSoC コンパイラに伝

える必要があります。AXI_DMA_Simple の方が小型で物理的に隣接したメモリを高速に転送できるの

で、SDSoC コンパイラで AXI_DMA_SG の代わりに AXI_DMA_Simple が選択されます。







49





pragma SDS data sys_portpragma SDS data sys_port

説明説明


要があり、その関数の呼び出し元すべてに適用されます。

このプラグマを使用すると、SDSoC コンパイラによるデフォルトのメモリポートとは異なるメモリポートを

指定できます。配列引数に対して sys_port プラグマを指定しない場合、配列のメモリ属性 (キャッシュ

可能か不可能か)、配列サイズ、使用されるデータムーバーなどに基づいて、SDSoC システムコンパイ

ラ (sdscc/sds++) により外部メモリへのインターフェイスが自動的に選択されます。

構文構文


#pragma SDS data sys_port(ArrayName:port)

説明:


• port: ACP、AFI、MIG のいずれを指定します。

◦ Zynq-7000 All Programmable SoC では、プログラマブルロジックと外部メモリの間にキャッシ

ュコヒーレントインターフェイス (S_AXI_ACP)、ノンキャッシュコヒーレントアクセス (AFI) 用に

ハイパフォーマンスポート (S_AXI_HP) を使用できます。

◦ Zynq UltraScale+ MPSoC では、キャッシュコヒーレントインターフェイス (S_AXI_HPCn_FPD)

とノンキャッシュコヒーレントインターフェイス (S_AXI_HPn_FPD) を使用できます。

• 1 つのプラグマで複数の配列をカンマ (,) で区切って指定できます。

#pragma SDS data sys_port(ArrayName1:port, ArrayName2:port)

例 1例 1

次に、このプラグマの使用例を示します｡

#pragma SDS data sys_port(A:AFI)void foo(int A[1024], int B[1024])

上記の例では、呼び出し元で malloc または sds_alloc などのキャッシュ可能割り当て呼び出しで割

り当てられた配列が A 引数に渡されると、SDSoC コンパイラではそれが最適でなくても AFI プラットフォ

ームインターフェイスが使用されます。




50









51





pragma SDS partitionpragma SDS partition

説明説明

SDSoC 環境では、ランタイム時にダイナミックに読み込まれる 1 つのアプリケーションに対して複数のビ

ットストリームを自動的に生成できます。各ビットストリームには、それぞれパーティション識別子が含まれ

ます。

重要: プラットフォームでは、たとえば再読み込み後にシャットダウンして再起動できないプラットフォームペリフェ

ラルがある場合など、ビットストリームの再読み込みがサポートされないことがあります。

PARTITION プラグマはハードウェア関数呼び出しの直前に指定し、ハードウェア関数のインプリメンテ

ーションを指定のパーティション ID に割り当てるようコンパイラに指示します。SDSoC コンパイラでこの

プラグマが認識されると、パーティション用にビットストリームが自動的に作成され、必要なときにビットスト

リームを読み込む呼び出しが挿入されます。

ヒント: デフォルトでは、ハードウェア関数はパーティション 0 にインプリメントされます。

構文構文


#pragma SDS partition(<ID>)

説明:

• <ID>: 正の整数を指定します。

重要: パーティション ID 0 は予約済みです。

例 1例 1

次に、PARTITION プラグマの使用例を示します｡

foo(a, b, c);#pragma SDS partition (1)bar(c, d);#pragma SDS partition (2)bar(d, e);




52



この例の場合、ハードウェア関数 foo には partition プラグマがないので、パーティション 0 にインプリメ

ントされます。関数 bar への最初の呼び出しはパーティション 1 にインプリメントされます。このパーティ

ションには別のビットストリームがあり、関数を実行する前に読み込まれます。関数 bar への 2 番目の

読み出しは、パーティション 2 にインプリメントされます。

例 2例 2

次に、このプラグマの使用例を示します｡

#pragma SDS partition (1)sobel_filter(yc_out_tmp, out_frames[frame]);

この例では、sobel_filter 関数はパーティション 1 にインプリメントされ、実行中にこのパーティション

に到達したときにビットストリームが動的に読み込まれます。パーティション 1 が完了したら、パーティショ

ン 0 の処理が再開します。

sobel_filter の完全な例は、<install_path>/samples/file_io_manr_sobel_partitions に含ま

れています。







53





pragma SDS resourcepragma SDS resource

説明説明

このプラグマは、手動でリソースバインドを指定するために関数呼び出しサイトに使用できます。

resource プラグマはハードウェア関数呼び出しの直前に指定し、呼び出し元を指定したアクセラレー

タインスタンスにバインドするようにコンパイラに指示します。SDSoC コンパイラは、関数に複数のリソー

ス ID が指定されている状況を特定し、プログラマブルロジックにハードウェア関数を実現するハードウ

ェアアクセラレータとデータモーションネットワークをる自動的に生成します。

構文構文


#pragma SDS resource(<ID>)

説明:

• <ID>: コンパイル時符号なし整数定数を指定する必要があります。同じ関数の場合は、独自の ID

それぞれでハードウェアアクセラレータの各インスタンスを示します。

例 1例 1

次のコードは、異なる ID を使用したこのプラグマの例です。

{#pragma SDS resource(1)mmult(A, B, C);#pragma SDS resource(2)mmult(D, E, F);...

}

上記の例の場合、関数 mmult への最初の呼び出しが ID 1 のアクセラレータにバインドされ、mmult へ

の 2 つ目の呼び出しが ID 2 のアクセラレータにバインドされます。







54





pragma SDS waitpragma SDS wait

説明説明

ヒント: 詳細は、ASYNC プラグマを参照してください。

WAIT プラグマは、ハードウェア関数の同期化の手動制御をサポートするため、ASYNC プラグマと共に使

用する必要があります。

ASYNC プラグマはハードウェア関数呼び出しの直前に指定し、データフロー解析に基づいて wait を自

動的に生成しないようにコンパイラに指示します。WAIT プラグマは、プログラムの適切な位置に挿入し、

関連付けられている同じ ID の ASYNC 関数呼び出しが完了するまで CPU が待機するよう指示します。







55





pragma SDS data zero_copypragma SDS data zero_copy

説明説明

ヒント: zero_copy プラグマの完全な説明は、pragma SDS data copy を参照してください。

COPY プラグマを使用すると、ホストプロセッサメモリとハードウェア関数の間で転送に適切なデータム

ーバーを使用してデータが明示的にコピーされます。ZERO_COPY を使用すると、ハードウェア関数が

AXI4 マスターバスインターフェイスを介して共有メモリからデータに直接アクセスします。

例 1例 1

次の例では、複数の配列に ZERO_COPY プラグマを指定し、DDR を使用した直接メモリインターフェ

イスとハードウェア関数を生成しています。

#pragma SDS data zero_copy(in1[0:mat_dim*mat_dim], in2[0:mat_dim*mat_dim],out[0:mat_dim*mat_dim])void matmul_partition_accel(int *in1, // Read-Only Matrix 1

int *in2, // Read-Only Matrix 2int *out, // Output Resultint mat_dim); // Matrix Dim (assumed only

square matrix) {...}







56





HLS プラグマHLS プラグマ

Vivado HLS での最適化Vivado HLS での最適化

SDAccel および SDSoC プロジェクトでは、ハードウェアカーネルを OpenCL、C、または C++ 言語から

RTL に合成し、ザイリンクスデバイスのプログラマブルロジックにインプリメントできるようにする必要が

あります。Vivado HLS は、OpenCL、C、および C++ 言語記述から RTL を合成します。

Vivado HLS はユーザーの操作なしで SDAccel または SDSoC 開発環境プロジェクトを処理できるよう

設計されていますが、生成される RTL コードのレイテンシの削減、スループットパフォーマンスの向

上、エリアおよびデバイスリソース使用率の削減など、デザインを最適化するためのプラグマが提供さ

れています。これらのプラグマは、カーネルのソースコードに直接追加できます。

Vivado HLS では Tcl set_directive コマンドも提供されており、ハードウェアカーネルのパフォーマ

ンスおよび最適化を制御するためランタイム時にツールに渡すことができます。これらのオプションの詳

細は、『Vivado Design Suite ユーザーガイド: 高位合成』 (UG902) を参照してください。

重要: SDSoC 環境では HLS プラグマの使用がサポートされますが、内部プロセスおよびハードウェア要件に基づ

いて SDSoC コンパイラで HLS プラグマが自動的に定義されます。sdscc/sds++ で選択されるプラグマと競合する

HLS プラグマを手動で追加した場合は、この自動プロセスはディスエーブルになります。sdscc or sds++ による自

動の HLS プラグマ選択を無効にする場合以外は、SDSoC 環境で使用するために Vivado HLS プラグマを指定し

たり、set_directive Tcl コマンドを使用することは推奨されません。詳細は、『SDSoC 環境最適化ガイド』

(UG1235) の「ハードウェア関数の最適化」を参照してください。

第 4 章



57





Vivado HLS プラグマには、次の最適化タイプがあります。

表 4: Vivado HLS プラグマ (タイプ別)

タイプ属性

カーネル最適化 • pragma HLS allocation

• pragma HLS clock

• pragma HLS expression_balance

• pragma HLS latency

• pragma HLS reset

• pragma HLS resource

• pragma HLS top

関数のインライン展開 • pragma HLS inline

• pragma HLS function_instantiate

インターフェイス合成 • pragma HLS interface

• pragma HLS protocol

タスクレベルのパイプライン処理 • pragma HLS dataflow

• pragma HLS stream

パイプライン処理 • pragma HLS pipeline

• pragma HLS occurrence

ループ展開 • pragma HLS unroll


ループ最適化 • pragma HLS loop_flatten

• pragma HLS loop_merge

• pragma HLS loop_tripcount

配列最適化 • pragma HLS array_map


• pragma HLS array_reshape

構造体のパック • pragma HLS data_pack

第 4 章: HLS プラグマ



58



pragma HLS allocationpragma HLS allocation

説明説明

インプリメントされたカーネルでのリソースの割り当てを制限するインスタンス制限を指定します。特定の

関数、ループ、演算、またはコアをインプリメントするのに使用される RTL インスタンスおよびハードウェ

アリソースの数を定義して制限できます。ALLOCATION プラグマは関数の本体、ループ、またはコード

領域内に指定します。

たとえば、C ソースコードに foo_sub という関数のインスタンスが 4 つある場合、ALLOCATION プラグ

マを使用して最終 RTL で foo_sub のインスタンスを 1 つだけにできます。C 関数の 4 つのインスタン

スすべてが、同じ RTL ブロックを使用してインプリメントされます。これにより関数で使用されるリソース

は削減されますが、パフォーマンスが低下することがあります。

加算、乗算、配列読み出し、書き込みなどの C コードでの演算は、ALLOCATION プラグマを使用して制

限できます。合成中に演算子がマップされるコアは、それらの演算子と同じ方法で制限できます。乗算

演算子の総数を制限する代わりに、組み合わせ乗算器コアの数を制限して、残りの乗算がパイプライン

乗算器を使用して実行されるようにすることもできます (逆も可能)。

ALLOCATION プラグマは、指定された関数、ループ、またはコード領域内に適用されますが、

config_bind コマンドの -min_op 引数を使用して、デザイン全体で演算子の数を最小限に抑えること

もできます。

ヒント: 詳細は、『Vivado Design Suite ユーザーガイド: 高位合成』 (UG902) の「ハードウェアリソースの制御」およ

び config_bind を参照してください。

構文構文

このプラグラマは、適用する関数の本体、ループ、または領域内に配置します。

#pragma HLS allocation instances=<list> \limit=<value> <type>

説明:

• instances=<list>: 関数、演算子、またはコアの名前を指定します。

• limit=<value>: カーネルで使用されるインスタンスの制限を指定します (オプション)。




59




• <type>: ALLOCATION プラグマが、関数、演算、またはコア (デザインを作成するのに使用される

加算器、乗算器、パイプライン乗算器、ブロック RAM などのハードウェアコンポーネント) に適用さ

れることを指定します。次のいずれかを指定します。

◦ function: ALLOCATION プラグマが instances= にリストされた関数に適用されることを指

定します。関数には、次の条件を満たす元の C または C++ コードの関数を指定できます。

▪ pragma HLS inline または set_directive_inline によりインライン展開されていな

い。

▪ Vivado HLS により自動的にインライン展開されていない。

◦ operation: ALLOCATION プラグマが instances= にリストされた演算に適用されることを

指定します。ALLOCATION プラグマを使用して制限可能な演算のリストは、『Vivado Design

Suite ユーザーガイド: 高位合成』 (UG902) を参照してください。

◦ core: ALLOCATION プラグマが、コア (デザインを作成するのに使用される加算器、乗算器、

パイプライン乗算器、ブロック RAM などのハードウェアコンポーネント) に適用されることを指

定します。使用するコアは、instances= オプションで指定します。コアを指定する場合、ツー

ルで使用される必要のあるコアを指定するか、または指定したコアの制限を定義できます。

例 1例 1

デザインに関数 foo のインスタンスをが複数含まれているとします。この例では、ハードウェアカーネル

の RTL における foo のインスタンス数を 2 に制限しています。

#pragma HLS allocation instances=foo limit=2 function

例 2例 2

次の例では、関数 my_func のインプリメンテーションに使用される乗算演算の数を 1 に制限していま

す。この制限は、my_func 外にある乗算器、または my_func のサブ関数に含まれる乗算器には適用さ

れません。

ヒント: サブ関数のインプリメンテーションに使用される乗算器の数を制限するには、そのサブ関数に

ALLOCATION プラグマを指定するか、サブ関数を my_func にインライン展開します。

void my_func(data_t angle) {#pragma HLS allocation instances=mul limit=1 operation...}



• pragma HLS inline





60





pragma HLS array_mappragma HLS array_map

説明説明

複数の小型の配列を 1 つの大型の配列にまとめ、ブロック RAM リソースを削減します。

通常は、pragma HLS array_map コマンド (同じ instance= ターゲット) を使用して、複数の小型の

配列を 1 つの大型の配列にまとめます。この大型の配列は、1 つの大型メモリ (RAM または FIFO) リソ

ースに配置できます。

各配列は、ブロック RAM または UltraRAM (デバイスでサポートされる場合) にマップされます。FPGA

で提供される基本ブロック RAM の単位は 18K です。小型の配列の多くで 18K がフルに使用されない

場合、小型の配列を 1 つの大型の配列にマップすることでブロック RAM リソースを効率的に使用でき

ます。

ヒント: ブロック RAM が 18K を超える場合は、それらが複数の 18K 単位に自動的にマップされます。

ARRAY_MAP プラグマでは、複数の小型の配列を 1 つの大型の配列にマップするのに次の 2 つの方

法がサポートされています。

• 水平マップ: 元の配列を連結して新しい配列を作成します。物理的には、要素数の多い 1 つの配

列にインプリメントされます。

• 垂直マップ: 元の配列のワードを連結して、新しい配列を作成します。物理的には、ビット幅の広い

1 つの配列にインプリメントされます。

配列はプラグマが指定された順に、次のものから連結されます。

• 水平マップの場合はターゲット要素 0。

• 垂直マップの場合はビット 0。

構文構文

C ソースの配列変数が定義されている関数内に配置します。

#pragma HLS array_map variable=<name> instance=<instance> \<mode> offset=<int>

説明:

• variable=<name>: 必須の引数で、新しいターゲット配列 <instance> にマップする配列変数を

指定します。

• instance=<instance>: 配列の結合先である新しい配列の名前を指定します。

• <mode>: 配列マップを horizontal または vertical に指定します (オプション)。

◦ デフォルトは水平マップ (holizontal) で、配列は要素の多い新しい配列に連結されます。

◦ 垂直マップ (vertical) では、ワード数が多い新しい配列に連結されます。




61



• offset=<int>: 水平マップにのみ適用されます。配列を新しい配列 <instance> にマップする前

に適用するオフセット値を整数で指定します。次に例を示します。

◦ 配列変数の要素 0 は、新しいターゲットの要素 <int> にマップされます。

◦ ほかの要素は新しいターゲットの <int+1>、<int+2> にマップされます。

重要: オフセット値が指定されていない場合は、配列要素の重複を避けるため、Vivado HLS で必要なオフセ

ットが自動的に計算されます。

例 1例 1

次の例では、関数 foo の配列 array1 および array2 が array3 として指定した 1 つの配列にマッ

プされます。

void foo (...) {int8 array1[M];int12 array2[N];#pragma HLS ARRAY_MAP variable=array1 instance=array3 horizontal#pragma HLS ARRAY_MAP variable=array2 instance=array3 horizontal...loop_1: for(i=0;i<M;i++) {array1[i] = ...;array2[i] = ...;...}...}

例 2例 2

次の例では、関数 foo の配列 A[10] および B[15] を、新しい 1 つの配列 AB[25] にマップしていま

す。

• 要素 AB[0] は A[0] と同じになります。

• 要素 AB[10] は B[0] と同じになります (offset= オプションが使用されていないため)。

• 配列 AB[25] のビット幅は A[10] または B[15] の最大ビット幅になります。

#pragma HLS array_map variable=A instance=AB horizontal#pragma HLS array_map variable=B instance=AB horizontal

例 3例 3

次の例では、配列 C と D を垂直マップで連結し、C と B を結合したビット幅の新しい配列 CD にまとめ

ています。CD の要素数は、元の配列 C または D の最大数になります。

#pragma HLS array_map variable=C instance=CD vertical#pragma HLS array_map variable=D instance=CD vertical




62










63




pragma HLS array_partitionpragma HLS array_partition

説明説明

配列をより小型の配列または個々の要素に分割します。

この分割により、次のようになります。

• 1 つの大型メモリではなく、複数の小型メモリまたは複数のレジスタを含む RTL が生成されます。

• ストレージの読み出しおよび書き込みポートの数が増加します。

• デザインのスループットが向上する可能性があります。

• より多くのメモリインスタンスまたはレジスタが必要となります。

構文構文

C ソースの配列変数が定義されている関数内に配置します。

#pragma HLS array_partition variable=<name> \<type> factor=<int> dim=<int>

説明:

• variable=<name>: 必須の引数で、分割する配列変数を指定します。

• <type>: 分割タイプを指定します (オプション)。デフォルトは complete です。次のタイプがサポ

ートされます。

◦ cyclic: 循環分割では、元の配列の要素をインターリーブすることにより小型の配列が作成さ

れます。新しい各配列に要素が 1 つずつ配置され、すべての配列に配置されたら最初の配

列に戻って、配列が完全に分割されるまでそれが繰り返されます。たとえば factor=3 の場

合、要素は次のように割り当てられます。

▪ 要素 0 は 1 番目の新しい配列。



▪ 要素 3 は再び 1 番目の新しい配列。

◦ block: ブロック分割では、元の配列の連続したブロックから小型の配列が作成されます。N

が factor= 引数で定義される整数だとすると、1 つの配列が N 個のブロックに分割されま

す。

◦ complete: 完全分割では、配列が個々の要素に分割されます。1 次元配列の場合は、メモリ

が個々のレジスタに分割されます。これがデフォルトです。

• factor=<int>: 作成する小型の配列の数を指定します。

重要: 完全分割では指定しません。ブロック分割および循環分割では、factor= は必須です。




64



• dim=<int>: 多次元配列のどの次元を分割するかを指定します。配列が N 次元の場合、0 ～ N の

整数を指定します。

◦ 0 を指定すると、多次元配列のすべての次元が指定したタイプおよび係数オプションで分割さ

れます。

◦ 0 以外の値を指定すると、指定した次元のみが分割されます。たとえば、1 を指定した場合、

最初の次元のみが分割されます。

例 1例 1

次の例では、13 要素の配列 AB[13] をブロック分割を使用して 4 つの配列に分割しています。

#pragma HLS array_partition variable=AB block factor=4

ヒント: 13 は 4 の倍数ではないので、次のように分割されます。

• 3 つの配列には要素が 3 個ずつ含まれます。

• 1 つの配列には 4 つの要素が含まれます。

例 2例 2

次の例では、2 次元配列 AB[6][4] の 2 番目の次元を次元 [6][2] の配列 2 つに分割しています。

#pragma HLS array_partition variable=AB block factor=2 dim=2

例 3例 3

次の例では、2 次元配列 in_local の 2 番目の次元を個々の要素に分割しています。

int in_local[MAX_SIZE][MAX_DIM];#pragma HLS ARRAY_PARTITION variable=in_local complete dim=2


• pragma HLS array_map



• xcl_array_partition





65





pragma HLS array_reshapepragma HLS array_reshape

説明説明

配列分割と垂直配列マップを組み合わせます。

ARRAY_RESHAPE プラグマは、配列を複数の小型の配列に分割する ARRAY_PARTITION と、ビット幅を

増やして配列の要素を連結する ARRAY_MAP の垂直タイプを組み合わせたものです。これにより、使用

されるブロック RAM の数を削減すると共に、分割の主な利点であるデータへの並列アクセスを実現でき

ます。このプラグマでは元の配列よりも要素数が少なくビット幅の広い配列が作成され、1 クロックサイク

ルでアクセスできるデータ量が増加します。

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

void foo (...) {int array1[N];int array2[N];int array3[N];#pragma HLS ARRAY_RESHAPE variable=array1 block factor=2 dim=1#pragma HLS ARRAY_RESHAPE variable=array2 cycle factor=2 dim=1#pragma HLS ARRAY_RESHAPE variable=array3 complete dim=1...}

ARRAY_RESHAPE プラグマを使用すると、配列が次の図に示すように変換されます。

図 1: ARRAY_RESHAPE プラグマ

0 1 2 ... N-3 N-2 N-1

N/2 ... N-2 N-10 1 ... (N/2-1)

1 ... N-3 N-10 2 ... N-2

block

cyclic

complete

X14307

0 1 2 ... N-3 N-2 N-1

0 1 2 ... N-3 N-2 N-1

array1[N]

array2[N]

array3[N] N-1N-2...10

MSBLSB

MSBLSB

MSB

LSB

array4[N/2]

array5[N/2]

array6[1]

構文構文

C ソースの配列変数が定義されている関数の領域内に配置します。




66



#pragma HLS array_reshape variable=<name> \<type> factor=<int> dim=<int>

説明:

• <name>: 必須の引数で、再形成する配列変数を指定します。

• <type>: 分割タイプを指定します (オプション)。デフォルトは complete です。次のタイプがサポ

ートされます。

◦ cyclic: 循環再形成では、元の配列の要素をインターリーブすることにより小型の配列が作

成されます。たとえば、factor=3 の場合、要素 0 は新しく作成される 1 番目の配列に割り当

てられ、要素 1 は 2 番目、要素 2 は 3 番目、要素 3 は 1 番目の配列に割り当てられます。

最終的な配列は、新しい配列を 1 つの配列に垂直連結 (ワードを連結してワード数が大きい

ものを作成) したものになります。

◦ block: ブロック再形成では、元の配列の連続したブロックから小型の配列が作成されます。こ

れにより、配列が N 個 (N は factor= オプションで定義されている数) のブロックに分割さ

れ、その N 個のブロックが word-width*N で 1 つの配列にまとめられます。

◦ complete: 完全再形成では、配列が一時的に個々の要素に分割され、その後ワード数の大

きい 1 つの配列にまとめられます。1 次元配列の場合、これはワード数が非常に大きいレジス

タを 1 つ作成するのと同じです (元の配列が N 個の M ビット要素を含む場合、N*M ビットの

レジスタとなる)。これが配列再形成のデフォルトタイプです。

• factor=<int>: 現在の配列を分割する量 (一時的に作成する配列数) を指定します。2 に設定す

ると、配列が 2 分割され、ビット幅は倍になります。3 に設定すると、配列が 3 分割され、ビット幅は

3 倍になります。

重要: 完全分割では指定しません。ブロック再形成および循環再形成では、factor= は必須です。

• dim=<int>: 多次元配列のどの次元を分割するかを指定します。配列が N 次元の場合、0 ～ N の

整数を指定します。

◦ 0 を指定すると、多次元配列のすべての次元が指定したタイプおよび係数オプションで分割さ

れます。

◦ 0 以外の値を指定すると、指定した次元のみが分割されます。たとえば、1 を指定した場合、

最初の次元のみが分割されます。

• object: コンテナー配列のみに関連します。このキーワードを指定すると、ARRAY_RESHAPE プラ

グマがコンテナー内のオブジェクトに適用され、コンテナー内のオブジェクトのすべての次元が再

形成されますが、コンテナー自体のすべての次元は保持されます。このキーワードを指定しない場

合、プラグマはコンテナー配列に適用され、オブジェクトには適用されません。

例 1例 1

次の例では、17 個の要素を含む 8 ビット配列 AB[17] を、ブロックマップを使用して 5 つの要素を含

む 32 ビット配列に再形成 (分割およびマップ) しています。

#pragma HLS array_reshape variable=AB block factor=4

ヒント: factor=4 は、配列を 4 つに分割することを指定します。つまり、17 個の要素がビット幅が 4 倍の 5 つの要

素を含む配列に再形成されます。この場合、最後の要素 AB[17] は、5 番目の要素の下位 8 ビットにマップされ、

5 番目の要素の残りは空になります。




67



例 2例 2

次の例では、2 次元配列 AB[6][4] を次元 [6][2] の配列 1 つに再形成しています。この次元 2 のビット

幅は 2 倍です。

#pragma HLS array_reshape variable=AB block factor=2 dim=2

例 3例 3

次の例では、関数 foo の 3 次元の 8 ビット配列 AB[4][2][2] を 128 ビット幅は (4*2*2*8) の 1 要素配

列 (1 つのレジスタ) に再形成しています。

#pragma HLS array_reshape variable=AB complete dim=0

ヒント: dim=0 は、配列のすべての次元を再形成することを指定します。









68





pragma HLS clockpragma HLS clock

説明説明

指定したクロックを指定した関数に適用します。

C および C++ デザインでは、クロック 1 つのみがサポートされます。create_clock で指定したクロック

周期が、デザイン内のすべての関数に適用されます。

SystemC デザインでは、複数のクロックがサポートされます。create_clock コマンドを使用して複数の

クロックを指定し、pragma HLS clock を使用して個々の SC_MODULE に適用できます。各

SC_MODULE は、1 つのクロックを使用して合成されます。

構文構文

C ソースの関数本体内に配置します。

#pragma HLS clock domain=<clock>

説明:

• domain=<clock>: クロック名を指定します。

重要: create_clock コマンドを使用して既に作成されているクロックを指定する必要があります。create_clock と

同等のプラグマはありません。詳細は、『Vivado Design Suite ユーザーガイド: 高位合成』 (UG902) を参照してく

ださい。

例 1例 1

最上位 foo_top にクロックポート fast_clock および slow_clock を含む SystemC デザインがある

とします。foo_top ではその関数内で fast_clock のみが使用され、サブブロック foo_sub では

slow_clock のみが使用されます。

この例では、Vivado HLS ツールを起動したときに指定された script.tcl ファイルで次の

create_clock コマンドが指定されています。

create_clock -period 15 fast_clkcreate_clock -period 60 slow_clk

C ソースファイルで次のプラグマを指定し、クロックを指定の関数 foo_sub および foo_top に割り当

てています。

foo_sub (p, q) {#pragma HLS clock domain=slow_clock




69




...}void foo_top { a, b, c, d} {

#pragma HLS clock domain=fast_clock...






70




pragma HLS data_packpragma HLS data_pack

説明説明

構造体 (struct) のデータフィールドをワード幅が広い 1 つのスカラーにパックします。

DATA_PACK プラグマは、struct のすべての要素を 1 つの幅の広いベクターにパックし、変数に必要

なメモリを削減すると同時に、struct のすべてのメンバーを同時に読み出しおよび書き込みできるよう

にします。生成されるワードのビットアライメントは、struct フィールドの宣言順から推論されます。最初

のフィールドはベクターの LSB で、struct の最後の要素がベクターの MSB に揃えられます。

struct に配列が含まれる場合、DATA_PACK プラグマにより ARRAY_RESHAPE プラグマと同様の処理が

実行され、再形成された配列が struct 内のほかの要素とまとめられます。struct 内で宣言されてい

る配列はすべて完全に分割され、幅の広いスカラーに再形成されて、ほかのスカラーフィールドと共に

パックされます。ただし、struct を DATA_PACK と ARRAY_PARTITION または ARRAY_RESHAPE を同時

に使用して最適化することはできません。これらのプラグマは同時に使用できません。

重要: 大型の配列を含む struct オブジェクトに DATA_PACK 最適化を使用する際は注意が必要です。配列に

int 型の要素が 4096 個含まれる場合、ベクター (およびポート) の幅は 4096*32=131072 ビットになります。Vivado

HLS でこの RTL デザインは作成できますが、FPGA インプリメンテーション中に論理合成でこれが配線できること

はほとんどありません。

通常は、任意精度 (またはビット精度) データ型を使用することをお勧めします。標準 C 型は 8 ビット境

界 (8、16、32、64 ビット) に基づいていますが、デザインで任意精度型を使用すると、合成前に C コー

ドでビットサイズを指定できます。ビット精度幅の方が、小型で高速なハードウェア演算子が得られま

す。これにより、より多くのロジックが FPGA に配置できるようになり、ロジックがより高速のクロック周波数

で実行できるようになります。DATA_PACK プラグマでは、必要に応じて、パック型 struct のデータを 8

ビット境界に揃えることもできます。

struct ポートを AXI4 インターフェイスを使用してインプリメントする場合は、DATA_PACK <byte_pad>

オプションを使用して struct のメンバー要素が 8 ビット境界に自動的に揃えられるようにすることを考

慮してください。AXI4-Stream プロトコルでは、IP の TDATA ポートの幅を 8 の倍数にする必要がありま

す。TDATA ポートの幅が 8 の倍数でない AXI4-Stream IP を定義することは仕様違反となるので、

TDATA の幅をバイトの倍数に繰り上げる必要があります。詳細は、『Vivado Design Suite ユーザーガイ

ド: 高位合成』 (UG902) の「インターフェイス合成および構造体」を参照してください。

構文構文

パックする struct 変数の定義の近くに配置します。

#pragma HLS data_pack variable=<variable> \instance=<name> <byte_pad>

説明:

• variable=<variable>: パックする変数を指定します。




71




• instance=<name>: パック後の変数名を指定します。<name> を指定しない場合は、<variable>の名前が使用されます。

• <byte_pad>: データを 8 ビット境界 (8 ビット、16 ビット、24 ビット...) 上にパックするかを指定します

(オプション)。次の 2 つの値がサポートされます。

◦ struct_level: まず struct 全体をパックし、次の 8 ビット境界までパディングします。

◦ field_level: struct の各要素 (フィールド) をそれぞれ 8 ビット境界までパディングしてか

ら、struct をパックします。

ヒント: データの複数のフィールドをバイト境界に揃える前 (field_level) または後 (struct_level) に連

結するかは、通常データがどれだけアトミックであるかによって決定されます。アトミック情報はそれのみで解

釈可能なデータであり、非アトミック情報はデータの解釈には不完全です。たとえば、アトミックデータには浮

動小数点値のすべてのビットが含まれます。浮動小数点値の指数ビットのみでは、アトミックではありません。

TDATA に情報をパックする際は通常、ビット幅にかかわらず、データの非アトミックビットはアトミックユニット

を形成するまで連結されます。その後、アトミックユニットが必要に応じてパディングビットを使用してバイト境

界にそろえられます。

例 1例 1

次の例では、3 つの 8 ビットフィールド (R、G、B) を含む struct 配列 AB[17] を、17 個の 24 ビット要

素の配列 1 つにパックしています。


pixel AB[17];#pragma HLS data_pack variable=AB

例 2例 2

次の例では、関数 foo にある 3 つの 8 ビットフィールドを含む struct ポインター AB (typedef struct

{unsigned char R, G, B;} pixel) を 1 つの 24 ビットポインターにパックしています。


pixel AB;#pragma HLS data_pack variable=AB

例 3例 3

次の例では、rgb_to_hsv 関数の in および out 引数に DATA_PACK プラグマを指定して構造体を 8

ビット境界にパックし、メモリアクセスを向上しています。

void rgb_to_hsv(RGBcolor* in, // Access global memory as RGBcolor




72



struct-wiseHSVcolor* out, // Access Global Memory as HSVcolor

struct-wiseint size) {

#pragma HLS data_pack variable=in struct_level#pragma HLS data_pack variable=out struct_level...}








73




pragma HLS dataflowpragma HLS dataflow

説明説明

DATAFLOW プラグマは、タスクレベルのパイプライン処理をイネーブルにして関数およびループをオー

バーラップできるようにし、RTL インプリメンテーションでの同時実行性を増加してデザイン全体のスル

ープットを向上します。

C 記述では、すべての演算が順次に実行されます。Vivado HLS では、pragma HLS allocation な

どのリソースを制限する指示子がない場合は、レイテンシを最小限に押さえ、同時実行性を増加するこ

とが試みられます。ただし、データ依存性のためにこれが制限されることがあります。たとえば、配列にア

クセスする関数またはループは、完了する前に配列への読み出し/書き込みアクセスをすべて終了する

必要があります。そのため、そのデータを消費する次の関数またはループの演算を開始できません。

DATAFLOW 最適化を使用すると、前の関数またはループがすべての演算を完了する前に、次の関数ま

たはループの演算を開始できるようになります。

図 2: DATAFLOW プラグマ

void top (a,b,c,d) { ... func_A(a,b,i1); func_B(c,i1,i2); func_C(i2,d)

return d;}

func_Afunc_Afunc_Bfunc_Bfunc_Cfunc_C

8 cycles

func_Afunc_A func_Bfunc_B func_Cfunc_C

8 cycles

3 cycles

func_Afunc_Afunc_Bfunc_B

func_Cfunc_C

func_Afunc_Afunc_Bfunc_B

func_Cfunc_C

5 cycles

(A) Without Dataflow Pipelining (B) With Dataflow Pipelining

X14266

DATAFLOW プラグマを指定した場合、Vivado HLS で順次関数またはループ間のデータフローが解析さ

れ、プロデューサー関数またはループが完了する前にコンシューマー関数またはループの演算を開始

できるように、ピンポン RAM または FIFO に基づいてチャネルが作成されます。これにより関数または

ループを並列実行でき、レイテンシが削減されて RTL のスループットが向上します。

開始間隔 (II) (関数またはループの開始から次の関数またはループの開始までのサイクル数) が指定さ

れていない場合は、Vivado HLS で開始間隔が最小になるようにし、データが使用可能になったらすぐ

に演算を開始できるようにすることが試みられます。




74



ヒント: config_dataflow コマンドは、データフロー最適化で使用されるデフォルトのメモリチャネルと FIFO の

深さを指定します。詳細は、『Vivado Design Suite ユーザーガイド: 高位合成』 (UG902) の config_dataflowコマンドを参照してください。

DATAFLOW 最適化が機能するようにするには、デザイン内でデータが 1 つのタスクから次のタスクに流

れる必要があります。次のコーディングスタイルを使用すると、Vivado HLS で DATAFLOW 最適化が実

行されなくなります。

• シングルプロデューサーコンシューマー違反

• タスクのバイパス

• タスク間のフィードバック

• タスクの条件付き実行

• 複数の exit 条件を持つループ

重要: これらのコーディングスタイルのいずれかが使用されている場合、Vivado HLS でメッセージが表示され、

DATAFLOW 最適化は実行されません。

最後に、DATAFLOW 最適化には階層インプリメンテーションはありません。サブ関数またはループに

DATAFLOW 最適化が有益な可能性のあるタスクが含まれる場合、DATAFLOW 最適化をそのループま

たはサブ関数に適用するか、サブ関数をインライン展開する必要があります。

構文構文

C ソースの領域、関数、またはループ内に配置します。


例 1例 1

次の例では、ループ wr_loop_j 内で DATAFLOW 最適化を指定しています。

wr_loop_j: for (int j = 0; j < TILE_PER_ROW; ++j) {#pragma HLS DATAFLOW

wr_buf_loop_m: for (int m = 0; m < TILE_HEIGHT; ++m) {wr_buf_loop_n: for (int n = 0; n < TILE_WIDTH; ++n) {

#pragma HLS PIPELINE// should burst TILE_WIDTH in WORD beatoutFifo >> tile[m][n];

}}wr_loop_m: for (int m = 0; m < TILE_HEIGHT; ++m) {

wr_loop_n: for (int n = 0; n < TILE_WIDTH; ++n) {#pragma HLS PIPELINE

outx[TILE_HEIGHT*TILE_PER_ROW*TILE_WIDTH*i+TILE_PER_ROW*TILE_WIDTH*m+TILE_WIDTH*j+n]= tile[m][n];

}}




75





• pragma HLS allocation


• xcl_dataflow





76





pragma HLS dependencepragma HLS dependence

説明説明

DEPENDENCE プラグマは、ループ運搬依存を克服し、ループをパイプライン処理できるようにする (また

はより短い間隔でパイプラインできるようにする) ための追加情報を提供します。

Vivado HLS では、次の依存性が自動的に検出されます。

• ループ内 (ループ独立依存)。

• 同じループの反復間 (ループ運搬依存)。

こうした依存は、演算をスケジューリングするタイミング、特に関数およびループのパイプライン処理に影

響します。

• ループ独立依存: 同じ要素が同じループ反復でアクセスされます。

for (i=0;i<N;i++) {A[i]=x;y=A[i];

}

• ループ運搬依存: 同じ要素が異なるループ反復でアクセスされます。

for (i=0;i<N;i++) {A[i]=A[i-1]*2;

}

複雑な条件下では、自動依存性解析が保守的すぎ、偽依存性が除去されないことがあります。変数依

存の配列インデックスや、外部要件を満たす必要があるような状況 (2 つの入力が同じインデックスにな

らない場合など) では、依存解析が保守的すぎることがあります。DEPENDENCE プラグマを使用すると、

依存を明示的に指定し、偽依存を解決できます。

重要: 偽依存でないものを偽依存と指定すると、ハードウェアが正しく機能しなくなる可能性があります。依存性

(true または false) が正しいことを確認してから指定してください。

構文構文

依存が定義されている関数内に配置します。

#pragma HLS dependence variable=<variable> <class> \<type> <direction> distance=<int> <dependent>

説明:

• variable=<variable>: 依存を考慮する変数を指定します (オプション)。




77



• <class>: 依存を明確にする必要がある変数のクラスを指定します (オプション)。有効な値は

array または pointer です。

ヒント: 関数内で変数または変数のクラスのいずれかを指定していれば、<class> および variable= の両

方を指定する必要はありません。

• <type>: 有効な値は intra または inter です。依存のタイプを指定します。

◦ intra: 同じループ反復内の依存。<type> を intra、<dependent> を false に設定すると、

Vivado HLS によりループ内で演算を自由に移動でき、パフォーマンスまたはエリアを向上で

きる可能性が高くなります。<dependent> を true に設定すると、演算を指定の順序で実行す

る必要があります。

◦ inter: 異なるループ反復間の依存。これがデフォルトです。<type> を inter、

<dependent> を false に設定すると、関数またはループがパイプライン処理されているか、ル

ープが展開されていない場合または部分的に展開されている場合に、並列実行が可能にな

り、<dependent> を true に設定すると並列実行が不可能になります。

• <direction>: 有効な値は RAW、WAR、または WAW です。これはループ運搬依存にのみ関連し、

依存の方向を指定します。

◦ RAW (Read-After-Write - 真の依存): 書き込み命令により書き込まれた値が読み出し命令で


◦ WAR (Write-After-Read - 非依存): 読み出し命令により値が取得され、その値が書き込み命

令で上書きされます。

◦ WAW (Write-After-Write - 出力依存): 2 つの書き込み命令により、特定の順序で同じロケー

ションに書き込みが実行されます。

• distance=<int>: 配列アクセスの反復間隔を指定します。これは、依存が true に設定されてい

るループ運搬依存でのみ使用されます。

• <dependent>: 依存を適用する必要があるか (true)、削除するか (false) を指定します。デフォ

ルトは true です。

例 1例 1

次の例では、Vivado HLS では cols の値を認識する機能がないので、buff_A[1][col] への書き込

みと buff_A[1][col] の読み出し間に常に依存性があると想定されます。このようなアルゴリズムで

は、cols が 0 になることはほとんどありませんが、Vivado HLS ではデータ依存を想定できません。この

依存を解決するため、DEPENDENCE プラグマを使用して、ループ反復間 (この例の場合は buff_A と

buff_B の両方) に依存がないことを指定できます。

void foo(int rows, int cols, ...)for (row = 0; row < rows + 1; row++) {

for (col = 0; col < cols + 1; col++) {#pragma HLS PIPELINE II=1#pragma HLS dependence variable=buff_A inter false#pragma HLS dependence variable=buff_B inter falseif (col < cols) {buff_A[2][col] = buff_A[1][col]; // read from buff_A[1][col]buff_A[1][col] = buff_A[0][col]; // write to buff_A[1][col]buff_B[1][col] = buff_B[0][col];temp = buff_A[0][col];

}




78



例 2例 2

次の例では、関数 foo の loop_1 の同じ反復での Var1 の依存を削除しています。

#pragma HLS dependence variable=Var1 intra false

例 3例 3

次の例では、関数 foo の loop_2 にあるすべての配列の依存を定義し、同じループ反復ではすべて

の読み出しが書き込みの後に実行される (RAW) ように設定しています。

#pragma HLS dependence array intra RAW true




• xcl_pipeline_loop





79





pragma HLS expression_balancepragma HLS expression_balance

説明説明

C ベースの仕様が演算のシーケンスで記述され、RTL で長い演算チェーンとなることがあります。クロッ

ク周期が短い場合、これによりデザインレイテンシが増加する可能性あります。デフォルトでは、Vivado

HLS で演算の関連性および接続性を考慮して、演算が並べ替えられます。これにより、ツリーのバラン

スが取られてチェーンが短くなるので、ハードウェアリソースは増加しますが、デザインのレイテンシを削

減できます。

EXPRESSION_BALANCE プラグマを使用すると、指定のスコープ内でこの演算調整をディスエーブルま

たは明示的にイネーブルにできます。

構文構文

C ソースの必要なロケーションの境界内に配置します。

#pragma HLS expression_balance off

説明:

• off: 指定のロケーションで演算調整をオフにします。

ヒント: プラグマでこのオプションを使用しないと、デフォルトで演算調整がオンになります。

例 1例 1

次の例では、関数 my_Func 内で演算調整を明示的にオンにしています。

void my_func(char inval, char incr) {#pragma HLS expression_balance

例 2例 2

次の例では、関数 my_Func 内で演算調整をオフにしています。

void my_func(char inval, char incr) {#pragma HLS expression_balance off




80








81




pragma HLS function_instantiatepragma HLS function_instantiate

説明説明

FUNCTION_INSTANTIATE プラグマは、関数の階層を保持するエリアの利点を維持しながら、関数の特

定のインスタンスに対してローカル最適化を実行する優れたオプションを提供する最適化手法です。こ

れにより関数呼び出し周辺の制御ロジックが単純になり、レイテンシおよびスループットが向上すること

があります。

デフォルトでは次のようになります。

• 関数は RTL で個別の階層ブロックのままになります。

• 同じ階層レベルにある関数のすべてのインスタンスは、同じ RTL インプリメンテーション (ブロック)

を使用します。

FUNCTION_INSTANTIATE プラグマは、関数の各インスタンスに固有の RTL インプリメンテーションを作

成し、関数呼び出しに応じて各インスタンスをローカルで最適化できるようにします。このプラグマを使用

すると、関数が呼び出されたときに関数の一部の入力が定数であることがあるという事実を利用して、周

辺の制御構造が単純化され、小型で最適化された関数ブロックが作成されます。

FUNCTION_INSTANTIATE プラグマを使用しない場合、次のコードから、foo 内の関数の 3 つのインス

タンスすべてに対して関数 foo_sub の RTL インプリメンテーションが 1 つ作成されます。関数

foo_sub の各インスタンスはまったく同じようにインプリメントされます。これは、関数を再利用して、関数

の各インスタンス呼び出しに必要なエリアを削減するには良いですが、foo_sub の各呼び出しのバリエ

ーションを考慮するため、関数内の制御ロジックがより複雑なものとなります。

char foo_sub(char inval, char incr) {#pragma HLS function_instantiate variable=incrreturn inval + incr;

}void foo(char inval1, char inval2, char inval3,char *outval1, char *outval2, char * outval3)

{*outval1 = foo_sub(inval1, 1);*outval2 = foo_sub(inval2, 2);*outval3 = foo_sub(inval3, 3);

}

上記のコード例では、FUNCTION_INSTANTIATE プラグマにより関数 foo_sub の 3 つのインプリメンテ

ーションが生成され、それぞれを個別に incr 引数で最適化されるので、エリアが削減されて関数のパ

フォーマンスが向上します。FUNCTION_INSTANTIATE 最適化の後、foo_sub は 3 つの個別の関数に

変換され、それぞれ incr に指定された値によって最適化されます。

構文構文





82



#pragma HLS function_instantiate variable=<variable>

説明:

• variable=<variable>: 必須の引数で、定数として使用する関数引数を定義します。

例 1例 1

次の例では、関数 swInt に FUNCTION_INSTANTIATE プラグマを配置し、関数 swInt の各インスタ

ンスが maxv 関数引数に対して個別に最適化されるようにしています。

void swInt(unsigned int *readRefPacked, short *maxr, short *maxc, short*maxv){#pragma HLS function_instantiate variable=maxv

uint2_t d2bit[MAXCOL];uint2_t q2bit[MAXROW];

#pragma HLS array partition variable=d2bit,q2bit cyclic factor=FACTOR

intTo2bit<MAXCOL/16>((readRefPacked + MAXROW/16), d2bit);intTo2bit<MAXROW/16>(readRefPacked, q2bit);sw(d2bit, q2bit, maxr, maxc, maxv);

}



• pragma HLS inline





83




pragma HLS inlinepragma HLS inline

説明説明

関数を階層の別エンティティとして削除します。インライン展開された関数は呼び出し関数に分解され、

RTL で別の階層として表示されなくなります。関数をインライン展開すると、関数内の演算が共有され、

周辺の演算と効率よく最適化されるようになることがあります。ただし、インライン展開された関数は共有

できないので、RTL をインプリメントするのに必要なエリアが増加する可能性があります。

INLINE プラグマは、その指定方法によって、定義されているスコープに異なる方法で適用されます。

• INLINE: 引数を指定しない場合、関数は呼び出し関数または領域に上向きにインライン展開され

ます。

• INLINE OFF: プラグマを指定した関数を呼び出し関数または領域にインライン展開しないよう指定

します。これにより、自動的にインライン展開、あるいは領域または再帰の一部としてインライン展開

されるはずであった関数のインライン展開がディスエーブルになります。

• INLINE REGION: プラグマを領域または関数の本体に適用します。領域または関数の内容が下向

きにインライン展開されますが、階層全体に再帰的にインライン展開されることはありません。

• INLINE RECURSIVE: プラグマを領域または関数の本体に適用します。領域または関数の内容が

下向きに再帰的にインライン展開されます。

デフォルトでは、インライン展開は関数階層のすぐ下の階層でのみ実行され、サブ関数では実行されま

せん。recursive オプションを使用すると、階層全体でインライン展開が指定されます。

構文構文

C ソースの関数本体内またはコードの領域内に配置します。

#pragma HLS inline <region | recursive | off>

説明:

• region: 指定した領域内の (または関数の本体に含まれる) すべての関数をインライン展開するよ

う指定し、領域スコープに適用します。

• recursive: デフォルトでは、関数のインライン展開は 1 つの階層レベルでのみ実行され、指定の

関数内の関数はインライン展開されません。recursive オプションを使用すると、指定の関数また

は領域内のすべての関数が再帰的にインライン展開されます。

• off: 関数のインライン展開をオフにし、指定の関数がインライン展開されないようにします。たとえ

ば、関数に recursive オプションが指定されている場合、ほかの関数はインライン展開されても、

特定の呼び出された関数がインライン展開されないようにできます。

ヒント: Vivado HLS では小型の関数が自動的にインライン展開されるので、INLINE プラグマと off オプショ

ンを使用してこの自動インライン展開が実行されないようにすることができます。




84



例 1例 1

次の例では、指定した領域内 (foo_top の本体) のすべての関数をインライン展開しています。この関

数内の下位関数はインライン展開されません。

void foo_top { a, b, c, d} {#pragma HLS inline region...

例 2例 2

次の例では、foo_top の本体内のすべての関数がインライン展開され、この関数に含まれる階層すべ

てで再帰的にインライン展開が実行されます。ただし、関数 foo_sub はインライン展開されません。

recursive プラグマは関数 foo_top に配置されています。関数 foo_sub にはインライン展開をディス

エーブルにするプラグマが配置されています。

foo_sub (p, q) {#pragma HLS inline offint q1 = q + 10;foo(p1,q);// foo_3...}void foo_top { a, b, c, d} {

#pragma HLS inline region recursive...foo(a,b);//foo_1foo(a,c);//foo_2foo_sub(a,d);...

}

注記: この例では、INLINE は関数 foo_top の内容に下向きに適用されますが、foo_sub を呼び出すコードには

上向きに適用されます。

例 3例 3

次の例では、copy_output 関数が copy_output を呼び出す関数または領域にインライン展開されま

す。

void copy_output(int *out, int out_lcl[OSize * OSize], int output) {#pragma HLS INLINE

// Calculate each work_item's result update locationint stride = output * OSize * OSize;

// Work_item updates output filter/image in DDRwriteOut: for(int itr = 0; itr < OSize * OSize; itr++) {#pragma HLS PIPELINE

out[stride + itr] = out_lcl[itr];}




85










86




pragma HLS interfacepragma HLS interface

説明説明

C ベースデザインでは、すべての入力および出力操作がフォーマル関数引数を使用して 0 時間で実

行されます。RTL デザインでは、同じ入力および出力操作をデザインインターフェイスのポートを介して

実行する必要があり、通常は特定の I/O (入力/出力) プロトコルを使用して実行されます。詳細は、

『Vivado Design Suite ユーザーガイド: 高位合成』 (UG902) の「インターフェイスの管理」を参照してく

ださい。

INTERFACE プラグマは、インターフェイス合成で関数定義からどのように RTL ポートが作成されるかを

指定します。

RTL インプリメンテーションのポートは次のものから導出されます。

• 指定されている任意の関数レベルのプロトコル。

• 関数引数。

• 最上位関数によりアクセスされ、スコープ外部で定義されるグローバル変数。

関数レベルのプロトコルは、ブロックレベルの I/O プロトコルとも呼ばれ、関数の演算が開始したときに

制御する信号と、関数の演算が終了したこと、アイドル状態であること、新しい入力を受信できる状態で

あることを通知する信号を提供します。関数レベルのプロトコルのインプリメンテーションは次のようになり

ます。

• <mode> 値により ap_ctrl_none、ap_ctrl_hs、または ap_ctrl_chain のいずれかに指定され

ます。デフォルトは ap_ctrl_hs ブロックレベル I/O プロトコルです。

• 関数名に関連付けられています。

各関数引数は、有効ハンドシェイク (ap_vld) や肯定応答ハンドシェイク ap_ack などの独自のポート

レベル (I/O) インターフェイスプロトコルを持つように指定できます。ポートレベルインターフェイスプ

ロトコルは、最上位関数の各引数および関数の戻り値 (関数が値を返す場合) に対して作成されます。

作成されるデフォルトの I/O プロトコルは、C 引数のタイプによって異なります。ブロックレベルのプロト

コルが使用されてブロックの演算が開始したら、ポートレベルの I/O プロトコルを使用して、データをブ

ロック内外に順に送信できます。

グローバル変数がアクセスされても、すべての読み出しおよび書き込みがデザインのローカルである場

合は、リソースはデザイン内に作成され、RTL に I/O ポートは必要ありません。グローバル変数が外部

ソースまたはデスティネーションである場合は、インターフェイスは標準関数引数と同様の方法で指定し

ます。例を参照してください。

INTERFACE プラグマがサブ関数に使用されている場合は、register オプションのみを使用できます。

サブ関数では、<mode> オプションはサポートされません。

ヒント: サブ関数で使用される I/O プロトコルは Vivado HLS により自動的に決定されます。ポートにレジスタを付

けるかどうかを指定することを除き、これらのポートを制御することはできません。




87

https://japan.xilinx.com/cgi-bin/docs/rdoc?v=2017.2;d=ug902-vivado-high-level-synthesis.pdf;a=xManagingInterfaces



構文構文

関数内に配置します。

#pragma HLS interface <mode> port=<name> bundle=<string> \register register_mode=<mode> depth=<int> offset=<string> \clock=<string> name=<string> \num_read_outstanding=<int> num_write_outstanding=<int> \max_read_burst_length=<int> max_write_burst_length=<int>

説明:

• <mode>: 関数引数、関数で使用されるグローバル変数、またはブロックレベルの制御プロトコルの

インターフェイスプロトコルモードを指定します。これらのモードの詳細な説明は、『Vivado Design

Suite ユーザーガイド: 高位合成』 (UG902) を参照してください。モードは次のいずれかに指定で

きます。

◦ ap_none: プロトコルなし。インターフェイスはデータポートです。

◦ ap_stable: プロトコルなし。インターフェイスはデータポートです。Vivado HLS では、リセット

後はデータポートが常に安定していると想定され、内部最適化により不要なレジスタが削除さ

れます。

◦ ap_vld: データポートと、データが読み出しまたは書き込みに対して有効になったことを示す

valid ポートがインプリメントされます。

◦ ap_ack: データポートと、データが読み出された/書き込まれたことを肯定応答する

acknowledge ポートがインプリメントされます。

◦ ap_hs: データポートと、データが読み出しおよび書き込みに対して有効になったことを示す

valid ポートおよびデータが読み出された/書き込まれたことを肯定応答する acknowledgeポートがインプリメントされます。

◦ ap_ovld: 出力データポートと、データが読み出しまたは書き込みに対して有効になったこと

を示す valid ポートがインプリメントされます。

重要: 入力引数または読み出し/書き込み引数の入力部分は ap_none モードを使用してインプリメント

されます。

◦ ap_fifo: 標準 FIFO インターフェイスのポートが、アクティブ Low FIFO の empty および

full ポートが関連付けられたデータ入力および出力ポートを使用してインプリメントされま

す。

注記: このインターフェイスは、読み出し引数または書き込み引数のみに使用できます。ap_fifo モー

ドでは双方向の読み出し/書き込み引数はサポートされません。

◦ ap_bus: ポインターおよび参照渡しポートがバスインターフェイスとしてインプリメントされま

す。

◦ ap_memory: 配列引数が標準 RAM インターフェイスとしてインプリメントされます。Vivado IP

インテグレーターで RTL デザインを使用する場合は、メモリインターフェイスは個別のポート

ととして表示されます。

◦ bram: 配列引数が標準 RAM インターフェイスとしてインプリメントされます。Vivado IP インテ

グレーターで RTL デザインを使用する場合は、メモリインターフェイスはシングルポートとし

て表示されます。




88




• ◦ axis: すべてのポートが AXI4-Stream インターフェイスとしてインプリメントされます。

◦ s_axilite: すべてのポートが AXI4-Lite インターフェイスとしてインプリメントされます。

Vivado HLS では、RTL のエクスポート中に C ドライバーファイルの関連セットが生成されま

す。

◦ m_axi: すべてのポートが AXI4 インターフェイスとしてインプリメントされます。32 ビット (デフ

ォルト) または 64 ビットのアドレスポートを指定し、アドレスオフセットを制御するには、

config_interface コマンドを使用できます。

◦ ap_ctrl_none: ブロックレベル I/O プロトコルなし。

注記: ap_ctrl_none を使用すると、C/RTL の協調シミュレーション機能を使用してデザインを検証で

きなくなることがあります。

◦ ap_ctrl_hs: デザインの演算を start し、デザインが idle、done、および新しい入力デー

タに対して ready になっていることを示すブロックレベルの制御ポートセットをインプリメント

します。

注記: ap_ctrl_hs モードはデフォルトのブロックレベル I/O プロトコルです。

◦ ap_ctrl_chain: デザインの演算を start および continue し、デザインが idle、done、

および新しい入力データに対して ready になっていることを示すブロックレベルの制御ポー

トセットをインプリメントします。

注記: ap_ctrl_chain インターフェイスモードは ap_ctrl_hs と似ていますが、バックプレッシャーを

適用するために入力信号 ap_continue が追加されている点が異なります。Vivado HLS ブロックをチ

ェーン接続する場合は、ap_ctrl_chain ブロックレベル I/O プロトコルを使用することをお勧めしま

す。

• port=<name>: INTERFACE プラグマを適用する関数引数、関数戻り値、またはグローバル変数の

名前を指定します。

ヒント: 関数の return 値のポートには、ブロックレベル I/O プロトコル (ap_ctrl_none、ap_ctrl_hs、また

は ap_ctrl_chain) を割り当てることができます。

• bundle=<string>: 関数引数を AXI ポートにまとめます。デフォルトでは、Vivado HLS で

AXI4-Lite (s_axilite) インターフェイスとして指定されたすべての関数引数が 1 つの AXI4-Lite

ポートにまとめられます。同様に、AXI4 (m_axi) インターフェイスとして指定されたすべての関数引

数は 1 つの AXI4 ポートにまとめられます。このオプションでは、同じ bundle=<string> が指定さ

れたすべてのインターフェイスポートが 1 つの AXI インターフェイスポートにまとめられ、RTL ポ

ートの名前が <string> になります。




89



• register: 信号および関連プロトコル信号にレジスタを付けるオプションのキーワードで、信号が

少なくとも関数実行の最終サイクルまで保持されます。このオプションは、次のインターフェイスモ

ードに適用されます。

◦ ap_none

◦ ap_ack

◦ ap_vld

◦ ap_ovld

◦ ap_hs

◦ ap_stable

◦ axis

◦ s_axilite

ヒント: config_interface コマンドの -register_io オプションは、最上位関数のすべての入力/出力に

レジスタを付けるかどうかをグローバルに制御します。詳細は、『Vivado Design Suite ユーザーガイド: 高位

合成』 (UG902) を参照してください。

• register_mode= <forward|reverse|both|off>: register キーワードと共に使用し、

forward パス (TDATA および TVALID)、reverse パス (TREADY)、またはその両方 (both) の

パス (TDATA、TVALID、および TREADY) にレジスタを配置するか、どのポート信号にもレジスタ

を配置しないか (off) を指定します。デフォルトは both です。AXI-Stream (axis) サイドチャネル

信号はデータ信号と考慮され、TDATA にレジスタが付けられるとレジスタが付けられます。

• depth=<int>: テストベンチで処理されるサンプルの最大数を指定します。この設定は、Vivado

HLS で RTL 協調シミュレーション用に作成される検証アダプターに必要な FIFO の最大サイズを

示します。

ヒント: depth は通常はオプションですが、m_axi インターフェイスでは必須です。

• offset=<string>: AXI4-Lite (s_axilite) および AXI4 (m_axi) インターフェイスのアドレスオ

フセットを指定します。

◦ s_axilite インターフェイスでは、<string> はレジスタマップのアドレスを指定します。

◦ m_axi インターフェイスでは、<string> は次の値を指定します。

▪ direct: スカラー入力オフセットポートを生成します。

▪ slave: オフセットポートを生成し、AXI4-Lite スレーブインターフェイスに自動的にマッ

プします。

▪ off: オフセットポートは生成しません。

ヒント: config_interface コマンドの -m_axi_offset オプションは、デザインのすべての M_AXI イ

ンターフェイスのオフセットポートをグローバルに制御します。

• clock=<name>: s_axilite インターフェイスモードのみでオプションで指定します。インターフェ

イスで使用するクロック信号を定義します。デフォルトでは、AXI4-Lite インターフェイスクロックは

システムクロックと同じです。このオプションを使用すると、AXI4-Lite インターフェイス

(s_axilite) に別のクロックを指定できます。

ヒント: bundle オプションを使用して複数の最上位関数引数を 1 つの AXI4-Lite インターフェイスにまとめ

ている場合は、clock オプションはバンドルメンバーの 1 つにのみ指定します。




90




• num_read_outstanding=<int>: AXI4 (m_axi) インターフェイスで、デザインが停止するまでに、

AXI4 バスに対して応答なしで読み込み要求を送信できる回数を指定します。これにより、デザイン

の内部ストレージである FIFO のサイズ

(num_read_outstanding*max_read_burst_length*word_size) が決まります。

• num_write_outstanding=<int>: AXI4 (m_axi) インターフェイスで、デザインが停止するまで

に、AXI4 バスに対して応答なしで書き込み要求を送信できる回数を指定します。これにより、デザ

インの内部ストレージである FIFO のサイズ

(num_write_outstanding*max_write_burst_length*word_size) が決まります。

• max_read_burst_length=<int>: AXI4 (m_axi) インターフェイスでのバースト転送で読み出さ

れるデータの最大数を指定します。

• max_write_burst_length=<int>: AXI4 (m_axi) インターフェイスでのバースト転送で書き込ま

れるデータの最大数を指定します。

• name=<string>: ポートの名前を変更します。生成された RTL ポートでこの名前が使用されます。

例 1例 1

次の例では、両方の関数引数が AXI4-Stream インターフェイスを使用してインプリメントされます。

void example(int A[50], int B[50]) {//Set the HLS native interface types#pragma HLS INTERFACE axis port=A#pragma HLS INTERFACE axis port=Bint i;for(i = 0; i < 50; i++){

B[i] = A[i] + 5;}

}

例 2例 2

次の例では、ブロックレベル I/O プロトコルをオフにし、関数戻り値に割り当てています。

#pragma HLS interface ap_ctrl_none port=return

関数引数 InData は ap_vld インターフェイスを使用し、入力にレジスタが付けられます。

#pragma HLS interface ap_vld register port=InData

これにより、グローバル変数 lookup_table が RTL デザインでポートとして処理され、インターフェイス

は ap_memory に指定されます。

pragma HLS interface ap_memory port=lookup_table




91



例 3例 3

次の例では、最上位 transpose 関数のポートに INTERFACE 規格を定義しています。bundle= オプ

ションを使用して信号をグループ化しています。

// TOP LEVEL - TRANSPOSEvoid transpose(int* input, int* output) {

#pragma HLS INTERFACE m_axi port=input offset=slave bundle=gmem0#pragma HLS INTERFACE m_axi port=output offset=slave bundle=gmem1

#pragma HLS INTERFACE s_axilite port=input bundle=control#pragma HLS INTERFACE s_axilite port=output bundle=control#pragma HLS INTERFACE s_axilite port=return bundle=control



• pragma HLS protocol





92




pragma HLS latencypragma HLS latency

説明説明

関数、ループ、および領域の完了するまでの最小レイテンシまたは最大レイテンシ、あるいはその両方

を指定します。レイテンシは、出力を生成するのに必要なクロックサイクル数として定義されます。関数

レイテンシは、関数がすべての出力値を計算して戻るまでに必要なクロックサイクル数です。ループレ

イテンシは、ループのすべての反復を実行するのにかかるサイクル数です。『Vivado Design Suite ユー

ザーガイド: 高位合成』 (UG902) の「パフォーマンスメトリクスの例」を参照してください。

Vivado HLS では常に、デザインのレイテンシを最短にするよう試みられます。LATENCY プラグマを指

定すると、ツールで次のように処理されます。

• レイテンシが最小値より大きく、最大値未満: 制約は満たされています。これ以上の最適化は実行

されません。

• レイテンシが最小値未満: レイテンシが指定値まで拡張されます。リソースがさらに共有される可能

性があります。

• レイテンシが最大値を超える: 指定された制約を満たすことができるようエフォートレベルが上げら

れます。それでも最大レイテンシを満たすことができない場合は、警告が表示され、達成可能な最

短のレイテンシでデザインが作成されます。

ヒント: LATENCY プラグマを使用すると、ツールで最良のソリューションを探すエフォートを制限することもできま

す。コード内のループ、関数、または領域にレイテンシ制約を指定すると、そのスコープ内で可能なソリューション

が削減され、ツールの実行時間が短縮されます。詳細は、『Vivado Design Suite ユーザーガイド: 高位合成』

(UG902) の「ランタイムおよび容量の改善」を参照してください。

構文構文

レイテンシを制御する関数、ループ、または領域内に配置します。

#pragma HLS latency min=<int> max=<int>

説明:

• min=<int>: 関数、ループ、またはコードの領域の最小レイテンシを指定します (オプション)。

• max=<int>: 関数、ループ、またはコードの領域の最大レイテンシを指定します (オプション)。

注記: min および max はオプションですが、いずれかを指定する必要があります。




93





例 1例 1

次の例では、関数 foo の最小レイテンシを 4、最大レイテンシを 8 に指定しています。

int foo(char x, char a, char b, char c) {#pragma HLS latency min=4 max=8char y;y = x*a+b+c;return y

}

例 2例 2

次の例では、loop_1 の最大レイテンシを 12 に指定しています。プラグマはループ本体内に記述しま

す。

void foo (num_samples, ...) {int i;...loop_1: for(i=0;i< num_samples;i++) {#pragma HLS latency max=12

...result = a + b;

}}

例 3例 3

次の例では、コード領域を作成し、同じクロックサイクルで変化する必要のある信号を 0 レイテンシを指

定してグループ化しています。

// create a region { } with a latency = 0{

#pragma HLS LATENCY max=0 min=0*data = 0xFF;*data_vld = 1;

}






94




pragma HLS loop_flattenpragma HLS loop_flatten

説明説明

入れ子のループを 1 つのループ階層にフラット化し、レイテンシを改善します。

RTL インプリメンテーションでは、外側のループから内側のループに、内側のループから外側のループ

に移動するのに 1 クロックサイクルかかります。入れ子のループをフラットにすると、それらを 1 つのル

ープとして最適化できるので、クロックサイクル数を削減でき、ループ本文のロジックをさらに最適化す

ることが可能です。

ループ階層内の一番内側にあるループの本体に LOOP_FLATTEN プラグマを適用します。完全または

半完全ループのみをこの方法でフラットにできます。

• 完全ループの入れ子:

◦ 最内ループのみにループ本体の内容が含まれます。

◦ ループ文の間に指定されるロジックはありません。

◦ すべてのループ範囲は定数です。

• 半完全ループの入れ子:

◦ 最内ループのみにループ本体の内容が含まれます。

◦ ループ文の間に指定されるロジックはありません。

◦ 最外ループの範囲は変数にできます。

• 不完全ループの入れ子: 内側のループの範囲が変数であったり、ループ本体が内側のループに

のみ含まれているとは限らない場合、コードの構造を変更するか、ループ本体内のループを展開し

て、完全ループの入れ子を作成してみてください。

構文構文

C ソースの入れ子のループ内に配置します。

#pragma HLS loop_flatten off

説明:

• off: オプションのキーワードで、フラットされないようにします。指定ロケーション内の一部のループ

はフラットにせず、それ以外のループをフラットにできます。

注記: LOOP_FLATTEN プラグマを使用すると、最適化がイネーブルになります。

例 1例 1

関数 foo 内の loop_1 と、ループ階層でこれより上にあるすべてのループ (完全または半完全) を 1

つのループにフラット化します。プラグマを loop_1 の本体に記述します。




95



void foo (num_samples, ...) {int i;...loop_1: for(i=0;i< num_samples;i++) {#pragma HLS loop_flatten...result = a + b;

}}

例 2例 2

loop_1 でループがフラット化されないようにします。

loop_1: for(i=0;i< num_samples;i++) {#pragma HLS loop_flatten off...




• pragma HLS unroll





96




pragma HLS loop_mergepragma HLS loop_merge

説明説明

連続するループを 1 つのループに結合して、全体的なレイテンシを削減し、共有を増やして最適化を

向上します。ループを結合すると、次が可能になります。

• RTL でループ本文のインプリメンテーション間の移行に必要なクロックサイクル数を削減できま

す。

• ループを並列にインプリメントできます (可能な場合)。

LOOP_MERGE プラグマでは、適用されたスコープ内のループすべてを結合するよう試みられます。たと

えば、LOOP_MERGE プラグマをループの本体に適用した場合、Vivado HLS ではプラグマがそのループ

自体ではなく、ループ内の下位ループに適用されます。

ループ結合の規則は、次のとおりです。

• ループの境界が変数の場合、同じ値 (反復回数) である必要があります。

• ループの境界が定数の場合、最大定数値が結合されたループの境界として使用されます。

• 境界が変数のループと定数のループを結合することはできません。

• 結合するループ間のコードが、結合により悪影響を受けないようにします。コードを複数回実行して

も常に同じ結果になるようにする必要があります。たとえば、a=b は許容されますが a=a+1 は許容さ

れません。

• ループに FIFO 読み出しが含まれる場合は、ループは結合できません。結合により読み出しの順

序が変更されてしまうためです。FIFO または FIFO インターフェイスからの読み出しは、常に順序

どおりに実行される必要があります。

構文構文

C ソースの必要なスコープまたは領域内に配置します。

#pragma HLS loop_merge force

説明:

• force: Vivado HLS で警告が出力されてもループが結合されるようにするオプションのキーワード

です。

重要: この場合、結合したループが問題なく動作するかどうかをユーザーが確認する必要があります。

例例

次の例では、関数 foo の連続するすべてのループを 1 つのループに結合しています。




97



void foo (num_samples, ...) {#pragma HLS loop_mergeint i;...loop_1: for(i=0;i< num_samples;i++) {...

次の例では、loop_2 内の loop_2 を除くすべてのループを force オプションを使用して結合してい

ます。プラグマを loop_2 の本体に記述します。

loop_2: for(i=0;i< num_samples;i++) {#pragma HLS loop_merge force...


• pragma HLS loop_flatten


• pragma HLS unroll





98




pragma HLS loop_tripcountpragma HLS loop_tripcount

説明説明

TRIPCOUNT プラグマをループに適用すると、ループで実行される反復回数の合計を手動で指定できま

す。

重要: TRIPCOUNT プラグマは解析専用で、合成結果には影響しません。

Vivado HLS により、各ループの合計レイテンシ、つまりループのすべての反復を実行するためのクロッ

クサイクル数がレポートされます。ループレイテンシは、ループ反復数 (トリップカウント) に依存します。

トリップカウントは、定数値であることもあり、ループ式 (x<y など) で使用される変数の値やループ内の

制御文によって異なる場合もあります。Vivado HLS でトリップカウントを決定できないこともあり、その場

合はレイテンシは不明になります。これは、トリップカウントの決定に使用される変数が次のいずれかの

場合です。

• 入力引数。

• ダイナミック演算により算出される変数。

ループのレイテンシが不明または算出できない場合、TRIPCOUNT プラグマを使用してループの反復回

数の最小値および最大値を指定できます。これにより、ループのレイテンシがデザインの総レイテンシの

どの程度を占めているのかがツールで解析されてレポートされるので、デザインに適切な最適化を判断

するのに役立ちます。

構文構文

C ソースのループ本体内に配置します。

#pragma HLS loop_tripcount min=<int> max=<int> avg=<int>

説明:

• max=<int>: ループの反復回数の最大値を指定します。

• min=<int>: ループの反復回数の最小値を指定します。

• avg=<int>: ループの反復回数の平均値を指定します。

例例

次の例では、関数 foo の loop_1 の最小トリップカウントを 12、最大トリップカウントを 16 に指定してい

ます。

void foo (num_samples, ...) {




99



int i;...loop_1: for(i=0;i< num_samples;i++) {#pragma HLS loop_tripcount min=12 max=16...result = a + b;

}}






100




pragma HLS occurrencepragma HLS occurrence

説明説明

関数またはループをパイプライン処理するとき、OCCURRENCE プラグマを使用して、ある領域のコードが

それを含む関数またはループのコードよりも低頻度で実行されるように指定します。これにより、実行速

度が遅いコード部分が低頻度でパイプライン処理されるようにでき、最上位パイプライン内で共有できる

可能性があります。OCCURRENCE (実行頻度) は次を基に判断します。

• ループは N 回反復する。

• ループ本体の一部が条件文で有効になっており、M 回しか実行されない (N は M の整数倍)。

• 条件コードの実行頻度は、ループ本体の残りの部分の N/M 倍。

たとえば、10 回実行されるループで、ループ内の条件文が 2 回だけ実行される場合、実行頻度は 5

(10/2) となります。

領域に OCCURRENCE プラグマを使用すると、その領域内の関数およびループがそれを含む関数または

ループよりも遅い開始間隔 (II) でパイプライン処理されます。

構文構文

C ソースのコードの領域内に配置します。

#pragma HLS occurrence cycle=<int>

説明:

• cycle=<int>: N/M の実行頻度を指定します。

◦ N は領域を含む関数/ループの実行回数です。

◦ M は条件領域の実行回数です。

重要: N は M の整数倍数である必要があります。

例例

次の例では、領域 Cond_Region の実行頻度を 4 に指定しています。この領域は、それを含むコード

の 1/4 の速度で実行されます。

Cond_Region: {#pragma HLS occurrence cycle=4...}




101









102




pragma HLS pipelinepragma HLS pipeline

説明説明

PIPELINE プラグマは、演算を同時実行できるようにすることにより関数またはループの開始間隔 (II) を

短縮します。

パイプライン処理された関数またはループは、N クロックサイクル (N は関数またはループの開始間隔)

ごとに新しい入力を処理できます。PIPELINE プラグマのデフォルトの開始間隔は 1 で、クロックサイク

ルごとに 1 つの入力を処理します。開始間隔は、プラグマの II オプションを使用して指定できます。

ループをパイプライン処理すると、次の図に示すように、ループ内の演算が同時実行されるようインプリ

メントできます。この図の (A) はデフォルトの順次演算を示しています。各入力は 3 クロックサイクルごと

に処理され (II=3)、最後の出力が書き出されるまでに 8 クロックサイクルかかっています。

図 3: ループのパイプライン

void func(m,n,o) { for (i=2;i>=0;i--) { op_Read; op_Compute; op_Write;

}}

4 cycles

RDRD

3 cycles

8 cycles

1 cycleRDRD CMPCMP WRWR

RDRD CMPCMP WRWR

RDRD CMPCMP WRWR

(A) Without Loop Pipelining (B) With Loop PipeliningX14277

CMPCMP WRWR RDRD CMPCMP WRWR RDRD CMPCMP WRWR

重要: ループのパイプラインは、ループ運搬依存を使用することにより回避できます。DEPENDENCE プラグマを使

用して、ループ運搬依存を克服し、ループをパイプライン処理できるようにする (またはより短い間隔でパイプライ

ンできるようにする) ための追加情報を提供します。

Vivado HLS で指定した開始間隔でデザインを作成できない場合は、次が実行されます。

• 警告メッセージが表示されます。

• 達成可能な最短の開始間隔でデザインが作成されます。

警告メッセージを参考にデザインを解析し、必要な開始間隔を満たしてデザインを作成するためにどの

手順が必要なのかを判断します。




103



構文構文

C ソースの関数の本体またはループ内に配置します。

#pragma HLS pipeline II=<int> enable_flush rewind

説明:

• II=<int>: パイプラインの開始間隔を指定します。Vivado HLS では、この指定を満たすことが試み

られます。データの依存性によって、実際の開始間隔はこの指定より大きくなることがあります。デ

フォルトは 1 です。

• enable_flush: オプションのキーワードで、パイプラインの入力で有効であったデータが非アクテ

ィブになった場合にデータをフラッシュして空にするパイプラインをインプリメントします。

ヒント: この機能は、パイプライン処理された関数でのみサポートされ、パイプライン処理されたループではサ

ポートされません。

• rewind: オプションのキーワードで、1 つのループ反復の終了と次の反復の開始の間に一時停止

のない連続ループパイプライン処理 (巻き戻し) をイネーブルにします。巻き戻しは、最上位関数

内に 1 つのループしかない (完全なループネスト) 場合にのみ効果的です。ループ前のコード部

分は、次のようになります。

◦ 初期化と認識されます。

◦ パイプラインで一度だけ実行されます。

◦ 条件演算 (if-else) を含むことはできません。

ヒント: この機能は、パイプライン処理されたループでのみサポートされ、パイプライン処理された関数ではサ

ポートされません。

例 1例 1

この例では、関数 foo が開始間隔 1 でパイプライン処理されます。

void foo { a, b, c, d} {#pragma HLS pipeline II=1...

}

注記: II のデフォルト値は 1 なので、II=1 を指定する必要はありません。




• xcl_pipeline_loop





104





pragma HLS protocolpragma HLS protocol

説明説明

PROTOCOL プラグマは、コードの領域をプロトコル領域として指定します。この領域には、コードで明確に

指定していない限り、Vivado HLS によりクロック動作は挿入されません。プロトコル領域は、最終的なデ

ザインを特定の I/O プロトコルを使用するハードウェアブロックに接続できるようにするため、インターフ

ェイスプロトコルを手動で指定するために使用できます。

注記: 詳細は、『Vivado Design Suite ユーザーガイド: 高位合成』 (UG902) の「インターフェイスの手動指定」を参

照してください。

Vivado HLS では、関数引数からの読み出しおよび関数引数への書き込みも含め、操作の間にクロック

は挿入されません。このため、読み出しおよび書き込みの順序は RTL で保持されます。

クロック動作は、次のように指定できます。

• C の場合: ap_wait() 文 (ap_utils.h を含む) を使用します。

• C++ および SystemC の場合: wait() 文 (systemc.h を含む) を使用します。

ap_wait および wait 文は、C および C++ デザインのシミュレーションには影響せず、Vivado HLS で

のみ解釈されます。

C コードの領域を作成するには、次の手順に従います。

1. 領域を波かっこ ({ }) で囲みます。

2. オプションで識別子を指定します。

次の例では、io_section という領域を定義しています。

io_section:{...}

構文構文

プロトコルを定義する領域内に配置します。

#pragma HLS protocol <floating | fixed>

説明:

• floating: プロトコル領域外の文を最終的な RTL のプロトコル領域内の文と重複できるようにしま

す。プロトコル領域内のコードはサイクル精度ですが、その他の操作は同時に実行できます。これ

がデフォルトのプロトコルモードです。

• fixed: プロトコル領域内の文とプロトコル領域外の文が重複しないようにします。

重要: プロトコルモードを使用しない場合は、floating に設定されます。




105




例 1例 1

この例では、領域 io_section を fixed プロトコル領域として定義しています。プラグマは領域内に配

置します。

io_section:{#pragma HLS protocol fixed...

}





• xcl_array_partition





106





pragma HLS resetpragma HLS reset

説明説明

特定のステート変数 (グローバルまたはスタティック) のリセットを追加または削除します。

リセットポートは、リセット信号が適用されたときにリセットポートに接続されているレジスタおよびブロッ

ク RAM を初期値に戻すために FPGA で使用されます。RTL リセットポートの存在と動作は、

config_rtl コンフィギュレーションファイルで制御されます。リセット設定ではリセットの極性および同

期か非同期かを設定できますが、重要なのは、[reset] オプションを使用してリセット信号を適用したとき

にリセットするレジスタを指定できるということです。詳細は、『Vivado Design Suite ユーザーガイド: 高

位合成』 (UG902) の「クロック、リセット、および RTL 出力」を参照してください。

RESET プラグマを使用すると、リセットを詳細に制御できます。変数がスタティックまたはグローバルの場

合、RESET プラグマを使用してリセットを明示的に追加したり、off に設定して変数からリセットを削除し

たりできます。これはスタティック配列またはグローバル配列がデザインに含まれる場合に特に便利なこ

とがあります。

構文構文

C ソースコードの変数のライフサイクルの境界内に配置します。

#pragma HLS reset variable=<a> off

説明:

• variable=<a>: プラグマを適用する変数を指定します。

• off: 指定した変数にリセットを生成しないようにします。

例 1例 1

次の例では、グローバルリセット設定が none または control の場合でも、関数 foo の変数 a にリセ

ットが追加されます。

void foo(int in[3], char a, char b, char c, int out[3]) {#pragma HLS reset variable=a

例 2例 2

次の例では、グローバルリセット設定が state または all の場合でも、関数 foo の変数 a からリセッ

トが削除されます。




107




void foo(int in[3], char a, char b, char c, int out[3]) {#pragma HLS reset variable=a off






108




pragma HLS resourcepragma HLS resource

説明説明

変数 (配列、算術演算、関数引数) を RTL にインプリメントするのに使用するライブラリリソース (コア)

を指定します。RESOURCE プラグマを指定しない場合、Vivado HLS により使用するリソースが自動的

に判断されます。

Vivado HLS では、ハードウェアコアを使用して演算がインプリメントされます。演算をインプリメントでき

るコアがライブラリに複数ある場合、RESOURCE プラグマを使用して使用するコアを指定できます。使用

可能なコアのリストを生成するには、list_core コマンドを使用します。

ヒント: list_core コマンドを使用すると、ライブラリで使用可能なコアの詳細を表示できます。list_core は

Vivado HLS の Tcl コマンドインターフェイスでのみ使用でき、set_part コマンドを使用してザイリンクスデバイ

スを指定する必要があります。デバイスを指定しない場合、list_core コマンドは実行されません。

たとえば、配列をインプリメントするのに使用するライブラリのメモリエレメントを RESOURCE プラグマを使

用して指定し、配列をシングルポート RAM とデュアルポート RAM のどちらとしてインプリメントするか

を制御できます。配列に関連付けられているメモリタイプによって RTL で必要なポートが決まるので、こ

れは最上位関数インターフェイスの配列には重要な方法です。

latency= オプションを使用すると、コアのレイテンシを指定できます。インターフェイスのブロック RAM

の場合、latency= オプションを指定すると、たとえばレイテンシ 2 または 3 の SRAM をサポートするな

ど、インターフェイスにオフチップの標準でない SRAM を記述できます。詳細は、『Vivado Design Suite

ユーザーガイド: 高位合成』 (UG902) の「インターフェイスの配列」を参照してください。内部演算の場

合、latency= オプションを使用すると、演算をより多くのパイプライン段を使用してインプリメントできま

す。これらの追加のパイプライン段により、RTL 合成中にタイミング問題を解決しやすくなります。

重要: latency= オプションを使用するには、使用可能な複数段のコアを演算に含める必要があります。Vivado

HLS には、基本的な算術演算 (加算、減算、乗算、除算)、すべての浮動小数点演算、およびすべてのブロック

RAM 用に複数段コアが含まれています。

より良い結果を得るため、C の場合は -std=c99 を、C および C++ の場合は -fno-builtin を使用

することをお勧めします。-std=c99 などの C コンパイルオプションを指定するには、Tcl コマンドの

add_files に -cflags オプションを使用します。または、[Project Settings] ダイアログボックスの

[Edit CFLAGs] ボタンを使用します。詳細は、『Vivado Design Suite ユーザーガイド: 高位合成』

(UG902) の「新規合成プロジェクトの作成」を参照してください。

構文構文

C ソースの配列変数が定義されている関数の本体内に配置します。

#pragma HLS resource variable=<variable> core=<core>\latency=<int>




109





説明:

• variable=<variable> (必須): RESOURCE プラグマを設定する配列、算術演算、または関数引数

を指定します。

• core=<core> (必須): テクノロジライブラリで定義されているようにコアの名前を指定します。

• latency=<int>: コアのレイテンシを指定します。

例 1例 1

次の例では、関数 foo の変数 c の乗算をインプリメントするのに 2 段のパイプライン乗算器を指定して

います。変数 d に使用するコアは、Vivado HLS により決定されます。

int foo (int a, int b) {int c, d;#pragma HLS RESOURCE variable=c latency=2c = a*b;d = a*c;return d;}

例 2例 2

次の例では、最上位関数の foo_top に対する引数である変数 coeffs[128] が、ライブラリの

RAM_1P コアを使用してインプリメントされるように指定しています。

#pragma HLS resource variable=coeffs core=RAM_1P

ヒント: coeffs の値にアクセスするために RTL で作成されるポートは、RAM_1P コアで定義されます。






110




pragma HLS streampragma HLS stream

説明説明

デフォルトでは、配列変数は RAM としてインプリメントされます。

• 最上位関数の配列パラメーターは、RAM インターフェイスのポートとしてインプリメントされます。

• 一般配列は、読み出しおよび書き込みアクセス用に RAM としてインプリメントされます。

• DATAFLOW 最適化に関連するサブ関数では、配列引数は RAM のピンポンバッファーチャネ

ルを使用してインプリメントされます。

• ループベースの DATAFLOW 最適化に関連する配列は、RAM のピンポンバッファーチャネル

を使用してインプリメントされます。

配列に格納されているデータが順次に消費または生成される場合は、STREAM プラグマを指定して

RAM ではなく FIFO を使用し、ストリーミングデータを使用する方が効率的です。

重要: 最上位関数の引数の INTERFACE タイプが ap_fifo に指定されている場合は、配列は自動的にストリーミ

ングとしてインプリメントされます。

構文構文


#pragma HLS stream variable=<variable> depth=<int> dim=<int> off

説明:

• variable=<variable>: ストリーミングインターフェイスとしてインプリメントする配列の名前を指定

します。

• depth=<int>: DATAFLOW チャネルの配列ストリーミングにのみ適用されます。RTL にインプリメ

ントされる FIFO の深さは、デフォルトでは C コードで指定した配列と同じサイズになります。このオ

プションを使用すると、FIFO に異なる深さを指定できます。

配列が DATAFLOW 領域にインプリメントされる場合は、depth= オプションで FIFO のサイズを削

減する方法がよく使用されます。たとえば、DATAFLOW 領域ですべてのループおよび関数がデ

ータを II=2 のレートで処理する場合、データはクロックサイクルごとに生成および消費されるので、

大型 FIFO は必要ありません。この場合、depth= オプションを使用して FIFO サイズを 1 に削減

すると、RTL デザインのエリアを大幅に削減できます。

ヒント: config_dataflow -depth コマンドを使用すると、DATAFLOW 領域のすべての配列をストリーミン

グできます。depth= オプションを指定すると、その variable に対して config_dataflow コマンドを無効

にできます。

• dim=<int>: ストリーミングする配列の次元を指定します。デフォルトは次元 1 です。N 次元の配列

の場合、0 ～ N の整数を指定します。




111



• off: ストリーミングデータをディスエーブルにします。DATAFLOW チャネルの配列ストリーミング

にのみ適用されます。

ヒント: config_dataflow -default_channel fifo コマンドを使用すると、STREAM をデザインのすべて

の配列に適用するのと同じになります。off オプションを指定すると、その variable に対して

config_dataflow コマンドを無効し、RAM ピンポンバッファーベースのチャネルを使用したデフォルトで

インプリメントできます。

例 1例 1

次の例では、配列 A[10] をストリーミングにし、FIFO としてインプリメントするよう指定しています。

#pragma HLS STREAM variable=A

例 2例 2

次の例では、配列 B が深さ 12 の FIFO でストリーミングされるように設定しています。

#pragma HLS STREAM variable=B depth=12

例 3例 3

次の例では、配列 C のストリーミングをディスエーブルにしています。ストリーミングは

config_dataflow によりイネーブルになっていると想定しています。

#pragma HLS STREAM variable=C off






112




pragma HLS toppragma HLS top

説明説明

関数に名前を付けます。この名前を set_top コマンドで使用し、名前を付けた関数および指定した最

上位から呼び出される関数を合成できます。これは通常 C/C++ のクラスのメンバー関数を合成するた

めに使用されます。

このプラグマはアクティブソリューションで指定し、その新しい名前を set_top コマンドで使用します。

構文構文


#pragma HLS top name=<string>

説明:

• name=<string>: set_top コマンドで使用する名前を指定します。

例例

次の例では、関数 foo_long_name を最上位関数に指定し、名前を DESIGN_TOP に変更しています。

コードにプラグマを含めた後、Tcl コマンドラインから、または GUI プロジェクト設定で指定した最上位

で set_top コマンドを実行する必要があります。

void foo_long_name () {#pragma HLS top name=DESIGN_TOP...

}

set_top DESIGN_TOP






113




pragma HLS unrollpragma HLS unroll

説明説明

ループを展開し、複数の演算を 1 つにまとめたものではなく、複数の個別の演算を作成します。

UNROLL プラグマを使用すると、RTL デザインにループ本体のコピーを複数作成することにより、一部ま

たはすべてのループ反復を並列実行できるようになります。

C/C++ 関数のループは、デフォルトでは展開されません。ループが展開されていない場合、合成では

そのループの 1 反復に対してロジックが作成され、RTL デザインでこのロジックがループの反復ごとに

順に実行されます。ループは、ループ帰納変数で指定されている反復回数実行されます。反復の回数

は、break 条件やループ exit 変数の変更など、ループ本体内のロジックにも影響されます。UNROLL プ

ラグマを使用すると、データのアクセスおよびスループットを向上するためにループを展開できます。

UNROLL プラグマでは、ループを完全にまたは部分的に展開できます。ループを完全に展開すると、

RTL に各ループ反復対してループ本体のコピーが作成され、ループ全体を同時に実行できるようにな

ります。ループの部分展開では、係数 N を指定してループのコピーを N 個作成し、ループ反復数を削

減します。ループを完全に展開するには、ループの境界がコンパイル時に認識される必要があります。

これは部分展開には必要ありません。

ループを部分展開する場合、N は最大反復回数の整数因数である必要はありません。Vivado HLS で

は、部分展開されたループが元のループと同じように動作することを確認する終了チェックが追加されま

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

for(int i = 0; i < X; i++) {pragma HLS unroll factor=2a[i] = b[i] + c[i];

}

ループを係数 2 で展開すると、コードが次のように変換されます。このコードでは、break コンストラクト

により機能が同じになり、ループが適切なポイントで終了します。

for(int i = 0; i < X; i += 2) {a[i] = b[i] + c[i];if (i+1 >= X) break;a[i+1] = b[i+1] + c[i+1];

}

最大反復回数 X は変数であり、Vivado HLS でその値を判断できないので、部分展開されるループに

終了チェックと制御ロジックが追加されます。ただし、展開係数 (この例では 2) が最大反復回数 X の整

数因数であるとわかっている場合は、skip_exit_check オプションを使用して終了チェックとその関連

ロジックを削除できます。これによりエリアが最小限に抑えられ、制御ロジックが単純になります。




114



ヒント: DATA_PACK、ARRAY_PARTITION、ARRAY_RESHAPE などのプラグマの使用により 1 クロックサイクルで

より多くのデータにアクセスできるようになっている場合、このデータを消費するループを展開することによりスルー

プットが向上するのであれば、Vivado HLS でこれらのループが自動的に展開されます。ループを完全または部分

展開すると、1 クロックサイクルでこれらの追加データを消費するのに十分なハードウェアを作成できます。この機

能は、config_unroll コマンドを使用して制御します。詳細は、『Vivado Design Suite ユーザーガイド: 高位合

成』 (UG902) の config_unroll を参照してください。

構文構文

C/C++ ソースの展開するループの本体内に配置します。

#pragma HLS unroll factor=<N> region skip_exit_check

説明:

• factor=<N>: 0 以外の整数値を指定して、部分展開が実行されるよう指定します。ループの本体

が指定した回数繰り返され、反復情報がそれに合わせて調整されます。factor= を指定しない場

合、ループは完全に展開されます。

• region: オプションのキーワードで、指定したループ自体は展開せずに、そのループの本体 (領

域) 内に含まれるすべてのループを展開します。

• skip_exit_check: factor= を使用して部分展開を指定している場合にのみ適用されるオプショ

ンのキーワードです。ループの反復回数が既知であるかどうかによって、終了チェックが削除されま

す。

◦ 固定 (既知の) 範囲: 反復回数が係数の倍数である場合、終了条件チェックは実行されませ

ん。反復回数が係数の整数倍でない場合は、次のようになります。

1. 展開は実行されません。

2. 処理を続行するには終了チェックを実行する必要があることを示す警告メッセージが表

示されます。

◦ 変数 (不明の) 範囲: 指定したとおりに終了条件チェックが削除されます。次を確認してくださ

い。

1. 可変境界が指定した展開係数の整数倍数である。

2. 終了チェックが不要である。

例 1例 1

次の例では、関数 foo 内の loop_1 を完全に展開しています。プラグマを loop_1 の本体に記述しま

す。

loop_1: for(int i = 0; i < N; i++) {#pragma HLS unrolla[i] = b[i] + c[i];

}




115




例 2例 2

次の例では、関数 foo の loop_2 を係数 4 で部分展開し、終了チェックを削除しています。

void foo (...) {int8 array1[M];int12 array2[N];...loop_2: for(i=0;i<M;i++) {

#pragma HLS unroll skip_exit_check factor=4array1[i] = ...;array2[i] = ...;...

}...

}

例 3例 3

次の例では、関数 foo の loop_1 内に含まれるすべてのループを完全に展開しますが、region キー

ワードを使用して loop_1 自体は展開しないようにしています。

void foo(int data_in[N], int scale, int data_out1[N], int data_out2[N]) {int temp1[N];loop_1: for(int i = 0; i < N; i++) {

#pragma HLS unroll regiontemp1[i] = data_in[i] * scale;

loop_2: for(int j = 0; j < N; j++) {data_out1[j] = temp1[j] * 123;

}loop_3: for(int k = 0; k < N; k++) {

data_out2[k] = temp1[k] * 456;}

}}


• pragma HLS loop_flatten




• opencl_unroll_hint





116





その他のリソースおよび法的通知その他のリソースおよび法的通知

ザイリンクスリソースザイリンクスリソース

アンサー、資料、ダウンロード、フォーラムなどのサポートリソースは、ザイリンクスサポートサイトを参照

してください。

ソリューションセンターソリューションセンター

デバイス、ツール、IP のサポートについては、ザイリンクスソリューションセンターを参照してください。

デザインアシスタント、デザインアドバイザリ、トラブルシューティングのヒントなどが含まれます。

参考資料参考資料

このガイドの補足情報は、次の資料を参照してください。

日本語版のバージョンは、英語版より古い場合があります。

1. 『SDx 環境リリースノート、インストールおよびライセンスガイド』 (UG1238)

2. 『SDAccel 環境ユーザーガイド』 (UG1023)

3. 『SDAccel 環境最適化ガイド』 (UG1207)

4. 『SDAccel 環境チュートリアル: 入門』 (UG1021)

5. 『SDSoC 環境プラットフォーム開発ガイド』 (UG1164)

6. SDAccel 開発環境ウェブページ

7. 『SDSoC 環境ユーザーガイド』 (UG1027)

8. 『SDSoC 環境最適化ガイド』 (UG1235)

9. 『SDSoC 環境チュートリアル: 入門』 (UG1028)

10. 『SDSoC 環境プラットフォーム開発ガイド』 (UG1146)

11. SDSoC 開発環境ウェブページ

12. 『UltraFast エンベデッドデザイン設計手法ガイド』 (UG1046: 英語版、日本語版)

13. 『ZC702 評価ボード (Zynq-7000 XC7Z020 All Programmable SoC 用) ユーザーガイド』 (UG850)

14. 『Vivado Design Suite ユーザーガイド: 高位合成』 (UG902)

15. 『PetaLinux ツール資料: ワークフローチュートリアル』 (UG1156)

16. Vivado® Design Suite の資料

17. 『Vivado Design Suite ユーザーガイド: カスタム IP の作成とパッケージ』 (UG1118)

付録 A



117

https://japan.xilinx.com/support.html

https://japan.xilinx.com/support/solcenters.htm

https://japan.xilinx.com/cgi-bin/docs/rdoc?v=2017.2;d=ug1238-sdx-rnil.pdf

https://japan.xilinx.com/cgi-bin/docs/rdoc?v=2017.2;d=ug1023-sdaccel-user-guide.pdf


https://japan.xilinx.com/cgi-bin/docs/rdoc?v=2017.2;d=ug1021-sdaccel-intro-tutorial.pdf

https://japan.xilinx.com/cgi-bin/docs/rdoc?v=2017.2;d=ug1164-sdaccel-platform-development.pdf

https://japan.xilinx.com/products/design-tools/software-zone/sdaccel.html



https://japan.xilinx.com/cgi-bin/docs/rdoc?v=2017.2;d=ug1028-sdsoc-intro-tutorial.pdf

https://japan.xilinx.com/cgi-bin/docs/rdoc?v=2017.2;d=ug1146-sdsoc-platform-development.pdf

https://japan.xilinx.com/products/design-tools/software-zone/sdsoc.html

https://japan.xilinx.com/cgi-bin/docs/rdoc?d=ug1046-ultrafast-design-methodology-guide.pdf

https://japan.xilinx.com/cgi-bin/docs/rdoc?d=j_ug1046-ultrafast-design-methodology-guide.pdf

https://japan.xilinx.com/support/documentation/boards_and_kits/zc702_zvik/ug850-zc702-eval-bd.pdf


https://japan.xilinx.com/cgi-bin/docs/rdoc?v=2017.2;d=ug1156-petalinux-tools-workflow-tutorial.pdf

https://japan.xilinx.com/cgi-bin/docs/rdoc?t=vivado+docs

https://japan.xilinx.com/cgi-bin/docs/rdoc?v=2017.2;d=ug1118-vivado-creating-packaging-custom-ip.pdf



18. Khronos Group ウェブページ: OpenCL 規格の資料

19. Alpha Data ウェブページ: ADM-PCIE-7V3 カードの資料

20. Pico Computing ウェブページ: M-505-K325T カードおよび EX400 カードの資料

お読みください: 重要な法的通知お読みください: 重要な法的通知

本通知に基づいて貴殿または貴社 (本通知の被通知者が個人の場合には「貴殿」、法人その他の団体

の場合には「貴社」。以下同じ) に開示される情報 (以下「本情報」といいます) は、ザイリンクスの製品を

選択および使用することのためにのみ提供されます。適用される法律が許容する最大限の範囲で、(1)

本情報は「現状有姿」、およびすべて受領者の責任で (with all faults) という状態で提供され、ザイリンク

スは、本通知をもって、明示、黙示、法定を問わず (商品性、非侵害、特定目的適合性の保証を含みま

すがこれらに限られません)、すべての保証および条件を負わない (否認する) ものとします。また、(2)

ザイリンクスは、本情報 (貴殿または貴社による本情報の使用を含む) に関係し、起因し、関連する、い

かなる種類・性質の損失または損害についても、責任を負わない (契約上、不法行為上 (過失の場合を

含む)、その他のいかなる責任の法理によるかを問わない) ものとし、当該損失または損害には、直接、

間接、特別、付随的、結果的な損失または損害 (第三者が起こした行為の結果被った、データ、利益、

業務上の信用の損失、その他あらゆる種類の損失や損害を含みます) が含まれるものとし、それは、た

とえ当該損害や損失が合理的に予見可能であったり、ザイリンクスがそれらの可能性について助言を受

けていた場合であったとしても同様です。ザイリンクスは、本情報に含まれるいかなる誤りも訂正する義

務を負わず、本情報または製品仕様のアップデートを貴殿または貴社に知らせる義務も負いません。事

前の書面による同意のない限り、貴殿または貴社は本情報を再生産、変更、頒布、または公に展示して

はなりません。一定の製品は、ザイリンクスの限定的保証の諸条件に従うこととなるので、

https://japan.xilinx.com/legal.htm#tos で見られるザイリンクスの販売条件を参照してください。IP コア

は、ザイリンクスが貴殿または貴社に付与したライセンスに含まれる保証と補助的条件に従うことになりま

す。ザイリンクスの製品は、フェイルセーフとして、または、フェイルセーフの動作を要求するアプリケー

ションに使用するために、設計されたり意図されたりしていません。そのような重大なアプリケーションに

ザイリンクスの製品を使用する場合のリスクと責任は、貴殿または貴社が単独で負うものです。

https://japan.xilinx.com/legal.htm#tos で見られるザイリンクスの販売条件を参照してください。

自動車用のアプリケーションの免責条項自動車用のアプリケーションの免責条項

オートモーティブ製品 (製品番号に「XA」が含まれる) は、ISO 26262 自動車用機能安全規格に従った

安全コンセプトまたは余剰性の機能 (「セーフティ設計」) がない限り、エアバッグの展開における使用ま

たは車両の制御に影響するアプリケーション (「セーフティアプリケーション」) における使用は保証され

ていません。顧客は、製品を組み込むすべてのシステムについて、その使用前または提供前に安全を

目的として十分なテストを行うものとします。セーフティ設計なしにセーフティアプリケーションで製品を

使用するリスクはすべて顧客が負い、製品の責任の制限を規定する適用法令および規則にのみ従うも

のとします。

© Copyright 2017 Xilinx, Inc. Xilinx、Xilinx のロゴ、Artix、ISE、Kintex、Spartan、Virtex、Vivado、

Zynq、およびこの文書に含まれるその他の指定されたブランドは、米国およびその他各国のザイリンクス

社の商標です。OpenCL および OpenCL のロゴは Apple Inc. の商標であり、Khronos による許可を受

けて使用されています。PCI、PCIe、および PCI Express は PCI-SIG の商標であり、ライセンスに基づ

いて使用されています。すべてのその他の商標は、それぞれの保有者に帰属します。

付録 A: その他のリソースおよび法的通知



118


http://www.alpha-data.com/

http://www.picocomputing.com/

https://japan.xilinx.com/legal.htm#tos

https://japan.xilinx.com/legal.htm#tos



この資料に関するフィードバックおよびリンクなどの問題につきましては、[email protected]

まで、または各ページの右下にある [フィードバック送信] ボタンをクリックすると表示されるフォームから

お知らせください。フィードバックは日本語で入力可能です。いただきましたご意見を参考に早急に対

応させていただきます。なお、このメールアドレスへのお問い合わせは受け付けておりません。あらかじ

めご了承ください。

付録 A: その他のリソースおよび法的通知



119

mailto:[email protected]



Documents

SDx プラグマ リファレンス ガイド (UG1253SDx プラグマ リファレンス ガイド UG1253 (v2017.2) 2017 年 8 月 16 日 この資料は表記のバージョンの英語版を翻訳したもので、内容に相違が生じる場合には原文を優先します。資

SDx プラグマリファレンスガイド (UG1253SDx プラグマリファレンスガイド UG1253 (v2017.2) 2017 年 8 月 16 日この資料は表記のバージョンの英語版を翻訳したもので、内容に相違が生じる場合には原文を優先します。資