FC2カウンター FPGAの部屋 Vivado HLS 2019.2 で krnl_dma_write を作成する2
FC2ブログ

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

FPGAの部屋

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

Vivado HLS 2019.2 で krnl_dma_write を作成する2

Vivado HLS 2019.2 で krnl_dma_write を作成する1”の続き。

Vitis のカーネル間ストーミング接続をテストするために DMA Read カーネル ー ラプラシアン・フィルタ・カーネル ー DMA Write カーネルをストーミング接続するために、前回は DMA Write カーネルを作成したのだが、リソースを消費すぎているのが分かった。今回は、リソース使用量を少なくするように努力してみよう。

PIPELINE 指示子を削除してみた。
streaming_kernel_50_200129.png

この状態で C コードの合成を行った。
streaming_kernel_51_200129.png

合成後の結果は、LUT が 1 % 程度と約 1/20 になった。

C/RTL 協調シミュレーションを行った。Latency は 3828 クロックだった。総ピクセル数は 3072 ピクセルなので、3828 / 3072 ≒ 1.25 クロック / ピクセルになる。あまり性能良くないな。。。
streaming_kernel_52_200129.png

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

AWLEN は 0f で 16 バーストであることが分かる。これは問題ない。WVALID を見ると、 0 に落ちている時間が目立つ。これが問題のようだ。
拡大してみよう。
streaming_kernel_54_200129.png

ストリーム入力も同様にTREADY が落ちているので、これで見てみよう。TREADY の周期は、395 ns となった。
streaming_kernel_55_200129.png

TREDY が 0 に落ちている間は、75 ns なので、395 / ( 395 - 75 ) ≒ 1.23 クロック / ピクセルということになった。先程の C/RTL 協調シミュレーションのクロック / ピクセルの値には初期の設定部分も入っているため、大体合っていると思う。

extern "C" { } を戻して、もう一度、C コードの合成を行って、Export RTL を行った。
streaming_kernel_56_200129.png

Export RTL の結果を示す。
streaming_kernel_57_200129.png

LUT が 11939 個で、FF が 10866 個になっていた。Vivado HLS の見積もりとは違いすぎる。

また、PIPELINE 指示子を有効にしてやってみた。
streaming_kernel_58_200129.png

C コードの合成を行って、C/RTL 協調シミュレーションを行った。
streaming_kernel_59_200129.png

こちらは、 3404 クロックだった。 1.11 クロック / ピクセルとなった。

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

WVALID や TREADY の落ち幅がこちらのほうが少ない。
波形を拡大してみよう。
streaming_kernel_61_200129.png

TREADY の周期は、340 ns だった。
streaming_kernel_62_200129.png

0 に落ちている幅は 20 ns で 4 クロックだった。 340 / (340 - 20) ≒ 1.06 クロック / ピクセルだった。

なぜにこんなにリソースを消費しているのか?だが。
Analysis 画面で見るとステートが 75 ステートあるのだ。
streaming_kernel_64_200130.png

そして、合成で生成された Verilog HDL ファイルの内の dma_write_urem_64bkb.v を見ると、何やら除算しているような?
32 回ループを回っているようだ。
streaming_kernel_65_200130.png

Analysis の Resource Profile を見ても、 dma_write_urem_64bkb が 2 個入っていて、殆どのリソースを消費している。
streaming_kernel_66_200130.png

でも何で除算なのだろう?引き算で行けるんじゃないだろうか?
dma_read も dme_write もラプラシアン・フィルタと違って、AXI4 Master があるので、任意のピクセル数となるとダイナミックに剰余を出したいのかも知れない?

次回は急遽、その解決方法を書いていきたい。
  1. 2020年01月30日 04:12 |
  2. Vitis
  3. | トラックバック:0
  4. | コメント:0

コメント

コメントの投稿


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

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