AXI4-Stream インターフェースのReLU 2（CシミュレーションとCコードの合成）

”AXI4-Stream インターフェースのReLU 1（C++ ソースコード）”の続き。

前回は、C++ ソースコードを貼った。今回は、Vivado HLS 2017.4 の relu プロジェクトで C シミュレーションと C コードの合成を行う。

まずは、Vivado HLS 2017.4 の relu プロジェクトを示す。


C シミュレーションを行った。ここでは、ReLU を実行した結果の relu_output.h を出力することを目的としている。


これが、relu_output.h だ。次のマックス・プーリング層への入力となる。
これが、float で演算したときの relu_fout[312][2] だ。ちなみに 312 は畳み込み後の結果の 52 x 6 ピクセルで、2 は畳み込みフィルタの数だ。


2つ目の畳み込みフィルタの出力が 0 になっている。1 個のフィルタでも行けるのかもしれない？
次に、同じ relu_output.h の const ap_fixed<16, 6, AP_TRN, AP_WRAP> relu_out[312][2] を示す。


C コードの合成を行った。結果を示す。


Estimated は 6.47 ns で目標の 10 ns をクリアしている。Latency は 317 クロックで、6 x 52 = 312 から 5 クロックしか増えていない。
リソース使用量は FF が 577 個で、LUT が 1227 個だった。

Analysis 画面を示す。


C5 まである。

これで、C コードの合成は終わりなのだが、最初、relu.cpp の記述が下の様になっていた。
固定小数点数でも 0 は 0.0 と書いたほうが良いかな？と思ってソースコードを書いていた。


これで C コードの合成を行うと、Estimated がオーバーしてしまう。


Latency は、1566 で約 5 倍のクロックがかかっている。その証拠に、Initiation achieved が 5 クロックになっている。
リソース使用量も増えている。

Analysis 画面を示す。


C10 までステートが増えている。

この原因は、relu_ap_dcm_0_no_dsp_64_ip.tcl を開くと分かるが、0.0 と記述したのが、浮動小数点数と認識されているようだ。


下手に 0.0 と書かないで、0 と書いておこう。コンパイラに怒られたらキャストするか、0.0 と書く方が良さそうだ。