FC2カウンター FPGAの部屋 Vivado HLS 2014.4 で合成したラプラシアンフィルタIPの高速化6(動作周波数のチューンナップ)
fc2ブログ

FPGAやCPLDの話題やFPGA用のツールの話題などです。 マニアックです。 日記も書きます。

FPGAの部屋

FPGAの部屋の有用と思われるコンテンツのまとめサイトを作りました。Xilinx ISEの初心者の方には、FPGAリテラシーおよびチュートリアルのページをお勧めいたします。

Vivado HLS 2014.4 で合成したラプラシアンフィルタIPの高速化6(動作周波数のチューンナップ)

Vivado HLS 2014.4 で合成したラプラシアンフィルタIPの高速化4(tu1978さんのCソースコード)
Vivado HLS 2014.4 で合成したラプラシアンフィルタIPの高速化5(tu1978さんのCソースコードを実機で検証)
で、tu1978さんが教えてくれたCソースコードを元に、少しCソースコードをチューンナップしてみた。
この、ラプラシアンフィルタIP は、ラプラシアンフィルタ処理時間のみを計測してみたところ、約 20.0 ms だったので、60fps の16.7 ms までもう少しのところだ。そこで、動作周波数を上げて 16.7 ms を目指すことにした。
現在の動作周波数は 100MHz なので、 周期は 10 ns x (16.7 / 20.0) = 8.35 ns になれば良いことになる。動作周波数は約120 MHz となる。

ここで、 tu1978 さんの高速化ラプラシアンフィルタIP の遅延時間を 8 ns に設定してみた。
やり方は、Soultion メニューのSolution Settings... を選択して、表示されたダイアログの左側のウインドウでSynthesis を選択する。
Clock Period: を 8 に設定して、OKボタンをクリックする。
lap_fil_hls_14_4_62_150401.png

この設定で、高位合成を行うと、8 ns の制約に対して、見積もり値は、11.47 ns になってしまった。
lap_fil_hls_14_4_63_150401.png

Clock Period: を 9 に設定しても見積もり値は設定値を満足しない。
lap_fil_hls_14_4_64_150401.png

結局、7 ns とか動作周波数が速い方もいろいろと試して見たが、10 ns の制約の時が一番遅延時間が短かった。
tu1978 さんの高速化ラプラシアンフィルタIP については、動作周波数を高くすることで高速化することはできそうもない。

次に、PIPELINEディレクティブに依って高速化したラプラシアンフィルタIP の動作周波数を高くしてみよう。こちらは、tu1978 さんの高速化ラプラシアンフィルタIP ほど最適化されていない。
Vivado HLS 2014.4 で合成したラプラシアンフィルタIPの高速化2(PIPELINEディレクティブ)
Vivado HLS 2014.4 で合成したラプラシアンフィルタIPの高速化3(PIPELINEディレクティブを実機テスト)
を参照下さい。

このVivado HLS 2014.4 のプロジェクトで、Solution Settingsダイアログの Clock Period: を 8 に設定して、高位合成を行った。
lap_fil_hls_14_4_65_150401.png

8 ns の制約に対して、見積もり値は 7 ns で制約を満たしている。

次に、制約を 4 ns にしてみた。動作周波数は 250MHz だ。これに対しても高位合成の結果の見積もり値は 3.94 ns で制約を満たしている。
lap_fil_hls_14_4_66_150401.png

PIPELINEディレクティブを2つ追加した前回の 100 MHz 動作のの高位合成結果の内のUtilization Estimates を示す。

================================================================
== Utilization Estimates
================================================================
* Summary:
+-----------------+---------+-------+-------+-------+
| Name | BRAM_18K| DSP48E| FF | LUT |
+-----------------+---------+-------+-------+-------+
|Expression | -| 11| 0| 1080|
|FIFO | -| -| -| -|
|Instance | 0| -| 1168| 1392|
|Memory | 10| -| 0| 0|
|Multiplexer | -| -| -| 385|
|Register | -| -| 1097| 34|
+-----------------+---------+-------+-------+-------+
|Total | 10| 11| 2265| 2891|
+-----------------+---------+-------+-------+-------+
|Available | 120| 80| 35200| 17600|
+-----------------+---------+-------+-------+-------+
|Utilization (%) | 8| 13| 6| 16|
+-----------------+---------+-------+-------+-------+


PIPELINEディレクティブを2つ追加した前回の 250 MHz 動作のの高位合成結果の内のUtilization Estimates を示す。

================================================================
== Utilization Estimates
================================================================
* Summary:
+-----------------+---------+-------+-------+-------+
| Name | BRAM_18K| DSP48E| FF | LUT |
+-----------------+---------+-------+-------+-------+
|Expression | -| -| 0| 1079|
|FIFO | -| -| -| -|
|Instance | 0| 11| 1168| 1392|
|Memory | 10| -| 0| 0|
|Multiplexer | -| -| -| 431|
|Register | -| -| 1477| 50|
+-----------------+---------+-------+-------+-------+
|Total | 10| 11| 2645| 2952|
+-----------------+---------+-------+-------+-------+
|Available | 120| 80| 35200| 17600|
+-----------------+---------+-------+-------+-------+
|Utilization (%) | 8| 13| 7| 16|
+-----------------+---------+-------+-------+-------+


リソースは少し増えたくらいのようだ。

動作周波数は 2.5 倍になった。結構、これも良いかもしれない?動作周波数を高くすることができる。
レイテンシは増えていると思う。どのくらい増えているのかを確認するためにシミュレーションを行った。(制約を 4 ns にした場合、動作周波数は 250MHz )
但し、シミュレーション時のラプラシアンフィルタIP のクロックは今まで通りに 100 MHz だ。
シミュレーション結果を下に示す。
lap_fil_hls_14_4_67_150402.png

DMA Write の間隔が 169.8 us になった。以前の 100MHz 動作の場合は 91.86 us だった
ラプラシアンフィルタ処理のみの時間を計算してみよう。

169.8 us / 2.5 * 600 行 = 40752 us ≒ 40.8 ms

となった。
100MHzでのラプラシアンフィルタ処理のみの時間は、55.12 ms だったので、1.35倍速くなった。

動作周波数は2.5倍だったのに、レイテンシが増えて、実際の速度向上は 1.35倍だったのが残念だ。パイプライン化できていないところがかなりあるのだと思う。完全にパイプライン化できていれば、パイプラインのレイテンシのみが増えるだけになるだろう?
  1. 2015年04月02日 19:55 |
  2. Vivado HLS
  3. | トラックバック:0
  4. | コメント:2

コメント

古いデバイスだと物理的な配置がからむBRAMとかに制約をかけて使用すると、クリティカルなパスが増えて高速化できないっていうのがありました。
VHDLとかで記述する時はFFでラッチしてから使う方法で回避できましたが高位合成ではどうなんでしょう。

高速化しようとすると可読性が悪くなり画像処理の本末からは外れてしまいますし。
最終的な仕様が決まっている仕事とかならかりかりにチューンできるんですが....
書いた本人にさえ後で読み取れないソースを納品したこともありますw
  1. 2015/04/03(金) 09:26:08 |
  2. URL |
  3. おる #-
  4. [ 編集 ]

おるさん、お返事が遅れてすみません。
高位合成がどうなっているか?にとても興味があります。と言っても中身を解析する元気は無いし、実機で検証してテスト出来たら?と思っています。

仰るとおりですね。
  1. 2015/04/04(土) 06:45:01 |
  2. URL |
  3. marsee #f1oWVgn2
  4. [ 編集 ]

コメントの投稿


管理者にだけ表示を許可する

トラックバック URL
https://marsee101.blog.fc2.com/tb.php/3110-0baade96
この記事にトラックバックする(FC2ブログユーザー)