Vivado HLS 2019.2 の HLS Video Library を使用して resize() を実装する4

”Vivado HLS 2019.2 の HLS Video Library を使用して resize() を実装する3”の続き。

前回は、HLS Video Library の resize を使用して、800 x 600 ピクセルの画像を 60 x 45 ピクセル、100 x 75 ピクセル、200 x 150 ピクセルに縮小できるかどうか？を C シミュレーションですべてできることを確認した。今回は、60 x 45 ピクセル、200 x 150 ピクセルに縮小した時の C コードの合成、 C/RTL 協調シミュレーション、 Export RTL を行った。

800 x 600 ピクセルの画像を 60 x 45 ピクセルに縮小した場合
C コードの合成を行った。


Latency は 503450 クロックだった。これは、 503450 クロック / 480000 ピクセル数 ≒ 1.05 クロック / ピクセルだ。
リソース使用量もそこそこだ。

C/RTL 協調シミュレーションを行った。


Latency は 498437 クロックで、合成レポートよりも小さくなっている。

C/RTL 協調シミュレーションの全体波形を示す。


outs_TVALID が櫛形になっているのが分かる。

もう少し拡大してみた。


outs_TVALID の櫛形の部分が細かいデータ転送が集まっていることが分かる。この塊が画像の 1 行に相当する。

outs_TVALID のデータ転送部分を拡大してみた。


やはり、outs_TVALID が櫛形になっているのが分かる。これは、60 / 800 ピクセルで 1 / 13.3333 であるはずだ。

Export RTL の結果を示す。


CP achieved post-implementation が 4.085 ns で問題ない。

800 x 600 ピクセルの画像を 200 x 150 ピクセルに縮小した場合
C コードの合成を行った。左が200 x 150 ピクセルに縮小した場合のレポートで、右が 60 x 45 ピクセルに縮小した場合のレポートだ。


200 x 150 ピクセルに縮小した場合の方が FF と LUT の使用量が僅かに増えている。
Latency は同じだった。

C/RTL 協調シミュレーションを行った。


Latency は 502637 クロックで、 60 x 45 ピクセルのときよりも多い。

C/RTL 協調シミュレーションの波形を示す。


1 / 13.33333 から 1 / 4 の縮小率になったので、 outs_TVALID の櫛形の間隔が狭い。

拡大してみよう。


やはり、outs_TVALID の櫛形の部分が細かいデータ転送が集まっていることが分かる。

outs_TVALID のデータ転送部分を拡大してみた。


データ転送は 4 クロックに 1 回であることが分かる。

Export RTL を行った。


Export RTL の結果は、 60 x 45 ピクセルに縮小した場合と全く同じだ。。。興味深い。

800 x 600 ピクセルの画像を 200 x 150 ピクセルに縮小した場合で、C コードの合成結果を HLS Video Library と xfOpenCV とで比較してみよう。左が HLS Video Library で、右が xfOpenCV での結果だ。


Latency は HLS Video Library が 503450 クロックで、 xfOpenCV が 487696 クロックだった。
リソース使用量の差を表にする。


xfOpenCV の方が BRAM_18K を除くと HLS Video Library よりもリソース使用量は少ない。

xfOpenCV と HLS Video Library は適材適所で良いかもしれない。