”
axis2xf8uc3vflip IP を Vitis HLS 2020.2 で作成する1”で、vflip の axis2xf8uc8 は dma_write 関数の for ループの PIPELINE 指示子に rewind オプションを付加すると”
Vitis Vision Library でカメラ画像にメディアン・フィルタをかけてディスプレイに出力する8(aixs2xf8uc3 IP その4)”の様にリソース使用量が 8 倍以上になってしまったのだが、その原因を追求することにした。
まずは、 dma_write 関数の for ループの PIPELINE 指示子をディレクティブ・ファイルに変更して、 solution1 が rewind オプションを付けない場合とした。
solution2 を rewind オプションを付けた場合とした。
solution2 も C コードの合成を行って、ソリューションごとの比較を行った。
min のレイテンシは、solution1 の方が小さいが、max のレイテンシは solution2 の方が小さい。
FF 、 LUT の使用量は圧倒的に solution2 の方が大きい。
solution1 の syn/verilog のファイルを示す。
solution2 の syn/verilog のファイルの一部を示す。
axis2xf8uc3vflip_mul_32ns_31ns_63_2_1.v と axis2xf8uc3vflip_urem_63ns_31ns_63_67_1.v が増えているようだ。
axis2xf8uc3vflip_mul_32ns_31ns_63_2_1.v のコードの一部を示す。
乗算器のようだ。
axis2xf8uc3vflip_urem_63ns_31ns_63_67_1.v のコードの一部を示す。
割り算器のようだ。
Analysis 画面でリソース使用量を調べる。
全体だと dma_write 関数のリソース使用量が多い。
dma_write 関数内でのリソース使用量を調べた。
urem_63ns_31ns_63_67_1 が 2 個インスタンスされていて、リソース使用量増加のほとんどを占めているのが分かった。
それじゃ何で、axis2xf8uc3vflip_urem_63ns_31ns_63_67_1.v が作られて呼ばれているのか?を調べようとして C/RTL 協調シミュレーションを solution2 でやってみたのだが、シミュレーションで urem_63ns_31ns_63_67_1 がどのように使用されているか?を確認しようとした。
C/RTL 協調シミュレーションを soluiton2 でやると、32 GB の Ubuntu マシンのメモリを食いつぶして、Ubuntu 18.04 パソコンの反応が極端に遅くなってしまう。解析は無理のようだ。ということであきらめた。。。orz
(追加)
Vitis HLS でやっているが、それじゃ Vivado HLS はどうなんだろう?ということで、Vivado HLS 2019.2 で同様にやってみた。
結果を示す。
Vivado HLS 2019.2 だと Vitis HLS 2020.2 の結果とリソース使用量が逆転してる。
solution1 が極端にリソース使用量が大きく、 solution2 はリソース使用量が少ない。
なお、ソースコードはほぼ同一だが、AXI4-Stream の指示子だけエラーがでたので、Vivado HLS 用に変更してある。
- 2021年05月10日 04:24 |
- Vitis HLS
-
| トラックバック:0
-
| コメント:0